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

Bamboo에서의 이주

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

GitLab CI/CD 기본 사항

GitLab CI/CD를 처음 사용하는 경우, 시작 가이드를 사용하여 기본적인 개념과 첫 .gitlab-ci.yml 파일을 만드는 방법을 배울 수 있습니다. 이미 GitLab CI/CD를 사용해 본 경험이 있는 경우, CI/CD YAML 구문 참조에서 사용 가능한 키워드의 전체 디렉터리을 확인할 수 있습니다.

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

주요 유사점 및 차이점

오퍼링

Atlassian은 Bamboo를 클라우드(SaaS) 또는 데이터 센터(Self-Managed형) 옵션으로 제공합니다. 2024년 2월 15일에 EOL 예정인 세 번째 서버 옵션이 있습니다.

이러한 옵션은 GitLab의 SaaS 및 Self-Managed형 옵션과 유사합니다. GitLab은 또한 완전히 격리된 단일 테넌트 SaaS 서비스인 GitLab Dedicated도 제공합니다.

에이전트 vs 러너

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

GitLab은 에이전트와 유사한 개념인 러너(runner)를 사용하며, executors를 사용하여 빌드를 실행합니다.

executors의 예시로는 shell, Docker 또는 Kubernetes가 있습니다. GitLab SaaS 러너를 사용하거나 Self-Managed형 러너를 배포할 수 있습니다.

워크플로우

Bamboo 워크플로우는 프로젝트로 구성됩니다. 프로젝트는 계획, 변수, 공유 자격증명 및 여러 계획에서 필요한 권한을 조직하는 데 사용됩니다. 계획에는 작업을 단계로 그룹화하고 응용 프로그램이 호스팅되는 코드 리포지터리에 연결합니다. 리포지터리는 Bitbucket, GitLab 또는 다른 서비스에 있을 수 있습니다.

작업은 동일한 Bamboo 에이전트에서 순차적으로 실행되는 일련의 작업입니다. Bamboo에서는 CI 및 배포가 별도로 처리됩니다. 배포 프로젝트 워크플로우는 빌드 계획 워크플로우와 다릅니다. Bamboo 워크플로우에 대해 더 알아보세요.

GitLab CI/CD는 유사한 워크플로우를 사용합니다. 작업은 스테이지로 구성되며 프로젝트에는 개별 .gitlab-ci.yml 구성 파일이나 기존 템플릿이 포함됩니다.

템플릿 및 코드로 구성

Bamboo Specs

Bamboo 계획은 웹 UI 또는 Bamboo Specs로 구성할 수 있습니다. Bamboo Specs는 코드로 구성되어 Java 또는 YAML로 작성할 수 있습니다. YAML Specs은 사용하기 쉽지만 Bamboo 기능 커버리지가 낮습니다. Java Specs는 Bamboo의 모든 기능을 커버하며 Groovy, Scala 또는 Kotlin과 같은 모든 JVM 언어로 작성할 수 있습니다.

Bamboo Specs를 사용하면 Bamboo 구성을 내보낼 수도 있습니다.

또한 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 Server 인스턴스에서 내보낸 것으로, 상당히 상세한 출력을 생성합니다.

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 동등한을 검토합니다.

워크플로우

GitLab과 비교하여 Bamboo는 구조적으로 다릅니다. GitLab에서는 프로젝트에 .gitlab-ci.yml 파일을 추가하거나 그룹의 Compliance 파이프라인이 있는 경우, 또는 AutoDevOps를 사용하여 프로젝트에서 CI/CD를 활성화할 수 있습니다. 규칙이나 컨텍스트에 따라 자동으로 파이프라인이 트리거되며 AutoDevOps가 사용됩니다.

반면에 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 에이전트의 기본 운영 체제에서 실행되지만 컨테이너에서 실행하도록 구성할 수도 있습니다. 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으로 됩니다.

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: "A global variable"

job1:
  variables:
    JOB_VAR: "A job variable"
  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 "안녕하세요"
      conditions:
        - variable:
            equals:
              planRepository.branch: development

GitLab에서는 GitLab CI/CD에서 작업 실행을 제어하는 데 rules 키워드로 이를 수행할 수 있습니다.

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

job:
  script: echo "안녕하세요, 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: # XML 보고서 생성
  artifacts:
    name: "test-report-files"
    untracked: true
    paths:
      - target/reports

이 예에서:

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

캐싱

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

GitLab은 cache 키워드를 사용하여 작업 당 Git 캐시와 작업 캐시를 지원합니다.

예를 들어, 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 마켓플레이스에서 Bamboo 작업 또는 스크립트일 수 있습니다.

예를 들어, 배포 프로젝트 설정 예시:

version: 2

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

release-naming: release-1.0

environments:
  - Production

Production:
  tasks:
    - # 프로덕션으로 앱 배포 스크립트
    - ./.ci/deploy_prod.sh

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

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

deploy-to-production:
  stage: deploy
  script:
    - # 배포 스크립트 실행
    - ./.ci/deploy_prod.sh
  environment:
    name: production

대신 릴리스를 만들려면 릴리스 키워드와 릴리스-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                  # 매뉴얼으로 태그를 만들 때 이 작업을 실행합니다
  script:
    - echo "릴리스 버전 빌드 중"
  release:
    tag_name: $CI_COMMIT_TAG
    name: '릴리스 $CI_COMMIT_TAG'
    description: '릴리스-cli를 사용하여 생성된 릴리스입니다.'

보안 스캔 기능

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

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

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

시크릿 관리

CI/CD 워크플로에 필요한 민감한 정보 또는 자격 증명인 “시크릿”은 Bamboo에서는 공유 자격 증명 또는 Atlassian 마켓플레이스에서 제공되는 타사 애플리케이션을 통해 보통 처리됩니다.

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

• HashiCorp Vault
• Azure Key Vault.

또한 GitLab은 OIDC(OIDC를 지원하는 기타 타사 서비스를 사용하기 위한 OIDC 인증)를 지원합니다.

또한 CI/CD 변수에 시크릿을 저장하여 작업에 사용할 수 있으며, 그러나 평문으로 저장된 시크릿은 우연한 노출의 위험에 노출될 수 있으므로, Bamboo와 마찬가지로 마스킹된 및 보호된 변수에 항상 민감한 정보를 저장해야 합니다.

또한 프로젝트, 그룹 또는 인스턴스 설정에서만 평문으로 저장된 시크릿을 넣어야 합니다.

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으로 프로젝트를 마이그레이션합니다.
   • (권장) 사용 가능한 importer를 사용하여 외부 SCM 공급자에서 대규모 임포트를 자동화할 수 있습니다.
   • URL을 사용하여 리포지터리를 가져오세요.
2. 각 프로젝트에 .gitlab-ci.yml 파일을 만드세요.
3. Bamboo 프로젝트/계획을 YAML Spec로 내보내세요.
4. GitLab CI/CD 작업으로 Bamboo YAML Spec 구성을 마이그레이션하고 결과를 Merge Request에서 직접 표시할 수 있게 구성하세요.
5. 클라우드 배포 템플릿, 환경 및 Kubernetes를 위한 GitLab 에이전트를 사용하여 배포 작업을 마이그레이션합니다.
6. 다른 프로젝트 간에 재사용할 수 있는 CI/CD 구성이 있는지 확인한 후, CI/CD 템플릿을 만들고 공유하세요.
7. 파이프라인 효율성 문서를 확인하여 GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법을 알아보세요.

여기에 없는 질문이 있으면 GitLab 커뮤니티 포럼이 좋은 자원이 될 수 있습니다.