CI(Continuous Integration system)가 무엇인가?

지속적 통합이라는 뜻으로 형상관리 시스템 (SVN or Git) 에 있는 Source 파일을 읽어들여 자동으로 빌드하여 실행할 수 있는 결과물 형태 (exe , jar, apk or war 등) 로 주기적으로 생산해주는 시스템

그냥 쉽게 말하면 주기적으로 소스파일을 빌드해서 실행 파일을 만든다.

CI System이 왜 좋지?

예를들어 개발자 + 기획자 + 테스터 + 외 다수 등이 존재하는 개발 상황에서 ( 개발자 뿐만이 아닌 다른 사람들도 해당 결과물을 궁금해 하는 상황 ) 개발자처럼 최신의 결과물을 즉시 볼 수 있는 여건이 갖추어 지지 않은 기획자 및 테스터들도 개발자가 생산한 최신의 결과물을 보고 싶어한다. 이게 왜냐면 업무 효율이랑 굉장히 밀접하기 때문.. PM이 현재까지 프로젝트 진행 사항이 궁금한데 1달 전 소스로 빌드된 걸 보면 그게 말이 안되듯..
반대로 버그는 가능한 빨리 잡는게 좋다고 해서 테스터에게 개발자가 매일 혹은 시간단위로 새로 직접 빌드를 해서 던져 준다고 하면 개발자의 시간을 뺏는 일이 아닐 수 없다.

걍 쉽게 말해서

테스터 : 제가 이거 저번에 에러라고 말씀 드렸잖아요. 아직도 안 고치셨나요?
개발자 : 아니.. 그거 수정했는데.. 당신이 돌리는 프로그램이 옛날꺼에요..
테스터 : 그럼 반영된 프로그램을 주세요!
개발자 : (빌드하기 귀찮아;;) 네.. 여기요..
..
테스터 : 이거 저번엔 제대로 되던거 왜 안되죠?
개발자 : 아! 다른 로직을 수정했더니 그 영향이 여기에 미쳤네요.. 진작에 알았으면 손이 덜 갔을텐데…
           (버그는 빨리 발견할 수록 좋음)
테스터 : ;; (뭐래; 그럼 미리미리 업뎃 파일을 주던가..)

혹은 빌드 할 때 몇 시간씩 걸리는 대형 프로젝트일 경우 개발자들이 ReBuild를 해보지 않고 소스를 커밋하는 경우가 많다. SVN에서 소스를 받아오고 새로 들어온 소스와 기존 소스가 잘 맞게 돌아가지 않는 경우도 있는데, 보통은 전체를 빌드하지 않고 변경 사항이 있는 파일에 대해서만 빌드를 수행하기 때문에 간~혹 변경 사항이 있는 파일만 빌드를 한 경우와 다르게 전체 리빌드시 컴파일 에러를 뿜어내는 경우도 발생 (무슨말이지..)

아무튼 주기적으로 가장 완벽한 빌드를 수행해서 빌드 에러를 찾아내는 것도 CI System의 역할

또! CI System은 가장 최신의 소스를 가지고 무언가를 하는 곳 이라는 전략적 요충지이기 때문에 CI와 관련 없어 보이는 많은 기능을 탑재하기 좋다. 예를들어 코드 품질 관리 시스템을 붙인다던지.. (예를 들어 Sonar)

Jenkins는 뭐지?

CI System을 해주는 Opensource Tool이다. 공짜라서 좋고 오픈소스중에 가장 유명해서 업데이트가 잦다. 원래 이름은 Hudson인데, 아니 Hudson 개발자가 퇴사하고 Jenkins를 만든거

무료 CI 툴 중에는 걍 이게 젤 좋아 보임. (전세계적으로도 많이 사용됨.. 팀장님이 실리콘밸리 갔다왔는데 젠킨스은 실리콘밸리에서도 가장 많이 사용된다고 했던 듯)

Jenkins는 어떻게 구축하지?

Jenkins를 구축하기 위해서 아래 사항을 염두하여야 한다.

1. 형상 관리 시스템이 있어야 한다. (SVN이나 Git)
2. 자동으로 빌드할 수 있는 무언가를 하여야 한다. (maven, ant)
3. 배포 전략도 고민하면 좋다. (빌드 후 TEST WEB Server로 올린다던지, 파일 시스템에 올린다던지..)

1. 형상 관리 시스템이 있어야 한다.

