젠킨스의 장점중 하나는 다양한 플러그인으로 기능을 확장할 수 있는 점이다.

젠킨스 설치후에 바로 git 저장소와 연계할 수 있게 git 플러그인을 설치해 보았으므로 독자들은 플러그인 설치와 관리에 큰 어려움은 없을 것이다.

 

플러그인 설치는 "젠킨스 관리"->"플러그인 관리" 메뉴에서 "설치 가능" 탭에서 할 수 있으며 다양한 플러그인이 있으므로 상단의 필터에 플러그인 이름을 넣어서 필터링하는게 편리하다.

Warnings 플러그인 설치 화면

 

바로 사용 가능한 플러그인도 있지만 대부분은 설치후 젠킨스 재구동이 필요하다.

 

이번 절에서 여러 플러그인중에 유용한 플러그인 몇 개를 살펴보고 이를 사용해 보자.

여기서 설명한 것 외에 독자들의 빌드 환경이나 빌드시 추가로 수행하는 프로세스(리포팅, 정적 코드 분석, 코드 커버리지등)에 따라 많은 플러그인이 필요할 수 있으므로 플러그인 목록에서 용도를 확인하고 용도에 맞는 플러그인을 설치하면 된다.

단위 테스트 결과 확인

지속적인 통합은 자동화된 빌드와 테스트를 장려하고 있다. 메이븐으로 빌드시 jUnit 등으로 테스트 케이스를 만들고 빌드시 test 단계를 거치는 게 일반적이다.

젠킨스는 빌드시 수행한 테스트 결과를 확인하기 위해 "Test Result" 메뉴를 제공하지만 젠킨스에서 이 테스트 결과를 보기에는 많이 불편하다.

또 C++ 이나 PHP 등의 개발 언어를 사용할 경우 별도의 테스트 프레임워크가 존재하며 이의 출력 결과는 jUnit 과 상이한 형식으로 표시된다.

"xUnit Plugin" 은 위와 같은 문제를 해결하기 위한 플러그인으로 테스트 결과를 사람이 식별하기 좋게 표시해 주며 jUnit 외에 PHPUnit 이나 CppUnit 같은 다른 언어의 테스트 프레임워크의 결과도 분석해 준다.

 

설정

xUnit 을 사용하려면 작업의 빌드 설정에서 결과를 XML 로 출력하도록 설정을 변경해야 한다. 작업에 들어가서 좌측에서 구성을 눌러서 환경 설정에 들어가자.

그리고 "빌드 후 조치" 에서  "Publish xUnit test result report" 를 선택하면 된다.

빌드후 조치 설정

 

설정이 완료되었다면 "Build Now" 를 클릭해서 빌드를 재실행 해보자. 그러면 jUnit 테스트 결과가 가독성 좋게 표시되는 것을 확인할 수 있다.

jUnit 테스트 결과

 

의존성 그래프 보기

https://wiki.jenkins-ci.org/display/JENKINS/Dependency+Graph+View+Plugin

큰 규모의 프로젝트일 경우 다양한 모듈과 하위 프로젝트로 나뉘어져 있다. 이런 프로젝트에서 빌드는 각 모듈간의 의존성을 파악하고 의존성 관계에 따라 빌드 순서가 정해져야 한다.

"Dependency Graph View Plugin" 은 복잡한 프로젝트에서 각 모듈과 프로젝트 간의 의존성을 그래프로 그려서 표시해 주는 플러그인으로 복잡한 프로젝트의 전체 구성을 한 눈에 알아 보기 쉽게 도와준다.


이 플러그인은 각종 그래프를 그려주는 유틸리티인 graphviz  를 필요로 한다. 플러그인을 설치전에 다음 yum 명령어로 설치하자.

yum install graphviz

 

그후에 플러그인을 설치하면 대시보드에 "Dependency Graph" 가 생기며 이를 클릭하면 의존성을 그래프로 확인할 수 있다.

의존성 그래프

 

빌드 경고 확인

https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin

소스를 컴파일할 때 컴파일러가 내는 경고 메시지를 주의 깊게 보고 이를 처리하는 것은 매우 좋은 습관이다. 하지만  빌드가 복잡해 지면서 과정마다 많은 정보를 표시하므로 출력을 별도의 로그 파일로 남기고 이를 확인하지 않는 이상 빌드시 발생한 경고 메시지를 찾기는 쉽지가 않다.

