2013-11-25 4 views
0

우리의 소규모 분산 팀은 프로젝트에서 NuGet 패키지를 사용합니다. 이 패키지에는 현재 릴리스의 버그가 있습니다. 불행히도 패키지는 publish debug symbols and source이 아니므로 &을 최신 소스로 빌드하고 NuGet을 통해 프로젝트를 제거하고 방금 빌드 한 프로젝트에 임시 참조를 추가했습니다.NuGet 패키지 패치를 효율적으로 통합

밝혀졌습니다. 문제는 최신 코드베이스에서 수정되었습니다.

이 특정 프로젝트는 6 개월마다 NuGet에 대한 업데이트 만 릴리스하는 것으로 보입니다.

다음 릴리스가 출시 될 때까지는 버그가 수정 된 코드 버전을 사용해야합니다.

하나의 옵션은 소스 코드를 소스 코드 저장소로 확인하고 프로젝트 참조 (NuGet 참조가 아닌)를 유지하는 것입니다. 본질적으로 내부 유틸리티 프로젝트로 간주합니다.

"오래된 학교"라고 느껴진다.

NuGet 인프라를 사용하여 이러한 상황을 관리하는 더 좋은 방법이 있습니까?

답변

3

하나의 옵션은 업데이트 된 코드로 자신의 NuGet 패키지를 만드는 것입니다. 그런 다음 새로운 로컬 패키지 소스를 추가하십시오 (파일 공유를 만들고 거기에 .nupkg 파일을 저장하십시오). NuGet이 온라인으로보기 전에 패키지를 사용하게하려면 로컬 패키지 소스를 공식 패키지 소스보다 우선 순위를 높여야합니다.

특히 NuGet 패키지를 로컬 저장소에 복사하는 것이 좋습니다. 특히 패키지 복원을 사용하는 경우에 좋습니다. 이렇게하면 nuget.org에 의존하지 않고 항상 가동 상태를 유지할 수 있습니다 (다운 타임이 여러 번 발생했습니다).

마지막 단점은 업데이트 된 패키지가 nuget.org에 최종적으로 게시 될 때 패키지 원본을 지정하지 않으면 Update-Package가 새 패키지를 선택하지 않는다는 것입니다.

어쨌든 업데이트 된 패키지를 기다리는 동안 계속해서 NuGet을 사용할 수 있습니다.

+0

Google 팀이 분산되어 있습니다 (공유 파일 서버 없음). 로컬 패키지에 파일 공유 이외의 메커니즘을 사용하는 것이 가능합니까 (그리고 상당히 간단합니까)? –

+0

myget.org를 사용해 볼 수 있습니다. NuGet 패키지를 호스트 할 무료 플랜이 있습니다. NuGet 갤러리를 직접 열 수도 있습니다. https://github.com/NuGet/NuGetGallery – Kiliman