우리 회사에는 많은 솔루션이 있습니다. 대부분은 여러 기능 (로깅, 캐싱, 데이터 액세스)을위한 공통 라이브러리 세트를 사용합니다.프로젝트간에 공통 라이브러리 관리 및 버전 관리
내가 가진 질문은 어떻게 제대로 관리되는지 확인하는 것입니다. 병합 및 지사 필요가 없습니다 :
참조 창
장점을 APP1에서 직접 추적 프로젝트
.단점 : 코드를 다시 컴파일 할 때 시스템에 문제가 발생할 수 있습니다. 이후 지금은 최신 버전으로 컴파일됩니다.
각 프로젝트마다 추적을 분기하고 한 번씩 병합하십시오. 장단점은 주먹 옵션과 정반대입니다.
나는 아이디어에 완전히 매료되어 있을지 모르지만 더 나은 방법이 있어야한다고 확신합니다.
우리가 여기서하는 일은 계속해서 공통 라이브러리를 지속적으로 업데이트하고 개선하는 것입니다. 그런 다음 우리가 편안하게 사용할 수 있고 응용 프로그램에서 사용해야 할 시점에 이르면 주요 버전 또는 부 버전 변경 횟수에 따라 설치 프로그램을 빌드하고 소스 제어에 레이블을 지정하십시오.
우리는 이전 응용 프로그램을 변경해야 할 때 최신 버전으로 업그레이드함으로써 기존 응용 프로그램을 처리합니다.
공용 라이브러리 용 SDK 및 재배포 가능 설치 프로그램을 빌드합니다. SDK는 모든 개발자에게 배포되며 소스 코드, 템플릿, 설명서를 포함하고 드라이브에 DLL을 넣은 다음 해당 GAC에 DLL을 저장합니다. 재배포 가능 패키지는 DLL을 GAC에 넣기 만하면됩니다. 우리는 서버에 재배포 가능 패키지를 설치합니다.
우리는 재배포 가능하지 않은 방법으로 곧 갈 것입니다. 우리는 SDK 만 생산할 것이며, 그 SDK에서 공통 라이브러리를위한 병합 모듈이 될 것입니다. 개발자가 라이브러리를 사용하고 프로덕션으로 앱을 옮길 준비가되면 설치 프로그램을 빌드하고 해당 설치 프로그램에 병합 모듈을 포함합니다. 그러면 응용 프로그램 배포에 항상 올바른 버전의 공용 라이브러리가 있고 먼저 서버에 설치하는 것에 대해 걱정할 필요가 없습니다.
환경에 대해 알지 못하므로 이러한 기술이 어떻게 작동 할 지 모르지만 지금 당장은 잘 작동합니다.
하나의 중요한 차이점은 서버의 두 하위 프로젝트가 다른 버전의 "공유"코드를 실행하는 경우 중요한지 여부입니다. 도서관, 괜찮을거야. 공유 서비스? 아마도 그렇지 않습니다. 후자의 경우 모든 사람이 동기화되지 않기 때문에 분기가 훨씬 더 어려워집니다. 서로 다른 버전을 나란히 배치 할 수 있다면 변경 방법을 적용 할 때 각 프로젝트/영역에 더 많은 제어 권한을 부여하기 때문에 분기 방법을 사용합니다.
언급하지 않은 옵션 중 하나는 소스 컨트롤에 공통 프로젝트 용 바이너리를 저장하고 바이너리 참조를 사용하는 것입니다. 이것은 두 번째 옵션 (분기)과 비슷한 속성을가집니다. 잘 알려진 (또는 최소한 컴파일 가능한) 버전 만 사용할 수 있기 때문에 직접 프로젝트 참조보다 문제가 적습니다. 한 가지 단점은 공유 프로젝트를 사용하는 프로젝트와 병렬로 편집하는 것이 약간 힘들 수 있다는 것입니다.
이렇게하면 큰 솔루션에서 혼란을 피할 수 있습니다.
사용자 지정 빌드 후 작업을 사용하여 공유 프로젝트에서 CI 빌드를 설정하고 새 바이너리를 체크인하는 등의 설정을 통해 현명한 작업을 수행 할 수도 있습니다.
나는 당신의 다른 프로젝트의 팀이 프로젝트의 필요에 따라 사용하는 공통 lib2의 버전을 결정할 수 있다고 덧붙였다. –