지속적인 통합 (Continuous Integration)

Contents

• 지속적인 통합으로 피처요구사항 빌드하기 (Building a Feature with Continuous Integration)
• 지속적인 통합의 수행 지침 (Practices of Continuous Integration)
  • 단일화된 소스 저장소를 유지해라. (Maintain a Single Source Repository.)
  • 빌드를 자동화하라. (Automate the Build)
  • 빌드에 자체 테스트를 추가해라. (Make Your Build Self-Testing)
  • 매일 모든 개발자가 메인라인에 커밋하게 하라. (Everyone Commits To the Mainline Every Day)
  • 모든 커밋은 반드시 통합서버에서 메인라인을 빌드해야 한다. (Every Commit Should Build the Mainline on an Integration Machine)
  • 빌드 시간을 짧게 유지해라 (Keep the Build Fast)
  • 실 운영환경과 똑같은 환경에서 테스트를 수행해라 (Test in a Clone of the Production Environment)
  • 누구나 쉽게  최신 실행파일을 얻을 수 있게 하라 (Make it Easy for Anyone to Get the Latest Executable)
  • 누구나 작업 진행 상황을 알 수 있어야 한다. (Everyone can see what’s happening)
  • 디플로이를 자동화 하라 (Automate Deployment)
• 지속적인 통합의 효과 (Benefits of Continuous Integration)
• 지속적인 통합 소개하기 (Introducing Continuous Integration)
• 마지막 생각 (Final Thoughts)
• 더 읽을 거리 (Further Reading)

나는 대규모 프로젝트를 처음 견학했던 때를 생생하게 기억한다. 당시 나는 꽤 규모가 큰 영국 전자회사에서 하계 인턴쉽을 수행 중에 있었다.  QA그룹 소속이었던 내 관리자는 사이트를 둘러볼 수 있게 해주었고, 우리는  큐브가 가득 쌓여있는 상당히 우울한 느낌을 주는 창고로 들어섰다.  그 프로젝트는 2년이상 개발이 진행이 되고 있었으며, 최근 몇 달동안 통합 작업이 진행 중에 있다는 것을 들었다. 내 가이드는 그 어느 누구도 통합 작업을 언제 끝마치게 될지 장담을 할 수 없다고 했다. 이 일로 나는 소프트웨어 프로젝트의 일반적인 얘기를 하나 알게 되었다. :통합은 예측하기 어려운 기나긴 프로세스 라는 것을.

하지만 이는 문제가 되지 않는다. 내 동료들과  ThoughtWorks에서 수행한 대부분의 프로젝트 혹은 전 세계 많은 프로젝트에서 통합 작업은 큰 문제로 여겨지지 않는다. 개별 개발자들의 작업은 공유된 프로젝트 상태에서 단 몇시간 만 떨어져 나와 있을 뿐, 몇 분안에 공유 프로젝트 상태에 통합이 될 수 있다. 통합 수행 과정에서 에러는 조기에 발견되며 수정된다.

이러한 차이는 고가의 복잡한 툴의 결과가 아니다. 핵심은 팀의 모든 이는 작업한 내용을 소스코드 저장소에 자주(보통 일 단위) 통합을 한다는 단순한 지침에 있다.

“지속적인 통합에 대한 최초 글“은 Matt이 2000년 ThoughtWorks 프로젝트에서 지속적인 통합을 합칠 수 있도록 도와준것 에 대한 우리의 경험을 서술한 글이다.

이 지침을 사람들에게 설명하면, 나는 두 가지 형태의 반응을 접하게 된다: “여기서는 그렇게 할 수 가 없어요”, “그렇게 해서 뭐가 크게 달라지는 없을 거에요”. 하지만 이 지침을 시도해본 사람들은 생각보다 매우 쉬우며, 개발할 때 매우 큰 차이점을 만들어낸다는 것을 알게된다. 그래서 세번째 반응은 다음과 같다. “예. 우리는 그렇게 합니다.-그렇게 하진 않고서 어떻게 개발을 할 수 있어요?”

“지속적인 통합”이라는 용어는 XP(Extreme Programming)에서 유래한 단어로써 XP에서 제시하는 12가지 지침 중 하나다.  처음 ThoughtWorks에서 컨설턴트로 시작할 때, 나는 내 프로젝트에서 이 기법을 사용하도록 독려하였다. Matthew Foemmel은 내 모호한 권고사항을 구체적인 활동으로 바꿨고, 띄엄 띄엄 발생하여 매우 복잡했던 통합작업이 나중에는 별 문제가 되지 않는 프로젝트로 변하는 것을 보게 되었다. Mattew와 나는 당시의 경험을 이 글의 초기 버전에 적었고, 이제 내 사이트 중 가장 인기있는 글중 하나가 되었다.

지속적인 통합이 디플로이를 위한 특정 툴을 요구하지 않지만, 우리는 지속적인 통합을 위한 서버를 사용하는 것이 좀더 효과적이라는 것을 알게되었다. 제일 잘 알려진 서버는 ThoughtWorks의 몇몇 개발자에 의해 최초로 개발돼, 이제는 많은 커뮤니티에서 유지되고 있는 오픈소스 Cruise Control이다.

원문보기
Continuous Integration

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