"Warnings Plugin" 은 다양한 콘솔 로그를 스캔할 수 있는 플러그인으로 다양한 개발툴과 젠킨스 플러그인을 지원하고 있다. 정규식에 익숙한 독자라면 정규식으로 별도의 스캐너를 만들어서 로그를 스캔할 수 있다.


사용하려면 설치후 작업의 환경 설정 메뉴로 들어간 후에 "빌드 후 조치 추가"를 누르고 "scan for compiler warning" 메뉴를 선택한다.

메이븐 프로젝트일 경우 파서를 메이븐으로 설정하면 되며 JDK 를 바로 사용하는 경우 javac 를 설정한다.

로그 스캔 설정

작업 설정을 완료하고 빌드를 수행하면 파서가 콘솔 실행 결과를 분석해 주며 좌측 메뉴에 "Maven Warnings" 가 생기며 이를 클릭하면 다음과 같이 전체 경고 메시지가 정리되어 표시된다.

해당 컬럼을 누르면 자세한 경고 메시지를 볼 수 있으며 경고 부분을 강조해서 표시해 주므로 알아 보기가 쉽다.

메이븐 워닝 화면

작업 설정 이력 관리

https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory+Plugin

작업 환경 설정은 매우 중요한 설정으로 실수가 있을 경우 빌드가 제대로 되지 않을 경우가 많다.

"JobConfigHistory Plugin" 은 작업 환경 설정을 변경할 때마다 예전 설정 파일을 백업해 주는 플러그인이다.

예전 파일과 현재 파일을 비교해 보는 기능도 있으므로 실수했을 때 예전 설정으로 복구하는데도 도움을 줄 수 있다.

단 설정 파일을 복구하는 기능은 없으므로 XML 파일을 비교해 가면서 직접 편집해야 복구가 가능하다.

작업 설정 이력


 

https://wiki.jenkins-ci.org/display/JENKINS/Blame+Upstream+Committers+Plugin

Blame Upstream Committers Plugin

독자들은 젠킨스 테스트를 위해 lib-hello 와 이를 사용하는 hello-webapp 두 개의 작업을 생성했다. 이제 실제 개발 환경을 생각해 보자. 두 개의 프로젝트가 있고 각각이 일정 규모이상이라 별도의 개발자 내지는 개발팀이 있다.

hello-webapp 는 lib-hello 가 변경되면 자동으로 빌드하도록 빌드 트리거를 "

이제 lib-hello 개발자가 API 를 수정하고 커밋후 빌드했고 젠킨스로 빌드를 수행했고 정상적으로 종료됐다. 트리거에 의해 hello-webapp 도 빌드되지만 API 를 수정하여 빌드를 실패한다.

실패 원인은 lib-hello 의 개발자가 알리지 않고 API 를 수정했기 때문이다. 

Blame Upstream Committers 플러그인은 이런 상황 발생시 상위 프로젝트 커밋터에게 빌드 실패를 통보해 주는 플러그인이다.

 

Claim Plugin

https://wiki.jenkins-ci.org/display/JENKINS/Claim+plugin

Task Scanner Plugin

https://wiki.jenkins-ci.org/display/JENKINS/Task+Scanner+Plugin

이슈로 등록하기에는 너무 작은 일이지만 나중에는 해야 할 일이라 기록해 두고 싶은 경우가 있다.  필자의 경우 이런 일은 자바의 소스에 TODO, FIXME, XXX 등의 키워드와 함께 기록해 놓는다.

태스크 스캐너 플러그인은 이렇게 자바 소스에 기록해 놓은 부분을 파싱하여 표시해 주는 플러그인이다.

 

디스크 용량 모니터링

https://wiki.jenkins-ci.org/display/JENKINS/Disk+Usage+Plugin

지속적인 통합의 특성상 젠킨스는 많은 메모리와 디스크를 소비하게 된다. "Disk Usage Plugin" 은 현재 젠킨스가 사용하고 있는 디스크의 용량을 그래프와 수치로 확인할 수 있게 해주는 플러그인이다.

전체 용량과 작업별로 확인할 수 있으므로 젠킨스가 사용하는 용량을 한눈에 파악하고 디스크를 언제 증설해야 할지 계획 수립에 도움을 준다.

