지속적인 통합

지속적인 통합(Continuous Integration)이란

소프트웨어 개발 프로젝트는 다음 그림처럼 비슷한 생명 주기를 지니고 있으며 각 단계는 프로젝트가 진행되는 동안 계속 반복적으로 실행되는 경우가 많다.

개별 단계내에서 진행되는 업무 내역을 상세하게 분석해 보면 처리해야 할 업무가 생각보다 많으며 복잡하며 중간에 하나만 실수하거나 잘못되어도 상당히 많은 시간이 소요되는 경우가 많다.

이런 복잡성과 시간이 많이 소요되는 특성때문에 반복적인 단계를 잘 실행하지 않으며 이로 인해 개별 개발자가 작업한 내용을 통합하고 테스트하는 작업을 드물게 실행하거나 심지어는 프로젝트의 중반 이후에야 실행하는 경우가 많았다.

이로 인해 소프트웨어 통합 작업은 매우 힘이 들고 고통스럽고 시간이 오래 걸리는 작업이 되고 있었다.

지속적인 통합은 위와 같은 문제점을 해결하기 위해 개발 팀원들이 작성한 코드를 최대한 자주 통합하는 소프트웨어 개발 실천법중 하나이다.

버전 관리와 자동화된 빌드와 테스트, 리포팅을 통해 최대한 빨리 오류를 발견하고 발생한 문제를 조기에 처리할 수 있다.

이를 통해 통합에 드는 시간을 줄이고 발생하는 문제를 최소화할 수 있으며 고품질의 소프트웨어를 개발할 수 있다.

장점

지속적인 통합은 팀으로 일할 때 특히 참여자가 많고 규모가 큰 프로젝트일 때 장점이 더욱 두드러지지만 설령 혼자 일하는 개발자라도 많은 장점을 가져다 준다.

다음은 지속적인 통합을 구축했을 때의 장점이다.

빌드와 테스트 프로세스를 자동화하여 코드 작성에 더욱 집중할 수 있다.
자동화를 통해 수시로 통합할 수 있으며 이를 통해 문제를 조기에 발견하고 조치할 수 있다.
빌드와 테스트를 개인 환경과 독립적으로 구성할 수 있다. 즉 개발자가 코드를 수정하고 커밋하지 않아 개인 환경에서만 빌드되는 문제를 조기에 수정하게 해준다.
빌드한 결과를 톰캣이나 제티등 WAS 서버나 기타 환경에 디플로이 하는 업무를 자동화하여 프로세스를 간략하게 할 수 있다.
다른 개발자가 수정한 내용을 자동으로 빌드하고 통합 테스트를 진행할 수 있다.
현재 프로젝트의 코딩 표준과 모듈별 의존성등의 보고서를 빌드 과정에서 자동화하여 개선 여부를 검토할 수 있다.

모범 사례(Best Practice)

지속적인 통합을 잘 사용하기 위해서는 이미 사용하고 있는 곳에서 적용한 모범 사례를 참고하는 게 좋다. 다음은 일반적으로 지속적인 통합 적용시 반영하는 것을 권장하는 사례이다.

소스의 변경은 버전 관리 서버를 통해 관리하는 게 좋다.
소스가 변경되면 수시로 커밋한다. CVS나 서브버전은 분기(branch)와 병합(merge)이 어려워서 트렁크 트리에서만 커밋 하는 경향이 있으므로 소스의 병합이 어렵고 충돌이 많이 발생하는 문제가 있다.
또 미완성 소스 커밋으로 빌드가 깨질까봐 완성전까지 아예 커밋을 안 하는 나쁜 버릇을 갖게 되는 경우도 있다. 이 문제는 git 같은 분산 버전 관리를 도입하고 git flow 같은 검증된 분기 전략을 사용하여 해결하는 게 좋다.
수시로 빌드한다. 빌드는 매우 복잡한 절차를 거쳐야 하고 반복 작업 및 수작업을 통해 진행되는 경우가 많다. 빌드를 자동화하면 반복 작업이 줄어들고 프로세스가 단순화되므로 잦은 빌드가 가능해 진다.
빌드마다 자동화된 테스트를 구동하며 테스트가 100% 통과되도록 한다. 테스트 환경은 실제 운영 환경과 최대한 유사하게 구축한다.
모든 프로젝트 참여자가 빌드의 산출물과 빌드 결과를 확인할 수 있도록 한다.
빌드가 깨졌을 경우 테스트와 패키징등 다음 단계로 진행할 수가 없으므로 깨진 빌드를 수정하는 일에 우선순위를 높게 부여한다.
빌드 결과물을 WAS 등 외부 서비스에 디플로이 해야 한다면 가능하다면 지속적인 통합 서버에서 이런 작업을 자동화 한다. 단 운영 서버에 바로 디플로이하는 것은 많은 고려 사항이 있으므로 충분한 검토가 필요하다.

