2
여러 프로젝트에서 잠재적으로 재사용 할 수있는 사내 .NET 라이브러리를 관리하는 합리적인 방법을 찾아야합니다. 몇 시간 동안이 문제에 대한 인터넷 검색 및 생각을 통해 다음과 같은 결론을 이끌어 냈습니다.이 방법은 공용 라이브러리를 관리하는 좋은 방법입니까?
우리가 보유한 각 라이브러리의 각 버전에 대해 빌드 서버 (Jenkins) . 라이브러리가 성공적으로 빌드되면 빌드 출력 (대개 .dll 파일)이 공통 네트워크 저장소에 복사됩니다. 이 저장소의 구조는 다음과 유사 할 수 있습니다 :
-libraryA
-1.0
-libraryA_1.0.dll
-1.1
-libraryA_1.1.dll
-libraryB
-1.0
-libraryB_1.0.dll
특히 프로젝트 종속성을 저장하는 데 사용되는 폴더에이 저장소에서 필요한 라이브러리를 복사합니다 간단한 .bat 파일과 함께 올 것이다 라이브러리를 사용하고자하는 각 프로젝트 . 그런 다음이 폴더에서 종속성을 참조합니다. 예제 프로젝트는 다음과 같이 수 :
-project
-src
-dependencies
-libraryB
-1.0
-libraryB_1.0.dll
-getDependencies.bat
getDependencies.bat
dependencies 폴더의 내용을 삭제하고 저장소에서 라이브러리의 새로운 복사본을 얻을 것이다. Jenkins에서 프로젝트를 빌드하기 전에 실행됩니다.
dependencies 폴더는 결코 SVN에 커밋되지 않습니다.
일부 대안 I도 고려했습니다
- 대신 간단한 저장소의 공급 NuGet 사용자 정의를 사용. 내가 알기 엔 아직 우리 회사에서 사용중인 Visual Studio 2008에서 NuGet을 사용하는 것은 quite a pain이기 때문에 이것을 버렸습니다. 그렇지 않으면 이것이 내가 선호하는 해결책이 될 것입니다.
- svn : externals를 사용하여 종속성을 해결합니다. 두 가지 이유로이 점이 마음에 들지 않습니다.
- 위의 솔루션에서와 같이 이진 파일 만 처리하는 대신 svn : externals는 소스 코드를 처리해야합니다. 필자는 소스 코드로 라이브러리를 사용하는 모든 프로젝트를 혼란스럽게하고 싶지 않습니다.
- 은 어떻게 든, 관리 종속 SVN 사용하여바로을 느끼지 않는다 (적어도 내 생각에, 사용되어야한다 버전 관리합니다). 또한 svn : externals은 특정 프로젝트의 종속성을 추적하기 어렵게 만들고 프로젝트를 SVN에 너무 의존하게 만듭니다.
사람이 내 선호하는 솔루션 또는 당신이 잘못 생각하는 단지 아무것도 잠재적 인 문제를 지적 할 수 있다면 정말 감사하겠습니다. 또한 휠을 재발견하려고 시도하고 이미이 표준화 된 솔루션이 사용되는 경우 (언급 한 대안 제외) 제발 주저하지 말고 저에게 계몽하십시오 :
대단히 고마워요!
svn : externals에서 멀리 떨어져있는 것이 현명합니다. 그들은 처음에 멋지게 보일지 모르지만, 일단 당신이 그들에게 의존하게되면, 내가 발견 한 다른 소스 제어 시스템에는 상응하는 기능이 없으므로 SVN에 고정됩니다. 적어도 정확히 동일하게 작동하는 것은 없습니다. 우리는 현재의 직장에서 외부 접근법을 사용합니다. – CodingWithSpike
그래, 우리 가게에서 SVN에서 git로 옮기는 것에 대한 몇 가지 이야기가 있었기 때문에 나는 SVN에 너무 의존하고 싶지 않다. –