설치하면 메인 대시보드에 "Disk Usage" 버튼이 생성되며 클릭하면 다음과 같이 디스크 용량을 확인할 수 있다.

 

사용량 계산은 부하를 주게 되므로 약 6시간마다 실행하게 되며 지금 바로 용량 계산을 하려면 하단의 "Record Disk Usage" 버튼을 클릭하면 된다.

디스크 용량 확인

 

이메일로 통합 결과 공유

https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin

통합 결과를 통보하고 피드백을 받는 것은 굉장히 중요한 일이다. 이때 생각해야 할 점은 적절한 시기에 적절한 방법으로 적절한 정보를 적절한 사람에게 전달해야 하는 것이다.

만약 빌드가 실패하거나 불안정하게 끝났을 경우 관련없는 이에게도 이메일로 통보한다고 생각해 보자. 받은 이는 내용을 살펴보고 본인과 관련 없다고 생각해서 삭제할 것이다.

이후에도 이런 메일이 자주 오면 아예 읽지를 않거나 스팸 처리할 수도 있다. 

 

정보를 공개하지 않는 것도 문제지만 정보의 과부하도 주의해야 하며 과부하시 사람들은 정보라 생각하지 않고 무시해 버리므로 특히 중요한 부분중에 하나는 적절한 사람에게 전달하는 것이다.

젠킨스에 기본 포함된 이메일 기능은 간단한 대신 이런 요구사항을 만족할 수 없게 되어 있다.

 

"Email-ext Plugin" 은 다양한 조건과 상황에서 보낼 정보를 가공하고 수신자를 설정할 수 있으며 파라미터와 환경 변수를 지원하므로 동적으로 전송 시기 및 메일 내용이나 수신자 목록을 설정할 수 있다.

 

플러그인을 설치하면 "젠킨스 관리" -> "시스템 설정" 에 "Extended E-mail Notification" 설정이 추가된 것을 볼 수 있다. 여기에서 전역 설정을 하면 되며 설정할 수 있는 항목은 다음과 같다.

이메일 확장 설정

 

  • Add 'Precedence: bulk' Email Header
    모든 이메일에 'Precedence: bulk'  를 붙여서 송신한다. 이 헤더가 있으면 송신자가 휴가를 가거나 부재중이라 자동 응답 메시지로 설정 했을 경우 송신자에게 가는 것을 방지해 준다.
  • Default Recipients
    기본 송신자를 설정한다. 콤마를 구분자로 하여 여러 주소를 기술할 수 있다. 이 값은 $DEFAULT_RECIPIENTS 파라미터에 설정된다. 
  • Reply To List
    수신자가 답장할 경우 응답받을 이메일 주소를 설정한다. 자동 메일로 보내므로 수신자가 응답시 송신자 메일 주소를 바로 사용하면 안 되는 경우에 설정하면 된다. 여러 개일 경우 콤마를 구분자로 사용한다.
  • Excluded Recipients
    메일을 보내지 않을 주소를 설정한다.
  • Default Subject
    기본 제목 형식을 설정한다. 기본 설정은 "$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS!" 이다.
  • Maximum Attachment Size
    첨부 파일의 최대 사이즈를 설정한다. MB 단위이며 미설정시 사이즈 제한이 없다.
  • Default Content
    기본 메일 내용이다. 기본 설정은 제목에 있는 내용과 빌드 내역을 상세하게 확인할 수 있는 URL 링크이다. 
  • Default Pre-send Script
    메일을 전송하기 전에 전용 스크립트를 통해 내용과 수신자등을 수정할 수 있다. 스크립트는 자바와 비슷하며 사전에 정의된 몇 가지 변수들이 있다. 예로 Mime Message 는 msg 라는 변수로 빌드는 build 라는 변수에 매핑되어 있다.
    다음은 빌드 실패시  이메일에 우선 순위 높음을 설정하는 예제이다.

    if (build.result.toString().equals("FAILURE")) { 
        msg.addHeader("X-Priority", "1 (Highest)"); 
        msg.addHeader("Importance", "High"); 
    }

 