지속적인 통합 제품

현재 시장에는 다양한 지속적인 통합 도구가 출시되어 있다. 이중에는 오픈소스 기반으로 무료로 사용할 수 있는 제품도 있고 비용을 지불해야 하는 상용 제품도 있다.

상용 제품의 경우 일반적인 소프트웨어 라이선스는 사용자수에 따라 금액이 책정되는 경우가 많지만 지속적인 통합 제품은 이와는 약간 다르게 라이선스가 책정된다.

빌드는 시스템의 자원을 매우 많이 소비하는 부하가 상당한 작업이므로 분산 환경으로 여러 개의 빌드 서버를 동시에 운영하는 경우가 많다.

이런 개별 빌드 서버에 설치되어 빌드를 진행하는 프로그램을 보통 빌드 에이전트라고 하며 이런 에이전트를 몇 개를 설치할 수 있는지에 따라 라이선스가 달라지는 경우가 많다.

또 자바외에 MS 의 비주얼 스튜디오와 .NET 그리고 애플의 XCode 를 지원하는 제품들도 있으므로 이런 플랫폼에서도 지속적인 통합을 구축하겠다면 제품이 지원하는지 여부를 확인해 봐야 한다.

또 한가지 고려할 사항은 지속적인 통합은 이슈 관리와 밀접하게 연계하여 사용하게 되는 경우가 많다. 이슈 관리와 연계를 지원하는 제품이라면 다음과 같은 통합 관리가 가능하다.

빌드가 실패했거나 특정 테스트가 제대로 동작하지 않을 경우 새로운 이슈로 등록하고 처리 내역을 추적
"새로운 기능" 으로 등록된 이슈를 구현한 빌드 번호가 무엇인지를 이슈 관리 시스템에서 바로 확인
현재 빌드와 관련된 이슈가 어떤 것인지 지속적인 통합 시스템에서 확인

상용 버전의 경우 자사의 이슈 관리 시스템이 있으므로 기존에 이슈 관리를 사용하고 있었다면 동일 회사 제품을 사용하는게 통합과 관리 측면에서 훨씬 나을 수 있다.

위와 같은 필요성을 따져 보고 예산이 충분하고 잘 활용할 자신이 있을 경우 상용 제품을 도입하는 것도 좋은 선택이 될 수 있다.

상용 제품은 일반적으로 오픈소스 제품보다 잘 설계되고 사용이 편리한 GUI 화면을 제공하며 잘 정비된 매뉴얼과 교육, 기술 지원을 제공하므로 초기에 도입시 시행착오를 최소화할 수 있다.

이에 비해 오픈소스 제품은 라이선스 제한이 없으므로 비용이 발생하지 않으며 큰 장점이 있으며 제품들의 신뢰도와 안정성이 높아져서 기업 환경에서 사용해도 손색이 없다.

하지만 관리 기능과 GUI 가 상용에 비해 떨어지는 경우가 있으며 문서이 빈약하고 별도의 기술 지원을 하지 않으므로 경험 많고 기술력 있는 엔지니어가 없을 경우 도입시 여러 시행 착오와 어려움을 겪을 우려가 있다.

