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

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

이번 회는 허드슨 CI 서버(Hudson CI server)에 대한 두 번째 번역입니다. 이번에는 '허드슨에서 빌드 세팅하기'에서 '빌드 업무(build job)을 설정'하는 부분까지 입니다. 번역 분량이 적지 않다보니, 다소 시간이 걸렸습니다. 자세하게 다듬지 않아 내용이 어색할 수 도 있습니다만, 가급적 너그럽게 보시고, 혹시 의미를 곡해하는 부분이 있으면 알려주세요. 수정하도록 하겠습니다.

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

그럼, 밝고 희망찬 새해 되세요. 감사합니다. :)

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

허드슨에서 빌드 세팅하기(Setting up a build in Hudson)

당신은 윈도우즈XP에서 동작하는 톰캣, 혹은 우분투 리눅스에서 동작하는 JBoss 에 허드슨을 인스톨하는 절차를 지금까지 겨쳐왔다. 대부분의 단계들은 운영체제에서 어플리케이션 서버를 설치하고 관리자 작업을 수행하는 것에 관련되어 있었다.; 나는 당신이 허드슨을 인스톨 하는 것 그 자체는 사소한 부분이라는 것에 동의하리라 생각한다. 다음으로는, 빌드 업무를 구축할 수 있도록 허드슨에서 필요한 몇 가지 기본 설정 방법을 보게 될 것이다.

전제조건

빌드 업무(build job)를 셋업하기 전에, 아래와 같은 조건들이 반드시 만족되어야 한다.

• 접근 가능한 소스 코드 저장소(repository)가 있어야 한다.
• 저장소는 빌드를 필요로 하는 소스 코드를 담고 있어야 한다.
• 저장소는 소스를 빌드하는 빌드 스크립트를 반드시 포함하고 있어야 한다. 허드슨이 간단한 쉘을 지원하지만, 여기서 말하는 스크립트는 보통 Ant 나 Maven 스크립트, NAnt 나 MSBuild 같은 빌드 스크립트를 말한다.

본 글에서는, 예제 소스를 빌드하는데 Ant version 1.7 을 사용할 것이다.

허드슨 설정하기

소프트웨어 빌드작업을 시작시키기에 앞서 허드슨에 있는 몇 가지 마이너한 설정에 주의를 기울일 필요가 있다. 우선, 허드슨에게 JAVA JDK 와 Ant 의 인스톨위치가 어디인지 알려주어야 한다. http://localhost:8080/Hudson의 허드슨 메인 페이지에서, Manage Hudson 링크를 클릭하여라. 이어지는 페이지에서, Configure System 을 클릭한다.

시스템 설정 페이지에서, 목록의 첫 번째 항목인 Home directory 를 주의 깊게 보기 바란다. 이곳이 바로 허드슨의 모든 설정이 저장되고 모든 작업이 이루어지는 곳이다. 본 글의 뒷 부분에서 이 디렉터리를 다시 살펴볼 것이다.

JDK와 Ant 인스턴스 둘 다 설정하기 위해서, 각각의 섹션 하단에 있는 Add 버튼을 누르자. 한 세트의 필드들이 설정 섹션 아래로 확장될 것이다. 이들 두 개의 섹션은 그림 10에서 보여주고 있다.

그림10. Ant와 JDK 설정하기

각각의 경우에 있어, JDK와 Ant 인스톨을 식별해 주는 임의의 이름을 할당한다. 당신의 프로젝트 요구사항에 따라서 복수개의 인스턴스가 설정될 수 있기 때문에 겹치지 않는 임의의 이름을 할당할 필요가 있다. 예를 들면, 당신은 Java JDK 1.4, 1.6, 그리고 1.7용 인스턴스와 Ant 1.6, 1.7 용 인스턴스를 갖고 있을 수도 있다. 당신이 당신 프로젝트 빌드를 설정할 때에는, 사용하기 원하는 인스턴스를 선택하는 것이 가능하다.

