• GitLab CI/CD Primer
• 주요 유사점과 차이점
  • 제공 사항
  • 에이전트 vs 러너
  • 작업 흐름
  • 템플릿 및 코드 구성
    • Bamboo Specs
    • .gitlab-ci.yml 구성 파일
  • 구성
    • Bamboo YAML Spec 구문
  • 공통 구성
    • Workflow
    • 빌드 계획
    • 컨테이너 이미지
    • 변수
    • 작업 및 작업
    • 조건문
    • 트리거
    • 아티팩트
    • 캐싱
    • 배포 프로젝트
  • 보안 스캐닝 기능
  • 시크릿 관리
  • 이주 계획
    • 마이그레이션 계획 생성
    • 전제 조건
    • 마이그레이션 단계

Bamboo에서의 이주

Atlassian Bamboo에서 GitLab CI/CD로의 이주 방법을 살펴봅니다. 이주의 초점은 Atlassian Bamboo UI에서 내보낸 또는 Spec 저장소에 저장된 Bamboo Specs YAML에 있습니다.

GitLab CI/CD Primer

GitLab CI/CD에 처음이라면 시작 가이드를 사용하여 기본 개념을 익히고 첫 .gitlab-ci.yml 파일을 만드는 방법을 배우세요. 이미 GitLab CI/CD를 사용해 본 경험이 있다면 CI/CD YAML 구문 참조를 확인하여 사용 가능한 키워드의 완전한 목록을 볼 수 있습니다.

또한 Auto DevOps를 살펴보세요. 이것은 미리 구성된 기능 및 연동을 사용하여 응용 프로그램을 자동으로 빌드, 테스트 및 배포합니다.

주요 유사점과 차이점

제공 사항

Atlassian은 Bamboo를 클라우드(SaaS) 또는 데이터 센터(자체 관리) 옵션으로 제공합니다. 세 번째 서버 옵션은 2024년 2월 15일에 EOL 예정입니다.

이러한 옵션은 GitLab의 SaaS 및 자체 관리와 유사합니다. GitLab은 또한 GitLab Dedicated을 제공합니다. 이는 완전히 격리된 단일 테넌트 SaaS 서비스입니다.

에이전트 vs 러너

Bamboo는 빌드 및 배포를 실행하는 데 에이전트를 사용합니다. 에이전트는 Bamboo 서버에서 실행되는 로컬 에이전트 또는 서버 외부에서 실행되는 원격 에이전트일 수 있습니다.

GitLab은 러너라고 불리는 에이전트와 유사한 개념을 사용합니다. 러너는 executors를 사용하여 빌드를 실행합니다. executors의 예는 shell, Docker, 또는 Kubernetes입니다. GitLab SaaS 러너를 사용하거나 자체 관리 러너를 배포할 수 있습니다.

작업 흐름

Bamboo 작업 흐름은 프로젝트로 구성됩니다. 프로젝트는 여러 계획에 필요한 변수, 공유 자격 증명, 및 권한을 구성하는 데 사용됩니다. 계획은 작업을 단계별로 구성하고 애플리케이션이 호스팅되는 코드 저장소에 링크됩니다. 저장소는 Bitbucket, GitLab 또는 기타 서비스에 있을 수 있습니다.

작업은 Bamboo 에이전트에서 순차적으로 실행되는 일련의 작업입니다. Bamboo에서 CI와 배포는 별도로 처리됩니다. 배포 프로젝트 작업 흐름은 빌드 계획 작업 흐름과 다릅니다. Bamboo 작업 흐름에 대해 자세히 알아보세요.

GitLab CI/CD는 유사한 작업 흐름을 사용합니다. 작업은 단계로 구성되며 프로젝트에는 개별 .gitlab-ci.yml 구성 파일 또는 기존 템플릿이 포함됩니다.

템플릿 및 코드 구성

Bamboo Specs

Bamboo 계획은 Web UI 또는 Bamboo Specs로 구성할 수 있습니다. Bamboo Specs은 코드로 구성되며 Java 또는 YAML로 작성할 수 있습니다. YAML Specs은 사용이 쉽지만 Bamboo 기능에 부족한 점이 있습니다. Java Specs는 Bamboo 모든 기능을 제공하며 Groovy, Scala, 또는 Kotlin과 같은 JVM 언어로 작성할 수 있습니다. Web UI를 사용하여 계획을 구성한 경우 Bamboo 구성을 Bamboo Specs로 내보낼 수 있습니다.

