CI가 무엇이며, 어떻게 돌아가는지 설명하는 가장 간단한 방법은 작은 피처 요구사항을 개발하는 과정에 어떻게 적용되는지 사례를 드는 것이다. 자 내가 소프트웨어의 어떤 특정 부분을 개발하기로 치자. 이 시점에서 개발하기로 한 것이 어떤 일인지가 중요한게 아니라 작고 몇 시간 안에 끝낼 수 있는 일이라는 것이 주요 포인트이다.(긴 시간을 필요로 하는 타스크와 그 외 이슈는 나중에 알아보기로 한다.)
최신 통합 소스의 복사본을 내 로컬 개발 머신에 갖다 놓는다. 이를 위해 소스관리시스템의 메인라인에서 워킹카피(working copy)를 체크아웃한다.
위 문단은 소스코드관리시스템을 사용해 본 사람이라면 이해할 수 있을 것이다. 그러나 사용해보지 않은 이들에게는 횡설수설처럼 들릴 것이다. 그런 이들을 위해 간단한 설명을 덧붙인다. 소스코드 관리 시스템은 모든 프로젝트의 소스코드를 저장하는 저장소이다. 시스템의 현재 상태는 보통 메인라인(main line)이라 일컺는다. 개발자는 언제라도 메인라인에서 관리되는 본을 각자의 로컬 머신으로 복사할 수 있는데 이러한 복사 행위를 체크아웃이라 한다. 개발자 로컬 머신에 있는 본을 워킹카피라 한다.(많은 시간 개발자들은 자신들의 워킹카피를 메인라인에 업데이트하게 된다.)
타스크를 마치기 위해 나는 워킹카피를 이용하여 여러 작업들을 수행하게된다. 이는 운영코드를 수정하는 것과, 자동화된 테스트를 변경, 혹은 추가하는 것 둘 다를 포함한다. 지속적인 통합은 높은 등급의 테스트 수행(소프트웨어 안에 자동화된 테스트-나는 이를 자체 테스팅 코드라 부른다.- 종종 이들은 XUnit 테스트 프레임웤을 이용한다.)을 전제로 한다.
일단 작업을 마친 후(혹은 작업을 수행하는 과정에서 매 시점마다) 나는 내 개발 머신에서 자동화된 빌드를 수행한다. 이때 내 워킹카피를 사용하여 컴파일, 링크를 수행하여 실행파일을 만들어 내며, 자동화된 테스틀 수행한다. 모두 빌드하고 에러가 없는 테스트가 수행되었을 때만 전체 빌드가 성공되었다고 간주 할 수 있다.
빌드가 성공이 되면 나는 저장소로 내 변경 내역을 커밋할 수 있다. 물론 일이 꼬일 수 도 있다. (통상 일어날 수 있는 경우로) 내가 커밋하기 전에 다른 개발자가 메인라인에 변경을 반영하는 경우가 있을 수 있다. 그래서 나는 다른 개발자가 변경한 내역을 다시 내 워킹카피로 업데이트한 뒤 재빌드를 수행 한다. 다른 개발자의 변경 내용이 내가 수행한 변경내용과 충돌이 일어나면, 빌드나 테스트 수행 시 실패가 나는 것은 명확하다. 이 경우 이를 수정해하는 주체는 내가 되며, 메인라인과 동기화된 내 워킹카피가 성공적을 빌드될 때 까지 작업을 반복한다.
올바르게 동기화된 워킹카피에 대한 빌드가 성공하면, 마침내 내가 수행한 변경 내용에 대해 (저장소를 업데이트 하는 작업인) 메인라인 커밋을 수행한다
그러난 커밋으로 내 할 일이 모두 끝나는 것은 아니다. 이번에는 통합서버에서 메인라인에 있는 소스코드로 빌드를 다시 수행해야 한다. 이 빌드가 성공되 후에야 각자의 변경작업이 완료되었다고 할 수 있다. 내 개발 머신에서는 언제나 뭔가 빠질 수 있는 소지가 있으며, 이럴 경우 저장소가 올바로 업데이트 되지 않는다. 내가 커밋한 변경이 통합서버에서 성공적으로 빌드가 되어야만 내 할 일이 끝나게 된다. 이러한 통합은 내가 수동으로 할 수도 있고, Cruise에 의해 자동 수행 될 수 도 있다.
두 개발자 사이 충돌이 발생하면, 통상 두번째 개발자가 워킹 카피을 업데이트하고 커밋하는 시점에 감지가 된다. 그렇지 않으면 빌드는 실패되어야 한다. 이러한 방식으로 인해 에러는 조기에 감지된다. 이 부분에서 수행해야 하는 제일 중요한 타스크는 는에러를 수정하고,빌드를 다시 하는 것이다. 지속적인 통합환경에서 개발자들은 실패한 통합빌드를 오래 방치하면 안된다. 좋은 팀은 매일 (수정으로 인한) 빌드를 자주 수행한다. 충돌로 인해 빌드 실패가 종종 발생하지만, 신속하게 수정 및 재빌드 된다.
이렇게 함으로써 버그를 적게 포함하고 제대로 작동하는 소프트웨어 개별 부분들이 존재한게 된다. 모든 개발자들이 안정된 베이스를 공유하게 되며, 안정된 베이스에서 너무 오랫동안 떨어진 채 작업이 진행되어 다시 통합을 하는데 복잡하고 힘들어지는 경우가 사라지게 된다. 버그가 신속하게 발견되므로 버그를 찾는데 들이는 시간을 줄일 수 있다.
본 포스트는 Martin Fowler 선생께서 쓴 글을 번역 게재한 글이다. 선생은 본인의 글을 직접 게재하는 것을 허용하지는 않지만, 번역은 허용하고 있다.
원문에도 한국어 번역글로 등록이 되어있는데, 이 글보다 몇 년 앞서 더 훌륭한 솜씨로 한글로 번역해 놓은 글이 있으니 참조하면 좋을 듯 하다. (황상철님의 실용주의이야기 의 ‘지속적인 통합‘)