현재 빈 공백 필드로 보여지고 있는 JAVA_HOME과 ANT_HOME이 유효한 디렉터리가 아니라는 걸 허드슨이 즉각적으로 당신에게 알려준다는 점에 주목하길 바란다. 유효한 디렉터리가 입력되면, 경고가 사라지게 될것이다. 이게 바로 허드슨이 유저 친화적이라고 말할 수 있는 간단한 예의 하나이다. 허드슨은 디렉터리를 찾게 될 때야 비로소 에러가 발생하게 되는 방식이 아닌 즉각적인 피드백을 준다.

나는 이미 Java 1.6 JDK를 설치했기 때문에, 다음과 같이 JDK 인스톨 정보를 설정할 수 있다.

• name: JDK 1.6.0_07
• JAVA_HOME:
  • Windows: C:\jdk1.6.0_07
  • Linux: /usr/lib/jvm/java-6-sun

만일 당신인 윈도우즈를 사용하고 있다면, 간단하게 Ant 설치파일 을 다운로드 받아 대상 디렉터리에 압축을 풀어버리면 된다. 우분투라면, Ant 를 설치하기 위해 아래와 같은 명령어를 사용할 것이다.

sudo apt-get install ant
sudo apt-get install ant-optional
ant -version
Apache Ant version 1.7.0 compiled on August 29 2007

우분투의 인스톨 명령은 Ant를 /usr/share/ant 에 설치할 것이다.

그림11은 우분트에서의 JDK와 Ant 설정을 보여주고 있다. 인스톨된 위치를 지정하는 필드들을 입력하면, 경고표시가 사라진다. 나는 올바르지 않게 설정된 Ant의 두 번째 인스턴스를 또 하나 추가했다. 만일 당신이 Ant 인스턴스가 설치된 올바른 디렉터리는 아니지만, 유효한 디렉터리 경로를 입력했다면, 그림에서처럼 당신이 입력한 항목이 올바르지 않은 것 같다는 허드슨의 경고를 보게 될 것이다. JDK나 Ant 둘 다 마찬가지다. 나는 그 후에 이 잘못된 Ant 항목을 지웠고, 유효한 것 하나만 남겼다.

그림 11. 우분투에서의 JDK 와 Ant 설정

같은 폼의 약간 아랫부분에서는, 실행가능한 CVS 의 장소를 지정할 수 없 다는 경고가 보일 것이다. 만일 CVS를 사용하지 않는다면, 가볍게 무시해도 된다.

이 페이지에서 중요한 마지막 항목은, 허드슨이 빌드 실패 같은 중요한 이벤트들을 이메일로 당신에게 알려줄 수 있게 하는 SMTP 설정이다. 만일 당신의 SMTP 서버가 인증를 필요로 한다면, 고급 옵션(advanced)을 사용할 필요가 있다. 나는 내 Google Apps 호스트 도메인을 사용한다. 하지만, 만일 당신이 Gmail 계정을 가지고 있다면, 당신은Google SMTP 서버와 Gmail 어드레스를 사용할 수 있다. 그림12에서 보이는 것이 본인의 허드슨 서버 이메일 설정이다.

그림12. 구글 메일 서버를 이용한 허드슨 SMTP 발송 설정 (클릭하면 확대됨)

기본적인 시스템 레벨의 설정은 이제 끝났다. 당신은 이제 특정 빌드 작업(build job)을 설정할 준비가 되었다.

허드슨에서 빌드 업무 설정하기 (Configuring a build job in Hudson)

http://localhost:8080/Hudson 에 있는 허드슨 메인 페이지에서, New Job 링크를 클릭하여라. 그림 13은 그 다음에 나타날 화면을 보여주고 있다. 여기에서, 당신은 새로운 빌드 업무(build job)에 이름을 할당한다. 새로 빌드 업무 만드는 데에는 몇 가지 옵션이 있다. 하지만, 이 글의 범위에서는, Build a free-style software project 라고 이름 붙여진 타입에 집중할 생각이다. 내가 종종 사용하는 다른 옵션 타입 하나는 Copy existing job 이다. 이 타입은 이미 존재하는 빌드 업무를 복사해서 새 빌드 업무를 만들고자 할 때 손 쉽게 사용 가능한 타입이다.

그림13. 새로운 업무(Job) 이름 (마찬가지로 클릭하면 확대 됨)

