작업 상세 설정

작업 상세 설정

일반 설정

프로젝트 키와 스타일을 설정했으니 이제 작업의 상세 설정을 진행해 보자.

• Item 이름 
  작업의 이름을 지정한다. 대시보드에 표시되는 이름이며 유일한 키값이기도 하다. 작업간의 의존성을 적용할 때에도 꼭 필요하므로 알아보기 쉽게 지어야 한다. 메이븐 프로젝트라면 pom.xml 에 설정한 artifactId 와 일치하게 주는 것이 좋다.
  lib-hello 프로젝트의 경우 lib-hello 를 hello-webapp 의 경우는 hello-webapp 를 설정하자.
• 설명
  작업에 대해서 자세한 설명을 기술하는 부분이다. 이름만으로는 어떤 프로젝트인지 알기 어려울 수 있으므로 상세한 설명을 기술하는 게 좋다.
• 오래된 빌드 삭제 
  빌드는 많은 하드 디스크 용량을 차지하므로 오래 되었거나 또는 빌드수가 초과했을 경우 예전 데이타를 삭제한다. 아래의 설정은 빌드는 최대 30일, 최대 빌드 갯수는 50개를 보관하는 설정이다.
• 이 빌드는 매개변수가 있습니다
  빌드에 파라미터를 넘겨줄 경우 설정한다.  파라미터는 메이븐의 골이나 기타 프로퍼티를 설정하는데 사용할 수 있으며 버전 관리 서버에 태그를 붙이거나 하는 등의 용도로 사용할 수 있다.
• 빌드 안 함
  설정하면 빌드 작업을 실행하지 않는다.  버전 관리 서버가 이전하여  특정 기간동안 빌드를 못하거나 네트웍이 다운되었는데 복구에 오랜 시간이 필요하거나 또는 빌드 에러가 너무 많아 해결 하기전까지는 빌드를 하고 싶지 않은 경우등에 사용하면 된다.
• 필요한 경우 concurrent 빌드 실행
  설정되면 동시에 여러 빌드를 수행한다. 빌드가 매우 오래 걸리는 작업이고 다른 파트에서 빌드 시작이후 커밋한 내용을 확인하고 싶은 경우등에 사용할 수 있다.
  빌드가 WAS 에 디플로이까지 하게 구성되어 있다면 concurrent 빌드를 수행하면 문제가 될 수 있으니 주의해야 한다. 기본적으로는 꺼져 있다.
• JDK
  빌드에 사용할 JDK 를 선택한다. "젠킨스 관리->시스템 설정" 에서 등록한 JDK 가 표시된다. JDK 설치를 선택했다면 최초 빌드시 JDK 도 설치하게 되므로 빌드 시간이 오래 걸리게 된다.
  여기서는 1.6 버전(예: 6u45) 를 설치해 보자.

소스 코드 관리

빌드를 하려면 버전 관리에서 소스를 가져와야 하므로 버전 관리 시스템을 설정할 순서이다. 먼저 서브버전일 때 설정을 알아 보자.

서브버전 설정

• Repository URL
  저장소의 URL 을 설정한다. 로컬 저장소라면 lib-hello 는  "file:///${HOME}/svnrepos/lib-hello/trunk" 를 설정하고 hello-webapp는 "file:///${HOME}/svnrepos/hello-webapp/trunk" 를 설정하자.
  또는 http나 https 프로토콜로 저장소를 만들었다면 해당 URL 로 설정하면 된다.
• Credentials
  예제는 로컬 저장소라 별도의 인증 절차가 없지만 http 나 https 를 사용하는 경우 인증을 거쳐야만 서브 버전에 접근할 수 있는 경우가 많다.
  지속적인 통합을 위해 빌드 작업시 인증 정보 입력을 사람이 하면 자동화를 할 수 없으므로 ID/PWD 나 SSH 공개키 쌍등 인증에 필요한 정보는 Credentials저장소에 설정하여 자동으로 입력되게 할 수 있다.
  "Add" 를 클릭하면 인증 정보를 추가할 수 있다.

