Jenkins Pipeline 알아보기

Intro

CI/CD가 이제는 개발팀의 표준처럼 자리 잡았다.

누구나 한 번쯤 Jenkins를 써봤을 것이고,

직접 Jenkins Pipeline을 짜면서 "이거 왜 이럽게 복잡하지?"라는 생각을 해본 적도 있을 것이다.

 

나 역시 처음엔

"파이프라인이 뭐지? 그냥 빌드 잡 여러개 연결한 건가?"
이런 막연한 상태로 시작했다.

 

특히 Scripted, Declarative, Jenkinsfile...

종류가 많고, 예제마다 스타일이 달라서 헷갈리기 쉽다.

 

그래서 이 글에서는

• Jenkins Pipeline의 개념
• 두 가지 문법(방식)의 차이
• 내가 써보며 느낀 실전 팁과 단점 이런 것들을 한 번에 정리해본다.

 

 

출처: https://blog.devops.dev

Jenkins Pipeline 왜 필요한가?

예전에는 빌드, 테스트, 배포를 수동으로 하거나

Jenkins에서 "프리스타일 집"으로 개별적으로 관리했다.

 

하지만,

• 작업이 많아지면 관리가 어렵고
• 작업 순서나 의존성이 복잡해지면 에러 추적이 힘들어진다.

 

Jenkins Pipeline은 이런 문제를 해결하기 위해 등장했다.

즉, 코드로 파이프라인 전체를 설계하고

각 단계를 시각적으로 관리할 수 있다는 게 핵심이다.

 

 

Jenkins Pipeline 구성 방식

Jenkins Pipeline을 구성하는 대표적인 3가지 방식이 있다.

방식	설명	특징
Pipeline script(Webadmin)	Jenkins UI에서 직접 파이프라인 작성	Shell Script와 비슷, 빠른 테스트 용이
Git SCM	Git에 Jenkinsfile 작성, 빌드 시작 시 불러옴	실무에서 가장 많이 쓰임, 버전 관리 가능
Blue Ocean	UI 기반 시각적 파이프라인 구성	쉽고 직관적, Jenkinsfile도 자동 생성

내 경험상, Git SCM 방식이 실무에서는 거의 표준이다.

파이프라인 정의와 코드를 함께 관리할 수 있어서 협업에 좋다.

 

 

출처: https://velog.io/@kku64r/pipeline

파이프라인 스크립트 문법 (Scripted vs Declarative)

Jenkins Pipeline은 문법에 따라 Scripted와 Declarative 두 가지 방식이 있다.

 

Scripted Pipeline

• Grovy 기반, 프로그래밍 유연성 높음
• 자유도가 높지만 문법이 다소 복잡
• 커스텀 작업, 반복문, 분기 등 절차적 처리에 강점
• 예전 방식이라 점점 줄어드는 추세

 

Declarative Pipeline

• 현대 Jenkins에서 표준으로 쓰임
• 구조가 명확하고, 배워서 쓰기 쉽다
• 필수 및 선택 섹션이 구분되어 있어서 가독성 및 유지보수에 유리
• 실무에서도 가장 추천

 

직관적으로 정리하면

Scripted = Groovy 코딩이 편한 사람, 복잡한 조건 처리에 유리
Declarative = 대부분의 팀 프로젝트, 표준화된 빌드 파이프라인

 

 

Declarative Pipeline 주요 문법과 예시

Declarative Pipeline 다음과 같은 구조로 작성한다.

pipeline {
    agent any
    environment {
        VAR_NAME = 'value'
    }
    stages {
        stage('Build') {
            steps {
                echo '빌드 시작'
            }
        }
        stage('Test') {
            steps {
                echo '테스트 실행'
            }
        }
    }
    post {
        always {
            echo '파이프라인 종료'
        }
    }
}

여기서 자주 쓰는 문법과 기능을 하나씩 정리해본다.

 

pipeline 블록

• 파이프라인 전체를 감싸는 최상위 선언부
• 하나의 Jenkinsfile에 하나만 존재

 

agent

• 파이프라인이 실행될 노드(에이전트) 지정
• agent any: 사용 가능한 어떤 노드에서도 실행
• agent none: 각 stage별로 agent 선언 필요

pipeline {
    agent { label 'build-server' }
}

 

도커 기반 에이전트 설정도 가능하다.

agent {
    docker {
        image 'node:18'
        args '-p 3000:3000'
    }
}

 

environment

• 파이프라인에서 사용할 환경변수 정의

environment {
    NODE_ENV = 'production'
    SECRET_KEY = credentials('my-secret-key')
}

stage 내에서 별도로 선언 가능.

 

tools

• Maven, JDK 등 빌드 도구를 자동 설치

tools {
    maven 'maven-3.6.3'
}

 

options

• 타임아웃, 빌드 이력 관리 등 파이프라인의 옵션 지정

options {
    timeout(time: 30, unit: 'MINUTES')
    skipStagesAfterUnstable()
}

 

parameters

• 파이프라인 실행 시 사용자 입력값(매개변수) 받기

parameters {
    string(name: 'DEPLOY_ENV', defaultValue: 'dev', description: '배포 환경 선택')
    booleanParam(name: 'RUN_TEST', defaultValue: true, description: '테스트 실행 여부')
}

 

stages & steps

• stages: 빌드의 각 단계(스테이지)를 묶음
• steps: 각 단계에서 실제 실행할 작업(쉘 명령 등)

stages {
    stage('Install') {
        steps {
            sh 'npm install'
        }
    }
    stage('Lint') {
        steps {
            sh 'npm run lint'
        }
    }
}

 

post

• 빌드가 끝난 후 항상 성공 or 실패 시점별로 실행할 작업 정의

post {
    always {
        echo '파이프라인 종료'
    }
    success {
        echo '성공적으로 완료'
    }
    failure {
        echo '에러 발생'
    }
}

 

 

마무리

Jenkins Pipeline은 

코드로 빌드, 테스트, 배포 과정을 한눈에 설계할 수 있는 강력한 도구다.

 

직접 써보니

• 파이프라인의 "가시성"
• 코드 리뷰, 협업의 편의성
• 실패 원인 추적의 용이함

이런 점이 생각 이상으로 실무에서 유용했다.

 

반면,

• 러닝커브와 플러그인 관리
• UI/UX의 한계
• 환경 세팅의 번거로움

이런 부분은 분명 단점이기도 했다.

 

처음은 어렵지만, 익숙해지면
효율적인 DevOps 문화의 핵심이 된다 :)

 

 

참고자료:

Jenkins Official Web Site - Pipeline Syntax

Pipeline Syntax