젠킨스는 주기적으로 개발자가 커밋한 소스를 받아와서 최신의 소스를 빌드한다는 목적이 있다.
그런데 형상관리 시스템처럼 최신의 소스를 가지고 있는 어딘가가 없다면 젠킨스를 사용할 필요가 없다.
(난 혼자 개발하고 여러명이 빌드 결과물을 보고 싶어하는데요? – 니 컴퓨터를 SVN 서버로 구축하세요 혹은 니는 굳이 젠킨스까지 구축할 필욘 없어보입니다.)

2. 자동으로 빌드할 수 있는 무언가를 하여야 한다.

빌드가 간단하다면 Jenkins에서 javac나 gcc 같은걸 직접 날리면 되긴 하다. ( 실제로 우리회사 C++ 제품 개발 연구소에서는 C 컴파일 명령어를 Jenkins가 그냥 날림 )
그런데 maven이나 ant 같은 빌드 관리 툴을 사용하면 더 쉽게 스크립트를 작성하여 빌드를 수행하도록 할 수 있다.

Maven 이나 Ant로 빌드를 어떻게 하나요?

Maven으로 빌드하는 스크립트는 인터넷에 엄청 많다. 상대적으로 Ant는 많지가 않은데 그래서 그런건 아니고 내가 Ant를 썼기 때문인데..ㅎㅎ 추후 포스팅은 Ant로 빌드 스크립트를 작성하는 것을 쓸 것이다.

3. 배포 전략도 고민하면 좋다.

SVN에 있는 최신의 소스로 빌드하여 따끈따끈한 결과물이 나왔다면 이를 어떻게 배포하여야 활용도가 좋아질지 고민하여야 한다. 우리 회사 C++ 연구소는 빌드한 결과물을 네트워크 망으로 특정 PC에 exe파일을 떨어뜨린다. 그래서 관심 있는 사람들이 파일을 복사해서 가져감.. 지금 내가 있는 웹 개발팀은 빌드하여 war로 압축하고 테스트 웹 서버에 바로 올려버린다. 결국 주기적으로 테스트 웹 서버의 결과물 페이지는 최신의 상태로 갱신된다.

추후 내가 고민했던 Jenkins와 연동된 최적의 Test 웹 서버 환경 구축에 대한 내용을 포스팅 할 예정

Jenkins 구축 후 반응이?

우리 팀은 신사업 신생아 팀이다. 그래서 CI가 없이 몇 달을 개발을 해왔는데, 그 몇 달 동안은

기획자 : 이거 해주세요
개발자 : 다 했어요. 이리와서 봐보세요. 이런 의미 맞죠?

혹은

기획자 : 나 확인해야 할 사항이 있는데요..
개발자 : (자기 피시 서버를 올리고) 제 IP로 주소 치고 들어와서 보세요. 확인하시는 동안 저는 좀 쉬어야 겠네요;

이거 였는데 지금은

기획자 : 이거 해주세요
개발자 : 테스트 서버에서 확인해보세요

하고 끝난다.

젠킨스가 빌드해서 테스트 서버로 배포까지 모든 과정을 자동으로 해주기 때문이다.

기획자도 개발자 눈치 안보고
개발자도 개발에 집중 할 수 있게 되었다.

업무 효율이란..

같은 시간을 투자해도 더 좋은 성과가 나오는게 업무 효율이 높은 것이다.

만약 누군가가 10분 개발 + 5분 인터럽트의 과정이 4번 반복되어 총 40분의 개발을 하였다면
이 사람은 40분 동안 온전히 개발에만 집중한 다른 사람보다 더 좋은 성과가 나오긴 힘들 것이다.

피터드러커가 말하길 지식 근로자에게 연속적인 시간 확보가 중요하다 라고 한 적이 있는데, 충분히 공감이 간다.

젠킨스는 그런 면에서 개발자에게 연속적인 시간 확보를 할 수 있도록 많은 도움을 준다.

기획자나 테스터 들에게 최신의 프로그램을 돌려보고 싶은 욕구를 참으라고 강요할 것인가?
아니면 당신이 일일이 수동으로 빌드해서 결과물을 던져줄 것인가?
아니면 자동화 시스템이 알아서 모든 것을 하게끔 맡길 것인가?

당신이 개발자라면 당신을 위해 젠킨스를 구축할 필요가 있을 것이고
당신이 PM 혹은 사장이라면 프로젝트와 회사의 업무 효율을 위해 구축할 필요가 있을 것이다.