Bamboo에서의 마이그레이션

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

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

GitLab CI/CD 기초

GitLab CI/CD를 처음 사용하는 경우, 시작하기 가이드를 사용하여 기본 개념과 첫 번째 .gitlab-ci.yml 파일을 만드는 방법을 배우십시오.

이미 GitLab CI/CD를 사용해본 경험이 있다면, CI/CD YAML 구문 참조를 검토하여 사용 가능한 키워드의 전체 목록을 확인할 수 있습니다.

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

주요 유사점 및 차이점

Offerings

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

이 옵션들은 GitLab SaaS 및 Self-Managed와 유사합니다. GitLab은 완전 격리된 단일 테넌트 SaaS 서비스인 GitLab Dedicated도 제공합니다.

Agents vs Runners

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

GitLab은 에이전트와 유사한 개념인 러너를 사용하며, 빌드를 실행하기 위해 실행기를 사용합니다.

실행기의 예로는 셸, Docker, 또는 Kubernetes가 있습니다. GitLab SaaS 러너를 사용할 수도 있고, 자신의 자체 관리 러너를 배포할 수도 있습니다.

Workflow

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

작업은 동일한 Bamboo 에이전트에서 순차적으로 실행되는 일련의 작업입니다. CI와 배포는 Bamboo에서 별도로 처리됩니다. 배포 프로젝트 워크플로우는 빌드 계획 워크플로우와 다릅니다. 자세히 알아보기 위해 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 언어로 작성할 수 있습니다.
웹 UI를 사용하여 계획을 구성했다면, 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: 테스트 계획
stages:
  - 기본 단계:
      manual: false
      final: false
      jobs:
        - 기본 작업
기본 작업:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: 기본 저장소 체크아웃
  - 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:
  - 데모 프로젝트:
      scope: global
triggers:
  - polling:
      period: '180'
branches:
  create: 수동으로
  delete: 결코
  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의 동등한 구성에 대해 검토합니다.

워크플로우

Bamboo는 GitLab CI/CD와 다르게 구조화되어 있습니다. GitLab에서는 CI/CD를 여러 가지 방법으로 프로젝트에서 활성화할 수 있습니다: 프로젝트에 .gitlab-ci.yml 파일을 추가하거나, 프로젝트가 속한 그룹에 Compliance pipeline이 존재하거나, 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:
        - # Run tests

Perform Security checks:
  tasks:
    - script:
        - # Run Security Checks

Build Application:
  tasks:
    - script:
        - # Run buils

이 예에서:

계획 사양에는 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:
    - # Run tests

security-checks:
  stage: test
  script:
    - # Run Security Checks

build-application:
  stage: build
  script:
    - # Run builds

컨테이너 이미지

빌드와 배포는 기본적으로 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:
        - # Run builds
  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:
    - # Run builds
  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: "A global variable"

job1:
  variables:
    JOB_VAR: "A job variable"
  script:
    - echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

GitLab CI/CD에서 변수는 일반 Shell 스크립트 변수처럼 접근됩니다. 예를 들어, $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: 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에서는 이를 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 키워드는 아티팩트를 Git에서 추적되지 않는 파일도 포함하도록 설정하여, paths에 명시된 파일과 함께 포함합니다.

캐싱

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

GitLab은 Git 캐시와 Job 캐시를 모두 지원합니다. 캐시는 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 마켓플레이스의 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 키워드를 사용하고 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: 'release-cli를 사용하여 생성된 릴리스입니다.'

보안 스캐닝 기능

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

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

SAST 스캐너와 같은 CI/CD 변수를 사용하여 보안 스캐너의 동작을 사용자 맞춤 설정할 수 있습니다.

비밀 관리

특권 정보, 일반적으로 “비밀”이라고 하는 것은 CI/CD 워크플로우에서 필요한 민감한 정보 또는 자격 증명입니다. 비밀을 사용하여 도구, 애플리케이션, 컨테이너 및 클라우드 네이티브 환경의 보호된 리소스 또는 민감한 정보에 대한 액세스를 잠금 해제할 수 있습니다.

Bamboo에서의 비밀 관리는 일반적으로 공유 자격 증명 사용 또는 Atlassian 마켓플레이스의 타사 애플리케이션을 통해 처리됩니다.

GitLab에서 비밀 관리를 위해 외부 서비스에 대한 지원되는 통합 중 하나를 사용할 수 있습니다. 이러한 서비스는 GitLab 프로젝트 외부에 비밀을 안전하게 저장하지만, 서비스에 대한 구독이 필요합니다:

GitLab은 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 사양으로 내보냅니다.
Bamboo YAML 사양 구성 을 GitLab CI/CD 작업으로 마이그레이션하고, 머지 요청에서 직접 결과를 표시하도록 구성합니다.
클라우드 배포 템플릿, 환경 및 Kubernetes용 GitLab 에이전트를 사용하여 배포 작업을 마이그레이션합니다.
CI/CD 구성이 서로 다른 프로젝트에서 재사용될 수 있는지 확인한 후 CI/CD 템플릿을 생성하고 공유합니다.
파이프라인 효율성 문서를 확인하여 GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법을 알아보세요.

여기서 답하지 않은 질문이 있는 경우, GitLab 커뮤니티 포럼이 좋은 자원이 될 수 있습니다.

Bamboo에서의 마이그레이션

GitLab CI/CD 기초

주요 유사점 및 차이점

Offerings

Agents vs Runners

Workflow

템플레이팅 & 코드로서의 구성

Bamboo Specs

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

구성

Bamboo YAML Spec 구문

일반 구성

워크플로우

빌드 계획

컨테이너 이미지

변수

작업 및 태스크

조건문

트리거

아티팩트

캐싱

배포 프로젝트

보안 스캐닝 기능

비밀 관리

마이그레이션 계획

마이그레이션 계획 수립

필수 조건

마이그레이션 단계

도움말

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

도움받기

Bamboo에서의 마이그레이션

GitLab CI/CD 기초

주요 유사점 및 차이점

Offerings

Agents vs Runners

Workflow

템플레이팅 & 코드로서의 구성

Bamboo Specs

.gitlab-ci.yml 구성 파일

구성

Bamboo YAML Spec 구문

일반 구성

워크플로우

빌드 계획

컨테이너 이미지

변수

작업 및 태스크

조건문

트리거

아티팩트

캐싱

배포 프로젝트

보안 스캐닝 기능

비밀 관리

마이그레이션 계획

마이그레이션 계획 수립

필수 조건

마이그레이션 단계

도움말

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

도움받기

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