ming-AA/jenkins.md

## jenkins.md

      
    Raw
  

              jenkins.md
            
          
    Jenkins

소프트웨어 빌드, 테스트, 제공, 배포와 관련된 모든 종류의 작업을 자동화하는데 사용할 수 있는 독립형 오픈 소스 자동화 서버

복잡하고 어려운 통합으로부터 해방
프로젝트의 진행 방향 및 속도를 확인 가능
이슈의 조기 발견, 모든 머지 이슈나 통합 이슈가 바로 발견되고 빌드 실패시 알람
빌드, 테스트 소스코드 통합을 자동으로 하는 환경이 되어 빠른 개발 가능

목차


설치 방법
Jenkins 시작하기
Jenkins 활용하기
개념 정리
출처

설치 방법

Jenkins 프로젝트는 Stable(LTS)과 Regular releases(Weekly) 두 가지를 제공한다. 필요에 따라 선택하면 된다.

Stable(LTS) : 최신 안정 버전의 젠킨스. 릴리스의 기준은 정기 릴리스의 흐름에서 12주마다 선택된다. 4주마다 버그 및 보안 수정을 포함하는 안정적인 릴리스를 제공한다.
Regualr releases(Weekly) : 최신 주간 릴리스 버전의 젠킨스. 릴리스는 버그 수정 및 새로운 기능을 필요로 하는 사용자 및 플러그인 개발자에게 빠른 제공을 지원한다. 일반적으로 주 단위로 제공된다.

설치 순서


젠킨스는 WAR 파일, 네이티브 패키지, 설치 프로그램, Docker 이미지로 배포된다.


설치 전에 사용자의 하드웨어 및 소프트웨어 요구사항을 검토해야 한다. 확인
다양한 패키지 중에 하나를 선택하고 설치 지침을 따른다. 설치
설치했으면 사용자 핸드북의 Jenkins 설치 섹션으로 이동한다. 설치 설명
설치한 패키지를 확인할 수도 있다. 설치 확인

Windows


하드웨어 및 소프트웨어 요구사항을 검토한다.
JAVA를 설치한다. 설치 방법
Stable(LTS) 젠킨스를 설치한다. 설치
내려받은 파일의 압축을 해제하면 jenkins.msi 파일을 볼 수 있다.
설치 과정 중 젠킨스 설치 폴더를 선택할 수 있다. 기본적으로 C:/Program Files/Jenkins 또는 C:/Program Files(X86)/Jenkins가 선택될 것이다. 이대로 Next 버튼을 눌러 진행한다.
Finish 버튼을 눌러 설치를 완료한다.

Windows에서 젠킨스를 시작, 중지, 재시작하기


커맨드 프롬프트(cmd)에서 다음 명령어를 이용해 Service 윈도우를 연다.

services.msc

서비스에서 jenkins라는 이름의 서비스를 찾는다.
jenkins 서비스를 우클릭해서 Properties(속성) 을 클릭한다.
일반(General) 탭에서 젠킨스 서비스 명과 실행 파일의 위치, 서비스 상태, 시작 파라미터를 볼 수 있다.
Startup type 옵션을 이용해 젠킨스가 윈도우 위에서 어떻게 실행될 것인지 선택할 수 있다. Automatic(Delayed Start) 중에서 선택 가능하다. 항상 Automatic을 선택하자.
다음 서비스 상태에서 젠킨스를 Start(시작), Stop(중지), Pause(정지), Resume(재시작) 시킬 수 있다.


로그온(Log On) 탭으로 이동해 젠킨스를 시작시킬 사용자 이름을 정한다.
Local System Account(로컬 시스템 계정)를 사용할 수도 있지만 권장하지 않고, 새로 사용자를 만들어 특별한 권한을 주는 것을 권장한다.


복구(Recovery) 탭에서는 젠킨스 서비스가 시작되는 과정에서 문제가 생길 경우 해야 할 일을 정의할 수 있다.
아래 예제를 보면, 첫 번째가 발생하면 젠킨스를 재시작시키고, 두 번째 실패 때는 컴퓨터를 다시 시작한다. 마지막으로 그 다음 실패가 일어나면 이슈를 디버그하기 위해 특정 프로그램을 실행시키거나, 젠킨스 실패 로그를 특정 젠킨스 관리자에게 메일로 보내 조사를 진행할 수 있다.


Jenkins 시작하기

설정 마법사