• • Kind : 어떤 종류의 인증 정보인지 설정한다. 기본은 "Username with password" 이며 아이디와 암호로 로그인할 경우 설정한다. SSH 로 로그인하는 경우 비밀 번호를 입력할 수 없으므로 미리 SSH 공개키와 개인키를 등록하여 사용해야 한다. 서브버전은 아이디 기반의 인증을 사용하므로 "Username with password" 를 선택한다.

  • Scope: 인증 정보의 사용 범위를 설정한다. 기본은 Global 이며 다른 프로젝트에서도 이 인증 정보를 사용할 수 있으므로 편리하지만 보안에 문제가 될 수 있다.  System 으로 설정하면 사용할 수 있는 범위가 제한된다.
  • Username: 로그인에 필요한 아이디를 설정한다.
  • Password: 로그인에 필요한 암호를 설정한다.
  • Description: 이 인증 정보에 대한 설명을 기술한다. 
• Local module directory : 버전 관리 서버에서 체크아웃 받을 경로를 설정한다. 기본 경로는 현재 경로(.) 이다.
• Repository depth : 버전 관리에서 체크 아웃 받을 경우 하위 디렉터리의 깊이를 설정한다. 기본 설정은 무제한이다.
• Ignore externals : 서브버전의 프로퍼티중 external 프로퍼티를 무시한다.
• Additional Credentials : 추가로 설정할 인증 정보가 있으면 설정한다.
• Check-out Strategy : 서브버전 체크 아웃시 전략을 설정한다. 기본 전략은 가능하면 svn update 를 실행하는 "Use 'svn update' as much as possible" 이다. 특별한 이유가 없다면 기본 설정으로 충분하다.
• Repository browser : 빌드 정보에서 "Changes" 뷰를 클릭하여 버전 관리의 커밋 내역을 확인할 수 있다. 이때 저장소 브라우징을 어떻게 할지 선택하는 메뉴이다. 특별한 서브버전 저장소 브라우징 소프트웨어를 설치했다면 설정을 변경해 주자. 기본 값은 자동이다.

git  설정

• Repository URL
  저장소의 URL 을 설정한다. 로컬 저장소라면 lib-hello 프로젝트는 "file:///${HOME}/lib-hello/" 를 설정하고 hello-webapp 프로젝트는 "file:///${HOME}/hello-webapp" 를 설정하자.
• Credentials
  깃 저장소 연결에 인증이 필요하다면 인증 정보를 설정하여야 한다. 인증 정보 설정 방식은 바로 위에서 설명하였다.
• Branches to build
  깃은 다수의 브랜치를 갖고 있을 수 있으므로 어떤 브랜치를 체크아웃 하고 빌드할 지 설정해야 한다. 브랜치명을 명시적으로 기술하거나 빌드 파라미터로 설정할 수 있다.
  와일드 카드가 통하므로 dev로 시작하는 모든 브랜치를 빌드할 경우 dev* 로 설정할 수 있다. 값을 설정하지 않으면 모든 브랜치를 빌드하게 된다. 기본 설정된 브랜치는 master 이다.
• Addtional behaviour
  젠킨스 git 플러그인은 git 의 동작을 제어할 수 있는 다양한 옵션을 갖고 있다. 이 옵션은 "Addtional behaviour" 메뉴에서 설정할 수 있으며 필요에 따라 취사 선택하면 된다. 매우 다양한 옵션이 제공되므로 필요한 옵션이 있는지 확인해 보기 바란다.

빌드 유발(Build Trigger)

빌드는 프로젝트 참여자가 메뉴를 통해 수동으로 실행할 수 있지만 매번 수동으로 빌드를 실행하는 것은 매우 불편한 일이므로 자동화가 필요하다.

이를 위해 특정 조건이나 이벤트가 발생하면 빌드를 자동으로 실행할 수 있는 기능이 지속적인 통합 서버에는 구현되어 있다.

빌드를 시작하게 하는 것을 빌드 트리거(Build Trigger) 라고 하며 젠킨스의 메뉴에는 "빌드 유발" 이라고 번역되어 있다.

젠킨스가 지원하는 빌드 트리거는 다중 선택이 가능하며 다음과 같은 종류가 있다.