Bamboo Specs는 저장소에 저장할 수 있습니다.

.gitlab-ci.yml 구성 파일

기본적으로 GitLab은 CI/CD 구성에 .gitlab-ci.yml 파일을 사용합니다. 또는 Auto DevOps를 사용하여 수동으로 구성된 .gitlab-ci.yml 파일 없이 애플리케이션을 자동으로 빌드, 테스트, 및 배포할 수 있습니다.

GitLab CI/CD 구성은 프로젝트 간에 재사용할 수 있는 템플릿으로 구성할 수 있습니다. GitLab은 빠르게 시작하고 효율적으로 작업을 복제할 수 있도록 미리 구축된 템플릿을 제공합니다.

구성

Bamboo YAML Spec 구문

이 Bamboo Spec은 Bamboo 서버 인스턴스에서 내보내었으며 다소 장황한 출력을 생성합니다:

version: 2
plan:
  project-key: AB
  key: TP
  name: test plan
stages:
  - Default Stage:
      manual: false
      final: false
      jobs:
        - Default Job
Default Job:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: Checkout Default Repository
  - script:
      interpreter: SHELL
      scripts:
        - |-
          ruby -v  # Print out ruby version for debugging
          bundle config set --local deployment true  # Install dependencies into ./vendor/ruby
          bundle install -j $(nproc)
          rubocop
          rspec spec
      description: run bundler
  artifact-subscriptions: []
repositories:
  - Demo Project:
      scope: global
triggers:
  - polling:
      period: '180'
branches:
  create: manually
  delete: never
  link-to-jira: true
notifications: []
labels: []
dependencies:
  require-all-stages-passing: false
  enabled-for-branches: true
  block-strategy: none
  plans: []
other:
  concurrent-build-plugin: system-default

...

유사한 동작을 하는 GitLab CI/CD .gitlab-ci.yml 구성은 다음과 같을 것입니다:

default:
  image: ruby:latest

stages:
  - default-stage

job1:
  stage: default-stage
  script:
    - ruby -v  # Print out ruby version for debugging
    - bundle config set --local deployment true  # Install dependencies into ./vendor/ruby
    - bundle install -j $(nproc)
    - rubocop
    - rspec spec

공통 구성

이 섹션에서는 일반적인 Bamboo 구성 및 해당하는 GitLab CI/CD와 비교합니다.

Workflow

Bamboo는 GitLab CI/CD와는 구조적으로 다릅니다. GitLab에서는 CI/CD를 프로젝트에서 여러 방법으로 활성화할 수 있습니다: 프로젝트에 .gitlab-ci.yml 파일을 추가하거나 프로젝트가 속한 그룹의 컴플라이언스 파이프라인이 존재하거나 AutoDevOps를 활성화함으로써 자동으로 파이프라인이 트리거됩니다.

반면 Bamboo는 저장소를 Bamboo 프로젝트에 추가해야하며, 인증 제공 및 트리거를 설정해야 합니다. 프로젝트에 추가된 저장소는 프로젝트의 모든 계획에서 사용할 수 있습니다. 테스트 및 응용프로그램 빌드에 사용되는 계획을 빌드 계획이라고 합니다.

빌드 계획

Bamboo의 빌드 계획은 순차적으로 실행되는 단계로 구성되어 응용프로그램을 빌드하고 관련 아티팩트를 생성합니다. 빌드 계획에는 기본 저장소가 첨부되어 있거나 상위 프로젝트에서 연결된 저장소를 상속받아야 합니다. 계획 간의 변수, 트리거 및 관계를 계획 수준에서 정의할 수 있습니다.

Bamboo 빌드 계획의 예시:

version: 2
plan:
  project-key: SAMPLE
  name: Build Ruby App
  key: BUILD-APP

stages:
  - Test App:
      jobs:
        - Test Application
        - Perform Security checks
  - Build App:
      jobs:
        - Build Application

Test Application:
  tasks:
    - script:
        - # 테스트 실행

Perform Security checks:
  tasks:
    - script:
        - # 보안 검사 실행

Build Application:
  tasks:
    - script:
        - # 빌드 실행

