빌드시간을 짧게 유지해라(Keep the Build Fast)

지속적인 통합의 중요 사항중에 하나는 빠른 피드백을 제공하는 것이다. CI활동 중에서 시간이 많이 소요되는 빌드만큼 나쁜 것도 없다. 긴 시간이 소요되는 빌드가 대체 얼마나 걸리는 건지에 대해서는 이견들이 있겠지만, 대부분의 내 동료들은 한시간 이상 소요되는 빌드 매우 비합리적이라 생각한다. 나는 빌드시간을 매우 짧게 단축하려는 팀들을 기억하는데, 때때로 그렇게 빌드시간을 단축하는것이 것이 매우 어려운 상황에 직면하곤한다.
대부분의 프로젝트에서는 XP의 가이드 라인 시간인 10분정도가 합리적이다. 근래의 우리의 프로젝트는 모두 이 기준을 준수했다. 이를 위해 집중된 노력을 투입하는 것은 가치 있는 일인 것이 빌드과정의 몇분을 단축하는 하면 그만큼 개별 개발자가 커밋을 수행시간이 줄어들기 때문이다. CI는 잦은 커밋을 요구하기 때문에 이렇게 개발자들의 단축되는 시간을 합쳐보면 꽤 많은 시간이 절약된다.

1시간 가량 걸리는 빌드를 보다 짧게 수행되게 하거나, 혹은 신규 프로젝트에서 빌드 시간을 줄이는 계획을 수립하는 것이 다소 벅찬 일일 수 있다. 전사 애플리케이션의경우 우리가 알고 있는 일반적인 병목지점은 (특히 데이타베이스처럼 외부 서비스를 포함한) 테스트이다

아마도 대부분 중요한 단계는 deploymnet pipeline 세팅 작업을 시작하는 일일 것이다. deploymnet pipeline(혹은 build pipeline, staged build 란 복수개의 빌드가 순차적으로 수행되는 것을 말한다.
메인라인에 대해 누군가 커밋을 하면 커밋빌드(Commit Build)가 수행되며, 이 커밋빌드가 순차적으로 빌드를 유발시킨다. 커밋빌드는 신속하게 처리되어야 하며, 그 결과 버그발견 효과가 떨어질 수 있다. 중요한것은 버그발견 효과 감소와 수행 시간 단추간간 절충점을 찾아 다른 사람들이 작업하기에 충분한 안정된 기반을 제공하는 것이 핵심이다.

커밋빌드가 정상완료되면, 다른 개발자들은 신뢰할 수 있는 기반에서 자신들의 작업을 할 수 있다. 그 다음에 해야 할 것이 바로 시간이 꽤 소요되는 테스트이다. 여분의 기계에서 시간이 더 걸리는 테스트를 수행하게 할 수 있는데, 이에 대한 간단한 사례가 바로 두 단계 빌드(two staged deployment pipeline)이다. 첫번째 빌드는 컴파일을 수행하고, DB관련작업이 없는 좀더 국지화된 단위테스트를 수행한다. 이런 테스트는 빠르면 10분 가이드라인을 지킬 수 있지만, 보다 큰 규모의 상호작용을 포함하는(특히 실DB작업등) 버그는 발견할 수 없을 것이다. 두번째 단계 빌드는 다른 test suite을 수행하며, 실DB를 건드리며, 보다 많은 end-to-end 행위를 포함한다. 이 test suite은 수행에 몇 시간이 걸릴수 도 있다.

작업자들은 이 시나리오에서 첫번째 빌드(1차빌드)를 커밋빌드로 이용하며, 그들의 CI작업의 메인 주기로 삼는다. 두번째 빌드(2차빌드)가 가능하다면 테스트 수행을 좀 더 하기 위해 마지막으로 성공한 커밋빌드에서 실행파일을 가져온다. 만약에 이 2차 빌드가 실패한다하더라도, 모든것을 중지하는 수준까지 이르지는 않으면서도, 커밋빌드가 계속 진행되는 것과 별개로, 가능한한 빨리 버그를 수정할 수 있다. 속도를 저하시키는 작업은 대부분 테스트 활동이기 때문에 이 사례에서 처럼 종종 2차 빌드는 순수하게 테스트만 수행한다.

2차빌드에서 버그가 발견되었다는 것은 커밋빌드에서 또 다른 테스트를 수행할 수 있었다는 신호다. 가능한한 많은 경우 담당자들은 2차빌드실패가 (예전에 버그를 잡을 수 있었을) 커밋빌드에서의 새로운 테스트들을 이끌어내어, 버그가 커밋빌드에서 수정된 채 유지되도록 보장되길 원한다.
이러한 방법으로 커밋빌드가 계속 수행하게 되어 커밋빌드가 강화되게 된다. 버그를 발견하는 빠른 속도의 테스트를 빌드할 수 있는 방법이 없어서, 그러한 조건의 테스트를 2차빌드에서만 하기로 결정하는 경우도 있다. 대부분의 경우 운좋게 커밋빌드에 알맞은 테스트를 추가할 수 있다.

이 예는 두 단계 빌드이지만 기본적인 원칙은 커밋빌드이후의 빌드를 복수개로 확장할 수 있다는 것이다.. 커밋빌드이후의 빌드들은 병렬로 수행되어 2시간 짜리 2차 테스트를 두 대의 머신에서 반반 나뉘서 각각 진행시켜 응답속도를 개선시킬 수 있다. 2차 빌드를 이렇게 병렬로 진행시켜, 개발자는 성능테스트등을 포함한 다양한 형태의 추가적인 자동화 테스트를 정규 빌드 프로세스에 추가할 수 있다. (지난 2년동안 ThoughtWorks의 많은 다양한 프로젝트에서 이에 대해 많은 흥미로운 기술들을 알게 되었다-나는 몇몇 개발자들을 설득하여 이에 대해 글을 쓰도록 설득하고 싶다.)

메인글로 돌아가기

원문보기

Continuous Integration

본 포스트는 Martin Fowler 선생께서  쓴 글을 번역 게재한 글이다. 선생은 본인의 글을 직접 게재하는 것을 허용하지는 않지만, 번역은 허용하고 있다.
원문에도 한국어 번역글로 등록이 되어있는데, 이 글보다 몇 년 앞서 더 훌륭한 솜씨로 한글로 번역해 놓은 글이 있으니 참조하면 좋을 듯 하다. (황상철님의 실용주의이야기 의 ‘지속적인 통합‘)

“빌드시간을 짧게 유지해라(Keep the Build Fast)”에 대한 한개의 댓글

  1. 핑백: 지속적인 통합의 수행 지침 (Practices of Continuous Integration) | Panicstyle Blog

댓글 남기기