Bamboo에서 마이그레이션하기

Bamboo에서 마이그레이션하기 (Migrate from Bamboo)

Atlassian Bamboo에서 GitLab CI/CD로 마이그레이션하려면 Bamboo Specs를 .gitlab-ci.yml 파일로 변환하면 돼요.

Bamboo UI에서 이 Specs를 내보내거나, Specs 저장소에 코드로 이미 정의해 둔 것을 사용할 수 있어요.

출처: 문서

본문

주요 마이그레이션 고려사항

Configuration aspect	Bamboo	GitLab CI/CD	Migration tasks
Configuration files	Bamboo Specs (Java or YAML)	.gitlab-ci.yml file	Convert Specs to GitLab YAML syntax
Variable syntax	${bamboo.variableName}	$VARIABLE_NAME	Update all variable references in scripts
Execution environment	Agents (local or remote)	Runners with executors	Install and configure runners
Artifact sharing	Named artifacts with subscriptions	Automatic inheritance between stages	Simplify artifact configuration
Deployments	Separate deployment projects	Deployment jobs with environments	Combine build and deploy in single pipeline

구성 예시

Bamboo Specs 내보내기

다음 예시들은 UI의 Bamboo Specs YAML 내보내기와 그에 해당하는 GitLab CI/CD 구성을 보여줘요.

Bamboo는 프로젝트가 여러 플랜을 포함하고, 플랜이 스테이지와 잡을 정의하며, 잡이 개별 태스크를 실행하는 중첩 계층 구조로 빌드를 구성해요. 프로젝트는 여러 플랜이 접근할 수 있는 변수, 자격 증명, 저장소 연결 같은 공유 리소스의 컨테이너 역할을 해요.

UI의 Bamboo Specs 내보내기에는 이 전체 계층 구조와 권한, 알림, 프로젝트 설정 같은 관리 메타데이터가 포함돼요.

내보내기를 검토할 때는 다음 마이그레이션에 중요한 요소에 집중하세요:

• 잡과 태스크: 실제 빌드 명령과 스크립트
• 스테이지 정의: 순차 실행 순서와 의존성
• 변수와 아티팩트: 잡 간에 공유되는 데이터와 파일
• 트리거와 조건: 빌드가 언제 실행될지 결정하는 규칙

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

---

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  # Print out ruby version for debugging
    - bundle config set --local deployment true  # Install dependencies into ./vendor/ruby
    - bundle install -j $(nproc)
    - rubocop
    - rspec spec

잡과 태스크

GitLab과 Bamboo 둘 다에서 같은 스테이지의 잡은, 먼저 충족해야 하는 의존성이 있는 경우를 제외하면 병렬로 실행돼요.

Bamboo에서 실행할 수 있는 잡 수는 Bamboo 에이전트 가용성과 Bamboo 라이선스 규모에 따라 달라져요.

GitLab CI/CD에서는 병렬 잡 수가 GitLab 인스턴스에 통합된 러너 수와 그 구성된 동시성(concurrency)에 따라 달라져요.

Bamboo에서 잡은 태스크로 구성돼요. 태스크는 스크립트로 실행되는 명령 집합일 수도 있고, 소스 코드 체크아웃이나 아티팩트 다운로드 같은 사전 정의 태스크일 수도 있어요. Bamboo는 Atlassian 태스크 마켓플레이스에서 다른 태스크도 제공해요.

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이며, 러너가 실행할 명령을 지정해요. CI/CD 템플릿과 CI/CD 컴포넌트를 사용하면 모든 것을 직접 작성할 필요 없이 파이프라인을 구성할 수 있어요.

job1:
  script: "bundle exec rspec"

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

컨테이너 이미지

다음 예시들은 Bamboo docker 키워드가 GitLab image 키워드로 어떻게 변환되는지 보여줘요.

빌드와 배포는 기본적으로 Bamboo 에이전트의 네이티브 운영체제에서 실행되지만, docker 키워드를 사용해 컨테이너에서 실행하도록 구성할 수 있어요.

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 키워드만 있으면 돼요.

default:
  image: alpine:latest

stages:
  - build

build-application:
  stage: build
  script:
    - # Run builds
  image:
    name: alpine:edge

변수

다음 예시들은 변수를 정의하고 접근하는 문법 차이를 보여줘요.

Bamboo에는 접근 패턴이 다른 다양한 변수 유형이 있어요. 시스템 변수는 ${system.variableName}을 사용하고, 다른 변수는 ${bamboo.variableName}을 사용해요.