이 예시에서:

• 계획 사양에는 YAML 사양 버전이 포함됩니다. 버전 2가 최신 버전입니다.
• project-key는 계획을 상위 프로젝트에 연결합니다. 키는 프로젝트를 생성할 때 지정됩니다.
• 계획 key는 계획을 고유하게 식별합니다.

GitLab CI/CD에서 Bamboo 빌드 계획은 프로젝트의 .gitlab-ci.yml 파일과 유사하여 다른 프로젝트 또는 템플릿에서 CI/CD 스크립트를 포함할 수 있습니다.

해당하는 GitLab CI/CD .gitlab-ci.yml 파일:

default:
  image: alpine:latest

stages:
  - test
  - build

test-application:
  stage: test
  script:
    - # 테스트 실행

security-checks:
  stage: test
  script:
    - # 보안 검사 실행

build-application:
  stage: build
  script:
    - # 빌드 실행

컨테이너 이미지

기본적으로 Bamboo 에이전트의 네이티브 운영 체제에서 빌드 및 배포가 실행되지만 컨테이너에서 실행되도록 구성할 수 있습니다. Bamboo에서 작업을 컨테이너에서 실행하려면 docker 키워드를 사용합니다.

예를 들어, Bamboo 빌드 계획에서:

version: 2
plan:
  project-key: SAMPLE
  name: Build Ruby App
  key: BUILD-APP

docker: alpine:latest

stages:
  - Build App:
      jobs:
        - Build Application

Build Application:
  tasks:
    - script:
        - # 빌드 실행
  docker:
    image: alpine:edge

GitLab CI/CD에서는 image 키워드만 필요합니다.

해당하는 GitLab CI/CD .gitlab-ci.yml 파일:

default:
  image: alpine:latest

stages:
  - build

build-application:
  stage: build
  script:
    - # 빌드 실행
  image:
    name: alpine:edge

변수

Bamboo에는 범위에 따라 다음 유형의 변수가 있습니다:

• 빌드별 변수는 빌드 시 평가됩니다. 예: ${bamboo.planKey}.
• Bamboo 인스턴스나 시스템 환경에서 상속된 시스템 변수.
• 모든 계획에서 사용할 수 있는 전역 변수.
• 프로젝트 전용으로 정의되며 동일 프로젝트의 계획에서 액세스할 수 있는 프로젝트 변수.
• 계획 전용 변수.

Bamboo에서 변수를 사용하려면 시스템 변수의 경우 ${system.variableName}, 기타 유형의 변수의 경우 ${bamboo.variableName} 형식을 사용합니다. 스크립트 작업에서 변수를 사용할 때 마침표는 언더스코어로 변환됩니다. ${bamboo.variableName}은 $bamboo_variableName으로 변환됩니다.

GitLab에서는 CI/CD 변수를 다음 수준에서 정의할 수 있습니다:

• 인스턴스.
• 그룹.
• 프로젝트.
• CI/CD 구성의 전역 수준에서.
• CI/CD 구성의 작업 수준에서.

Bamboo의 시스템 및 전역 변수와 유사하게, GitLab에는 모든 작업에서 사용할 수 있는 사전 정의된 CI/CD 변수가 있습니다.

CI/CD 스크립트에서 변수를 정의하는 방법은 Bamboo와 GitLab에서 유사합니다.

예를 들어, Bamboo 빌드 계획에서:

version: 2
# ...
variables:
  username: admin
  releaseType: milestone

Default job:
  tasks:
    - script: echo '$bamboo_username is the DRI for $bamboo_releaseType'

해당하는 GitLab CI/CD .gitlab-ci.yml 파일:

variables:
  GLOBAL_VAR: "전역 변수"

job1:
  variables:
    JOB_VAR: "작업 변수"
  script:
    - echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

GitLab CI/CD에서 변수는 일반적인 쉘 스크립트 변수처럼 액세스됩니다. 예: $VARIABLE_NAME.

작업 및 작업

GitLab 및 Bamboo 모두 동일한 단계에서 실행되는 작업은 병렬로 실행되며, 작업 실행 전 충족해야 하는 의존성이 있는 경우에만 달라집니다.

