참조
http://martinfowler.com/articles/continuousIntegration.html
http://moai.tistory.com/224

오늘은 두 번째 파트인 Continuous Integration 실천하기를 살펴보겠습니다.

각각의 실천 요소에 대한 번역판을 살펴볼 수 있습니다.

1. 단일 소스 레파지터리 유지하기.
svn이나 cvs와 같은 것을 사용하여 프로젝트와 관련된 모든 파일을 관리하라. 특정 파일을 찾으러 돌아다닐 필요가 없어진다.
실험 또는 앞서 출시한 버전의 버그 수정을 할 때 브랜치를 사용하면 유용하다.
단 빌드 파일의 결과물 같은 것들은 오히려 레파지터리를 지저분하게 만든다.

2. 빌드 자동화 하기.
손수 명령어를 치고 빌드 하는 것은 시간 낭비이며 실수를 할 확률이 높다.
Java의 Ant, Ruby의 Rake, .Net의 MSBuild를 사용하라.

3. 셀프 테스팅 빌드 만들기.
버그를 더 빨리 효율적으로 발견하는 방법은 빌드에 자동화 테스트를 추가하는 것이다.
XUnit 프레임워크를 사용하면 편리하다.
테스트에 통과했다고해서 버그가 없는 것은 아니다.

4. 모든 사람이 매일 커밋하기.
커밋의 주기가 잦을 수록 버그가 발생한 반경은 좁아진다.
작업의 단위를 몇 시간 이 내에 할 수 있는 작은 단위로 쪼개면 유용하다.
여러 곳의 코드가 수정되었다면 diffdibugging 활용하기.

5. 모든 커밋은 통합 서버의 메인라인에서 빌드되어야 한다.
커밋이 이루어지면 통합 서버에서 빌드를 거쳐야 한다.
서버를 빌드하는 작업을 정기적으로 할 수 있는데, 방법은 수동과 자동이 있다.
수동으로 하면 단순하지만 로컬에서 빌드하는 방법과 비슷하다.
자동은 CI 툴을 사용하는 방법으로 서버를 모니터링하고 있다가 커밋이 이루어지면 서버에 빌드 작업을 하고 그 작업 결과를 개발자에게 이메일로 알려준다.
메인 빌드가 실패하면 고쳐질 때까지 아무도 집에가지 못한다.
CI 서버 사용에 대한 학습이 필요하다.

6. 빌드가 빨리 되도록 유지하기.
빌드 과정 중에서 가장 시간을 많이 잡아 먹는 것은 테스트다.
빌드를 여러 Stage로 쪼갠 Staged 빌드를 활용하라.
커밋 빌드를 거친 뒤에 테스트 빌드를 별도의 서버에서 수행하여 응답 시간를 줄일 수 있다.

7. 운영 환경과 동일한 환경에서 테스트하라.
실제 제품이 운영되는 같은 버전의 같은 데이터베이스 소프트웨어, 같은 버전의 운영체제를 이용하라.
현실적인 한계가 있을 수 있기 때문에 가상화 서버를 이용할 수도 있다.

8. 누구든 최신 실행본에 쉽게 접근할 수 있게 하라.
각 이터레이션 마다 빌드를 유지하라.
데모를 통해서 기능에 익숙해 지도록 할 수 있다.

9. 모든 사람이 무슨 일이 일어나고 있는지 알게 하라.
지속적인 통합은 의사소통을 위한 것이다.
특히 메인라인의 빌드 상태를 공유해야 한다.
CI 서버를 사용하면 그러한 것이 매우 유용하다.
매일 같이 빌드가 제대로 되었는지 체크하는 달력도 유용하다.

10. 배포 자동화
지속적인 통합을 하다 보면 여러 환경에 배포하는 활동이 필요하다. 이것을 자동화 하라.
자동화된 배포는 프로세스 진행 속도를 높여주며 에러를 줄이는데 도움이 된다.
RoR의 Capistrano와 같은 것이 유용하다.