이 기사는 마틴파울러의 Continuous Integration을 번역한 기사임을 미리 밝혀둡니다.

모든 커밋은 통합 서버의 메인라인에서 빌드되어야 한다.

매일 커밋하게 되면, 팀은 자주 빌드를 테스트 해야 한다. 그래야 메인라인을 건강한 상태로 유지할수가 있다.  그러나 사실 잘못될 여지는 여전히 남아있다. 그 이유중 하나는 커밋하기 전에 빌드하고 업데이트 해야 한다는 원칙을 지키지 않기 때문이다. 또 다른 이유는 개발자 PC 환경의 차이에서 발생한다.

그 결과 정기적 빌드는 통합 서버에서 확인해야만 하는데 빌드가 성공적으로 된 경우만 커밋해야 한다.  커밋하는 개발자는 누구라도 이에 대한 책임을 져야하며, 개발자는 메인라인을 모니터링 해서 에러가 발생하면 이를  수정해야 한다.  이런일이 발생하게 되면 그 날 추가된 모든 커밋이 빌드될 때까지 아무도 집에 가지 못한다.

이를 확실하게 하기 위해서는 두가지 방법이 있다. : 수동 빌드를 이용하는 방버과 CI 서버를 이용하는 방법이다.

수동 빌드는 가장 단순한 방법이다. 중요한건 개발자가 레파지터리에 커밋하기 전에 로컬빌드를 유사하게 진행해야 한다는 것이다. 개발자는 통합서버에서 메인라인을 체크아웃하고 통합 빌드를 실행한다. 커밋된 사항에 대해 빌드가 성공하는지 모든 과정을 지켜본다.(짐 쇼어(Jim Shore)의 설명을 참고하라.)

CI 서버는 레파지터리를 모니터링 한다. 레파지터리에 커밋할때마다 서버는 자동으로 소스를 통합 서버로 체크아웃 하여 빌드를 초기화 하고 커밋한 사람에게 빌드 결과를 알려준다. 커밋한 사람은 이메일 같은걸로 통보가 올때까지 완료된게 아니다.

ThoughtWorks사는 CI 서버를 정말 좋아한다. 사실 우리회사가 CruiseControlCruiseControl.NET 개발을 이끌고 있는데 오픈소스 CI 서버로 널리 사용되고 있다. ThoughtWorkers는 이 오픈소스 프로젝트에서 여전히 활발하게 커미터로 활동하고 있는 폴 줄리어서(Paul Julius), 제이슨 입(Jason Yip), 오웬 로저스(Owen Rodgers)를 좋아한다. 우리는 크루즈 컨트롤을 거의 모든 프로젝트에서 사용하고 있으며 그 결과에 만족하고 있다.

모든 사람이 CI 서버를 사용하는것을 좋아하는건 아니다. 짐 쇼어(Jim Shore)는 왜 수동빌드가 자동빌드보다 좋은지를 설명하고 있다. 나 역시 CI가 단지 크루즈 컨트롤을 설치하는것 이상의 작업이라는데 동의한다. 여기 나와있는 모든 프랙티스는 지속적 통합을 효과적으로 적용하는데 필요한 사항들이다. 그러나 CI를 적용하는 많은 팀들에게 있어 크루즈 컨트롤은 도움이 되는 툴이다.

많은 조직들은 매일 밤과 같은 일정에 따라 정기적으로 빌드를 한다. 이는 지속적 빌드와는 약간 다른데 지속적 통합이라고 하기에는 부족하다. 지속적 통합에서는 가능한 빨리 문제를 발견할수 있어야 한다. 매일밤 빌드하는것은 버그가 하루종일 발견되지않고 숨어있다는것을 의미한다. 버그가 시스템이 오래 머물러 있게 되면 이를 발견해서 제거하는데 오랜 시간이 필요하다.

지속적 통합의 중요한 부분은 메인라인 빌드가 실패했을때 즉시 이를 수정해야 한다는 것이다. CI를 기반으로 작업할때는 항상 안정적인 소스를 기준으로 개발을 진행해야 한다. 메인라인 빌드가 깨지는게 나쁜건 아니다. 커밋하기 전에 로컬에서 빌드하고 수정하는등의 작업에 충분한 주의를 기울이지 않으면 이런상황은 언제든지 발생할수가 있다. 그러나 메인라인 빌드가 깨졌을때 가능한 빨리 이를 수정하는게 중요하다. 메인라인 빌드가 깨지는 것을 막기 위해서는 pending head를 이용하는것을 고려해 보라.

팀에 CI를 소개할때 가장 어려운 부분중 하나가 이를 가려내는것이다. 초기의 팀은 메인라인 빌드를 갖고 일하려는 습관을 고수하려고 하는데, 특히 기존 코드를 기반으로 일하려든다. 애플리케이션이 정기적으로 잘못되더라도 참을성을 가지고 진행해야 한다. 낙심하지 마라.

TAG