우리 시스템은 많은 .NET 웹 사이트, 클래스 라이브러리 및 MSSQL 데이터베이스로 구성됩니다. SVN을 소스 제어에 사용하고 TeamCity를 사용하여 테스트 서버에 자동으로 빌드합니다.릴리스의 종속성 관리에 대한 팁?
저희 팀은 일반적으로 한 번에 4 개 또는 5 개의 프로젝트를 진행하고 있습니다. 우리는 매 2-4 주마다 많은 변화를 큰 규모로 전개하려고 노력합니다.
제 문제는 롤아웃의 모든 종속성을 추적하는 것입니다. 예 :
웹 사이트 A는 클래스 라이브러리 B의 브랜치 X를 롤아웃하고 구성 업데이트 Y 및 Z와 데이터베이스 업데이트 D가 필요한 클래스 라이브러리 트렁크 C에 대해 차례로 빌드 할 때까지 사용할 수 없습니다. Migration Script E가 필요합니다 ...
각 개발자의 프로젝트가 실제로 다른 사람과 호환되는지 확인하고 같은 버전에 대비하여 빌드하는 것과 같이 더 복잡합니다. 예, 기술적 인 문제만큼이나 관리상의 문제입니다.
현재 우리의 비 최적의 솔루션입니다 :
- 우리는 꽤 확신 때까지 아직
- 라이브 출시를 계획 할 때 우리의 기억과 직관에 의존 사라하지 않은 기능을 나열하는 화이트 보드, 우리는 모든 것을 생각했습니다 ...
- 우리의 스테이징 환경에서 드라이 런. 좋은 징조이지만, Staging이 Live와 동기화되어 100 %인지 확신 할 수없는 경우가 종종 있습니다. 제가 해결하고자하는 문제의 일부입니다.
- 롤아웃 당일에 어느 정도 날개가 붙어 있습니다.
지금까지 그렇게 좋았습니다. 그러나 우리 시스템이 성장함에 따라 더 많은 유연성을 제공하는보다 과학적인 릴리스 관리 시스템을 원합니다. 단일 변경 또는 버그 수정을 자체적으로 수행 할 수 있고, 다른 것을 해치지 않을 것이라는 지식에서 안전 할 수 있습니다.
나는 최상의 솔루션이 어떤 종류의 버전 번호 체계를 포함하고 있으며 아마도 프로젝트 관리 도구를 사용하고 있다고 생각합니다. 우리는 신생 기업이기 때문에 종교적으로 엄격한 프로세스를 고집하지 않고 열심히 일하지는 않습니다. 그러나 가치가있는 것보다 많은 오버 헤드를 추가하지 않는다면 시작할 수 있습니다.
이 문제를 해결 한 다른 팀의 조언을 듣고 싶습니다.
프로젝트는 단일 저장소에 별도의 폴더에 있습니다. 상호 의존성의 예는 웹 사이트, 모바일 사이트 및 API가 모두 동일한 비즈니스 로직 라이브러리를 참조합니다. 다른 프로젝트와 마찬가지로 동일한 유틸리티 라이브러리를 참조하십시오. 우리가 CI를 완전히 활용하지 않고 있다는 점에 동의하고 안정적인 지점이라는 생각을 좋아합니다. 그러나 그것은 코드를 관리합니다. 데이터베이스, 구성, 마이그레이션 스크립트 및 기타 요인은 어떻습니까? – realworldcoder
@Andrew :이 모든 것이 코드 옆에 svn repo에 속합니다. –