Continuous Integration

Continuous Integration(이하 CI) – 지속적인 통합이라는 의미다.

요새 꽤나 “이슈” 가 많이 되고 있는(사실은 좀 이전에~~~) 주제이기도 하다.

 

보통 CI 라고 하면, CI 툴을 사용해서 설치하면 되지 않는가 라고 생각하기 쉽다.

사실 이 말도 맞다. 하지만, 모든 것이 그렇듯이 CI의 핵심은 “사람” 이고 “팀원” 이다.

 

먼저 CI의 구성 요소를 살펴보자.

1. 소스 형상 관리 시스템( SVN, CVS, VSS 등등 뭐든지 좋다. )

– 소스 형상 관리 시스템이 없다면,  솔직히 CI가 구성되지 않는다. 상상해보자.

특정 시간마다, 수많은 사람들이 USB나, 이메일 등 을 통해서 서로 다른 소스를 던져준다면?

수많은 버그와 함께, 코드 되돌리기 신공이 난무하게 될 것이다.  SVN을 쓰더라도 머지가 힘들 수도

있지만 (사실 SVN 등을 쓸 때, 머지의 책임은 뒤에 커밋하는 사람이 지는 것이다. ) 과연 어느 것이

쉬울지는 잠시만 적응해 보면 안다.

 

2. 빌드 머신 과 한방 빌드

보통 빌드라는 건, 개발자가 자신의 로컬 머신에서 VS등에서 F7 등을 눌리면 되는 것으로 생각하기 쉽다. 그러나, 빌드라는 것도, 공식 빌드, QA 빌드, 개발자 테스트 빌드, 개발도중의 빌드 등으로 나눌 수 있다. 여기서 개발 도중에 개발자가 하는 빌드를 빼고는 개발자 테스트 빌드 조차도 한방 빌드라는 공식화된 빌드 루틴을 타야 한다.

한방 빌드라는 것은, 그냥 배치 스크립트 등을 딱 한번 누르면, 깨끗한 머신에서 알아서 소스코드를 가져오고, 필요한 라이브러리를 링크해서 빌드 결과를 알려줄 수 있는 시스템이다. 그 안에는 사람의 손이 추가로 가서는 안 된다.

일일 빌드라는 유명한 것도, 이 한방 빌드로 만들어져야 한다.

3. CI 툴

사실 CI 툴은 편의를 도와주는 것이지만 사용하기 힘들다면 꼭 안써도 된다. 그냥 2의 한방 빌드를 예약 작업으로 걸어놓고, 10분이나, 1시간 단위로 돌려서 결과를 확인해도 된다. 하지만, 편의를 도와준다는 것은 생산성을 향상시켜준다는 것을 알아야 한다.

4. 사람(별표 백만개)

위의 시스템이 잘 갖춰져 있어도, 쓰는 사람들에 따라서 천지 차이다. –_-

SVN이 있더라도 하루에 한번 체크인을 한다든지, 3개월에 한번 한다든지 한다면, 별 의미가 없다.

같은 한방 빌드라도, 필요한 부분을 빨리 체크해서 결과를 알려주는 것과, 모두 끝난뒤에야 결과를 알려주는 등의 것도 어떻게 구성하는지에 따라서 매우 결과가 달라진다.

CI툴의 리포트도 사람이 신경쓰지 않으면 전혀 의미가 없다.

그래서 결국 사람이 가장 중요하다.

위에 것들이 관심이 있다면, 최소 1,2번 까지라도 설정해 보길 바란다.

CI 툴중에 소스코드를 커밋한걸 감지하고 있다가 소스코드가 커밋될 때마다 빌드해서 알려주는

기능도 있으니, 누군가 커밋을 빼 먹어 생기는 문제가 많다면, 이런 기능을 이용해 보는것도 어떨까?