Jenkins에서 마이그레이션하기

Jenkins에서 GitLab CI/CD로 마이그레이션한다면, Jenkins 워크플로를 복제하고 개선하는 CI/CD 파이프라인을 만들 수 있어요.

출처: 문서

본문

주요 유사점과 차이점

GitLab CI/CD와 Jenkins는 몇 가지 유사점이 있는 CI/CD 도구예요. GitLab과 Jenkins 모두:

잡 컬렉션에 스테이지를 사용해요.
컨테이너 기반 빌드를 지원해요.

또한 두 도구 사이에는 몇 가지 중요한 차이점이 있어요.

GitLab CI/CD 파이프라인은 모두 YAML 형식의 구성 파일로 구성돼요. Jenkins는 Groovy 형식의 구성 파일(선언적 파이프라인)이나 Jenkins DSL(스크립트 파이프라인)을 사용해요.
GitLab은 멀티 테넌트 SaaS 서비스인 GitLab.com과 완전히 격리된 단일 테넌트 서비스인 GitLab Dedicated를 제공해요. 자체 GitLab Self-Managed 인스턴스를 실행할 수도 있어요. Jenkins 배포는 셀프 호스팅해야 해요.
GitLab은 소스 코드 관리(SCM)를 기본 제공해요. Jenkins는 코드를 저장하려면 별도의 SCM 솔루션이 필요해요.
GitLab은 내장 컨테이너 레지스트리를 제공해요. Jenkins는 컨테이너 이미지를 저장하려면 별도의 솔루션이 필요해요.
GitLab은 코드 스캔을 위한 내장 템플릿을 제공해요. Jenkins는 코드 스캔에 서드파티 플러그인이 필요해요.

기능과 개념 비교

많은 Jenkins 기능과 개념은 GitLab에서 같은 기능을 제공하는 동등물이 있어요.

구성 파일

Jenkins는 Groovy 형식의 Jenkinsfile로 구성할 수 있어요. GitLab CI/CD는 기본적으로 .gitlab-ci.yml 파일을 사용해요.

Jenkinsfile 예시:

pipeline {
    agent any

    stages {
        stage('hello') {
            steps {
                echo "Hello World"
            }
        }
    }
}

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

stages:
  - hello

hello-job:
  stage: hello
  script:
    - echo "Hello World"

Jenkins 파이프라인 문법

Jenkins 구성은 섹션(section)과 지시문(directive)이 있는 pipeline 블록으로 구성돼요. GitLab CI/CD는 YAML 키워드로 구성된 비슷한 기능을 가지고 있어요.

섹션 (Sections)

Jenkins	GitLab	설명
agent	image	Jenkins 파이프라인은 에이전트에서 실행되고, agent 섹션은 파이프라인이 어떻게 실행되는지와 사용할 Docker 컨테이너를 정의해요. GitLab 잡은 러너에서 실행되고, image 키워드가 사용할 컨테이너를 정의해요. Kubernetes나 어떤 호스트에서든 자체 러너를 구성할 수 있어요.
post	after_script 또는 stage	Jenkins post 섹션은 스테이지나 파이프라인 끝에 수행할 작업을 정의해요. GitLab에서는 잡 끝에 실행할 명령에 after_script를, 잡의 다른 명령보다 먼저 실행할 작업에 before_script를 사용해요. 잡이 실행될 정확한 스테이지를 선택하려면 stage를 사용해요. GitLab은 항상 다른 정의된 스테이지 이전/이후에 실행되는 `.pre`와 `.post` 스테이지를 지원해요.
stages	stages	Jenkins stages는 잡의 그룹이에요. GitLab CI/CD도 stages를 사용하지만 더 유연해요. 각각 여러 독립 잡이 있는 여러 스테이지를 가질 수 있어요. 최상위에서 stages를 사용해 스테이지와 실행 순서를 정의하고, 잡 수준에서 stage를 사용해 해당 잡의 스테이지를 정의해요.
steps	script	Jenkins steps는 무엇을 실행할지 정의해요. GitLab CI/CD는 이와 비슷한 script 섹션을 사용해요. script 섹션은 YAML 배열로, 순서대로 실행할 각 명령에 대한 개별 항목이 있어요.

지시문 (Directives)