Bamboo에서 실행할 수 있는 작업의 수는 Bamboo 에이전트와 Bamboo 라이선스 크기에 따라 달라집니다. 반면, GitLab CI/CD에서 병렬 작업의 수는 GitLab 인스턴스에 통합된 러너 수와 러너에서 설정된 동시성에 따라 달라집니다.

Bamboo에서 작업은 작업으로 구성됩니다. 작업은 다음과 같은 명령어로 구성될 수 있습니다:

• 스크립트로 실행되는 명령어 집합
• 소스 코드 체크아웃, 아티팩트 다운로드 및 Atlassian 작업 마켓플레이스에서 제공되는 다른 작업과 같은 미리 정의된 작업.

예를 들어, Bamboo 빌드 계획에서:

version: 2
#...

Default Job:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: Checkout Default Repository
  - script:
      interpreter: SHELL
      scripts:
        - |-
          ruby -v
          bundle config set --local deployment true
          bundle install -j $(nproc)
      description: run bundler
other:
  concurrent-build-plugin: system-default

GitLab에서의 작업에 해당하는 것은 script로, 여기에서 러너가 실행해야 하는 명령을 지정합니다.

예를 들어, GitLab CI/CD .gitlab-ci.yml 파일:

job1:
  script: "bundle exec rspec"

job2:
  script:
    - ruby -v
    - bundle config set --local deployment true
    - bundle install -j $(nproc)

GitLab에서는 CI/CD 템플릿 및 CI/CD 구성요소를 사용하여 파이프라인을 직접 작성하지 않고 작성할 수 있습니다.

조건문

Bamboo에서는 모든 작업에는 작업이 실행되는지를 결정하는 조건이 있을 수 있습니다.

예를 들어, Bamboo 빌드 계획에서:

version: 2
# ...
tasks:
  - script:
      interpreter: SHELL
      scripts:
        - echo "Hello"
      conditions:
        - variable:
            equals:
              planRepository.branch: development

GitLab에서는 GitLab CI/CD에서 작업이 언제 실행되는지를 제어하기 위해 rules 키워드를 사용할 수 있습니다.

예를 들어, GitLab CI/CD의 .gitlab-ci.yml 파일에서:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME = development

트리거

Bamboo에는 빌드를 트리거하는 여러 옵션이 있습니다. 코드 변경, 일정, 다른 계획의 결과 또는 필요에 따라 실행할 수 있습니다. 계획은 새로운 변경사항을 주기적으로 확인하도록 구성할 수 있습니다. 아래와 같이 표시됩니다.

예를 들어, Bamboo 빌드 계획에서:

version: 2
#...
triggers:
  - polling:
      period: '180'

GitLab CI/CD 파이프라인은 코드 변경, 일정 또는 다른 작업 또는 API 호출에 따라 트리거될 수 있습니다. GitLab CI/CD 파이프라인은 폴링을 사용할 필요는 없지만 일정에 따라 트리거될 수 있습니다.

파이프라인 자체가 언제 실행되는지는 workflow 키워드 및 rules로 구성할 수 있습니다.

예를 들어, GitLab CI/CD의 .gitlab-ci.yml 파일에서:

workflow:
  rules:
    - changes:
        - .gitlab/**/**.md
      when: never

아티팩트

GitLab와 Bamboo에서 모두 artifacts 키워드를 사용하여 작업 아티팩트를 정의할 수 있습니다.

예를 들어, Bamboo 빌드 계획에서:

version: 2
# ...
  artifacts:
    -
      name: Test Reports
      location: target/reports
      pattern: '*.xml'
      required: false
      shared: false
    -
      name: Special Reports
      location: target/reports
      pattern: 'special/*.xml'
      shared: true

이 예에서 아티팩트는 이름, 위치, 패턴 및 선택적으로 다른 작업이나 계획과 아티팩트를 공유할 수 있는 기능으로 정의됩니다. 또한 아티팩트를 구독하는 작업도 정의할 수 있습니다.

artifact-subscriptions은 동일한 계획 내 다른 작업에서 아티팩트에 액세스하는 데 사용되며, 예를 들어:

Test app:
  artifact-subscriptions:
    -
      artifact: Test Reports
      destination: deploy

artifact-download은 다른 계획에서 작업의 아티팩트에 액세스하는 데 사용되며, 예를 들어:

version: 2
# ...
  tasks:
    - artifact-download:
        source-plan: PROJECTKEY-PLANKEY