본 예제에서는, java.net의 Subversion에 저장되어 있는 HeliosJMX 프로젝트 용 빌드 업무를 세팅할 예정이다. 나는 trunk에서 바로 꺼낸 신선하고 따끈따끈한 소스를 빌드할 예정이기 때문에, 해당 빌드 업무를 HeliosJMXTrunk 라고 이름붙였다. 그렇게 이름을 입력한 다음, OK 를 클릭했다.

다음으로는 새로운 빌드업무에 대한 다량의 설정 항목이 꽤 길게 이어진다. 이 설정의 상세한 내용은 아래 목록과 같다. 이 폼에 있는 각각의 옵션 오른쪽에는 작은 물음표(?) 아이콘이 있다. 어떤 설정 옵션이던지 좀 더 상세화된 설명을 보려면 망설이지 말고 클릭해라. 클릭한다고 해서 다른 페이지로 이동되어 버리는 식으로 진행중인 작업내용이 소실되거나 하진 않는다. 대신에, 허드슨은 도움말을 바로 페이지 안으로 간단히 나타나게 한다. 그래서 도움말 기능(Help)을 사용하는 것은 무시해도 좋을 정도로만 참견한다. 사실상 이 모든 설정들은 윈도우즈나 리눅스 둘 다 동일하다.

• 프로젝트 이름(Project name): 난 이미 HeliosJMXTrunk 라고 프로젝트 이름을 지었지만, 여기에서 바꿀 수 있다.
• 설명(Description): 빌드 업무에 대해 기술할 수 있는 자유 형식 폼 필드
• 오래된 빌드 버리기(Discard old builds): 허드슨은 이 체크박스를 선택하지 않는다면, 이전 기록을 보관할 것이다.
• 이 빌드작업은 파라미터화 됨(This build is parameterized): 만일 이 옵션을 선택하면, 허드슨은 빌드 프로세스에 전달 가능한, 이름-값 쌍으로 이루어진 임의의 파라미터 세트 제공을 허락 할 것이다. 설정 파라미터들은 러닝 빌드 환경에서 환경 변수로 지정될 것이다.
• 프로젝트 기반 보안 활성화(Enable project-based security): 허드슨은 유저들이 허드슨 웹 페이지를 접근할 때 인증작업을 하기 위한 전체 보안 스키마를 지원한다. 또한 이 보안 스키마는 어떤 유저들이 어떤 빌드 업무를 건드리는 것이 가능한지에 대한 제어를 제공할 수 있다. 나는 이 허드슨 인스턴스에서 보안은 설정하지 않았다.
• 빌드 불가(Disable build): 이 항목이 체크되면, 옵션이 비 활성화 될때까지 이 빌드 업무는 실행되지 않을 것이다.
• 고급 옵션(Advanced options): 나는 이 옵션 중에 사용하는 것은 없다. 하지만 이 체크 박스를 선택하면, 다음과 같은 옵션들이 인터페이스에 나타나게 된다.
  • 정숙 기간(Quiet Period): 빌드 수행이 예정되었을 때 실제 수행 이전에 발생하는 정숙 기간(=휴지기간)을 설정할 수 있다. (즉, Delay time과 동일의미, 0 이면 build now! 의 의미)
  • 커스텀 워크스페이스를 사용(Use custom workspace): 기본적으로, 허드슨은 ${jboss-home}/.hudson/jobs/[project name] 에 빌드 업무용 워크스페이스를 만든다. 이 옵션은 당신 다른 장소를 지정하는 것을 가능케 해준다.
• 소스 코드 관리(Source code management): 기본적으로 사용 가능한 세 가지 옵션은 다음과 같다.
  • Subversion
  • CVS
  • None
  None 옵션은 소스 코드 저장소가 선행조건이라고 앞서 말한 나의 단정사항에 위배된다. 그러나 대부분의 경우에 있어, 허드슨과 함께 어떤 유용한 일을 하려면 종류는 어찌되었든 저장소가 필요하다는 걸 여전히 지지한다. 이 글 뒷부분에서, 허드슨 플러그인들이 어떻게 설치되는지 소개할 것이다. 만약 당신이 SCM 관련 플러그인을 설치한 다음 허드슨을 재시작하면, 이 목록에 새로운 옵션이 보이게 될 것이다. 이 글에서, 나는 Subversion 을 사용하고 있다. 당신이 Subversion을 선택한다면, 설정 섹션이 폼에 확장되어 나타날 것이다. 다음 섹션에서 이 섹션에 대한 설정을 따로 소개할 것이다. ("서브버전 업무 설정"을 볼것)