스크립트 태스크에서는 점이 밑줄로 변환돼요. 예를 들어 ${bamboo.variableName}은 $bamboo_variableName이 돼요.

variables:
  username: admin
  releaseType: milestone

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

GitLab CI/CD에서는 변수를 일반 셸 스크립트 변수처럼 $VARIABLE_NAME으로 접근해요. Bamboo의 시스템·전역 변수처럼 GitLab에도 모든 잡에서 사용할 수 있는 사전 정의 CI/CD 변수가 있어요.

variables:
  DEFAULT_VAR: "A default variable"

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

조건과 트리거

이 예시들은 Bamboo 조건과 트리거가 GitLab rules로 어떻게 변환되는지 보여줘요.

Bamboo에는 빌드를 트리거하는 다양한 옵션이 있어요. 코드 변경, 일정, 다른 플랜의 결과, 또는 필요 시(on demand)에 기반할 수 있어요. 플랜은 새 변경 사항을 위해 프로젝트를 주기적으로 폴링하도록 구성할 수 있어요.

tasks:
  - script:
      scripts:
        - echo "Hello"
      conditions:
        - variable:
            equals:
              planRepository.branch: development

triggers:
  - polling:
      period: '180'

GitLab CI/CD 파이프라인은 코드 변경, 일정, API 호출에 기반해 트리거돼요. 파이프라인은 폴링을 사용하지 않아요.

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

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

아티팩트

GitLab과 Bamboo 둘 다에서 artifacts 키워드로 잡 아티팩트를 정의할 수 있어요.

Bamboo에서 아티팩트는 이름, 위치, 패턴으로 정의돼요. 아티팩트를 다른 잡·플랜과 공유하거나 아티팩트를 구독하는 잡을 정의할 수 있어요.

artifact-subscriptions는 같은 플랜의 다른 잡에서 아티팩트에 접근하는 데 사용되고, artifact-download는 다른 플랜의 잡에서 아티팩트에 접근하는 데 사용돼요.

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

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

# ...
Build:
  # ...
  tasks:
    - artifact-download:
        source-plan: PROJECTKEY-PLANKEY

GitLab에서는 이전 스테이지의 완료된 잡에서 온 모든 아티팩트가 기본적으로 다운로드돼요.

stages:
  - build

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

이 예시에서:

• 아티팩트의 이름은 명시적으로 지정되지만, CI/CD 변수를 사용해 동적으로 만들 수도 있어요.
• untracked 키워드는 paths로 명시적으로 지정한 파일과 함께 Git 추적되지 않은(untracked) 파일도 아티팩트에 포함하도록 설정해요.

캐싱

Bamboo에서 Git 캐시를 사용해 빌드를 빠르게 할 수 있어요. Git 캐시는 Bamboo 관리 설정에서 구성되며 Bamboo 서버나 원격 에이전트에 저장돼요.

GitLab은 Git 캐시와 잡 캐시를 모두 지원해요. 캐시는 cache 키워드로 각 잡에 정의돼요:

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 배포 프로젝트를 GitLab 배포 잡으로 변환하는 방법을 보여줘요.

Bamboo에는 배포 프로젝트가 있으며, 빌드 플랜에 연결해 아티팩트를 추적·가져와 배포 환경에 배포해요. 프로젝트를 만들 때 빌드 플랜에 연결하고, 배포 환경과 배포를 수행할 태스크를 지정해요.

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에서는 환경에 배포하거나 릴리스를 만드는 배포 잡을 만들 수 있어요.

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

대신 릴리스를 만들려면 glab CLI 도구와 함께 release 키워드를 사용해 Git 태그용 릴리스를 만들 수 있어요:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/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 CLI.'

보안 스캐닝

Bamboo는 보안 스캔을 실행하기 위해 Atlassian Marketplace에서 제공되는 타사 태스크에 의존해요.

GitLab은 SDLC 전반에서 취약점을 감지하는 보안 스캐너를 제공해요. 템플릿을 사용해 GitLab에서 이런 스캐너를 추가할 수 있는데, 예를 들어 파이프라인에 SAST 스캐닝을 추가하려면:

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

CI/CD 변수를 사용해 보안 스캐너의 동작을 사용자 정의할 수 있어요.

시크릿 관리

Bamboo의 시크릿 관리는 공유 자격 증명이나 Atlassian 마켓플레이스의 타사 애플리케이션으로 처리돼요.

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

GitLab은 OIDC를 지원하는 다른 타사 서비스를 위한 OIDC 인증도 지원해요.