source-plan 키워드에서 아티팩트를 다운로드하는 계획의 키를 제공해야 합니다.

GitLab에서는 이전 단계에서 완료된 작업의 모든 아티팩트가 기본적으로 다운로드됩니다.

예를 들어, GitLab CI/CD의 .gitlab-ci.yml 파일에서:

stages:
  - build

pdf:
  stage: build
  script: #generate XML reports
  artifacts:
    name: "test-report-files"
    untracked: true
    paths:
      - target/reports

이 예에서:

• 아티팩트의 이름이 명시적으로 지정되지만, CI/CD 변수를 사용하여 동적으로 만들 수 있습니다.
• untracked 키워드는 paths로 명시적으로 지정된 파일과 함께 Git 추적되지 않은 파일도 포함되도록 아티팩트를 설정합니다.

캐싱

Bamboo에서는 Git 캐시를 사용하여 빌드 속도를 높일 수 있습니다. Git 캐시는 Bamboo 관리 설정에서 구성되고 Bamboo 서버나 원격 에이전트에 저장됩니다.

GitLab은 cache 키워드를 사용하여 작업마다 캐시를 정의합니다.

예를 들어, GitLab CI/CD의 .gitlab-ci.yml 파일에서:

test-job:
  stage: build
  cache:
    - key:
        files:
          - Gemfile.lock
      paths:
        - vendor/ruby
    - key:
        files:
          - yarn.lock
      paths:
        - .yarn-cache/
  script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install
    - yarn install --cache-folder .yarn-cache
    - echo Run tests...

배포 프로젝트

Bamboo에는 배포 프로젝트가 있으며, 빌드 계획에 연결하여 배포 환경으로 아티팩트를 추적, 가져오고 배포할 수 있습니다.

프로젝트를 생성할 때 빌드 계획에 연결하고 배포 환경 및 배포 작업을 수행할 작업을 지정합니다. 배포 작업은 Atlassian marketplace의 스크립트 또는 Bamboo 작업일 수 있습니다.

예를 들어 배포 프로젝트 사양에서:

version: 2

deployment:
  name: Deploy ruby app
  source-plan: build-app

release-naming: release-1.0

environments:
  - Production

Production:
  tasks:
    - # scripts to deploy app to production
    - ./.ci/deploy_prod.sh

GitLab CI/CD에서는 배포 작업을 생성하여 환경으로 배포하거나 릴리스를 생성할 수 있습니다.

예를 들어, GitLab CI/CD의 .gitlab-ci.yml 파일에서:

deploy-to-production:
  stage: deploy
  script:
    - # Run Deployment script
    - ./.ci/deploy_prod.sh
  environment:
    name: production

대신 릴리스를 생성하려면, 릴리스 키워드와 release-cli 도구를 사용하여 Git 태그에 대한 릴리스를 생성합니다.

예를 들어, GitLab CI/CD의 .gitlab-ci.yml 파일에서:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Building release version"
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the release-cli.'

보안 스캐닝 기능

Bamboo는 Atlassian Marketplace에서 제공되는 타사 작업에 의존하여 보안 스캔을 실행합니다. GitLab은 SDLC의 모든 부분에서 취약점을 감지하기 위한 보안 스캐너를 기본 제공합니다. 이러한 플러그인을 GitLab에 추가할 수 있으며, 예를 들어 SAST 스캔을 파이프라인에 추가하려면 .gitlab-ci.yml에 다음과 같이 추가하면 됩니다.

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

CI/CD 변수를 사용하여 보안 스캐너의 동작을 사용자 정의할 수 있습니다.

시크릿 관리

시크릿이라고도 하는 특권 정보는 CI/CD 워크플로우에서 필요한 민감한 정보 또는 자격 증명입니다. 시크릿을 사용하여 보호된 리소스를 잠금 해제하거나 도구, 응용 프로그램, 컨테이너 및 클라우드 네이티브 환경에서 민감한 정보에 액세스할 수 있습니다.

Bamboo의 시크릿 관리는 일반적으로 공유 자격 증명 또는 Atlassian Marketplace의 타사 응용 프로그램을 사용하여 처리됩니다.

