나의 첫 젠킨스 파이프만들기

젠킨스 파이프이란?

젠킨스 파이프라인은 지속적인 배포 파이프라인을 구현하고 통합하는 것을 지원하는 플러그인입니다.

지속적 배포(Continuous delivery, CD)는 짧은 주기로 소프트웨어를 개발하는 소프트웨어 공학적 접근의 하나로, 소프트웨어를 더 빠르게, 더 주기적으로 빌드하고 테스트하고 배포하는 것을 목표로 하는 것입니다.

파이프라인은 Jenkinsfile이라고 불리는 텍스트 파일을 통해서 사용한다.

빠르게 파이프라인 시작해보기

  1. 파이프라인을 적용할 저장소(ex. github,bitbucket 등)에 Jenkinsfile이라는 이름으로 파일을 만든 후 그 안에 다음과 같은 예제 소스를 입력합니다.

    pipeline {
    agent { docker { image 'maven:3.3.3' } }
    stages {
        stage('build') {
            steps {
                sh 'mvn --version'
            }
        }
    }
}

  2. Jenkins에 접속하여 New Item을 클릭한 후 이름을 대충 짓고, Multibranch Pipeline을 선택한 후 ok를 누릅니다.

  3. 위의 Branch Sources 탭을 클릭후 Add source 버튼을 클릭하여 원하는 저장소의 종류를 선택하고 내용을 채웁니다.

  4. Save버튼을 클릭

이렇게 파이프라인을 셋팅시키게 되면 저장소에 새로운 PR(pull request)이나 새로운 브렌치를 젠킨스가 자동적으로 탐색하고 파이프라인이 실행된다.

Running multiple steps

파이프라인은 어플리케이션을 build,test,deploy를 할 수 있도록 멀티플한 단계로 구성되어있다. 파이프라인은 이러한 단계를 구성할 수 있도록 쉬운 방법을 제공하고 있다.

하나의 명령어로 하나의 액션을 취하며 이게 성공하였을 때 다음 단계로 넘어갈 수 있다. 하지만 이 단계가 실패했을 때는 파이프라인이 실패할것이다.

만약 이 모든단계가 성공적으로 수행되었을 때, 파이프라인은 성공적으로 실행됬음을 알린다.

유닉스 기반의 OS에서는 sh을 사용하며, 윈도우 기반의 OS는 bat파일을 사용한다.

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'echo "Hello World"'
                sh '''
                    echo "Multiline shell steps works too"
                    ls -lah
                '''
            }
        }
    }
}

Timeouts, retries and more

재시도와 타임아웃 등 다양한 강력한 기능들을 사용할 수 있다.

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                retry(3) {
                    sh './flakey-deploy.sh'
                }

                timeout(time: 3, unit: 'MINUTES') {
                    sh './health-check.sh'
                }
            }
        }
    }
}

위의 소스는 배포단계를 설정하는 것이고, 처음에는 flakey-deploy.sh 스크립트를 3번정도 재시고 한 후, 그 뒤에 health-check스크립트를 실행했을 때 3분안에 완료되야 함을 나타낸다.

Finishing up

작업이 완료된 후 필요한 작업을 post section에서 정의할 수 있다.

pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                sh 'echo "Fail!"; exit 1'
            }
        }
    }
    post {
        always {
            echo 'This will always run'
        }
        success {
            echo 'This will run only if successful'
        }
        failure {
            echo 'This will run only if failed'
        }
        unstable {
            echo 'This will run only if the run was marked as unstable'
        }
        changed {
            echo 'This will run only if the state of the Pipeline has changed'
            echo 'For example, if the Pipeline was previously failing but is now successful'
        }
    }
}

실행 환경 정의하기

이 전의 많은 예제들에서도 보았듯이 agent라는 디렉티브가 필요함을 알 수 있다. 이 디렉티브는 파이프라인의 실행 환경을 정의하는 것이다.

파이프라인은 도커 이미지와 컨테이너를 쉽게 사용하여 내부를 운영할 수 있도록 설계되었다. 이를 통해 Pipeline은 에이전트에 대한 다양한 시스템 도구와 종속성을 수동으로 구성할 필요 없이 필요한 환경과 도구를 정의할 수 있다. 이 방법을 사용하면 도커 컨테이너에 포장될 수 있는 모든 도구를 사용할 수 있다.

pipeline {
    agent {
        docker { image 'node:7-alpine' }
    }
    stages {
        stage('Test') {
            steps {
                sh 'node --version'
            }
        }
    }
}

Recording tests and artifacts

테스트 단계를 통해서 나온 수천가지의 라인이 콘솔을 통해서 보여질 것이다. 이 중 테스트 실패에 대한 정보를 찾기 위해 수천 개의 콘솔 출력 결과를 체크하고 싶지 않은 사람을 위해 파이프라인에서는 junit 단계를 제공한다. 이는 테스트 결과를 기록하고 집계할 수 있도록 만든다.

pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                sh './gradlew check'
            }
        }
    }
    post {
        always {
            junit 'build/reports/**/*.xml'
        }
    }
}

Cleaning up and notifications

post 섹션에서 이메일이나 hipcaht, slack등을 이용하여 알림을 주는 것이 가능하다.

post {
    failure {
        mail to: 'team@example.com',
             subject: "Failed Pipeline: ${currentBuild.fullDisplayName}",
             body: "Something is wrong with ${env.BUILD_URL}"
    }
}

튜토리얼을 마치면서

  • 젠킨스 파이프라인을 통해서 각 단계에 대하여 가볍게 알아볼 수 있었다.
  • 실제 적용해보고 싶은 그림은 원격저장소 기타 브렌치에서 변경이 일어났을 때 이를 빌드,테스트하는 것과 특정 브렌치에서는 변경이 일어났을 때는 빌드,테스트,배포 과정을 하고 싶다.
  • 우선 프로젝트의 다른 환경이 설정된 이후에 실제로 젠킨스를 이용하여 빌드/테스트/배포 자동화를 하는 것을 포스트해보겠다.