그러면 출시되어 있는 제품중에 많이 알려지고 사용자층이 두터운 대표적인 지속적인 통합 제품들에 대해서 알아 보자.

Cruisecontrol

오픈소스로 제공되는 제품으로 오래전부터 사용되어 온 도구이다. 단점은 업그레이드가 거의 안 되고 있으며 설정과 사용이 불편하다.

TeamCity

유명한 자바 IDE 인 IntelliJ IDEA의 개발사인 JetBrain 사의 제품이다. 무료로 사용할 수 있는 프로 페셔널 서버(Professional Server)와 상용인 엔터프라이즈 서버(Enterprise Serve)로 나뉘어져 있다.

프로 버전은 최대 20개의 빌드 설정이 가능하며 3개의 에이전트를 설치할 수 있다. 엔터프라이즈는 빌드 설정 제한이 없으며 에이전트의 수에 따라 가격이 달라진다.

Java 와 .NET, Ruby, XCode 를 지원하며 제트브레인사의 이슈 관리 시스템과 통합되어 있다.

기존에 제트브레인사의 이슈 관리 시스템을 사용한다면 도입을 검토해 볼 만한 가치가 있다.

Hudson

썬 마이크로 시스템즈의 엔지니어인 코수케 가와구치가 주도적으로 개발한 CI 제품이다. 오라클이 썬을 인수한 이후로 허드슨 개발 커뮤니티에 많은 이슈가 있었고 주요 개발자들은 허드슨 프로젝트를 떠나서 젠킨스 프로젝트를 만들었다.

오라클이 2011년에 이클립스 재단에 프로젝트를 기증하여 재단이 관리하고 있지만 프로젝트 창시자와 주요 개발자들은 별도로 갈라져나와 젠킨스 프로젝트를 진행하고 있다.

특별한 이유가 있지 않은 이상 허드슨보다는 젠킨스를 사용하기를 권장한다.

Bamboo

컨플루언스와 지라의 개발사인 atlassian 사의 제품이다. 아틀라시안 사의 다른 제품처럼 기업에서 사용하려면 돈을 주고 구매해야 하며 오픈 소스 프로젝트를 진행하면 무료로 제공하고 있다.

개인적으로는 가장 선호하는 솔루션으로 상용이므로 비용이 발생하는 단점이 있지만 자바외에 .NET 과 XCode 를 지원하며 잘 설계되고 미려한 UI 를 제공하고 있다.

또 아마존의 EC2 서비스를 지원하므로 EC2 내 가상 머신에 에이전트를 설치할 수 있다.

특히 자사 제품들과 완벽한 통합을 제공하는 장점이 있다. 이 기능을 사용하면 지라에서 뱀부의 빌드를 연결할 수 있으며 반대로 뱀부의 빌드에서 지라의 이슈와 연결할 수 있다.

이러면 지바의 특정 이슈를 해결하기 위한 빌드가 무엇인지 또는 현재 빌드에서 관련된 이슈가 무엇인지 와 고 하.NET 과 XCode 지원, 잘 서미려한 UI, 잘 구성된 매뉴얼, JIRA/FishEye 와 완벽한 통합 등의 장점이 있다.

활용 가능한 예산이 있다면 구매해서 사용해 보기를 권장한다.

Jenkins

OpenStack 의 CI 로 사용됨(http://ci.openstack.org/)

Why Choose Jenkins?

허드슨의 주요 개발자가 나와서 만든 프로젝트로 오픈 소스 CI 에서는 압도적인 사용자를 보유하고 있다.

많은 사용자와 플러그인 개발자가 있으므로 다양한 기능을 제공하고 많은 자료가 있다. 최근에는 오픈소스 클라우드 컴퓨팅 플랫폼인 오픈스택(OpenStack)의 CI 솔루션으로 채택되기도 하였다.

이 책에서는 젠킨스를 기반으로 CI 환경을 구축하는 방법을 설명할 것이다.

저장소 관리와 지속적인 통합/배포