• Build whenever a SNAPSHOT dependency is built 
  작업  메이븐 프로젝트일 경우에만 표시되는 메뉴이다. 설정할 경우 젠킨스는 pom.xml 을 분석하여 <dependency> 항목에 설정된 아티팩트의 스냅샷이 젠킨스에서 빌드되었을 경우 자동으로 의존하는 프로젝트도 빌드한다.
  예로 lib-hello 의 스냅샷 버전이 빌드되면 이것을 참고하는 프로젝트인 hello-webapp 도 자동으로 빌드하게 된다. 주의할 점은 프로젝트의 이름과 <dependency> 에 설정된 아티팩트의 artifactId 가 일치해야 하는 점이다.
  아래에 설명할 "Build after other projects are built" 를 메이븐의 특징에 맞게 최적화한 방식이라고 볼 수 있다. lib-hello 프로젝트는 설정할 필요없고 hello-webapp 은 lib-hello 아티팩트를 참고하므로 설정하자.

• 빌드를 원격으로 유발
  원격에서 스크립트나 API 를 통해 빌드를 실행시키는 경우이다. 예로 버전 관리 서버에서 소스가 변경되었을 때 젠킨스 서버에 HTTP GET Request 를 하면 빌드 명령을 내릴 수가 있으며 이는 원격 트리거가 된다.

  

  
  설정시 보안을 위해 인증 토큰(Authentication Token) 을 설정하는 게 좋다. 인증 토큰을 설정하면 클라이언트는 토큰을 알아야 빌드 요청을 보낼 수 있다. 
  빌드 요청 URL 은 다음과 같은 형식을 갖게 된다. 진하게 표시된 부분은 수정해야 할 부분이다.

  JENKINS_URL/job/JOB_NAME/build?token=TOKEN_NAME&cause=빌드+사유

• JENKINS_URL : 젠킨스가 설치된 URL 이다. 예로 http://jenkins.example.com  이 될 수 있다.
• JOB_NAME: 젠킨스에 설정한 프로젝트의 이름이다. 예로 lib-hello 또는 hello-webapp 이다.
• token : TOKEN_NAME 은 위에서 설정한 인증 토큰이다. 인증 토큰을 설정했을 경우 클라이언트는 요청에 정확한 토큰을 같이 보내야 원격에서 빌드할 수 있다.
• cause : 빼도 되는 옵션으로 왜 빌드를 했는지 이유를 문자열로 기술해 두는 필드로 나중에 빌드 확인시 도움이 된다.

만약 젠킨스 URL이 jenkins.example.com 이고 토큰을 mySecretToken 으로 설정했다면 최종 빌드 요청 URL 은 다음과 같다.

원격 빌드 요청이 제대로 동작하는 지는 4장 핵심 유틸리티에서 설명한 curl 명령어를 통해 간단하게 확인해 볼 수 있다.

-u 옵션 뒤에는 젠킨스에 로그인하기 위한 사용자ID와 암호를 설정해야 한다.

--data-urlencode 옵션은 URL 에 공백 문자나 기타 특수 문자가 들어갈 경우 인코딩해 주는 옵션이다. token 이나 cause 파라미터에 공백이나 특수 문자가 있을 경우 유용하게 사용할 수 있다.

Build after other projects are built

어떤 프로젝트의 빌드가 완료되면 그 후에 특정 프로젝트의 빌드를 실행할 수 있다. 여러 개의 빌드 프로젝트가 있고 각각에 의존성이 있을 경우 유용하게 사용할 수 있다.

예제로 사용할 두 개의 프로젝트를 보자. jar 파일을 생성하는 "lib-hello" 프로젝트와 이 jar 를 사용하는 웹 app 인 "hello-webapp" 프로젝트가 있다.

만약 lib-hello 가 변경되어 빌드할 경우 이를 사용하는 프로젝트도 같이 빌드하고 테스트를 하는 것은 지속적인 통합 목적에 부합되는 좋은 사용 방법이다.

의존성을 설정하여 상위 프로젝트 빌드시 하위 프로젝트도 빌드되게 하려면 *Projects to watch" 항목에 상위 프로젝트의 이름을 설정하면 된다.

상위 프로젝트 빌드 결과에 따라 현재 프로젝트도 빌드할 지 결정할 수 있으며 다음과 같이 3가지 설정이 가능하다.

• Trigger only if build is stable : 상위 프로젝트 빌드와 퍼블리셔가 모두 안정적으로 종료된 상태일때 현재 프로젝트를 빌드한다. 기본 설정이다.
• Trigger even if the build is unstable : 빌드는 정상적으로 됐지만 퍼블리셔는 정상 종료되지 않은 상태라도 현재 프로젝트를 빌드한다. 예로 jUnit 테스트 실행이 실패했을 경우 unstable 상태로 설정되며 이럴 때도 현재 프로젝트를 빌드한다.