• 다른 프로젝트들이 빌드 된 다음에 빌드(Build after other projects are built): 이 옵션은 (한 업무가 다른 업무의 결과물에 의존을 갖는 업무 의존성) 조립 라인이나 몇 개의 관련 프로젝트를 그룹으로 묶어 간단히 함께 빌드하길 원하는 것 같은 시나리오를 지원한다. 이것을 선택하면, 이 빌드가 실행하기 전에 먼저 실행할 콤마(,)로 분리된 다른 프로젝트 이름들을 입력하기 위한 필드가 제공될 것이다.
• SCM 폴링(Poll SCM): 이것은 CI 시스템들을 위한 고전적인 옵션이다. 이 옵션을 선택하면, 얼마나 자주 허드슨이 당신의 저장소 변경을 체크할 것인지를 정의하는 크론 표현식(cron expression)을 지정할 수 있다. 만일 변경이 발견되면, 빌드가 수행될 것이다. 예를 들어, 표현식이 0,15,30,45 * * * * 이라면 허드슨은 매 15분 마다 변경을 위해 당신의 저장소를 체크할 것이다. 크론 문법에 대한 좀더 상세한 내용은 the Quartz CronTrigger javadoc 을 살펴보길 바란다.
• 주기적인 빌드(Build periodically): (마찬가지로 크론 표현식으로 정의된) 이 옵션은 허드슨에게 SCM의 변경과 관계없이 특정 주기로 프로젝트를 빌드할 것을 간단하게 지시한다. 이 옵션은 SCM은 비교적 고정적인데 반해, 테스트 환경은 어떤 식으로든 주기적으로 생기는 경우, 그런 테스트의 실행을 하고자 할 때에 도움이 될 수 있다.
• 빌드 단계 추가하기(Add build step): 빌드 스크립트를 실행하기 위한 지시사항을 추가하려면 이 버튼을 클릭하여라. 지시사항은 다음 중 하나가 될 수 있다.
  • 쉘 실행하기
  • 윈도우 배치 명령어 실행
  • Ant 호출 (이게 내가 사용할 옵션이다. 자세한 내용은 아래에서 설명할 것이다)
  • 탑 레벨 Maven 타켓 호출
