우리는 여러 팀이 관리하는 다양한 솔루션/프로젝트를 보유하고 있습니다. 우리의 솔루션은 다른 팀이 소유하고있는 여러 프로젝트를 참조해야합니다. 이러한 의존성을 프로젝트 참조로 추가하고 싶지는 않습니다. 왜냐하면 우리는이 코드를 수정하려고하지 않고 그냥 사용하기를 원하기 때문입니다. 또한 우리는 이미 우리 솔루션에서 꽤 많은 프로젝트를 가지고 있으며 Visual Studio의 속도를 늦추므로 더 많은 것을 추가하고 싶지 않습니다. 따라서 우리는 이러한 프로젝트를 별도의 솔루션으로 구축하고이를 솔루션에 대한 파일 참조로 추가합니다.내부 타사 종속성 관리
제 질문은 사람들이 이러한 유형의 종속성을 어떻게 관리합니까? 프로젝트의 변경 사항을 찾아서 빌드하고 DLL을 소스 제어로 확인한 후 다른 타사 종속성처럼 처리하는 자동화 된 프로세스가 있습니까? 이 작업을 수행하는 권장 방법이 있습니까?
하나의 솔루션은 반드시 찾고자하는 것은 아니지만 각 종속 서브 시스템에서 릴리스를 수행하는 것입니다. 이 릴리스는 MSI 설치 또는 어셈블리의 네트워크 공유 형식 일 수 있습니다. 중요한 변경이 이루어지면 팀에서이를 알리고 설치 또는 스크립트를 실행하여 파일을 복사 할 수 있습니다.
릴리스를 얻은 후에는 프로젝트 저장소 폴더에 복사하는 것에 대해 걱정할 필요없이 GAC에 넣을 수 있습니다.
또 다른 솔루션은 빌드 서버 또는 어떤 종류의 지속적인 통합을 사용하는 경우 빌드 단계 또는 프로세스 단계에서 파일을 준비하는 것입니다. 다른 어떤 팀의 개발자가 새로운 파일을 가져 오거나 스크립트 또는 박쥐 파일을 로컬로 끌어낼 수 있습니다.
수정 - 다른 해결책 왜 이러한 종속성을 갖고 있는지 묻는 것이 가장 좋습니다. 응용 프로그램의 일부를 빌드 할 때 로컬에 실제로 필요합니까? 솔루션의 종속성을 조롱 해 단위 테스트를 코드화하고 빌드하고 실행할 수 있습니까? 실제 응용 프로그램은 DEV/Test/Prod 환경에서이를 연결합니다. 솔루션을 분리하고 자유롭게 유지하면 개별 팀에게 더 나은 솔루션이 될 수 있습니다. 응용 프로그램이 실제 설정에서 실행될 때 통합 및 결합을 그대로 두십시오.
첫 번째 솔루션은 현재 사용중인 솔루션입니다. 나는 팀원이 항상 당신에게 알려주지 않고 당신이 dll의 오래된 버전을 사용하기 때문에 결국이 것을 좋아하지 않는다. CI 솔루션은 현재 고려중인 솔루션이지만 CI가 이러한 종속성을 빌드하여 버전 제어에 반영하도록 고려 중이므로 개발자가 최신 버전을 얻으면 자동으로 가져옵니다. –
이전에 이런 방식으로 팀이 소스 제어에 바이너리를 커밋하는 것을 보았습니다. 그것은 효과가있다. 그러나 일반적으로 바이너리를 SOURCE 컨트롤로 커밋하는 것이 최선의 방법은 아닙니다. –
"내부"및 "타사"직교 용어가 아닌가요? :-) – Gray