Jenkins	GitLab	설명
environment	variables	Jenkins는 환경 변수에 environment를 사용해요. GitLab CI/CD는 variables 키워드로 잡 실행 중에 사용할 수 있고 더 동적인 파이프라인 구성에도 쓸 수 있는 CI/CD 변수를 정의해요. 이 변수들은 CI/CD 설정 아래 GitLab UI에서도 설정할 수 있어요.
options	해당 없음	Jenkins는 타임아웃, 재시도 값 등 추가 구성에 options를 사용해요. GitLab은 별도 options 섹션이 필요 없고, 모든 구성을 잡 또는 파이프라인 수준의 CI/CD 키워드(예: timeout, retry)로 추가해요.
parameters	해당 없음	Jenkins에서는 파이프라인을 트리거할 때 매개변수가 필요할 수 있어요. GitLab의 매개변수는 CI/CD 변수로 처리되며, 파이프라인 구성, 프로젝트 설정, UI 또는 API를 통한 런타임 수동 지정 등 여러 곳에서 정의할 수 있어요.
triggers	rules	Jenkins에서 triggers는 cron 표기법 등 파이프라인이 언제 다시 실행되어야 하는지 정의해요. GitLab CI/CD는 Git 변경, 머지 리퀘스트 업데이트 등 많은 이유로 파이프라인을 자동 실행할 수 있어요. 어떤 이벤트에 잡을 실행할지 제어하려면 rules 키워드를 사용해요. 예약된 파이프라인은 프로젝트 설정에서 정의돼요.
tools	해당 없음	Jenkins에서 tools는 환경에 설치할 추가 도구를 정의해요. GitLab에는 비슷한 키워드가 없어요. 잡에 정확히 필요한 도구로 사전 구축된 컨테이너 이미지를 사용하는 것이 권장되기 때문이에요. 이 이미지는 캐시할 수 있고 파이프라인에 필요한 도구를 이미 포함하도록 빌드할 수 있어요. 잡에 추가 도구가 필요하면 before_script 섹션의 일부로 설치할 수 있어요.
input	해당 없음	Jenkins에서 input은 사용자 입력 프롬프트를 추가해요. parameters와 비슷하게, inputs는 GitLab에서 CI/CD 변수로 처리돼요.
when	rules	Jenkins에서 when은 스테이지를 언제 실행할지 정의해요. GitLab에도 when 키워드가 있는데, 이전 잡의 상태(예: 잡이 통과했는지 실패했는지)에 따라 잡이 실행을 시작할지 정의해요. 특정 파이프라인에 잡을 추가할 시점을 제어하려면 rules를 사용해요.

일반적인 구성

이 섹션은 자주 사용되는 CI/CD 구성을 다루며, Jenkins에서 GitLab CI/CD로 어떻게 변환할 수 있는지 보여줘요.

Jenkins 파이프라인은 새 커밋이 푸시되는 등 특정 이벤트가 발생할 때 트리거되는 자동화된 CI/CD 잡을 생성해요. Jenkins 파이프라인은 Jenkinsfile에 정의돼요. GitLab의 동등물은 .gitlab-ci.yml 구성 파일 〔/ci/yaml/〕이에요.

Jenkins는 소스 코드를 저장할 곳을 제공하지 않으므로, Jenkinsfile은 별도의 소스 제어 저장소에 저장해야 해요.

잡 (Jobs)

잡은 특정 결과를 얻기 위해 정해진 순서로 실행되는 일련의 명령이에요.

예를 들어 컨테이너를 빌드한 다음 프로덕션에 배포하는 것을 Jenkinsfile로:

pipeline {
    agent any
    stages {
        stage('build') {
            agent { docker 'golang:alpine' }
            steps {
                apk update
                go build -o bin/hello
            }
            post {
              always {
                archiveArtifacts artifacts: 'bin/hello'
                onlyIfSuccessful: true
              }
            }
        }
        stage('deploy') {
            agent { docker 'golang:alpine' }
            when {
              branch 'staging'
            }
            steps {
                echo "Deploying to staging"
                scp bin/hello remoteuser@remotehost:/remote/directory
            }
        }
    }
}

이 예시는:

golang:alpine 컨테이너 이미지를 사용해요.
코드를 빌드하는 잡을 실행해요.
빌드된 실행 파일을 아티팩트로 저장해요.
staging에 배포하는 두 번째 잡을 추가하는데, 이 잡은:
- 커밋이 staging 브랜치를 대상으로 할 때만 존재해요.
- 빌드 스테이지가 성공한 후에 시작해요.
- 이전 잡의 빌드된 실행 파일 아티팩트를 사용해요.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