• 아티팩트 아카이브 하기(Archive the artifacts): 이 옵션을 선택해서 파일이나 디렉터리 마스크(mask = include와 exclude를 지정할 수 있는 Ant 스타일의 마스크)를 지정할때, 마스크와 일치하는 아티팩트들은 빌드가 완료되면, 허드슨 아티팩트 저장소에 추가되고 빌드 업무와 빌드 시퀀스 넘버를 사용해서 키값(key)으로 만들어지게 될 것이다. 옵션에 따라, 허드슨 서버의 디스크 공간을 절약하기 위해서 성공적으로 빌드된 이전의 모든 아티팩트들을 버릴 수 있다.
• 사용 추적을 위해 파일들의 사용 흔적을 기록 (Record fingerprints of files to track usage): 이 옵션을 선택하면, 비슷한 형태의 Ant 스타일 마스크(mask)를 사용해서, 허드슨으로 하여금 생성된 아티팩트들의 사용흔적(fingerprints)을 유지하도록 지시할 수 있다. 그렇게 해서, 시스템 내의 다른 어느 곳에서 이들 아티팩트들이 사용되는지를 당신이 좀 더 쉽게 추적할 수 있게 해준다.
• Javadoc 만들어내기(Publish javadoc): 만일 당신의 빌드 스크립트가 javadoc 컨텐트를 생성해낸다면, 이 옵션은 허드슨으로 하여금 해당 컨텐트를 만들어 낸 다음 곧바로 업무 홈 페이지에 게시할 것을 지시할 것이다. 빌드가 성공한 모든 경우에 있어 javadoc 컨텐트는 계속 유지될 것이다. 그러나 기본적으로 마지막에 해당하는 것만 유지된다.
• JUnit 테스트 결과 보고서 만들어내기(Publish JUnit test result report): 만일 당신의 빌드 스크립트가 JUnit 테스트를 수행한다면, 이 옵션은 허드슨으로 하여금 XML테스트 결과 문서를 처리해서 각각의 성공적인 빌드의 진행 보고서를 생성해 내고, 지속적으로 결과들을 모으도록 지시한다. 모인 결과가 바로 업무 홈 페이지에 있는 보고서에 해당하며, 오랜 시간에 걸쳐 수행된 빌드 업무용 단위 테스트의 기록이 될 수 있는 트랜드(historical trends)로 보여주는 보고서이다.
• 다운스트림 테스트 결과 모으기(Aggregate downstream test results): 어떤 경우에는, 한 업무의 단위 테스트 스위트의 수행 시간이 실제 빌드 시간 보다 엄청 더 길다. 이런 경우에는, 빌드와 테스트를 각각 다른 업무로 분리하는 것을 선택할 수 있다. 그래서 상대적으로 빌드가 빠르게 종료될 수 있도록 말이다. 하지만, 구현되어 있는 하나 이상의 테스트 업무들은 빌드가 성공적으로 완료되면 그 즉시 수행되게 된다. 만일 당신이 이 옵션을 선택하면, 허드슨은 모든 빌드 후속 업무들의 테스트 결과들을 모으고, 소급 적용하는 식으로 해당 내용들을 주요 빌드 업무에 대한 테스트 결과로 보고할 것이다.
• 다른 프로젝트 빌드하기(Build other projects): 앞선 항목들과 관련되어서, 이 옵션은 하나의 논리적인 빌드와 테스트 프로세스를 연속적으로 수행되어야 하는 두 개 이상의 물리적인 업무로 구현하기 위해 사용된다. 이 옵션을 선택되면, 필드가 보여지게 될텐데, 이 필드에는 현재 업무 이후에 수행되길 원하는 업무 이름들을 콤마(,)로 분리해서 기입하면 된다. 이 작업은 비록 현재 현재 업무 수행이 빌드가 불안정하다고 판단할 지라도 선택한 내용에 따라 수행된다.
• 이메일 공지(E-mail notification): 이 옵션을 선택하면, 하나 혹은 그 이상의 공백으로 분리된 이메일 주소를 입력할 수 있고, 해당 이메일로 허드슨의 업무 수행 완료 공지가 보내지게 된다. 빌드 실패, 불안정 빌드 등의 이벤트들은 이메일 발송을 일으키게 된다. 여기에 있는 추가적인 옵션은 허드슨이 판단하기에 빌드를 깨뜨린 코드를 SCM에 체크인 한 작업자에게 "특별한" 이메일을 보내도록 만드는 것이다.

이것들은 숙지해야 하는 적지 않은 정보들이다. 다음으로, 이 모든 것이 어떻게 작동하는지 좀 더 잘 이해하기 위해서, 빌드 업무의 예제를 살펴 볼 것이다. 이를 통해, 설정 옵션이 실제로 의미하는 것이 무엇인지를 알 수 있을 것이다.

허드슨에서 빌드 업무 설정하기: 예제

이어지는 내용은 내 허드슨 서버에 설정되어 있는 실제 빌드 업무의 예제이다. 이 빌드 업무는 HeliosJMX라고 불리는 내가 작성한 유틸리티 라이브러리를 빌드한다. 이 섹션에 있는 모든 이미지들은 이전 섹션에서 살펴본 New Job 화면에서 따왔다.

그림 14에서, 프로젝트 이름, 설명, 그리고 허드슨이 마지막 5개의 빌드만 유지하도록 하는 버림 정책(discard policy )을 볼 수 있다.

그림14. 업무 셋업 예제, 파트1

그림 15는 해당 업무(job)의 서브버전 셋업을 보여준다. java.net 에 있는 서브버전 저장소용 URL은 https://helios.dev.java.net/svn/helios/helios-jmx/trunk 이다. 로컬 모듈 디렉터리(Local module directory ) 프로퍼티는 업무 워크스페이스에 만들어지게 되는 선택적이고 추가적인 하위 디렉터리 이다.

