지속적인 통합(Continuous Integration)은 팀의 구성원들이 자신들의 작업한 내용을 자주 통합(통상 최소 매 일 단위)하는 개발 지침를 말한다.-개발자들은 하루에 몇차례씩 빌드를 수행한다.통합이 수행될 때마다 테스트를 포함한 자동화된 빌드절차에 의해 통합내용은 자동 검증 되며, 이로 인해 통합시 발생하는 에러를 조기에 발견할 수 있게된다. 많은 팀들이 이러한 접근이 소프트웨어 통합에서 발생할 수 있는 중요한 문제들을 줄여주고, 보다 빠르게 응집력이 높은 소프트웨어를 개발할 수 있게 해준 다는 점을 잘 알고 있다. 본 글은 지속적인 통합의 기술과 현재 사용에 관련된 내용을 정리한 간단한 리뷰이다.
01 May 2006
마틴 파울러 (Martin Fowler)
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이다.
본 포스트는 Martin Fowler 선생께서 쓴 글을 번역 게재한 글이다. 선생은 본인의 글을 직접 게재하는 것을 허용하지는 않지만, 번역은 허용하고 있다.
원문에도 한국어 번역글로 등록이 되어있는데, 이 글보다 몇 년 앞서 더 훌륭한 솜씨로 한글로 번역해 놓은 글이 있으니 참조하면 좋을 듯 하다. (황상철님의 실용주의이야기 의 ‘지속적인 통합‘)