이메일 확장 플러그인은 많은 변수를 사전에 정의해 놓았다. 환경 변수는 리눅스의 쉘 변수처럼 $ 와 {} 사이에 변수명을 적어준다. 이중에서 몇 가지 중요한 변수를 알아 보자. 이외의 변수들의 용도는 플러그인 설명을 참고하기 바란다.

  • ${PROJECT_NAME}
    빌드를 수행한 프로젝트 이름이다.
  • ${BUILD_STATUS}
    현재 빌드의 상태로 치환된다. 
  • ${BUILD_URL}
    빌드 정보에 접근할 수 있는 URL 이다.
  • ${BUILD_LOG}
    빌드시 발생한 로그의 내용이다.
  • ${BUILD_NUMBER}
    빌드 번호이다.
  • ${CAUSE}
    빌드가 실패한 원인을 담고 있다.

이제 전역 설정이 끝났다면 작업별로 설정할 순서이다.  작업 환경 설정에 들어가서 "빌드후 조치 추가" 를 누르고 "Editable Email Notification" 을 선택하자.

 

작업별 통보 설정
  • Save to Workspace
    생성된 이메일을 작업공간에 저장할 지의 여부이다. 체크할 경우 "triggername-buildid.[txt|html]. 형식으로 저장된다.
  • Triggers
    가장 중요한 설정이라고 볼 수 있다. 어떤 이벤트시 누구에게 메일을 보낼 지 설정하는 부분이므로 적절한 시기에 적절한 이에게 정보를 전달하는 부분이다. 설정해야 할 항목이 많으므로 아래에 별도의 항목에서 자세히 알아 보자.

이메일 트리거

이메일 트리거 설정

Add Trigger

클릭하면 이메일 트리거를 추가할 수 있는 팝업이 표시된다. 매우 많은 조건이 표시되는데 이중에 많이 사용되는 트리거를 알아 보자.

  • Always
    빌드가 끝날때 마다 보메일을 낸다. 정보의 과부하때문에 사용하지 않는게 좋다.
  • Failure
    실패했을 때 보내며 실패 조건을 상세히 설정할 수 있다.
    • Failure - 1st
      처음 실패시 보낸다. 이후에 실패해도 보내지 않는다.
    • Failure - 2nd
      두 번 연속 실패했을 때 보낸다.  이후에 실패해도 보내지 않는다.
    • Failure - Any
      실패할 경우마다 보낸다.
    • Failure - Still
      실패가 지속될 경우 보낸다. 2번 이상 실패시마다 보내는 것과 동일하다.
    • Failure -> Unstable (Test Failure)
      빌드가 실패하거나 테스트 케이스 실행 실패시 보낸다.
  • Fixed
    빌드가 실패에서 성공 또는 불안정 상태로 변경되었을 때 보낸다.
  • Unstable (Test failure)
    빌드가 불안정할 때 메일을 보낸다.
  • Unstable (Test failure) - Still
    빌드가 계속 불안정할 때 메일을 보낸다.

메일 트리거는 Failure 항목은 꼭 선택하는게 좋으며 프로젝트의 프로세스에 따라 Unstable 조건도 선택할 수 있다. 이제 우리는 이메일 테스트를 위해 트리거중에 "Before Build" 와 "Failure - Any" 를 선택해 보자.

Send To

수신자를 지정하는 메뉴이다. 정보의 과부하가 되지 않게 적절한 사람을 선택하자. 선택할 수 있는 옵션은 총 4가지이다.

  • Recipient List
    상단에서 설정한 프로젝트 수신자 목록을 사용한다.
  • Culprits
    마지막 정상 빌드 이후에 커밋한 사람들에게 이메일을 전송한다.
  • Developers
    변경한 사람들에게 메일을 보낸다.
  • Requestor
    요청자에게 메일을 보낸다.

 

이제 설정을 마쳤으면 저장한 후에 아무 소스나  컴파일 에러가 발생하게 소스를 수정하자.

그리고 커밋한 후에 빌드를 실행해 보자. 두 개의 트리거를 설정했으므로 빌드를 마치지 않아도 이메일이 하나 전송되며 빌드후 실패 내역을 다시 이메일로 전송하게 된다.

 

이메일 확장 플러그인은 사용법이 복잡하고 옵션이 많아서 접근이 어렵지만 잘만 사용하면 통합시 발생하는 정보를 의미있는 정보로 만들수 있는 강력한 플러그인이다.

메일 수신자와 메일 내용, 이메일 트리거등을 조금씩 조정해 가면서 프로젝트에 맞게 최적화 해보자.

 





blog comments powered by Disqus