default:
  image: golang:alpine

stages:
  - build
  - deploy

build-job:
  stage: build
  script:
    - apk update
    - go build -o bin/hello
  artifacts:
    paths:
      - bin/hello
    expire_in: 1 week

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to Staging"
    - scp bin/hello remoteuser@remotehost:/remote/directory
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
  artifacts:
    paths:
      - bin/hello

병렬 (Parallel)

Jenkins에서는 이전 잡에 의존하지 않는 잡이 parallel 섹션에 추가되면 병렬로 실행될 수 있어요.

예를 들어 Jenkinsfile에서:

pipeline {
    agent any
    stages {
        stage('Parallel') {
            parallel {
                stage('Python') {
                    agent { docker 'python:latest' }
                    steps {
                        sh "python --version"
                    }
                }
                stage('Java') {
                    agent { docker 'openjdk:latest' }
                    when {
                        branch 'staging'
                    }
                    steps {
                        sh "java -version"
                    }
                }
            }
        }
    }
}

이 예시는 서로 다른 컨테이너 이미지를 사용해 Python과 Java 잡을 병렬로 실행해요. Java 잡은 staging 브랜치가 변경될 때만 실행돼요.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

python-version:
  image: python:latest
  script:
    - python --version

java-version:
  image: openjdk:latest
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
  script:
    - java -version

이 경우 잡을 병렬로 실행하기 위한 추가 구성이 필요 없어요. 모든 잡에 충분한 러너가 있다면 각각 다른 러너에서 잡이 기본적으로 병렬로 실행돼요. Java 잡은 staging 브랜치가 변경될 때만 실행되도록 설정돼요.

매트릭스 (Matrix)

GitLab에서는 매트릭스를 사용해 단일 파이프라인에서 잡을 병렬로 여러 번 실행하되, 잡 인스턴스마다 다른 변수 값을 사용할 수 있어요. Jenkins는 매트릭스를 순차적으로 실행해요.

예를 들어 Jenkinsfile에서:

matrix {
    axes {
        axis {
            name 'PLATFORM'
            values 'linux', 'mac', 'windows'
        }
        axis {
            name 'ARCH'
            values 'x64', 'x86'
        }
    }
    stages {
        stage('build') {
            echo "Building $PLATFORM for $ARCH"
        }
        stage('test') {
            echo "Building $PLATFORM for $ARCH"
        }
        stage('deploy') {
            echo "Building $PLATFORM for $ARCH"
        }
    }
}

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

stages:
  - build
  - test
  - deploy

.parallel-hidden-job:
  parallel:
    matrix:
      - PLATFORM: [linux, mac, windows]
        ARCH: [x64, x86]

build-job:
  extends: .parallel-hidden-job
  stage: build
  script:
    - echo "Building $PLATFORM for $ARCH"

test-job:
  extends: .parallel-hidden-job
  stage: test
  script:
    - echo "Testing $PLATFORM for $ARCH"

deploy-job:
  extends: .parallel-hidden-job
  stage: deploy
  script:
    - echo "Testing $PLATFORM for $ARCH"

컨테이너 이미지

GitLab에서는 image 키워드를 사용해 별도의 격리된 Docker 컨테이너에서 CI/CD 잡을 실행할 수 있어요.

예를 들어 Jenkinsfile에서:

stage('Version') {
    agent { docker 'python:latest' }
    steps {
        echo 'Hello Python'
        sh 'python --version'
    }
}

이 예시는 python:latest 컨테이너에서 실행되는 명령을 보여줘요.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

version-job:
  image: python:latest
  script:
    - echo "Hello Python"
    - python --version

변수 (Variables)

GitLab에서는 variables 키워드로 CI/CD 변수를 정의해요. 변수를 사용해 구성 데이터를 재사용하거나, 더 동적인 구성을 만들거나, 중요한 값을 저장할 수 있어요. 변수는 전역적으로 또는 잡별로 정의할 수 있어요.

예를 들어 Jenkinsfile에서:

pipeline {
    agent any
    environment {
        NAME = 'Fern'
    }
    stages {
        stage('English') {
            environment {
                GREETING = 'Hello'
            }
            steps {
                sh 'echo "$GREETING $NAME"'
            }
        }
        stage('Spanish') {
            environment {
                GREETING = 'Hola'
            }
            steps {
                sh 'echo "$GREETING $NAME"'
            }
        }
    }
}

이 예시는 변수를 사용해 잡의 명령에 값을 전달하는 방법을 보여줘요.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

default:
  image: alpine:latest

stages:
  - greet

variables:
  NAME: "Fern"

english:
  stage: greet
  variables:
    GREETING: "Hello"
  script:
    - echo "$GREETING $NAME"

spanish:
  stage: greet
  variables:
    GREETING: "Hola"
  script:
    - echo "$GREETING $NAME"

변수는 GitLab UI의 CI/CD 설정에서도 설정할 수 있어요. 어떤 경우에는 시크릿 값에 protected 변수와 masked 변수를 사용할 수 있어요. 이 변수들은 구성 파일에 정의된 변수와 같은 방식으로 파이프라인 잡에서 접근할 수 있어요.

예를 들어 Jenkinsfile에서:

pipeline {
    agent any
    stages {
        stage('Example Username/Password') {
            environment {
                AWS_ACCESS_KEY = credentials('aws-access-key')
            }
            steps {
                sh 'my-login-script.sh $AWS_ACCESS_KEY'
            }
        }
    }
}

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

login-job:
  script:
    - my-login-script.sh $AWS_ACCESS_KEY

또한 GitLab CI/CD는 파이프라인과 저장소와 관련된 값을 담은 사전 정의 변수를 모든 파이프라인과 잡에 제공해요.

표현식과 조건 (Expressions and conditionals)

새 파이프라인이 시작되면 GitLab은 해당 파이프라인에서 어떤 잡이 실행되어야 하는지 확인해요. 변수 상태나 파이프라인 유형 같은 요소에 따라 잡이 실행되도록 구성할 수 있어요.

예를 들어 Jenkinsfile에서:

stage('deploy_staging') {
    agent { docker 'alpine:latest' }
    when {
        branch 'staging'
    }
    steps {
        echo "Deploying to staging"
    }
}

이 예시에서 잡은 커밋하는 브랜치 이름이 staging일 때만 실행돼요.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  rules:
    - if: '$CI_COMMIT_BRANCH == staging'

러너 (Runners)

Jenkins 에이전트처럼 GitLab 러너는 잡을 실행하는 호스트예요. GitLab.com을 사용한다면 자체 러너를 프로비저닝하지 않고 인스턴스 러너 풀로 잡을 실행할 수 있어요.

Jenkins 에이전트를 GitLab CI/CD에 사용하도록 변환하려면 에이전트를 제거한 다음 러너를 설치하고 등록해요. 러너는 오버헤드가 많이 필요하지 않으므로, 사용하던 Jenkins 에이전트와 비슷한 프로비저닝을 사용할 수 있을 거예요.

러너에 대한 몇 가지 주요 세부 정보:

러너는 구성을 통해 인스턴스, 그룹에 공유하거나 단일 프로젝트 전용으로 만들 수 있어요.
더 세밀한 제어를 위해 [tags 키워드](/ci/runners/configure_runners/#control-jobs-that-a-runner-can-run)를 사용하고 러너를 특정 잡과 연결할 수 있어요. 예를 들어 전용, 더 강력하거나 특정 하드웨어가 필요한 잡에 태그를 사용할 수 있어요.
GitLab에는 러너 자동 확장 기능이 있어요. 자동 확장으로 필요할 때만 러너를 프로비저닝하고 필요 없으면 축소할 수 있어요.

예를 들어 Jenkinsfile에서:

pipeline {
    agent none
    stages {
        stage('Linux') {
            agent {
                label 'linux'
            }
            steps {
                echo "Hello, $USER"
            }
        }
        stage('Windows') {
            agent {
                label 'windows'
            }
            steps {
                echo "Hello, %USERNAME%"
            }
        }
    }
}

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

linux_job:
  stage: build
  tags:
    - linux
  script:
    - echo "Hello, $USER"

windows_job:
  stage: build
  tags:
    - windows
  script:
    - echo "Hello, %USERNAME%"

아티팩트 (Artifacts)

GitLab에서는 어떤 잡이든 [artifacts](/ci/yaml/#artifacts) 키워드로 잡이 완료될 때 저장할 아티팩트 집합을 정의할 수 있어요. 아티팩트는 나중에 테스트나 배포에 사용할 수 있는 파일이에요.

예를 들어 Jenkinsfile에서:

stages {
    stage('Generate Cat') {
        steps {
            sh 'touch cat.txt'
            sh 'echo "meow" > cat.txt'
        }
        post {
            always {
                archiveArtifacts artifacts: 'cat.txt'
                onlyIfSuccessful: true
            }
        }
    }
    stage('Use Cat') {
        steps {
            sh 'cat cat.txt'
        }
    }
}

동등한 GitLab CI/CD .gitlab-ci.yml 파일은:

stages:
  - generate
  - use

generate_cat:
  stage: generate
  script:
    - touch cat.txt
    - echo "meow" > cat.txt
  artifacts:
    paths:
      - cat.txt
    expire_in: 1 week

use_cat:
  stage: use
  script:
    - cat cat.txt
  artifacts:
    paths:
      - cat.txt

캐싱 (Caching)

cache는 잡이 하나 이상의 파일을 다운로드해 미래에 더 빠르게 접근할 수 있도록 저장할 때 생성돼요. 같은 캐시를 사용하는 후속 잡은 파일을 다시 다운로드할 필요가 없으므로 더 빨리 실행돼요. 캐시는 러너에 저장되고, 분산 캐시가 활성화되면 S3에 업로드돼요. Jenkins 코어는 캐싱을 제공하지 않아요.

예를 들어 .gitlab-ci.yml 파일에서:

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

Jenkins 플러그인

Jenkins에서 플러그인으로 활성화되는 일부 기능은 GitLab에서 비슷한 기능을 제공하는 키워드와 기능으로 기본 지원돼요. 예를 들어:

Jenkins 플러그인	GitLab 기능
Build Timeout	timeout 키워드
Cobertura	커버리지 리포트 아티팩트 및 코드 커버리지
Code coverage API	코드 커버리지 및 커버리지 시각화
Embeddable Build Status	파이프라인 상태 배지
JUnit	JUnit 테스트 리포트 아티팩트 및 단위 테스트 리포팅
Mailer	알림 이메일
Parameterized Trigger Plugin	trigger 키워드 및 하위 파이프라인
Role-based Authorization Strategy	GitLab 권한 및 역할
Timestamper	잡 로그에 기본적으로 타임스탬프가 찍힘

보안 스캔 기능

Jenkins에서 코드 품질, 보안 또는 정적 애플리케이션 스캔 같은 용도로 플러그인을 사용했을 수 있어요. GitLab은 SDLC의 모든 부분에서 취약점을 탐지하는 보안 스캐너를 기본 제공해요. 템플릿을 사용해 이러한 플러그인을 GitLab에 추가할 수 있어요. 예를 들어 파이프라인에 SAST 스캔을 추가하려면 .gitlab-ci.yml에 다음을 추가해요.

include:
  - template: Jobs/SAST.gitlab-ci.yml

CI/CD 변수를 사용해 보안 스캐너의 동작을 커스터마이즈할 수 있어요. 예를 들어 SAST 스캐너 변수로요.

시크릿 관리

흔히 "시크릿"이라 불리는 권한 정보는 CI/CD 워크플로에 필요한 민감한 정보나 자격 증명이에요. 도구, 애플리케이션, 컨테이너, 클라우드 네이티브 환경의 보호된 리소스나 민감한 정보를 잠금 해제하는 데 시크릿을 사용할 수 있어요.

Jenkins의 시크릿 관리는 보통 Secret 타입 필드나 Credentials Plugin으로 처리돼요. Jenkins 설정에 저장된 자격 증명은 Credentials Binding 플러그인을 사용해 환경 변수로 잡에 노출될 수 있어요.

GitLab의 시크릿 관리는 외부 서비스에 대한 지원되는 통합 중 하나를 사용할 수 있어요. 이 서비스들은 GitLab 프로젝트 외부에 시크릿을 안전하게 저장하지만, 서비스 구독이 필요해요.

GitLab은 OIDC를 지원하는 다른 서드파티 서비스에 대한 OIDC 인증도 지원해요.

또한 CI/CD 변수에 자격 증명을 저장해 잡에 사용할 수 있게 할 수 있지만, 평문으로 저장된 시크릿은 Jenkins에서와 마찬가지로 우발적 노출에 취약해요. 민감한 정보는 항상 masked 및 protected 변수에 저장해야 하는데, 이것이 위험의 일부를 완화해줘요.

또한 .gitlab-ci.yml 파일에 시크릿을 변수로 저장하지 마세요. 이 파일은 프로젝트 접근 권한이 있는 모든 사용자에게 공개되기 때문이에요. 민감한 정보를 변수에 저장하는 것은 프로젝트, 그룹 또는 인스턴스 설정에서만 해야 해요.

보안 지침을 검토해 CI/CD 변수의 안전성을 개선하세요.

마이그레이션 계획 및 수행

다음 단계는 이 마이그레이션을 계획하고 수행하는 데 도움이 돼요.

마이그레이션 계획 만들기

마이그레이션을 시작하기 전에 준비를 위해 마이그레이션 계획을 만들어야 해요. Jenkins에서 마이그레이션하려면 준비 과정에서 스스로에게 다음 질문을 해 보세요.

오늘 Jenkins의 잡에서 사용하는 플러그인은 무엇인가요?
이 플러그인들이 정확히 무엇을 하는지 알고 있나요?
어떤 플러그인이라도 공통 빌드 도구(Maven, Gradle, NPM 등)를 감싸고 있나요?
Jenkins 에이전트에 무엇이 설치되어 있나요?
사용 중인 공유 라이브러리가 있나요?
Jenkins에서 어떻게 인증하나요? SSH 키, API 토큰 또는 다른 시크릿을 사용하나요?
파이프라인에서 접근해야 하는 다른 프로젝트가 있나요?
Jenkins에 외부 서비스(예: Ansible Tower, Artifactory 또는 다른 클라우드 제공자나 배포 대상)에 접근하는 자격 증명이 있나요?

전제 조건

마이그레이션 작업을 하기 전에 먼저:

GitLab에 익숙해져요.
- 핵심 GitLab CI/CD 기능에 대해 읽어요.
- 정적 사이트를 빌드·테스트·배포하는 첫 GitLab 파이프라인 및 더 복잡한 파이프라인을 만드는 튜토리얼을 따라 해요.
- CI/CD YAML 문법 참조를 검토해요.
GitLab을 설정하고 구성해요.
GitLab 인스턴스를 테스트해요.
- 공유 GitLab.com 러너를 사용하거나 새 러너를 설치해 러너가 사용 가능한지 확인해요.

마이그레이션 단계

SCM 솔루션에서 GitLab으로 프로젝트를 마이그레이션해요.
- (권장) 외부 SCM 제공자에서 대량 가져오기를 자동화하는 가능한 임포터를 사용할 수 있어요.
- URL로 저장소를 가져올 수 있어요.
각 프로젝트에 .gitlab-ci.yml 파일을 만들어요.
Jenkins 구성을 GitLab CI/CD 잡으로 마이그레이션하고 머지 리퀘스트에 결과를 바로 표시하도록 구성해요.
클라우드 배포 템플릿, 환경, Kubernetes용 GitLab 에이전트를 사용해 배포 잡을 마이그레이션해요.
여러 프로젝트에서 재사용할 수 있는 CI/CD 구성이 있는지 확인한 다음, CI/CD 템플릿을 만들어 공유해요.
GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법을 배우려면 파이프라인 효율성 문서를 확인해요.

추가 리소스

JenkinsFile Wrapper를 사용해 플러그인을 포함한 완전한 Jenkins 인스턴스를 GitLab CI/CD 잡 안에서 실행할 수 있어요. 이 도구를 사용해 덜 긴급한 파이프라인의 마이그레이션을 늦춰 GitLab CI/CD로의 전환을 완화할 수 있어요.

JenkinsFile Wrapper는 GitLab과 함께 패키징되지 않으며 지원 범위 밖이에요. 자세한 내용은 지원 명세서를 참고해요.

더 알아보기

마이그레이션 전반에 대한 체크리스트는 다른 도구에서 GitLab CI/CD로의 마이그레이션 계획하기 문서를 먼저 읽어보는 걸 추천해요. 컨테이너 기반 빌드와 Docker 이미지 실행은 Docker 컨테이너에서 CI/CD 잡 실행 문서에서, 주요 개념 매핑은 본 문서의 기능과 개념 비교를 참고해요.