Use update 체크박스는 매우 중요하다. 허드슨이 빌드 수행용 워크스페이스를 준비하기 위한 가장 빠른 방식은 간단하게 서브버전 저장소로부터 해당 디렉터리를 refresh 하는 것이다. 이 작업은 대부분의 경우에 적절하며 매우 빠르다. 그러나 어떤 인스턴스들에서는, 워크스페이스가 업데이트 될 때에 저장소로부터는 이미 제거된 소스 아티팩트들이 남아있을 수도 있다. 차선책은 이 옵션을 불가로 만드는 것이다. 해당 경우에 있어 허드슨은 워크스페이스를 깨끗히 비우고 저장소로부터 다시 불러올 것이다.

마지막 옵션은 FishEye 나 VisualSVN 같은 소스 저장소 브라우저를 할당한다. 만약 당신 이들 제품 중 사용 가능한한 것이 있다면, 적용 가능한 해당 브라우저를 선택해서, 당신의 소스 저장소를 지정해 놓아라.

그림15. 업무 셋업 예제, 파트2

그림 16에서 내가 선택한 빌드 트리거를 볼 수 있다. 나는 매 5분마다 서브버전을 조사해서 변경사항이 있으면 빌드작업을 수행하길 원한다.

그림16. 업무 셋업 예제, 파트3

그림17은 빌드 프로세스를 수행하기 위해 내가 정의해 놓은 Ant 태스크의 셋업을 보여준다. 설정 옵션들은 아래와 같다.

• Ant 버전(Ant version): 빌드를 수행 시에 사용하려고 미리 정의해 놓은 Ant 인스턴스
• 타겟들(Targets): 지정한 Ant 스크립트 중에서 수행되어야 하는 타겟들의 목록. 스크립트의 디폴트 테스크가 실행될 경우에는, 빈 칸으로 남겨 놓을 수 있다.
• 빌드파일(Build file): 유효 워크스페이스를 기준으로 놓고 봤을 때, 수행되어야 하는 Ant 스크립트의 상대적인 위치.
• 프로퍼티들(Properties): Ant 스크립트로 전달될 추가 시스템 프로퍼티 정의값. 나는 서브버전 인증정보를 스크립트로 전달하기 위해 이들 프로퍼티들을 사용했다. 왜냐하면 내 작업 절차에는 몇 가진 변경사항들을 저장소로 반영하는 단계가 포함되어 있기 때문이다. 추가적으로, 나는 내 단위 테스트들 위한 설정 파라미터들에 해당하는 몇몇 파라미터들을 정의했다.
• 자바 옵션들: 자바 명령행 옵션들을 여기에서 전달할 수 있다. 여기에서 나는 Ant의 -debug 옵션을 할당했다. 왜냐하면 나는 Ant 스크립트에 있는 디버깅 문제에 대해 작업하고 있었기 때문에, 해당 옵션을 사용해서 Ant가 추가적인 분석정보들을 로그에 생성하게 하였다. 다른 흔한 옵션은 기동되는 JVM의 초기 힙 사이즈(-Xms)와 최대 힙사이즈(-Xmx)를 특정하는 지시문들이다. 이 옵션은 빌드 스크립트를 수행하기 위해 허드슨에 의해 실행되는 모든 새로운 JVM 인스턴스가 따르게 된다.

그림17. 업무 셋업 예제, 파트4

그림18은 내가 정의한 빌드 후속 액션들을 보여준다.