Jenkins에 처음 접근하면 시작하기 마법사 화면이 나타난다.
젠킨스 잠금 해제하기
1. 처음 접속시 초기 관리자 비밀번호를 이용해 잠금을 해제해야 한다.
2. 비밀번호는 jenkins_home 폴더의 initialAdminPassword 파일에 있다.
3. 파일의 전체 경로는 다음 화면과 같이 젠킨스 화면에 나타난다.
4. initialAdminPassword 파일에서 암호를 찾아서 adminisrator password 칸에 붙여넣고 continue를 누른다.


젠킨스 커스터마이징

Jenkins 플러그인을 설치하기 위해 다음 화면과 같이 두 가지 옵션이 나타난다.
1. [Install suggested plugins]을 클릭하면 젠킨스 커뮤니티에서 추천하는 플러그인이 모두 설치된다.
2. [Select plugins to install]을 클릭하면 설치할 플러그인을 고를 수 있다. 선택하면 추천 플러그인은 이미 선택되어 있다.
3. 플러그인을 선택한 후 하단의 Install 버튼을 누르면 플러그인 설치가 진행될 것이다.


첫 번째 관리자 만들기
1. 플러그인이 설치된 후, 관리자를 만드는 화면이 나타난다.이전 단계인 젠킨스 셋업 마법사에서 사용한 관리자 계정과는 다르다.
2. 작성한 후 Save and Finish 버튼을 누른다. 새 관리자를 만드는 대신 Continue as admin 버튼을 눌러 초기 관리자로 진행하는 것도 가능하다.
3. Start using Jenkins를 눌러 젠킨스 대시보드로 넘어간다.


젠킨스 유저인터페이스

해당 화면은 젠킨스 대시보드이다. 화면에서 신규 작업을 생성하고, 기존 작업의 실행 일정을 변경하며, 작업 정의 화면으로 이동하는 등의 기능을 수행한다.

구성 패널
빌드 대기 목록 및 실행자 상대 패널
헤더
작업 테이블


Jenkins 활용하기

젠킨스 플러그인 매니저

젠킨스의 기능은 대부분은 플러그인에서 나온다. 플러그인 매니저를 활용하여 플러그인을 관리해보자.
1. 대시보드에서 젠킨스 관리 - 플러그인 관리를 클릭한다.
2. 업데이트된 플러그인 목록, 설치 가능, 설치된 플러그인 목록, 고급 네 가지의 탭을 볼 수 있다.


새로운 젠킨스 플러그인을 설치해보자. 설치 가능 탭은 젠킨스에서 사용 가능한 모든 플러그인의 목록을 나열한다. 아래의 플러그인을 다운로드한다.

Git plugin
GitHub plugin
Deploy to container plugin : 젠킨스가 빌드한 결과물을 톰캣에 배포하기 위한 플러그인
Publish Over SSH plugin : 젠킨스에서 원격 배포를 위한 플러그인

1. 대시보드에서 젠킨스 관리 - 플러그인 관리를 클릭한다.
2. 업데이트된 플러그인 목록, 설치 가능, 설치된 플러그인 목록, 고급 네 가지의 탭을 볼 수 있다.
3. 설치 가능 탭에서 플러그인을 검색한 다음 [재시작 없이 설치하기]나 [지금 다운로드하고 재시작 후 설치하기] 버튼을 클릭한다.
4. [지금 확인] 버튼을 누르면 새로고침 될 것이다.
젠킨스의 작업

1.프리스타일 프로젝트 활용하기

젠킨스에서 가장 일반적으로 활용되는 작업 유형은 프리스타일 프로젝트이다. 지금부터 Github 프로젝트와 연동시켜 보겠다.
상세 작업 구성
1. 젠킨스 대시보드에서 New Item을 누른다.
2. 여러 종류의 젠킨스 잡을 선택하는 화면에서 프리스타일 잡을 누른다.
3. Enter an item name란에 이름을 작성한다.
4. 상세 작업 구성 페이지로 이동한다.

상세 작업 구성 페이지는 아래와 같이 구성되어 있다.


General : 젠킨스에서 작업의 실행 방식을 사용자가 변경할 수 있도록 하는 영역
Source code management : 소스 제어와 관련된 구성을 정의하는 영역
Build triggers : 업스트림 작업, 빌드 스케줄링(CRON)과 지속적 통합 옵션(SCM 폴링)을 정의하는 영역
Build steps : 빌드의 일부로 실행하는 자동화 단계를 추가할 수 있는 영역
Post-build actions : 빌드가 완료된 후 실행할 모든 단계를 지정하는 영역


Gneral
1. [설명]을 작성한다.
2. [Github project]를 체크하고, Github의 프로젝트 페이지의 url과 name을 작성한다.
3. [오래된 빌드 삭제]를 선택하면 빌드 기록 제거 빈도를 설정할 수 있다. 유지 기간과 개수를 작성한다.


