지속적인 통합 설정의 철학과 디자인에 대한 도움이 필요합니다.
현재 CI 설정은 buildbot을 사용합니다. 디자인을 시작했을 때 전체 빌드를 한 번에 밤새 실행하도록 맞춤화 된 맞춤형 CI 빌더 (1 년 전 디자인에 참여한 것처럼 엄격하지는 않음)를 물려 받았습니다. 잠시 후, 우리는 이것이 불충분하다고 판단하고 다른 CI 프레임 워크를 탐색하기 시작하여 결국에는 buildbot을 선택했습니다. 빌드 봇으로 전환하는 나의 목표 중 하나는 모든 위즈 뱅 엑스트라를 즐기는 것 외에도 우리가 주문한 야간 건축업자의 부족함을 극복하는 것이었다.
잠시 유머를 가지고 상속받은 것을 설명하겠습니다. 우리 회사의 코드베이스는 거의 150 개의 고유 한 c ++ Windows 응용 프로그램으로, 각각 하나 이상의 내부 라이브러리 (및 타사 라이브러리에도 포함) 중 하나 이상에 종속되어 있습니다. 이러한 라이브러리 중 일부는 상호 의존적이며 해당 라이브러리의 동일한 빌드로 빌드해야하는 종속 응용 프로그램이 있습니다 (서로 관련이 없음). 이러한 애플리케이션 및 라이브러리의 절반은 "레거시"로 간주하고 이식 할 수 없으며 IBM 컴파일러의 고유 한 여러 구성으로 빌드해야하며 ( Compile다른 하위 클래스는 ), 나머지 절반은 Visual Studio로 빌드됩니다.ShellCommandVSS에 대한 지원이 없으므로 s).
우리의 독창적 인 야간 건축업자는 모든 것에 대한 소스를 간단히 가져 와서 특정 순서로 물건을 만들었습니다. 단일 응용 프로그램 만 작성하거나 개정을 선택하거나 항목을 그룹화 할 수있는 방법이 없었습니다. 여러 응용 프로그램을 구축하기 위해 가상 머신을 시작했습니다. 매우 강력하지 않았으며 배포 할 수 없었습니다. 정말 확장 할 수 없었습니다. 빌드 봇에서 이러한 모든 한계를 극복하고 싶었습니다.
원래이 작업을 수행 한 방식은 빌드하려는 각 응용 프로그램 (모두 150ish)에 대한 항목을 만든 다음 다양한 응용 프로그램을 그룹으로 구축 할 수있는 트리거 된 스케줄러를 만든 다음 해당 그룹을 전체 야간 빌드 스케줄러 아래에 포함시키는 것입니다. 이것들은 전용 슬레이브 (더 이상 가상 머신 chicanery가 아님)에서 실행될 수 있으며 원하는 경우 단순히 새로운 슬레이브를 추가 할 수 있습니다. 이제 일정을 벗어나 전체 빌드를 수행하려면 클릭 한 번이지만 원하는 경우 하나의 응용 프로그램 만 빌드 할 수도 있습니다.
There are four weaknesses of this approach, however. One is our source tree's complex web of dependencies. In order to simplify config maintenace, all builders are generated from a large dictionary. The dependencies are retrieved and built in a not-terribly robust fashion (namely, keying off of certain things in my build-target dictionary). The second is that each build has between 15 and 21 build steps, which is hard to browse and look at in the web interface, and since there are around 150 columns, takes forever to load (think from 30 seconds to multiple minutes). Thirdly, we no longer have autodiscovery of build targets (although, as much as one of my coworkers harps on me about this, I don't see what it got us in the first place). Finally, aformentioned coworker likes to constantly bring up the fact that we can no longer perform a full build on our local machine (though I never saw what that got us, either, considering that it took three times as long as the distributed build; I think he is just paranoically phobic of ever breaking the build).
이제 새로운 개발로 넘어 가면서 g ++ 및 서브 버전을 사용하기 시작했습니다 (이전 저장소를 포팅하지 않고 새로운 것만 고려하십시오). 또한 더 많은 단위 테스트 ( "more"는 잘못된 그림을 줄 수 있습니다 ... 더 비슷 합니다 ) 및 통합 테스트 (python 사용)를 시작했습니다. 이 구성을 기존 구성에 맞추는 방법을 알아내는 데 어려움을 겪고 있습니다.
그래서 여기서 철학적으로 어디 잘못 갔습니까? 구성을 실제로 유지 관리 할 수 있도록 빌드 봇으로 작업을 진행하는 가장 좋은 방법은 무엇입니까? 내 디자인의 약점을 어떻게 해결합니까? 복잡한 대규모 코드베이스에 대한 CI 전략 측면에서 실제로 효과가있는 것은 무엇입니까?
편집하다:
나는 내 문제를 설명했다고 생각했지만 분명히 명확하지 않았습니다. 나는 하지 CI 플랫폼 변경에 대한 제안을 찾고. 그것은 일어나지 않을 것이며, 그 제안은 받아 들여지지 않을 것입니다. 내가 알고 싶은 것은 다른 사람들이 CI를 사용하여 복잡한 코드베이스를 관리하는 방법입니다. 저는 12 가지 제곱의 다른 제품을 가지고 있으며 바람에 흩어져있는 종속성을 가지고 있으며 모두 다릅니다. 이것이 내가 다루는 방법을 알고 싶은 것입니다.