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

---

CI로 특정 기능 빌드하기

CI를 설명하는 가장 빠른 방법이 뭐냐고 내게 물어본다면 개발할때 CI가 어떻게 동작하는지 작은 기능을 가지고  짧게  사례를 보여주는거라고 대답할 것이다. 소프트웨어에 대해 어떤 작업을 한다고 가정해 보자. 작업이 뭐냐는 상관없다. 작은 일이고 몇시간안에 끝나는 일이라고 하자.(더 오래 걸리는 작업은 나중에 살펴볼것이다.)

현재 통합된 소스파일을 개발용으로 사용하는 PC에 복사하는 것으로 작업은 시작된다. 형상관리 시스템을 이용해서 체크아웃 하면 소스코드가 PC로 복사된다.

위 문장은 소스코드를 관리하는 시스템을 사용하는 사람들만이 이해할수 있을거 같다. 그래서 형상관리에 대해 짧게 설명을 덧붙이면, 소스코드 관리 시스템은 하나의 레파지터리에 모든 프로젝트 소스코드를 유지한다. 시스템의 현재 상태는 보통 '개발 머신'별로 참조가 된다. 개발자는 언제든지 자기 머신에 소스코드의 복사본을 두고 관리할수 있는데 이를 '체크 아웃'이라 부른다. 개발자의 머신에 있는 복사본을 '작업본'이라 부른다.(대부분 자기 머신에 있는 작업본을 수정하면서 작업하는데 사실 같은 거라 할 수 있다.)

이제 작업본을 가져와서 필요한 작업을 완료했다. 여기서 말하는 작업은 제품 코드를 변경하는것과 자동화된 테스트를 변경하는것으로 이루어 진다. 지속적 통합은 소프트웨어에 대해 높은 수준의 자동화된 테스트가 있다고 가정한다.:이를 셀프 테스팅 코드라고 부른다. 이 코드에서는 XUnit 테스트 프레임워크가 즐겨 사용된다.

일단 되고나면 작업할때 다양한 부분에 대해 내 개발머신에서 자동화된 빌드를 할수가 있다. 이 작업은 소스코드를 내 작업본으로 가져와서 컴파일하고 실행파일을 링크하고 자동 테스트를 수행하는 것이다. 모든 빌드와 테스트 과정중 에러가 발생하지 않으면 전체 빌드가 문제없다고 여길수가 있다.

빌드가 잘 되면 내가 변경한 부분을 레파지터리에 커밋한다. 물론 잘못되기도 하는데 내가 커밋하기 전에 다른 사람이 메인라인을 변경한 경우가 그렇다. 그래서 내가 작업한 부분을 처음 업데이트 하고 나면 빌드를 다시 해야 한다. 만약 내가 변경한것과 충돌이 생기면, 컴파일이나 테스트에서 실패했다는게 확실하다. 이 경우 내가 이 에러를 해결해야할 책임이 있으며 메인라인과 씽크를 유지하면서 작업본이 빌드될때까지 작업을 반복한다. 그러고 나서 마지막으로 머신에 변경된 부분을 커밋하고 레파지터리를 수정한다.ㅣ

그러나 커밋으로 모든 작업이 끝난것은 아니다. 이 시점에서 빌드를 다시해야 하는데, 이때는 통합 서버에서 빌드해야 한다. 이 빌드가 성공해야 변경이 완료됐다고 말할 수 있다. 내 머신에서만 빌드를 하면 작업한게 누락되서 레파지터리에 제대로 반영이 안될수가 있다. 내가 커밋한 변경사항이 통합서버에서 성공적으로 빌드가 끝났을때 작업이 완료된 것이다.

이  통합 빌드는 내가 수동으로 할수도 있지만 크루즈 컨트롤에 의해 자동으로 수행되도록 할 수도 있다.

두 개발자간에 충돌이 발생하는 경우는 대개 두번째 개발자가 자기가 작업하던것을 반영했을때 발생한다. 통합빌드가 안되고 실패하더라도 에러를 빨리 발견할수가 있다. 이 부분에 가장 중요한 것은 에러를 빨리 해결해서 빌드가 다시 제대로 되도록 만드는 것이다. 지속적 통합 환경에서 통합 빌드가 실패한채로 오랫동안 방치해서는 안된다. 좋은 팀은 매일 빌드를 수행하다가 빌드에러가 발생했을때 빨리 이를 고쳐나가는 팀을 의미한다.

이렇게 일을 하게 되면 소프트웨어는 안정적이 되서 제대로 동작하게 되며 버그는 줄어든다. 모든 개발자는 안정적인 베이스 라인의 코드를 공유하게 되고 통합이 어려울 정도로 오랫동안 베이스 라인에서 멀어져서 작업하게 되는 일은 없어진다. 버그가 빨리 드러나기 때문에 버그를 발견하는데 들어가는 시간도 점점 줄어든다.

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

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