최근 우리 회사의 거의 모든 소스 코드를 단일 솔루션으로 마이그레이션했습니다.
왜?
원래 수십 개의 솔루션이있었습니다. 솔루션의 일부 프로젝트는 다른 프로젝트의 프로젝트를 재사용했으며 아무도 패키지 관리자 사용에 신경 쓰지 않았습니다. 거의 모든 곳에서 사용되는 프로젝트를 실질적으로 변경 한 날에는 다음 며칠 또는 몇 주 동안 회사 전체에서 몇 시간과 몇 시간의 손실 된 작업이 예상됩니다. 최악의 부분은 당신이 알지도 할 수 없다는 것입니다 무엇인지 정확히 변화에 의해 영향을받을 것입니다.
모든 코드를 하나의 솔루션으로 병합하는 것이 대안이었습니다. 현재로서는 잘 작동하고 종속성을 쉽게 따라갈 수 있습니다. 메소드를 수정하고이 변경이 코드베이스의 어느 곳에있을 수있는 영향을 추적하고 싶습니까? Visual Studio는이를 쉽게 수행 할 수 있습니다. 저에게는 성공입니다.
지속적인 통합도 더욱 쉬워졌습니다. 컴파일하고 배포 할 수있는 솔루션입니다. 거의 구성 할 것이 없습니다.
확장 가능합니까?
성능면에서 Visual Studio에 매우 놀랐습니다 . 나는 그것이 50 프로젝트와 같은 해결책으로 울기 시작할 것이라고 생각했습니다. 현재 200 개가 넘는 프로젝트가 있습니다. Visual Studio는 그 중 20 개만있는 것처럼 관리 할 수있을 정도로 확장 가능한 것으로 보였습니다. 예, 시간이 걸리는 것들이 있습니다. 코드 계약, 코드 분석 등 기본적으로 모든 프로젝트를 다시 컴파일하면 시간이 오래 걸릴 것으로 예상됩니다. 그러나 아무도 10 개의 빠른 속도로 200 개의 프로젝트를 컴파일 할 것으로 예상하지 않으며, 그렇게하지 말아야합니다. 이것이 Continuous Integration Server의 역할입니다. 시작 시간 (콜드 스타트 후 솔루션로드)은 매우 빠릅니다 . 아마도 10 개의 프로젝트만큼 빠르지는 않지만 5 년 이상 전에 구입 한 기계에서 20 초 미만이면 여전히 수용 가능합니다.
더 나아가서 프로젝트를 체계적으로 언로드 하는 것이 좋습니다 (프로젝트가 솔루션 내의 디렉토리에 구성되어 있으면 정말 쉽습니다). 누군가 3 개의 프로젝트 만로드해야하는 작업을 수행하는 경우 200 개의 프로젝트를 모두로드 할 필요는 없습니다 (물론 종속성이 영향을받지 않는 한).
버전 제어도 예상대로 작동합니다 (중요하다면 SVN 서버를 사용하고 있습니다). 예를 들어, 수십 명의 개발자가 자주 코드를 커밋하는 실제 동시 환경에서 일하지는 않았지만 문제가 너무 많지는 않을 것이라고 생각합니다. 많은 개발자가 동시에 새 프로젝트를 추가하는 경우를주의하십시오. .sln 파일을 병합하는 것이 가장 쉬운 방법은 아닙니다.
결론
다시 결정을 내려야한다면 :
여전히 모든 것을 단일 솔루션으로 마이그레이션합니다. 이렇게하면 종속성이 깨지는 고통을 크게 줄일 수 있으며이 이점만으로도 그만한 가치가 있습니다. 모든 코드를 중앙에 배치하는 것도 좋은 생각입니다. 이를 통해 예를 들어 Visual Studio 내에서 무언가를 검색 할 수 있습니다. 또한 약한 두 개의 관련 프로젝트에서 작업 할 수 있지만 여전히 하나의 Visual Studio 창이 열려 있습니다.
또한 NuGet과 개인 NuGet 서버를 호스팅하는 기능에 대해 조금 더 연구했습니다. NuGet을 통해 종속성을 관리하면 몇 가지 프로젝트를 공통 솔루션으로 병합하지 않을 때 일부 문제를 해결할 수 있습니다. 개인적으로, 나는 그런 경우가 없었지만 다른 회사가있을 것이라고 상상합니다.
마지막으로 모든 개발자를위한 SSD에 투자하면 큰 차이를 만들 수 있습니다. 그러나 필요하지 않으며 필자의 경우 코드베이스는 여전히 일반 하드 드라이브에 저장됩니다.