[번역] 허드슨을 이용한 지속적인 통합(Continuous integration with Hudson) #4

허드슨 CI 서버(Hudson CI server)에 대한 네 번째, 마지막 번역분량입니다.

네. 그렇습니다. 이번엔 발로 번역했습니다. (상상은 자제를..-,-);; .. 고로, 한국어를 번역해야 하는 부분이 충.분.히 있을 수 있습니다.

가급적 너그럽게 보시고, 혹시 의미를 곡해하는 부분이 있으면 알려주세요. 수정하도록 하겠습니다.. 라고는 하지만, 아무도 뭐라하는 사람이 없어서 마음편하게 썼습니다. (하.하.하! 이제 부턴 새출발을!)

...

본 글은 자바월드(http://www.javaworld.com/)에 기고된 글을 번역한 것으로 허드슨(Hudson)에 대해서 매우 상세하게 설명되어 있어서 CI 서버가 생소한 사람들도 어렵지 않게 따라갈 수 있도록 되어있습니다.

원문은 http://www.javaworld.com/javaworld/jw-12-2008/jw-12-hudson-ci.html 에서 살펴보실 수 있습니다.

--------- started here ------------

빌드 트랙들 Build tracks

허드슨은 복수개의 빌드 트랙을 만들수 있게 해준다. 당신의 소프트웨어 개발 절차에 따라, 당신은 소프트웨어 프로젝트 당 하나 이상의 빌드 트랙을 만들어 내기를 원할 수 있다. 빌드 트랙은 고유한 설정을 갖고 있는 하나의 특정한 프로젝트나 프로덕트를 위한 빌드 업무이다. 동일한 프로젝트에 대한 빌드 트랙들을 서로 구분짓는 요소들은 해당 빌드 업무에서 가져온 소스 코드의 SCM 브랜치(branch)가 될 수도 있다. (즉 한 프로젝트 내에서 브랜치가 여러개 발생하면, 그에 따라 빌드들이 개별적인 '트랙'이라는 형태로 존재하게 될 수 있다는 이야기이다) 다른식으로는, 서로 다른 트랙들이란 같은 소스에 대해 수행하게 되는 서로 다른 작업들의 세트가 될 수도 있다. 논리적으로 동일한 소프트웨어 프로젝트에 대해 어떻게 서로 다른 빌드 트랙들을 만들지를 지시하는 것에 따른 영향은 다음과 같다.

• 소스 컨트롤 브랜치들(Source control branches): 많은 개발 팀들은 그들의 소스 컨트롤 시스템에서 소스 코드의 여러 버전에 대한 개발을 동시에 깔끔히 지원하기 위해서 일련의 브랜치들을 유지해 나간다. 이와 같은 경우에, 오래되어 사용하지 않는 브랜치들에 대해서 뿐 아니라, 개발에 사용되는 각각의 브랜치에 대해서 분리된 빌드 트랙을 만드는 것은 사리에 맞는다. (여기에서 구버전들을 관리하는 이유는 소프트웨어의 구 버전들이 카탈로그화 되어서 경우에 따라서는 쉽사리 다시 만들어 내기 위해서이다)
  • 트렁크 빌드: 가장 최신의 활성화된, 그리고 종종 변경이 일어나는 기반 소스
  • 릴리즈 빌드: 지속적인 릴리즈에 한정되어 있는 개별 분리된 브랜치. 소스 코드는 대부분 안정화 되어 있다. 하지만 트렁크 개발은 향후 릴리즈를 위해서 지속적으로 변경된다.
  • 버그 수정 빌드: 메인라인(=trunk) 활동으로부터 격리된 상태에서 버그를 수정하기 위해 생성된 개별 브랜치
  • 실험적인 빌드: 기반 소스에 실험적인 아이디어를 테스트 하기 위해서 생성된 개별 브랜치. 결국엔 메인라인 소스가 되지 않을 수 있음.
• 빌드 업무 작업 카테고리들: 다른 소스 기반에 대한 빌드는 어떠한 특정 브랜치들의 현재 활동이나 상태에 따라 다른 빌드 세트나 연속적인 빌드 작업이 필요할 수도 있다. 예를 들면, 다음과 같은 경우에 개별 트랙들을 구축하길 원할 수도 있다.
  • 안정성에는 관심이 없지만 빌드 여부와 빌드 아티팩트들이 사용가능 여부를 정기적으로 심플하게 확인하길 원하는 경우 같은 간단한 빌드 확인 업무(Simple build verification jobs)
  • 다소 띄엄띄엄 수행할 수도 있는, 그리고 아티팩트들을 빌드하고 소스 코드와 빌드된 아티팩트들에 대해서 풀 테스팅 스위트를 수행하는, 빌드와 안정성 확인 빌드(Build and stability verification builds)
  • 전체 빌드와 안정성 테스트 스위트들을 수행하고 배포를 위해 전달하게 되는 것들을 패키징하기 위한 일련의 작업들을 완료하는 릴리즈 후보 업무(Release candidate jobs)
  • 릴리즈 후보가 배포를 위해 준비되고 패키지된 아티팩트들이 공개 저장소에 자동적으로 업로드 되었을때, 전체 릴리즈를 완료하기 위해 필요한 다른 작업들과 함께 수행되는 전체 릴리즈 업무(Full release jobs )
• 전달가능한 고려사항들: 정확하게 동일한 코드 브랜치와 빌드 작업은 다소 다른 툴을 사용해서 빌드될 필요가 있을 수 있다. 예를 들면, 당신은 당신 클래스들의 버전들을 자바 1.5용과 자바 1.4용으로 분리해서 릴리즈 하도록 원할수 도 있다.

그림29는 소스 컨트롤 브랜치들과 그에 관련된 허드슨 빌드 트랙들 사이에서 생길 수 있는 논리적인 구조를 보여준다.

그림29. 소스 컨트롤 브랜치들과 허드슨 빌드 트랙들

허드슨은 기존 빌드 업무를 복사하는 식으로 새로운 빌드 업무를 쉽게 만들수 있다. 그렇게 하기 위해서는, 허드슨 대시 보드로 가서, New Job 링크를 클릭한다. 새로운 빌드 업무의 이름을 입력한 다음 Copy existing job 을 선택한다. 당신이 타이핑을 시작할 때에, 허드슨은 당신이 타이핑하는 것과 일치하는 복사 가능한 기존 빌드 업무 목록을 보여준다. 그리고 나서 OK를 누르면, 새로운 빌드 업무가 만들어질 것이다. 이 절차는 그림 30에서 보여주고 있다.

그림30. 기존 빌드 업무를 복사해서 새 빌드 업무 생성하기

당신은 이미 이런식으로 새 빌드 업무를 한번 만들었을텐데, 빌드 업무의 이름을 제외하고는 기존 빌드 업무를 복사한 것과 실제로 동일하다. 그래서 항목을 변경하는 식으로 새로운 복사본을 변경하고 싶을 것이다. 예를 들면 다음과 같은 작업을 원할 수 있다.

• 워크스페이스가 가져온 소스 컨트롤 대상 브랜치를 수정하기
• 허드슨이 실행할 빌드 스크립트나 빌드 스크립트 대상을 수정하기
• 허드슨에서 Ant 스크립트로 넘길 시스템 파라미터 수정하기

뷰 사용하기 Using views

이미 당신은 몇 개의 빌드 트랙을 만들었기에, 당신의 대시보드가 긴 빌드 업무 목록으로 다소 어지럽게 되었다고 느낄 수 있다. 대시보드를 정리하는 쉬운 방법은 뷰(Views)를 만드는 거다. 대시보드 뷰는 대시보드에 분리된 탭안에서 보여지는 연관있는 빌드 업무들의 그룹이다. 그리고 그 그룹은 당신이 임의로 정의할 수 있다. 관련있는 빌드 업무들을 그룹핑하는 뷰를 만들 때, 일관성있는 빌드 업무 네이밍 컨벤션을 구현하는 것이 유익하다는 것을 알게 될 것이다.

뷰를 만들려면, 대시보드에 + 로 라벨이 붙은 작은 탭을 클릭하여라. 새로운 뷰 페이지에서, 새로운 그룹의 이름과 선택적인 설명을 입력하여라. 당신이 해당 뷰에 포함하길 원하는 특정 빌드 업무를 선택할 수 있도록 허드슨은 현재 설정된 모든 빌드 업무에 대해 라벨 붙은 체크박스를 제공할 것이다.

그러나, 내 생각하기에 빌드 업무의 그룹을 만드는 더 나은 방법은 Use a regular expression to include jobs in the view(뷰에 빌드 업무를 포함하기 위해서 정규 표현식을 사용하기)라고 이름붙은 체크박스를 클릭해서 당신이 그룹에 포함시키기를 원하는 빌드 업무의 이름을 매치시킬 수 있는 정규 표현식을 적는 것이다. 이게 바로 손쉬운 일관성 있는 네이밍 컨벤션이다. 당신은 일반적인 소프트웨어 프로젝트나 혹은 가능한 경우, 빌드 타입으로 빌드 업무를 하나로 그룹핑하는 뷰를 설정할 수 있다. 나는 후자의 접근법을 선택하고, 그림31에서처럼 빌드 업무에 release 라는 단어가 들어간 모든 빌드 업무를 포함하는 릴리즈 빌드(Release Build)라고는 이름의 뷰를 만들었다.

그림31. 대시보드 뷰 만들기 F

정규 표현식으로 빌드 업무를 포함시키는 방법을 사용했을 때의 추가적인 이점은 새로운 빌드 업무가 생길때, 빌드 업무 이름과 매치되는 어떤 뷰에든 자동적으로 추가될 것이라는 점이다. 반면에 특정 빌드 업무를 선택해서 그룹핑하는 뷰는 손수 업데이트를 해주어야 한다.

그림32는 빌드 타입 기반으로 새롭게 정리된 대시보드를 보여주고 있다.

그림32. 빌드 타입으로 나눈 대시보드 뷰

허드슨 플러그인들 Hudson plugins

허드슨 플러그인이라는 말은 허드슨의 기존 기능을 확장하는 라이브러리들과 허드슨에 새로운 기능을 추가하기를 원하는 개발자들용 확장성을 제공하는 방법, 이 두가지를 다 의미할 수 있다. 어떤 플러그인들은 단순히 당신의 빌드 프로세스에 유용한 추가기능이 될 수도 있고, 혹은, CVS나 Subversion 이외의 다른 소스 컨트롤 시스템을 지원하기 위해 구현한 SCM 플러그인, 환경구축시에 허드슨을 사용하기 위해 필요한 무언가가 될 수도 있다.

현재 수 많은 플러그인들이 사용가능한 관계로, 여기에서 모든 리스트를 다루진 않을 것이다. 하지만, 일반적인 플러그인 카테고리는 다음과 같다.

• SCM: 허드슨이 CVS나 서브버전이외의 소스 컨트롤 시스템을 지원하기 위해 구현한 플러그인들
• 트리거들: 이벤트를 감시하고 빌드를 촉발하는 플러그인들. 예를들자면, URL 변경 트리거는 URL을 감시할 것이다. 해당 주소에 있는 컨텐트가 변경되면, 트리거는 빌드 업무를 수행할 것이다.
• 빌드 도구들: MSBuild나 Rake 같은 추가적인 빌드 도구를 구현한 플러그인들. 이 플러그인들은 허드슨에서 자바가 아닌 소프트웨어를 빌드하고자 할 때 매우 유용하다.
• 빌드 랩퍼들(Build wrappers): 자신의 빌드 프로세스 전 후에 제어된 이벤트들을 수행하는 것에 특별히 관련된 플러그인들. 예를 들면, VMware 플러그인은 빌드 전에 게스트 VM을 시작시키고, 빌드가 끝난 다음에 중지시킬 것이다. 단위 테스트들을 수행하기 위해서 게스트 VM이 필요한 상황에서 유용하다.
• 빌드 공지 관련(Build notifiers): 이 플러그인들은 빌드 업무 이벤트 관련 공지를 발행하는 대안 방법들을 지원해 준다. 대안 방법에는 Twitter나 IRC, 구글 캘린더 이벤트 같은 것들이 있다.
• 슬레이브 런처와 컨트롤러들(Slave launchers and controllers): 본 글에서 소개되지 않은 허드슨의 매우 강력한 기능 중 하나는, 마스터 허드슨 인스턴스를 대신해 작업을 수행하는 슬레이브 허드슨을 가지는 능력이다. 현재 이 카테고리에는 단 하나의 플러그인 만이 존재한다. SSH 링크를 통해 슬레이브를 관리하는 SSH 슬레이브 플러그인이 바로 그것이다.
• 빌드 보고서들(Build reports): 당신의 소스코드난 생성된 아티팩트를 분석한 몇가지 양식에 기반한 유용한 보고서들을 만드는 일련의 플러그인 들이다. 예를 들면, Cobertura 플러그인은 당신의 빌드 스크립트에 의해 생성된 지속적 커버리지 보고서들을 모은다.
• 외부 사이트 통합(External site integrations): 허드슨과 Jira나 버그질라 같은 다른 어플리케이션들을 통합하는 걸 도와주는 플러그인들
• 아티팩트 업로더(Artifact uploaders): java.net 파일 저장소나, FTP 서버 같은 어떤 네트워크로 연결된 종단점에 빌드된 아티팩트 배포를 돕는 플러그인들
• 페이지 데코레이터(Page decorators): 허드슨 웹 페이지의 미관을 꾸미거나 치장하는데 유용한, 몇 몇 플러그인들. 허드슨에서 제공하는 모든 페이지들에 구글 트래킹을 추가하는 구글 애널리틱스(Google Analytics) 같은 플러그인.

허드스 플러그인 매니저는 당신의 허드슨 서버에 새로운 플러그인들을 인스톨하고 기존 것들을 업데이트할 수 있게 해준다. 이 매니저는 사용가능한 플러그인들과 플러그인 업데이트 목록을 가져오기 위해 온라인 저장소에 접속할 것이다. 만일 당신의 허드슨 서버가 외부 리소스에 접속할 수 없다면, 허드슨 웹사이트에서 당신이 원하는 플러그인들을 다운로드 할 수도 있다. 사이트에서 plugins 폴더를 클릭하면 사용가능한 플러그인 목록을 보게 될 것이다. 개별 플러그인 파일들은 .hpi 확장자를 갖는다. 당신이 플러그인을 다운받은 다음에는, 허드스 홈 디렉터리에 있는 플러그인 하위디렉터리에 해당 플러그인을 복사한다. (허드슨 홈 디렉터리는 .hudson 이라고 불리고, 허드슨 서버를 운영하는 사용자의 홈 디렉터리에 위치할 것이다.) 일단 해당 플러그인 파일이 복사되고 나면, 플러그인이 동작하도록 허드슨을 재시작 할 필요가 있다.

허드슨 플러그인 매니저를 사용하기 위해서는, 대시보드에서 Manage Hudson 링크를 클릭한 다음, Manage Plugins 를 클릭한다. 플러그인 매니저는 그림33에 보여지고, 해당 매니저는 4개의 탭을 갖고 있다.

• 업데이트들(Updates): 허드슨이 업데이트 가능하다고 탐지한 플러그인 목록. 리스트에 올라있는 각각의 플러그인은 업데이트를 적용하기 위해해서 선택될 수 있다.
• 사용가능한 것들(Available): (현재 설치되어 있지 않은) 설치 가능한 플러그인 목록. 리스트에 올라있는 각각의 플러그인은 인스톨하기 위해서 선택가능하다.
• 인스톨(Install): 이미 설치된 플러그인 목록
• 고급(Advenced): 허드슨이 온라인 플러그인 저장소와 통신할 수 있도록 거쳐야 하는 HTTP 프록시를 설정할 수 있게 해준다. 추가적으로, 허드슨 외부에서 다운로드한 플러그인들을 설치하기 위해 사용할 수 있는 업로드 기능이 있다.

그림33. 허드슨 플러그인 매니저

일단 당신이 원한 플러그인이나 업데이트가 설치되면, 허드슨은 그것들을 적용하기 위해 재기동 되어야 한다. 만일 당신이 JBoss 를 사용한다면, 최초에 당신이 디플로이한 JBoss 디플로이 디렉터리에 있는 hudson.war 파일을 터치(unix의 touch)하는 걸로 효과를 발휘시킬 수 있다는 걸 주목해라. (touch는 특정 파일의 타임스탬프를 업데이트 하는 유틸리티이다)

어떤 종류들의 빌드 보고서 플러그인들을 이해하기 위한 한 가지 중요한 컨셉은, 그것들이 당신을 위한 핵심 보고서를 반드시 생성하는건 아니라는 점이다. 그보다는, 보고서들이 생성될때마 지속적으로 보고서들을 모으는 추가적인 작업에 관심을 갖는다. 어떤 경우에는, 생성된 보고를 통합된 허드슨 네이티브 보고서로 다시 포맷팅해서 생성해 낼 것이다. 예를 들면, Cobertura 플러그인은 당신의 대상 테스트 클래스들의 절차를 구현하고 단위테스트를 수행하고, 해당 빌드 한정의 커버리지 보고서를 생성할 빌드 스크립트가 필요하다. 그러면 해당 플러그인은 동작중인 히스토리컬 커버리지 경향 보고서를 업데이트 한다. 그렇게해서 당신은 당신의 커버리지 퍼센트율이 시간에 따라 어떻게 변해가는지 비주얼화 할 수 있다. 이들 경향 보고서의 예제는 그림 34에서 볼 수 있다.

그림34. 단위 테스트들, 정적 코드 분석, 코드 커버리지에 대해 이력으로 남은 경향들

추가로, JUnit 테스트 결과들과 FindBugs 들은 빌드 업드 홈페이지나 인스턴스 홈 페이지에 표시되는 허드슨 네이티브 보고서를 만들어 내느 플러그인의 예시들이다. (JUnit 플러그인은 사실 빌트인 되어있어서 설치할 필요가 없다) 그림35는 빌드 인스턴스 페이지에 볼 수 있는 FindBugs 플러그인에 의해 생성된 빌트인 보고서의 예시이다. .

그림35. 빌드에 대한 FindBugs 요약 보고서

당신은 당신 생각가능한 어떤 종류의 허드슨 확장이든 실제로 제공하기 위해서 당신 스스로 플러그인을 구현할 수 있다. 만일 당신이 플러그인 확장을 구현하는데 관심이 있다면, 허드슨 위키에서 레펀런스와 문서, 그리고 튜터리얼을 찾을 수 있다. (아래 부분에 있는 리소스 섹션을 보길)

결론

이로서 허드슨 지속적인 통합 서버에 대한 소개는 끝이났다. 나는 허드슨이 끝내주는 소프트웨어라는걸 당신이 알게 될거라 생각한다. 쉬운 설치와 설정 덕분에, 당신은 매우 빠른 시간안에 구축해서 띄우고 동작시켜 볼 수 있다. 허드슨 개발 프로젝트가 자리잡고 있는 java.net 사이트에서의 활동 규모를 근거로 놓고 봤을때, 허드슨은 확실히 강한 추진력을 갖고 있다. 내가 띄엄띄엄 보곤하는 메일링 리스트에서도 사람들이 일관되고 빠르게 그들의 질문에 대한 응답을 받는 것을 알 수 있다. 언젠가는 내가 해당 내용을 필요할 날이 올 수도 있게지만, 어쨌든 현재까지는 지원을 찾기 위해 날 멈추게 하는 이슈에 맞닥드려본 적은 없다. 나는 당신이 허드슨에 대해 함께 탐험해 본 것을 즐겼길 바란다. -- 더 많은 글과 다운로드꺼리, 관련 링크는 아래의 리소스 섹션을 체크해 보아라.

저자에 대해

Nicholas Whitehead 은 시니어 테크놀로지 아키텍트이다. (a senior technology architect at the Small Business Services division of ADP in Florham Park, N.J.)

리소스들(Resources)

Downloads

• Get the latest Hudson WAR file here or here.
• Download apache-tomcat-6.0.18.exe to install Tomcat on your Windows machine. Download JBoss 4.2.3.GA for a Linux environment (look for the file named jboss-4.2.3.GA.zip).
• Ant is the build tool used for examples in this article.
• jboss-init.sh enables the automatic start and stop of the JBoss server.
• If your Hudson server cannot connect to outside resources, you can download the plugins you need from the Hudson Website.

Learn more

• "Introducing continuous integration" (Paul Duvall, Steve Matyas, Andrew Glover; JavaWorld, 2007): Get an overview of CI in this chapter excerpt from Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Professional, June 2007).
• "Which open source CI server is right for you?" (John Smart, JavaWorld, 2006): Introduces and compares four top CI servers -- CruiseControl, Continuum, Luntbuild, and Hudson.
• Java Power Tools author John Smart talks shop about tools he's most likely to use for his own projects, including Hudson, in this podcast episode of JavaWorld's Java Technology Insider.
• Check out the Hudson project on Java.net.
• If you're ready to start using Hudson seriously, you should study up on best practices (from the Hudson Wiki). You might also want to be aware of CI anti-patterns (Paul Duvall, IBM developerWorks, December 2007).
• Hudson was the most used CI server in an informal developer survey in 2008. Learn more about the results here.
• The procedure for installing JBoss outlined in this article has been condensed from this useful thread in the Ubuntu forums.
• Check out the complete list of SCM plugins for Hudson.
• Find out more about the Hudson FindBugs plugin.
• If you are interested in implementing your own plugin, check out these references, documentation, and tutorials.
• Learn more about Cobertura.
• Read the Quartz CronTrigger javadoc for information on the cron syntax Hudson uses