Jenkins란?

Jenkins는 소프트웨어 개발 시 지속적으로 통합 서비스를 제공하는 CI툴이다.

CI는 Continuous Integration. 즉, 지속적인 통합이라는 의미를 가진다.
지속적인 통합이란, 애플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 Repository에 통합히는 것을 의미한다.

이러한 CI의 핵심 목표는 버그를 신속하게 찾아 해결하고, 소프트웨어의 품질을 개선하고, 새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것에 있다.

Jenkins가 가져다주는 이점

코드의 변경과 함께 이뤄지는 이 같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.

• 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
• 자동화 테스트 수행
• 정적 코드 분석에 의한 코딩 규약 준수 여부 체크
• 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시
• 결합 테스트 환경에 대한 배포 작업

Jenkins 설치 전 준비물

• openjdk 1.8
• Apache Tomcat 8.x

💡 Jenkins 버전 별로 호환되는 openjdk 가 각기 다르다.

가장 최신 버전(v2.361)은 Java 11 또는 17 지원
→ Java 8을 지원하는 가장 최신 버전을 설치하는 것을 권장

Jenkins version : 2.346.1 (2022/06)

설치

1. 아래 링크로 접속 후 war파일 설치
   https://get.jenkins.io/war-stable/
2. cmd창 열고 명령어로 war파일 설치 디렉토리로 이동
3. java -jar jenkins.war 명령어 실행
4. 접속 포트 번호 기본 값은 8080 이므로 http://localhost:8080 으로 이동하면 아래와 같이 Jenkins 잠금 해제 화면이 나타난다.
   
5. Jenkins를 실행했던 cmd창에서 초기 비밀번호를 확인 가능하다. 그대로 복사해서 Administartor password 입력 칸에 붙여 넣어주고 continue 버튼 클릭
   
6. 플러그인 설치는 일단 Install suggested plugins 선택해 권장하는 플러그인만 설치
   
7. 플러그인 설치가 완료되면 관리자 계정 생성
   
8. Jenkins 접속 url 설정 (기본 포트번호 8080)
   
   

Jenkins Plugin

Jenkins 관리 > 플러그인 관리 > 설치 가능 탭에서 검색 후 설치

Jenkins에서 지원하는 플러그인이 많지만 내가 실제로 적용했던 플러그인만 업급하겠다.

설치할 플러그인

• Subversion - Jenkins에 Subversion 지원
• Deploy to Container - war파일을 가져와 빌드 종료 시 실행 중인 원격 애플리케이션 서버에 배포
• Maven Integration - Jenkins와 Maven 간의 긴밀한 통합을 제공
• Warnings Next Generation - 정적 분석 도구(PMD, Checkstyle, Findbugs 등)에서 보고된 컴파일 경고 또는 문제를 수집하고 결과를 시각화해 보여주는 플러그인
  
  

Jenkins Job 생성 (프로젝트 등록)

Global Tool Configuration 설정

• 젠킨스 관리 > Global Tool Configuration 으로 이동
• 도구와 해당 도구 위치 및 자동 설치 프로그램 구성하는 화면

1. JDK 추가

• 로컬에 설치된 openjdk 경로를 입력해 jdk 추가
  

2. Maven 추가

• Install automatically 체크해 Maven version을 선택하면 Jenkins가 자동으로 Apache에서 Maven을 설치함
  
  

프로젝트(job) 생성

• Dashboard > 새로운 Item 선택
• Maven Project 선택 및 프로젝트 명 작성 후 OK 클릭
  
  

SVN 연동

• 미리 설치해 놓은 Subversion 플러그인으로 인해 설정이 가능
• checkout 받을 SVN Repository URL 입력
• Local module directory에 checkout 받을 로컬 디렉토리 경로 입력 (”.” 입력 시 ../jenkins/workspace 로 잡힘)
  
• Credentials - Add 버튼 클릭해 본인의 SVN 계정을 등록
  • Username : SVN username 입력
  • Password : SVN password 입력
  • ID : 원하는 Credential 이름 입력

젠킨스 관리 > Manage Credentials > Add Credentials 에서도 등록 가능

Build Triggers 설정

• Poll SCM 체크 후, Schedule 입력 칸에 소스 변경 감지 주기를 입력
  • 주기는 cron 표현식으로 입력
  • 아래와 같이 H/30 * * * * 으로 입력하면 매 시 30분마다 변경 감지
  • 지정한 주기마다 실행을 하지만 SVN상에 변경 사항이 없다면 빌드하지 않음
    
    

Build 설정

• Root POM 에 pom.xml 의 경로를 입력
  • Jenkins 작업 공간 Root 경로
    (../.jenkins/workspace/프로젝트 폴더) 가 아닌 다른 경로에 위치할 경우, 작업 공간을 기준으로 상대 경로 입력
  • 공백으로 두거나 아래와 같이 pom.xml 로 입력할 경우, 작업 공간 Root경로에서 찾는 것을 의미