소스 코드 관리

소스 코드 관리에서는 소스 제어 솔루션을 선택할 수 있다. Git의 경우 플러그인이 다운로드되어 있다면 아래와 같이 나타난다.


Repository : 복제할 깃 리포지토리를 지정한다.
Branches to build : 체크아웃할 브랜치를 한 개 또는 그 이상 지정할 수 있다. 기본값은 마스터이다.
Repository browser : 깃 리포지에서 사용할 기본 리포지토리 브라우저를 지정한다. 어셈블라웹, 킬른, TFS, 깃허브웹 등을 지원한다.

1. [Git]을 선택한다.
2. [Repository URL]에 복제할 깃 리포지토리의 URL을 작성한다.
3. [Credentials]에서 [Add]에서 jenkins를 클릭한다.
4. Jenkins Credentials Provider:Jenkins가 뜬다.
5. [Kind]를 Username with password로 설정한 후 Github의 Username과 Password를 작성한다. 그리고 Jenkins의 ID를 작성한다.
6. Add 버튼을 누른다.
7. [Branches to build]에 빌드할 브랜치를 작성한다. 기본값인 마스터로 둔다.


빌드 유발

빌드 유발은 빌드 작업이 실행되도록 명령을 내리는 이벤트다. 선택지 중 GitHub hook trigger for GITScm polling를 선택하면 github에서 push 이벤트가 발생하면 자동으로 빌드가 이루어진다. 그 전에 Github에서 webhook 설정을 해야한다. webhook은 앱이 다른 앱에 실시간 정보를 제공하는 방법이다.

1. 젠킨스 새창을 연다.
2. 젠킨스 관리 - 시스템 설정을 클릭한다.
3. [Jenkins Location]에서 [Jenkins URL]을 외부에서 접근할 수 있는 외부ip나 도메인으로 수정한다.
(젠킨스 포트의 방화벽을 여는 것을 잊지 말아야 한다. ngrok을 사용하였으나 보안상 문제가 될 수 있으니 참고 !)
4. GitHub 프로젝트 페이지를 연다.
5. [Setting] - [Webhooks]에서 Jenkins주소/github-webhook/을 입력한다.
6. Add webhook 버튼을 누른다.


1. [GitHub hook trigger for GITScm polling]를 선택한다.


빌드 스텝

빌드 스텝에서는 작업 실행 중 발생할 자동화 및 순서를 정의한다. 작업을 실행하면 젠킨스는 빌드 스텝 섹션에 지정된 스텝을 순서대로 실행한다. 상세작업 구성 페이지에서 정의할 수 있는 자동화 단계는 아래와 같다.


Excute Windows batch command(윈도우 배치 명령 실행) : 이 빌드 스텝을 통해 MS-DOS 배치 명령을 입력할 수 있다. 젠킨스는 실행 시 입력된 텍스트를 .bat 파일로 변환하고 대상 시스템에서 실행한다.
Excute shell(셸 실행) : 이 빌드 스텝을 통해 일련의 유닉스 셸 bash 명령 또는 bash 스크립트 코드를 입력할 수 있다.
Invoke Ant(엔트 호출) : 젠킨스에서 앤트 빌드 스크립트 내에서 특정 앤트 대상을 호출하도록 지정할 수 있다. 실행을 하면, 젠킨스는 메인 구성 영역에서 정의한 앤트를 시작하고 지정된 대상을 호출한다.
Invoke top-level Maven target(상위 레벨 메이븐 타겟 호출) : 특정 메이븐 생명주기 테스크를 대상으로 지정할 수 있다.
Send files or excute commands over SSH(SSH를 통해 파일 보내기 또는 명령 실행) : 젠킨스에서 원격으로 배포할 수 있다.


GitHub에 올린 프로젝트는 Maven 프로젝이기에 설정해준다.

Jenkins는 빌드 후 war를 $JENKINS_HOME/jobs/$Job_name/workspace에 저장한다.

1. [Invoke top-level Maven target]을 선택한다.
2. Maven Version은 Global Tool Configuration-Maven을 가져온다.
3. Goals에 clean package를 작성한다.
빌드 후 조치

주요 빌드 스텝이 끌날 때 실행된다. 빌드 후 조치는 알림 목적으로 사용하거나, 빌드 스텝이 성공적으로 끝나지 않아도 처리해야 할 작업을 수행하는데 편리하다. 아래와 같은 액션이 있다.


