실용주의이야기(Pragmatic Story)

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

빌드가 빨리 되도록 유지하기

지속적 통합의 정수는 빠른 피드백에 있다. 여기서 나는 CI 할동에서 빌드가 오래 걸리는것 만큼 치명적인 것은 없다는 사실에 동의한다. 내 동료 대부분은 빌드가 한시간 정도 걸려야 완전히 합당하다고 여긴다. 나는 팀이 가능한 빌드가 빨리 끝나길 원한다는걸 기억한다. 그러나 때로는 빨리 빌드하는게 어려울때도 여전히 빌드를 해야 하는 경우가 있다.

그러나 대부분 프로젝트에 대해 XP에서는 10분 빌드가 최적이라고 가이드 한다. 현대 프로젝트의 대부분은 이것이 가능하다. 가능한 여기에 노력을 기울이는건 의미있는 일이다. 왜냐면 빌드 시간을 매분 줄일때마다 모든 개발자가 커밋할때마다 이시간을 절약할 수 있기 때문이다. CI는 잦은 커밋을 요구하기 때문에, 이 때문에 많은 시간이 들어간다.

만일 빌드 타임 한시간으로 시작한다면, 더 빨리 빌드되도록 할수 있을것이다. 새로운 프로젝트에 작업을 시작했다 하더라도 어떻게 하면 더 빨리 빌드 할수있는지를 고민해야 한다. 엔터프라이즈 애플리케이션에서는 적어도 일반적인 병목점을 찾을수 있는데 바로 테스팅이다. 특히 데이터베이스와 같은 외부 서비스와 연관된 테스트가 그렇다.

아마도 가장 중요한 단계는 안정된 빌드(staged build)가 되도록 설정하는 것에서 시작하는 것이다. (빌드 파이프라인이라고 부르는) 안정된 빌드에 깔려있는 개념은 순서대로 여러 빌드가 이루어지는 것이다. 메인라인에 커밋되면 첫번째 빌드가 실행되는데 이를 커밋 빌드(commit build)라고 부른다. 커밋 빌드는 누군가 메인라인에 커밋할때 필요한 빌드이다. 커밋 빌드는 빨리 이루어져야 하며 그 결과는 버그를 발견하는데 드는 시간을 줄여준다. 재밌은 사실은 다른 사람들이 작업할수 있게 커밋 빌드가 안정적이 되도록 버그를 발견하는데 필요한것과 스피드에 대한 균형이 필요하다는 것이다.

일단 커밋 빌드가 이루어 지면 다른 사람들도 자신감을 갖고 코딩을 할수 있다. 그러나 아직 테스트가 남아있다. 여기서 시작해야 한다. 또 다른 서버에서 시간이 오래 걸리는 테스트가 실행되도록 할수 있다.

이 간단한 예는 2단계 빌드에 있다. 첫번째는 컴파일하고 데이터베이스와는 완전히 분리된 로컬상의 테스트를 실행한다. 이런 테스트는 아주 빨리 실행되기 때문에 10분이내 빌드라는 가이드라인을 준수할수 가 있다. 그러나 실제 데이터베이스와 연관있는 경우처럼 더 많은 범위의 상호작용과 연관된 버그는 발견되지 않을 것이다. 두번째 빌드는 실제 데이터베이스를 사용하며  엔드 투 엔드로 동작하는 등의 다른 형태의 테스트를 실행한다. 이런 테스트는 몇시간이 걸릴수도 있다.

이 시나리오는 사람들이 커밋 빌드에서 첫번째 빌드를 사용하게 하고 이를 주 CI 사이클에서도 이용한다. 두번째 단계 빌드는 실행되는 순서로는 두번째 빌드이며, 테스트를 위해 가장 최근에 성공한 커밋 빌드를 이용한다. 만약 두번째 빌드가 실패한다고 해서 모든 작업을 멈춰야 한다는걸 의미하지 않지만, 커밋 빌드가 실행되는 동안에 팀은 가능한 빨리 그런 버그를 제거하기 위해 노력해야 한다. 사실 이 두번째 빌드가 유지되지 않으면, 매번 버그가 발견될것이기 때문에 몇일내로 이를 처리해야한다.

두번째 빌드에 버그가 발견됐다는건 커밋빌드도 또 다른 테스트를 해야 한다는걸 나타낸다. 두번째 빌드가 실패했다는 사실은 커밋빌드가 버그를 잡을수 있도록 새로운 테스트를 추가해야 한다는걸 의미하며, 그렇게 하면 커밋빌드는 이 버그를 수정하게 된다.

이런 방식은 이런일이 발생할때 마다 커밋 테스트를 더 강하게 해준다. 버그가 드러나도록 해주는 테스트를 빨리 실행되게 할수 없는 경우가 있는데, 그래서 두번째 빌드에 들어갈 테스트 조건을 결정해야 한다. 다행스러운건 대부분은 커밋 빌드에 적당한 테스트를 추가할수 있다는 것이다.

이 예제는 2단계 빌드이지만, 기본 원칙은 이후에 실행되는 어떤 빌드에서도 확장될수 있다. 커밋 빌드 이후의 빌드 역시 병렬로 수행할수 있는데, 그래서 만약 두시간이 걸리는 두번째 테스트가 있다면 각 테스트를 반씩 두개 서버에서 실행되도록 해서 반응속도를 높일수 있다. 병렬의 두번째 빌드를 이렇게 이용하면 성능테스트와 같은 모든 종류의 자동화된 테스트를 기존의 정규 빌드 프로세스에 추가할수가 있다.(나는 지난 몇년간 ThoughtWorks사가 수행했던 다양한 프로젝트에서 많은 재밌는 기법들을 실행해왔다. 나는 개발자들이 이를 작성하도록 설득하길 바란다.)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.