• 아티팩트 아카이브하기(Archive artifacts): 허드슨에게 빌드가 완료되면 해당 아티팩트들을 아카이브 할 것을 지시한다. 이것은 Ant 스타일의 파일 마스크로, 유효한 워크스페이스에 상대적인 디렉터리와, 파일이름들, 그리고 아카이브 될 확장자들을 지정한다. 아카이브된 아이템들은 업무 빌드 인스턴스 홈 페이지를 통해 접근가능하게 될 것이다. 고급 옵션(advanced options)은 마스크에서 제외될 것들을 지정 가능하게 해주며, 마지막으로 성공한 빌드에서 생성된 것들을 제외한 모든 아카이브 된 아티팩트들을 지우는 옵션을 갖는다.
• javadoc 만들어내기: 이전 옵션과 비슷하다. 하지만 빌드 프로세스에 의해 생성된 임의의 javadoc 컨텐트에 대해 적용 가능하다.
• JUnit 테스트 결과 보고서 만들어내기: 허드슨에게 미리 정의된 위치에 JUnit XML 결과 문서를 얻어내고 기록이 될 수 있는 트랜드 보고서로 취합할 것을 지시한다.

그림18. 업무 셋업 예제, 파트5

그림19는 내가 정의해 놓은 빌드 후속 액션들을 좀 더 많이 보여준다.

• FindBugs 분석 결과 만들어내기: 나의 빌드 스크립트는 해당 빌드 업무와 연관되어 있는 소스코드에 대한 FindBugs 정적 코드 분석을 수행해서 findbugs 보고서를 생성한다. 이 옵션은 허드슨 FindBugs 플러그인이 설치된 경우에 사용가능하다. 이 옵션은 허드슨으로 하여금 정의된 FindBugs XML 결과 보고서를 불러와서 업무 홈 페이지에 게재되는 히스토리컬 FindBugs 경향 보고서로 취합할 것을 지시한다. FindBugs 플러그인용 고급 옵션은 보고되어 지는 FindBugs 단정 항목들과 허드슨이 판단하는 해당 빌드 업무의 상태에 관한 최종 결정에 그 단정 항목들이 어떻게 영향을 끼치게 할 것인지에 대한 카테고리를 정할 수 있게 해준다.
• 이메일 공지: 빌드 실패시 공지를 보낼 공백으로 분리된 이메일 주소를 지정한다. 빌드 업무가 영구적으로 불안정한 상태이거나 깨진 상태일때, Send email for every unstable build 옵션을 언체크 하는 것은 이미 알고 있는 상태에 대해서 계속적으로 공지가 되는 것을 막아준다.
• Cobertura 커버리지 보고서 만들어내기: 나의 빌드 스크립트는 생성된 클래스를 조율하기 위해 코드 커버리지 지시자로 Cobertura 를 사용한다. JUnit 테스트가 실행할때, Cobertura 는 코드 커버리지를 추적하고 테스트가 완료되면 커버리지 보고서를 생성한다. 이 옵션은 허드슨 Cobertura 플러그인이 설치되면 사용가능하다. 이 옵션은 허드슨으로 하여금 정의된 Cobertura XML 커버리지 리포트를 불러와서 마찬가지로 업무 홈페이지에 기록으로 남을 수 있는 Cobertura 트랜드 보고서로 게재하기 위해 취합된다. Coverage Metric Targets 이라고 이름붙은 섹션은 빌드 업무의 상태에 대한 허드슨 최정 결정에 영향을 미치는 코드 커버리지 맵의 레벨을 정하는 방법을 지정할 수 있게 해준다. (이것에 관해서는 '빌드 업무의 상태' 섹션을 보아라)

그림19. 빌드 업무 셋업 예제, 파트6

이 시점에서, 만일 당신이 새 업무를 정의를 마쳤다면, 실행해서 어떻게 동작하는지 볼 시간이다. 당신의 빌드 트리거들이 어떻게 설정되었든 상관없이, Disable Build 를 체크하지 않는 한 언제든 애드 혹(ad hoc, 특별한)빌드를 요청할 수 있다. 당신이 새로운 빌드 업무를 구축하거나 위에 있는 스크릿샷에서 보이는 것처럼 내가 했던 디버깅을 구축할때, 빌드 트리거를 기다리는 것은 사리에 맞지 않는다. 다음 섹션에서, 나는 빌드를 실행하도록 애드 혹을 요청하는 방법과 수행되고 있는 빌드 업무를 볼 수 있는 방법을 보여줄 것이다.

빌드 업무를 실행하고 지켜보기 Running and watching a job

에 대해서는 다음에 계속 하겠습니다. 다음 번에는 이번 보다 좀더 흥미로운 이야기가 나옵니다.