GitLab에서는 외부 서비스를 지원하는 지원되는 통합 중 하나를 사용하여 시크릿을 관리할 수 있습니다. 이러한 서비스는 GitLab 프로젝트 외부에 안전하게 시크릿을 저장하지만 해당 서비스의 구독이 있어야 합니다.

• HashiCorp Vault
• Azure Key Vault.

또한, OIDC를 지원하는 타사 서비스에 대해 OIDC 인증을 사용할 수 있습니다.

더불어 시크릿을 작업에서 사용할 수 있도록 만들거나, 평문에 저장된 시크릿은 우연한 노출에 취약하므로 Bamboo에서와 마찬가지로 항상 시크릿을 마스킹하고 보호해야 합니다.

또한 프로젝트에서 .gitlab-ci.yml 파일에 시크릿을 변수로 저장하지 마십시오. 민감한 정보를 변수에 저장하는 것은 프로젝트, 그룹 또는 인스턴스 설정에서만 해야 합니다.

CI/CD 변수의 안전성을 높이려면 보안 가이드라인을 검토하십시오.

이주 계획

다음은 빠르게 마이그레이션을 완료한 조직을 관찰한 후 작성된 권장 단계 목록입니다.

마이그레이션 계획 생성

마이그레이션을 시작하기 전에 마이그레이션 계획을 작성하여 마이그레이션을 준비하세요. Bamboo에서 마이그레이션하려면 다음 질문에 대답하세요.

• 현재 Bamboo 작업에서 어떤 Bamboo 작업이 사용되고 있습니까?
  • 이러한 작업이 정확히 무엇을 하는지 알고 있습니까?
  • 공통 빌드 도구를 둘러싼 작업이 있습니까? 예를 들어 Maven, Gradle 또는 NPM과 같은 것.
• Bamboo 에이전트에 설치된 것이 무엇입니까?
• 사용 중인 공유 라이브러리가 있습니까?
• Bamboo에서는 어떻게 인증하고 있습니까? SSH 키, API 토큰 또는 다른 시크릿을 사용하고 있습니까?
• 파이프라인에서 액세스해야 하는 다른 프로젝트가 있습니까?
• Bamboo에 외부 서비스에 액세스하는 자격 증명이 있습니까? 예를 들어 Ansible Tower, Artifactory 또는 기타 클라우드 제공 업체 또는 배포 대상.

전제 조건

마이그레이션 작업을 수행하기 전에 먼저 다음을 해야 합니다.

1. GitLab에 익숙해지세요.
   • 주요 GitLab CI/CD 기능에 대해 읽으십시오.
   • 첫 번째 GitLab 파이프라인 및 더 복잡한 파이프라인을 만들고, 테스트하며, 정적 사이트를 배포합니다.
   • CI/CD YAML 구문 참조를 확인하십시오.
2. GitLab을 설정하고 구성하십시오.
3. GitLab 인스턴스를 테스트하십시오.
   • 런너가 사용 가능한지 확인하십시오. 공유된 GitLab.com 러너를 사용하거나 새 런너를 설치하여야 합니다.

마이그레이션 단계

1. SCM 솔루션에서 프로젝트를 GitLab로 마이그레이션합니다.
   • (권장) 사용 가능한 importers를 사용하여 외부 SCM 제공업체로부터 대규모 가져오기를 자동화할 수 있습니다.
   • URL로 리포지토리 가져오기를 사용할 수 있습니다.
2. 각 프로젝트에 .gitlab-ci.yml 파일을 생성하십시오.
3. Bamboo 프로젝트/플랜을 YAML Spec으로 내보냅니다.
4. Bamboo YAML Spec 구성을 GitLab CI/CD 작업으로 마이그레이션하고 결과를 병합 요청에 직접 표시하도록 구성하십시오.
5. 클라우드 배포 템플릿, 환경, 및 Kubernetes용 GitLab 에이전트를 사용하여 배포 작업을 마이그레이션하십시오.
6. 다른 프로젝트 간에 재사용할 수 있는지 CI/CD 구성을 확인하고 CI/CD 템플릿을 생성하고 공유하십시오.
7. GitLab CI/CD 파이프라인을 더 빨리 실행되고 효율적으로 만드는 방법에 대한 파이프라인 효율성 문서를 확인하십시오.

여기서 답변되지 않은 질문이 있다면, GitLab 커뮤니티 포럼이 좋은 정보원이 될 수 있습니다.