Bamboo에서의 마이그레이션

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

이 마이그레이션 가이드는 Atlassian Bamboo에서 GitLab CI/CD로의 마이그레이션 방법을 살펴봅니다. 이것은 Bamboo UI에서 내보낸 Bamboo Specs YAML이나 Spec 리포지토리에 저장된 것에 중점을 둡니다.

GitLab CI/CD 기본

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 서비스를 제공합니다.

에이전트 대 러너

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 언어로 작성할 수 있습니다. 웹 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 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  # 디버깅용 루비 버전 출력
        bundle config set --local deployment true  # 의존성을 ./vendor/ruby에 설치
        bundle install -j $(nproc)
        rubocop
        rspec spec
      description: 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

---

version: 2
plan:
  key: AB-TP
plan-permissions:
- users:
  - root
  permissions:
  - view
  - edit
  - build
  - clone
  - admin
  - view-configuration
- roles:
  - logged-in
  - anonymous
  permissions:
  - view
...

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

default:
  image: ruby:latest

stages:
- default-stage

job1:
  stage: default-stage
  script:
    - ruby -v  # 디버깅용 루비 버전 출력
    - bundle config set --local deployment true  # 의존성을 ./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 Spec 버전이 포함됩니다. 버전 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은 $bamboo_releaseType의 DRI입니다'

등가 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같을 것입니다:

variables:
  GLOBAL_VAR: "전역 변수"

job1:
  variables:
    JOB_VAR: "작업 변수"
  script:
    - echo "변수는 '$GLOBAL_VAR' 및 '$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: 기본 저장소 체크아웃
  - script:
      interpreter: SHELL
      scripts:
      - |-
        ruby -v
        bundle config set --local deployment true
        bundle install -j $(nproc)
      description: 버들러 실행
other:
  concurrent-build-plugin: 시스템 기본

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: # XML 보고서 생성
  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:
    - # 프로덕션으로 앱 배포하는 스크립트
    - ./.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

대신 릴리스를 생성하려면 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                  # 수동으로 태그를 만들 때 작업 실행
  script:
    - echo "릴리스 버전 빌드 중"
  release:
    tag_name: $CI_COMMIT_TAG
    name: '릴리스 $CI_COMMIT_TAG'
    description: '릴리스-cli를 사용하여 만들어진 릴리스'

보안 스캐닝 기능

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

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

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

시크릿 관리

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

Bamboo의 시크릿 관리는 일반적으로 공유 자격 증명을 사용하거나 Atlassian 마켓 플레이스의 타사 응용 프로그램을 통해 처리됩니다.

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

또한 GitLab은 OIDC 인증을 지원하여 OIDC를 지원하는 다른 타사 서비스에 대해 OIDC 인증을 지원합니다.

또한 CI/CD 변수에 크리덴셜을 사용할 수 있도록 만들어 작업에서 사용할 수 있습니다. 그러나 평문으로 저장된 시크릿은 우연한 노출에 취약하며, 이는 Bamboo에서도 마찬가지입니다. 민감한 정보는 항상 마스킹하고 보호된 변수에 저장해야 하며, 이는 일부 위험을 완화합니다.

.gitlab-ci.yml 파일에 시크릿을 변수로 저장하지 마십시오. 해당 파일은 해당 프로젝트에 액세스 가능한 모든 사용자에게 공개되기 때문입니다. 민감한 정보를 변수에 저장해야 하는 경우에는 반드시 프로젝트, 그룹 또는 인스턴스 설정에서만 수행해야 합니다.

CI/CD 변수의 안전성을 높이기 위해 보안 가이드라인을 검토하세요.

마이그레이션 계획

다음은 이러한 마이그레이션을 빠르게 완료할 수 있는 조직들의 관찰을 토대로 추천된 단계 목록입니다.

마이그레이션 계획 만들기

마이그레이션을 시작하기 전에 마이그레이션 계획을 작성하여 마이그레이션을 위한 준비를 하십시오. Bamboo에서 마이그레이션할 때 다음 질문에 대답할 수 있어야 합니다:

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

전제 조건

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

GitLab을 익히세요.
- 주요 GitLab CI/CD 기능에 대해 읽으세요.
- 첫 번째 GitLab 파이프라인 및 더 복잡한 파이프라인을 만들고 해당 과정을 따르세요. 이를 통해 정적 사이트를 빌드, 테스트 및 배포할 수 있습니다.
- CI/CD YAML 구문 참조를 검토하세요.
GitLab을 설정하고 구성하세요.
GitLab 인스턴스를 테스트하세요.
- 공유 GitLab.com 러너를 사용하거나 새로운 러너를 설치하여 러너를 사용할 수 있는지 확인하세요.

마이그레이션 단계

SCM 솔루션에서 GitLab으로 프로젝트를 마이그레이션하세요.
- (권장 사항) 사용 가능한 가져오기 도구를 사용하여 외부 SCM 공급자에서 자동으로 가져오세요.
- URL별로 저장소 가져오기를 사용할 수 있습니다.
각 프로젝트에 .gitlab-ci.yml 파일을 만드세요.
Bamboo 프로젝트/계획을 YAML 스펙으로 내보냈습니다.
GitLab CI/CD 작업에 Bamboo YAML 스펙 구성을 마이그레이션하고 결과를 병합 요청에서 직접 표시할 수 있도록 구성하세요.
클라우드 배포 템플릿, 환경 및 GitLab 쿠버네티스 에이전트를 사용하여 배포 작업을 마이그레이션하세요.
여러 프로젝트에서 재사용할 수 있는 CI/CD 구성이 있는지 확인한 후 CI/CD 템플릿을 만들고 공유하세요.
GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법에 대해 알아보기 위해 파이프라인 효율성 문서를 확인하세요.

여기에 답변되지 않은 질문이 있으면 GitLab 커뮤니티 포럼이 좋은 리소스가 될 수 있습니다.

Bamboo에서의 마이그레이션

GitLab CI/CD 기본

주요 유사점과 차이점

제공

에이전트 대 러너

워크플로우

템플릿 및 코드 구성

Bamboo Specs

`.gitlab-ci.yml` 구성 파일

구성

Bamboo YAML Spec 구문

공통 구성

Workflow

빌드 계획

컨테이너 이미지

변수

작업 및 작업

조건부 명령

트리거

아티팩트

캐싱

배포 프로젝트

보안 스캐닝 기능

시크릿 관리

마이그레이션 계획

마이그레이션 계획 만들기

전제 조건

마이그레이션 단계

도움말

기능 사용 가능성과 제품 평가판

도움받기

Bamboo에서의 마이그레이션

GitLab CI/CD 기본

주요 유사점과 차이점

제공

에이전트 대 러너

워크플로우

템플릿 및 코드 구성

Bamboo Specs

.gitlab-ci.yml 구성 파일

구성

Bamboo YAML Spec 구문

공통 구성

Workflow

빌드 계획

컨테이너 이미지

변수

작업 및 작업

조건부 명령

트리거

아티팩트

캐싱

배포 프로젝트

보안 스캐닝 기능

시크릿 관리

마이그레이션 계획

마이그레이션 계획 만들기

전제 조건

마이그레이션 단계

도움말

기능 사용 가능성과 제품 평가판

도움받기

`.gitlab-ci.yml` 구성 파일