아티팩트 보관
다른 프로젝트 빌드
Junit 테스트 결과 보고서 발행
JavaDoc 발행
알림


빌드 후 WAS 컨테이너에 자동배포를 하도록 정보를 입력한다.


완료

코드 수정 후 push를 하면 빌드 히스토리에서 자동으로 빌드가 진행되는 것을 확인할 수 있다. 콘솔을 확인해보면 Github push로 빌드가 유발되었음을 확인 가능하다.


2.젠킨스 파이프라인 활용하기

이전 내용에서 프리스타일 잡은 웹 기반의 GUI로 동작하는 설정 방식이었다. CI 파이프라인에 변경 사항을 만들기 위해서는 젠킨스에 로그인해 각각의 프리스타일 잡의 설정을 변경해야만 했다.
젠킨스 파이프라인은 코드로 작성하는 방식으로, 프로그래밍과 버전 관리를 지원한다. 아래는 파이프라인 방식의 장점이다.

프로그래밍이 가능하다.
모든 CI/CD 파이프라인 설정이 하나의 파일(Jenkinsfile)을 이용해 표현 가능하다.
일반 코드처럼 버전 관리가 가능하다.
파이프라인을 서술적 파이프라인 문법을 이용해 정의할 수 있게 하여 쉽게 코딩할 수 있다.

상세 작업 구성
1. 젠킨스 대시보드에서 New Item을 누른다.
2. 여러 종류의 젠킨스 잡을 선택하는 화면에서 Pipeline을 누른다.
3. Enter an item name란에 이름을 작성한다.
4. 상세 작업 구성 페이지로 이동한다.
5. Pipeline 탭을 눌러 파이프라인 영역으로 이동한다.
6. [Definition] 영역에서 Pipeline script와 Pipeline script from SCM 두 가지 중 하나를 선택한다.
(첫 번째는 파이프라인 코드를 작성 가능하고, 두 번째는 파이프라인 스크립트가 자동으로 버전 관리 시스템에서 내려받아진다.)
7. [Pipeline Syntax]는 GUI 기반의 설정을 코드로 변환하는 것을 도와준다.
8. [Pipeline script]을 선택하고 try sample Pipeline 영역을 선택한 후 GitHub+Maven 옵션을 선택한다.
9. 하단의 Save 버튼을 눌러 파이프라인의 변경 사항을 저장한다.


파이프라인 스크립트

파이프라인 샘플 코드의 내용이다. 간략하게 알아보자.


pipeline{} 영역은 메인 컨테이너로, 젠킨스 마스터에서 파이프라인 스크립트 영역 전체를 실행하라는 것을 정의한다.
pipeline{} 컨테이너 안에 컨테이너가 있다.
stage('Build') 컨테이너에서 메이븐 소스코드를 깃허브 저장소에서 다운로드하고 젠킨스가 전역 환경 설정에서 정의된 M3 메이븐 도구를 사용하게 한다. 다음 메이븐 프로젝트를 빌드한다. 그리고 빌드 결과물을 JUnit 테스트 결과와 함께 묶어낸다.

pipeline {
    agent any

    tools {
        // Install the Maven version configured as "M3" and add it to the path.
        maven "M3"
    }

    stages {
        stage('Build') {
            steps {
                // Get some code from a GitHub repository
                git 'https://github.com/jglick/simple-maven-project-with-tests.git'

                // Run Maven on a Unix agent.
                // sh "mvn -Dmaven.test.failure.ignore=true clean package"

                // To run Maven on a Windows agent, use
                bat "mvn -Dmaven.test.failure.ignore=true clean package"
            }

            post {
                // If Maven was able to run the tests, even if some of the test
                // failed, record the test results and archive the jar file.
                success {
                    junit '**/target/surefire-reports/TEST-*.xml'
                    archiveArtifacts 'target/*.jar'
                }
            }
        }
    }
}

파이프라인 스테이지 뷰

스테이지 뷰는 젠킨스 파이프라인과 멀티브랜치 파이프라인 잡에서만 동작한다. 젠킨스 스테이지 뷰에서 파이프라인의 다양한 단계의 진행 상황을 실시간으로 확인할 수 있다. 이전 파이프라인을 실행해 확인해보자.

1. 젠킨스 대시보드의 All 탭 밑에서 만들었던 파이프라인의 빌드 트리거 아이콘을 눌러 파이프라인을 실행한다.
2. 스테이지 뷰를 보기 위해 파이프라인 이름을 클릭한다.
3. 스테이지 뷰 페이지로 이동한다. 파이프라인 번호, 실행 날짜와 시간, 스테이지 명칭과 상태, 실행 시간 등을 한눈에 확인가능하다.
4. 색상으로 채워진 상태 박스 클릭 시 로그를 볼 수 있다.