메이븐을 사용해 빌드한다면 "Build whenever a SNAPSHOT dependency is built " 메뉴로 더 간편하게 프로젝트간 의존성을 해결할 수 있다.

주의할 점은 프로젝트가 많고 의존 관계가 복잡할 경우 이 기능을 사용하면 상위 프로젝트(Upstream Project) 빌드시 의존하는 하위 프로젝트(Downstream Project)도 모두 빌드되어 시스템에 무리를 줄 수 있으므로 규모에 따라 적절하게 사용해야 한다.

스케줄링에 의한 빌드

빌드를 자동으로 실행할 시간대와 주기를 설정하고 이에 따라서 자동으로 빌드가 수행되게 설정하는 기능이다.

지속적인 통합이 안정적으로 구축되면 이 기능을 이용하여 자주 빌드 및 통합하여 문제를 조기에 식별하고 수정하는게 바람직하다.

실례로 일과를 시작하기 한 시간 전에 자동으로 빌드를 수행하고 실패시 관리자에 통보하도록 구성할 수 있다.

이러면 관리자는 업무 시작과 동시에 빌드 실패 원인을 찾고 담당자에게 수정하도록 요청 할 수 있다.

설정은 유닉스의 크론 형식의 설정 형식이 거의 유사하므로 "4장 중요 명령어와 유틸리티" 에서 설명한 크론을 참고하면 된다.

다음은 월요일부터 금요일까지 오전 8시, 오후 5시 정각에 빌드를 실행하는 설정이다.

1-5 대신 * 로 변경하면 매일 빌드를 수행하게 된다. lib-hello 와 hello-webapp 프로젝트마다 각각 별도의 스케줄링을 설정해 보자.

선행/선후 작업 지정

빌드전 혹은 빌드후 작업을 지정하는 메뉴이다. 이 기능을 통해 명시적으로 작업간의 의존성을 설정할 수도 있다.

Pre Steps

• 작업전에 실행할 단계가 있을 경우 설정한다. 빌드전에 특별한 절차가 필요할 경우 유용하게 사용할 수 있다.

  
• Build
  메이븐 프로젝트일 경우 꼭 설정해야 하는 메뉴이다.
• Root POM
  메이븐의 프로젝트 파일을 설정한다. 기본 값은 pom.xml 이다.
• Goals and options
  메이븐의 골과 옵션을 설정한다. 메이븐 프로젝트의 특성에 맞게 지정하면 된다. clean package나 clean deploy 등 용도에 맞는 골을 설정하자.
  jar 파일 생성이 목적인 lib-hello 프로젝트의 경우 clean package 가 적당하며 hello-webapp 는 clean package 실행시 war 파일이 생성된다. 웹 app 일 경우 WAS 에 자동 배포도 가능하며 이는 "배포" 절 에서 알아보도록 하자.

E-mail Notification

빌드 결과를 이메일로 전송한다. 젠킨스 관리에서 설정한 이메일 서버와 주소가 사용된다.

• Recipients : 이벤트 발생시 이메일을 송신할 메일 주소를 기술한다. 여러 개의 이메일을 적을 경우 공백을 구분자로 하여 적는다.
• Send e-mail for every unstable build : 안정적이지 않은 빌드 발생시 이메일을 전송한다.
• Send separate e-mails to individuals who broke the build  :  빌드 실패시 빌드를 깬 개개인에게 별도의 이메일을 전송한다/
• Send e-mail for each failed module: 개별 모듈 실패시 마다 메일을 전송한다.

너무 많은 이메일은 사용자에게 짜증을 유발하므로 메일 전송은 다양한 이벤트별로 수신자를 분리할 수 있는 기능이 필요하나 젠킨스의 기본 기능은 그렇지 않으므로 별도의 플러그인을 사용하는 것을 권장하며 관련 플러그인은 "플러그인으로 기능 확장" 부분에서 설명할 예정이다.

Post Steps

빌드후 실행할 작업을 지정한다. 빌드의 결과에 따라 실행 여부를 설정할 수 있다. 

• Run only if build succeeds - 빌드가 성공했을 경우에만 진행한다.
• Run only if build succeeds or is unstable  - 빌드가 성공했거나 안정적이지 않을 경우에 진행한다.
• Run regardless of build result  - 빌드 결과에 상관없이 진행한다.