추가로, CI/CD 변수에 자격 증명을 저장해 잡에서 사용할 수 있게 할 수 있어요. 하지만 일반 텍스트로 저장된 시크릿은 우연히 노출될 위험이 있어요. 민감한 정보는 항상 마스킹되고 보호된 변수에 저장해야 하며, 이렇게 하면 위험의 일부를 완화할 수 있어요.

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

마이그레이션 계획 만들기

마이그레이션을 시작하기 전에 마이그레이션 계획을 만들고 다음 질문에 답하세요:

• 오늘날 잡이 사용하는 Bamboo 태스크는 무엇이고 무슨 일을 하나요?
• Maven, Gradle, NPM 같은 일반 빌드 도구를 감싸는 태스크가 있나요?
• Bamboo 에이전트에 어떤 소프트웨어가 설치되어 있나요?
• Bamboo에서 어떻게 인증하나요(SSH 키, API 토큰, 또는 기타 시크릿)?
• 외부 서비스에 접근하기 위한 자격 증명이 Bamboo에 있나요?
• 사용 중인 공유 라이브러리나 템플릿이 있나요?

Bamboo에서 GitLab CI/CD로 마이그레이션하기

전제 조건:

• GitLab 인스턴스가 설정되고 구성되어 있어야 해요.
• 러너를 사용할 수 있어야 해요.

Bamboo에서 마이그레이션하려면:

1. Bamboo 구성을 감사하세요:Bamboo UI에서 프로젝트/플랜을 YAML Spec으로 내보내기.잡에서 사용하는 모든 Bamboo 태스크 나열(예: Maven, Docker, SCP).각 Bamboo 에이전트에 설치된 소프트웨어 버전 문서화.모든 공유 자격 증명과 그 사용처 식별.
2. 소스 코드 저장소를 GitLab으로 마이그레이션하세요:외부 SCM 제공자에서 대량 가져오기를 자동화하려면 사용 가능한 임포터를 사용하세요.개별 저장소는 URL로 저장소 가져오기를 사용하세요.
3. 동등한 소프트웨어로 GitLab 러너를 설정하세요:Bamboo 에이전트에 있는 소프트웨어와 같은 버전을 설치하세요.복잡한 에이전트 설정에는 필요한 도구가 있는 사용자 지정 Docker 이미지를 만드세요.러너가 빌드 명령을 성공적으로 실행할 수 있는지 테스트하세요.
4. Bamboo Specs를 .gitlab-ci.yml 파일로 변환하세요:Bamboo 플랜 구조를 GitLab 스테이지와 잡으로 바꾸세요.${bamboo.variableName} 문법을 $VARIABLE_NAME으로 변환하세요.${bamboo.planKey} 같은 Bamboo 전용 변수를 $CI_PIPELINE_ID 같은 GitLab 등가물로 바꾸세요.Bamboo checkout 태스크를 제거하세요. GitLab은 각 잡 시작 시 소스 코드를 자동으로 체크아웃해요.
5. 아티팩트 처리를 마이그레이션하세요:Bamboo artifact-subscriptions와 artifact-download 구성을 제거하세요.스테이지 간 자동 아티팩트 상속을 사용하세요.아티팩트 경로를 GitLab 잡 구조에 맞게 업데이트하세요.
6. Bamboo 배포 프로젝트를 변환하세요:별도의 Bamboo 배포 프로젝트에서 메인 .gitlab-ci.yml 파일로 배포 태스크를 옮기세요.Bamboo 환경을 GitLab 환경으로 바꾸세요.일반적인 배포 패턴에는 클라우드 배포 템플릿을 사용하세요.Kubernetes에 배포한다면 Kubernetes용 GitLab 에이전트를 구성하세요.
7. 시크릿과 자격 증명을 마이그레이션하세요:외부 시크릿 통합을 사용하거나 자격 증명을 마스킹·보호된 CI/CD 변수로 저장하세요.
8. 마이그레이션된 파이프라인을 테스트하고 최적화하세요:기능을 검증하는 테스트 파이프라인을 실행하세요.파이프라인 결과를 표시하도록 머지 리퀘스트 통합을 추가하세요.파이프라인 성능을 최적화하고 재사용 가능한 템플릿을 만드세요.

관련 주제

• 시작 가이드
• CI/CD YAML 문법 참조
• GitLab CI/CD 변수
• 파이프라인 효율성

더 알아보기

다음으로는 마이그레이션 계획 문서와 시작 가이드를 함께 보면, Bamboo 외의 다른 CI 도구에서도 체계적으로 GitLab CI/CD로 옮기는 방법을 익힐 수 있어요.