프로젝트 참조 v NuGet 종속성

Question

외부 바이너리 (예 : Moq, NUnit) 및 공유 기능이 포함 된 내부 라이브러리 프로젝트 모두에 대해 NuGet을 소프트웨어 개발 프로세스에 도입하는 중입니다.

TeamCity는 내부 라이브러리 프로젝트에서 NuGet 패키지를 생성하여 로컬 저장소에 게시합니다. 수정 된 솔루션 파일은 로컬 저장소를 사용하여 NuGet 패키지에 액세스합니다.

는 다음의 소스 코드 솔루션을 고려

1. Company.Interfaces.sln는 Company.Interfaces.1.2.3.7654.nupkg을 구축합니다.
2. Company.Common.sln는 NuGet 패키지 통해 Company.Interfaces에 대한 참조를 포함하며 Company.Interfaces.1.2.3.7654 종속성 포함하여, Company.Common.1.1.1.7655.nupkg을 만든다.
3. Company.DataAccess.sln은 Company.Common nupkg를 사용하여 Company.Interfaces 및 Company.Common을 참조로 추가합니다. 종속 구성 요소로 Company.Common.1.1.1.7655를 포함하여 Company.DataAccess.1.0.8.7660.nupkg을 빌드합니다.
4. Company.Product.A은 세 라이브러리 프로젝트 (모두 Company.DataAccess NuGet 패키지 선택)에 대한 참조를 포함하는 웹 사이트 솔루션입니다.

질문 :

Company.Interfaces에 소스 코드 변경이있는 경우, 나는 항상 패키지 번호를 다시 중간 패키지 (Company.Common 및 Company.DataAccess)을 재건하고 업데이트해야 할 Company.Product.A에서?

또는 소스 코드 변경 여부에 따라 달라집니다 않습니다는

• 버그 수정, 또는
• 새로운 기능 또는
• 주요 변경했다?

실제로는 8 레벨의 종속 라이브러리 패키지가 있습니다. 필요한 경우 전체 패키지 트리를 업데이트하기위한 툴링 지원이 있습니까?

시맨틱 버전 관리에 대해 알고 있습니다.

우리는 VS2012, C# 4.0, TeamCity 7.1.5를 사용하고 있습니다.

Answer 1

일찍 테스트하려면 각 체크인의 모든 것을 업데이트하는 것이 좋습니다.

설명하는 것은 이슈 종속성 (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) 및 "빌드 완료"빌드 트리거 (또는 "Nuget 종속성 트리거")를 사용하여 쉽게 관리 할 수 ​​있습니다.

Answer 2

기본 프로젝트에 우리 자신의 빌드 구성을 작성했습니다 (Company.Interfaces).sln이 경우) 한 번에 전체 트리를 작성하고 업데이트합니다. 업데이트 된 packages.config 파일과 .nuspec 파일을 체크인합니다. 처음에는 과도한 소리가 들릴지 모르지만 시간 절약이 얼마나 많은 시간을 우리에게 줄 수 있었는지는 말할 수 없습니다.

주의해야 할 사항 : 우리가 작성한 스크립트는 체인이 중간에 오류가 발생하더라도 파일을 검사하여 로컬 시스템에서 수정하고 수정 사항을 확인한 다음 게시를 다시 시작합니다.