• Goals and Option 에 수행할 Maven 명령어를 입력
  • clean : 컴파일된 결과물인 target 폴더 제거
  • install : target 폴더 하위에 war 파일 생성
  • pmd:pmd : pmd 분석을 수행하고 위반에 대한 보고서를 생성
  • pmd:cpd : cpd(복사/붙여넣기 감지기) 도구에 대한 보고서를 생성
  • findbugs:findbigs : findbugs 분석을 수행하고 위반에 대한 보고서를 생성
  • checkstyle:checkstyle : checkstyle 분석을 수행하고 위반에 대한 보고서를 생성
    
    

빌드 후 조치 설정

1. 정적 분석 도구 추가

• 미리 설치해 놓은 Warnings Next Generation 플러그인으로 인해 설정 가능
• 빌드 후 조치 추가 - Record compiler warnings and static analysis results 선택
• Add Tool 클릭해 **PMD**, **CheckStyle**, FindBugs 를 각각 추가
• Report File Pattern : 분석 결과 보고서의 위치를 입력
  • 공백으로 놔두면 각 분석 도구의 default 보고서 파일을 사용 (pmd - pmd.xml, checkstyle - checkstyle-result.xml, findbugs - findbugsXml.xml)
• Report Encoding : 보고서의 내용을 인코딩할 타입 선택 (UTF-8)
• Custom ID : 분석 도구의 ID 입력
• Custom Name : 분석 도구의 이름 입력
  
  

2. 빌드 후 배포할 컨테이너 설정

• 빌드 후 조치 추가 - Deploy war/ear to container를 선택
• Add Container 클릭해 알맞은 Tomcat 버전 선택
• WAR/EAR files : 배포할 war 파일을 file 패턴으로 입력
• Context path : 배포할 war 파일 생성 경로 (Tomcat 루트 경로 기준)
• Credentials : 배포할 Tomcat 서버의 user를 선택
  • 해당 계정도 SVN 계정과 동일하게 젠킨스 관리 > Manage Credentials > Add Credentials 에서 미리 등록 가능
  • 배포할 서버의 Tomcat 디렉토리/conf/tomcat-users.xml 에 user 정보를 등록
    
• Tomcat URL : 배포 서버 URL 입력
  

위의 모든 구성을 끝내고 저장 버튼을 클릭해 프로젝트(Job)를 생성

프로젝트(Job) 등록 완료 후 빌드

• 프로젝트 등록이 완료되면 아래와 같이 Jenkins 대쉬보드에서 확인이 가능하고, 빌드할 프로젝트를 클릭
  
• 해당 프로젝트로 들어와 왼쪽 탭에 지금 빌드 버튼을 클릭해 빌드 실행

빌드가 완료된 프로젝트(Job)는 빌드 회차 별로 CheckStyle, FindBugs, PMD 와 같은 분석 도구로 소스를 분석한 결과를 확인할 수 있다.
Severities Distribution ? 심각도 분포
Reference Comparison ? 이전 빌드 회차의 결과를 참조해 비교
Hsitory ? 전 회차 분석 결과 그래프
Details ? 분석 도구 별, 패키지 별, 파일 별, 보고된 타입 별 세부 정보

Jenkins로 빌드시 겪었던 이슈

Jenkins로 애플리케이션 빌드 시에 직접 겪은 Exception 중 Tomcat과 관련된 이슈를 정리해보았다.

Contextpath 이중 정의로 인한 충돌

해당 Exception은 Tomcat 설정과 관련된 Exception이다.
일반적으로 Tomcat 서버에서 애플리케이션을 배포하기 전 server.xml 설정 파일을 수정해 Tomcat의 Context Path와 docBase를 지정한다.

Jenkins에서는 바로 이 설정으로 인해 애플리케이션 빌드 시 문제가 발생한다.
Jenkins에서는 프로젝트 구성에 설정된 context path를 참고해 새롭게 정의하고 war파일과 war파일을 압축 해제한 폴더를 생성한다. 그런데, server.xml에 이미 정의가 되어있기 때문에 충돌이 발생하는 것이다.

따라서 위와 같은 Exception 발생 시에 server.xml 에서 직접 지정한 context path를 지워주면 Exception을 간단하게 처리할 수가 있다.

허용되지 않은 Tomcat User (403 에러)

위에서 볼 수 있다시피 “Tomcat Manager 사용에 허용되지 않은 Tomcat user” 라고 Exception 로그가 기록되어 있다.

해당 문제를 해결하려면, Catalina Home Path/webapps/manager/META-INF 하위에 위치한 context.xml 설정 파일을 수정해줘야 한다. 파일을 열어보면 아래와 같이 명시된 특정 아이피의 접근만 허용하는 설정을 확인할 수 있다.

해당 부분을 주석 처리 해주고 저장한 뒤, 다시 Jenkins로 빌드하면 해당 Exception이 발생하지 않고 정상적으로 빌드 되는 것을 확인할 수 있다.