Continuous Integration by Martin Fowler 1/15

출처 : http://pragmaticstory.com/224

지속적인 통합(Continuous Integration)

마틴 파울러

지속적인 통합은 여러명으로 구성된 팀이 작업한것을 자주 통합하는것을 가리키는 소프트웨어 개발 프랙티스 로서 여기서 자주는 각 팀원이 적어도 하루에 한번 이상, 매일 여러번의 통합이 이루어지는것을 의미한다. 매번 이루어지는 통합은 자동화된 빌드에 의해 통합 에러가 없는지 가능한 빨리 검증된다. (여기에서 빌드는 테스트도 포함한다.) 많은 팀들은 이런 접근 방법이 통합시에 발생하는 문제를 줄여주며 매우 응집력있는 소프트웨어를 더 빨리 개발할 수 있다는 사실을 알게 되었다. 이 기사는 지속적인 통합에 대한 개요로서 기법과 현재 사용하고 있는 환경에 대해 설명하고 있다. 

최종 업데이트 : 06년 5월 1일

ThoughtWorks사의 내 직원들은 컨설팅을 진행하면서 보통 지속적인 통합을 지원하는데 특히 크루즈 컨트롤을 애용한다. 우리가 크루즈 컨트롤을 처음 시작했고 각 프로젝트에 적극적으로 기여했다. 우리가 중요한 오픈소스 도구를 확장하고 지원했으면서도 대용량 엔터프라이즈 환경에 맞게 크루주 컨트롤 애드온 역시 개발하기 시작했다.(조금 막연하게 들릴텐데 이후에 자세히 살펴볼것이다.)  더 많은 정보는CruiseControl Enterprise을 참고하라.

목차

• CI로 특정 기능 빌드하기
• 지속적인 통합 프랙티스
  • 단일 소스 레파지터리 유지하기.
  • 빌드 자동화 하기
  • 셀프 테스팅 빌드 만들기
  • 모든 사람이 매일 커밋하기
  • 모든 커밋은 통합 서버의 메인라인에서 빌드되어야 한다.
  • 빌드가 빨리 되도록 유지하기
  • 운영 환경과 동일한 환경에서 테스트 하라
  • 누구든 최신 실행본에 쉽게 접근할수 있게 하라
  • 모든 사람이 무슨일 일어나고 있는지 알게 하라
  • 자동화된 배포
• 지속적인 통합의 이점
• 지속적인 통합 입문
• 마지막 생각

관련 기사

• 지속적인 통합(원래 버전)
• 개선된 데이터베이스 설계

나는 지금도 처음 경험했던 대규모 소프트웨어 프로젝트를 생생하게 기억한다. 그 당시 나는 대기업인 영국 전기 회사의 여름 인턴 과정에 참여하고 있었다. 내 매니저는 QA 그룹이었는데 내가 회사를 둘러볼수 있게 해주었다. 투어중에 박스가 가득쌓여있는 침울해 보이는 창고로 들어가게 됐다. 나는 이 프로젝트가 몇년간 개발을 진행했으며 현재 통합을 하는중이다. 그런데 몇달째 통합을 진행하고 있다는 이야기를 듣게 됐다. 가이드는 누구도 통합이 언제 끝날지 알지 못한다고 내게 말했다. 여기서 나는 통합은 오래 걸리고 예측하기 어려운 프로세스라는 소프트웨어 프로젝트의 공통된 문제에 대해 알게되었다.

그러나 이에 대한 해결책이 없는건 아니다. ThoughtWorks의 동료들이 일하는 대부분의 프로젝트와 전 세계의 많은 다른 사람들은 통합을 특정 사건으로 여기지 않는다. 각각의 개발자 들이 공유 프로젝트와 분리된 상태로 일하는건 단지 몇시간일 뿐이며 몇분내에 다시 통합된 상태로 돌아갈수가 있다. 이때 통합에 발생하는 에러는 빨리 발견되고 바로 수정이 된다.

이런 비교가 비싸고 복잡한 도구를 사용해서 나온 결과가 아니다. 여기서 중요한건 팀의 모든 사람들이 자주 매일 매일 통합하고, 소스 코드 리파지터리를 관리하는 단순한 프랙티스에 있다.

이 프랙티스를 사람들에게 설명하면 보통 사람들은 두가지로 반응한다. "여기서는 불가능해요. 할수 없어요" 아니면 "그게 무슨 차이가 있죠". 일단 시도를 해본 사람들은 듣던거에 비해 더 쉽다는것을 알게되고 개발에 커다란 차이가 있다는것을 깨닫는다. 그러고 나면 세번째 반응이 나타난다. "이야 우리가 해냈어요. 이거 없이 어떻게 살았죠 ?"

'지속적인 통합(Continuous Integration)'이란 용어는 XP의 12가지 프랙티스중 하나에서 가져왔다. ThoughtWorks를 시작할때 컨설턴트로서 이 기법을 사용해서 프로젝트를 성공적으로 이끌었다. 매튜 포멜은 나의 애매한 권고를 확실한 행동으로 바꿔 놓았고 우리는 프로젝트에서 통합이 힘들고 복잡한 작업에서 내가 언급한것처럼 특정 사건이 아닌것으로 바뀌어 가는걸 보았다. 매튜와 나는 우리의 경험을 바탕으로 이 문서의 원본을 작성했는데, 이 문서는 이후 이 사이트에서 가장 인기있는 문서가 되었다.

관련기사 참고 : 지속적인 통합(원래 버전)

이 웹사이트에 지속적인 통합의 원래 기사가 남아있다. 링크를 따라가면 이 기사를 읽을수 있다.(하지만 새 기사를 읽는것이 더 좋을것이다.) 이 기사는 ThoughtWorks 초기 시절에 매튜가  프로젝트에서 지속적인 통합을 위해 일했던 경험을 설명하고 있다.

지속적인 통합 자체는 배포를 위한 특정 도구를 필요로 하지 않는 프랙티스지만 이를 유용하게 사용하기 위해서는 통합 서버를 사용해야 한다는걸 알게 되었다. 그런 서버로 알려진것중 최고는 크루즈 컨트롤인데, ThoughtWorks 사의 몇명이 오픈소스 프로젝트로 만들기 시작했고 지금은 커뮤니티에 의해 유지되고 있다. 원래 크루즈 컨트롤은 자바로 작성되었지만 마이크로 소프트 플랫폼인 CruiseControl.net도 개발되었다.