개념정리

컴파일, 빌드, 배포


출판사에 비유

1. 영문으로된 글을 한글로 번역하는 것 = 컴파일
2. 번역한 글을 책으로 엮는 것 = 빌드
3. 완성된 책을 고객들이 읽을 수 있도록 서점에 진열하는 것 = 배포
4. 1~2번 과정을 하나로 묶어 '빌드 한다'고 하기도 힌다.

프로그래밍적 관점

1. 컴파일 : 사용자가 작성한 코드를 컴퓨터가 이해할 수 있는 언어로 바꾸는 일
2. 빌드 : 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일
3. 배포 : 코드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일
4. 혹은 컴파일을 포함해 war, jar 등의 실행 가능한 파일을 뽑아내기까지의 과정을 빌드한다고도 한다.
1. 코드를 작성하고 Run 버튼을 눌러 코드를 실행시킴(컴파일+실행)
2. 정상적 실행이 된다면 이것을 war 파일로 만듬(빌드) 또는 exe, jar 파일로 만듬(빌드)
3. 웹서버에 올림(배포, deploy) or 사용자에게 전달(배포, distribution)
반복된 작업

코드의 수정이 있을때마다 컴파일, 빌드, 배포 등의 과정이 반복된다.

예를 들어 수정된 코드를 git에 올리면-> 통합된 코드 컴파일 -> 빌드 -> 배포와 같은 과정이 필요하다.

더 나아가 코드가 제대로 작동하는지 테스트 코드를 작성하고 수행 및 검증하는 작업도 필요하다.
자동화

개발자가 git에 수정된 코드를 올리면

컴파일, 테스트, 빌드, 배포 등의 과정을 정해진 절차에 따라 특정 프로그램이 자동으로 수행한다.

모든 과정이 끝나면 결과를 개발자에게 리포트한다.

즉, 자동화는 사람이 직접 수행할 필요 없이 프로그램이 대신 자동으로 수행해주는 것을 말한다.
CI/CD

CI(Continuous Integration), 지속적 통합

고전적 방식(모든 개발이 끝난 이후에 코드 품질을 관리)의 단점을 해소하기 위해 나타난 개념

CI는 개발을 하면서 '코드에 대한 통합'을 '지속적'으로 진행함으로써 품질을 유지하는 것

예를 들어 아래와 같은 상황을 만들지 않기 위해서 필요

10명의 개발자가 참여하는 프로젝트
git에 기본 틀인 코드가 올라와 있고, 각 개발자는 자신의 로컬 환경에 clone 받아서 작업을 시작
그런데 개발이 끝날때까지 모든 개발자가 한 번도 중앙저장소에 코드를 올리지 않음
개발이 완료된 후, 10명의 개발자의 코드를 한 번에 통합해야 하는 상황
그렇다면 지속적인 통합을 이루기 위해서는 어떻게 해야 할까?

자동화가 되지 않았을 경우

1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 저장소 코드와 통합한다.
2. 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.
3. 통합된 코드가 제대로 빌드되는지 테스트한다.
4. 결과를 정리하고, 버그가 있다면 다음날 업무 목록에 적는다.
위의 과정이 잘 지켜진다면 코드의 품질을 유지할 수 있을 것이다.

이러한 CI는 아주 이상적으로 보이지만, 너무 귀찮고 긴 시간이 소요될 수 있다는 단점이 있다.

그렇기에 CI에 자동화라는 키워드가 따라다닌다.

자동화가 이루어진 경우

1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 저장소 코드와 통합한다.
2. 다음날, 출근하여 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.
테스트, 빌드 등의 복잡한 절차가 모두 생략되고, git에 코드를 올리면 되는 것이다.
CI의 자동화가 되어 모든 과정이 단순화되었다.
CD(Continuous Delivery, Continuous Deployment), 지속적 배포

소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념

CI를 통해 개발 중에 지속적으로 빌드와 테스트를 진행하고 이를 통과한 코드에 대하여 테스트 서버와 운영 서버에 곧바로 내용을 배포해 반영하는 것이다. 이상적인 환경이라면 CI가 잘 이루어졌다면 자연스럽게 CD도 이루어지게 되어있다.
출처


https://www.jenkins.io
https://itholic.github.io
https://gintrie.tistory.com
https://blog.outsider.ne.kr/1159
책, 젠킨스 마스터, 조나단 맥앨리스터
책, 초보를 위한 젠킨스2 활용 가이드, 니킬 파타니아