正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Bambooから移行する

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

Atlassian BambooからGitLab CI/CDへ、BambooのUIからエクスポートされたBamboo仕様YAML設定を変換するか、仕様リポジトリに保存されているものを変換することで、移行することができます。

主な移行に関する考慮事項

設定の側面BambooGitLab CI/CD移行タスク
設定ファイルBamboo仕様 (JavaまたはYAML).gitlab-ci.yml ファイル仕様をGitLab YAML構文に変換
変数構文${bamboo.variableName}$VARIABLE_NAMEスクリプト内のすべての変数参照を更新
実行環境エージェント (ローカルまたはリモート)RunnerとexecutorRunnerのインストールと設定
アーティファクトの共有サブスクリプション付きの名前付きアーティファクトステージ間の自動継承アーティファクトの設定を簡素化
デプロイ個別のデプロイプロジェクトデプロイメントジョブと環境単一のパイプラインでビルドとデプロイを組み合わせる

設定例

Bamboo仕様のエクスポート

以下の例は、Bamboo UIからエクスポートされたBamboo仕様YAMLと、そのGitLab CI/CDの同等物を示しています。

Bambooは、プロジェクトが複数のプランを含み、プランがステージとジョブを定義し、ジョブが個々のタスクを実行するネストされた階層構造によってビルドを編成します。プロジェクトは、複数のプランがアクセスできる変数、認証情報、リポジトリ接続などの共有リソースのコンテナとして機能します。

Bamboo仕様のUIからのエクスポートには、この完全な階層に加えて、パーミッション、通知、プロジェクト設定などの管理メタデータが含まれます。

あなたのエクスポートをレビューする際には、これらの移行に不可欠な要素に焦点を当ててください:

  • ジョブとタスク: 実際のビルドコマンドとスクリプト
  • ステージの定義: 順次実行順序と依存
  • 変数とアーティファクト: ジョブ間で共有されるデータとファイル
  • トリガーと条件: ビルドが実行されるタイミングを決定するルール
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インスタンスと統合されたRunnerの数、およびRunnerで設定された並行処理によって異なります。

Bambooでは、ジョブはタスクで構成されており、これはスクリプトとして実行されるコマンドのセット、またはソースcodeのチェックアウト、アーティファクトのダウンロード、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であり、Runnerが実行するコマンドを指定します。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を使用して通常のShellスクリプト変数のようにアクセスされます。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のルールにどのように変換されるかを示しています。

Bambooには、codeの変更、スケジュール、他のプランの結果、またはオンデマンドに基づいてビルドをトリガーするためのさまざまなオプションがあります。プランは、新しい変更のためにプロジェクトを定期的にポーリングするように設定できます。

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

triggers:
  - polling:
      period: '180'

GitLab CI/CDパイプラインは、codeの変更、スケジュール、または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キーワードは、アーティファクトにGitで追跡されていないファイルと、pathsで明示的に指定されたファイルも含むように設定します。

キャッシュ

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

代わりにリリースを作成するには、glabCLIツールと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 Marketplaceのサードパーティアプリケーションを使用することで処理されます。

GitLabでのシークレット管理には、外部サービスのサポートされているインテグレーションを使用できます。これらのサービスはGitLabプロジェクトの外部にシークレットを安全に保存しますが、そのサービスに対するサブスクリプションが必要です。

GitLabは、OIDCをサポートする他のサードパーティサービスに対するOIDC認証もサポートしています。

さらに、認証情報をCI/CD変数に保存することで、ジョブで利用可能にすることができますが、平文で保存されたシークレットは偶発的な漏洩の影響を受けやすいです。常に機密情報をマスクされ保護された変数に保存することで、リスクの一部を軽減する必要があります。

シークレットを.gitlab-ci.ymlファイルに変数として保存しないでください。これはプロジェクトにアクセスできるすべてのユーザーに公開されます。機密情報を変数に保存するのは、プロジェクト、グループ、またはインスタンスの設定でのみ行うべきです。

移行計画の作成

移行を開始する前に、移行計画を作成し、以下の質問に答えてください:

  • 今日、どのようなBambooタスクがジョブによって使用されており、それらは何をするものですか？
  • いずれかのタスクがMaven、Gradle、またはNPMなどの一般的なビルドツールをラップしていますか？
  • どのようなソフトウェアがBambooエージェントにインストールされていますか？
  • Bambooからどのように認証していますか（SSHキー、APIトークン、または他のシークレット）？
  • 外部サービスにアクセスするための認証情報がBambooにありますか？
  • 共有ライブラリやテンプレートは使用されていますか？

BambooからGitLab CI/CDへ移行する

前提条件:

  • GitLabインスタンスがセットアップされ、設定されている必要があります。
  • Runnerが利用可能である必要があります。

Bambooから移行するには:

  1. あなたのBamboo設定を監査します:

    • Bamboo UIからBambooプロジェクト/プランをYAML仕様としてエクスポートする。
    • あなたのジョブで使用されているすべてのBambooタスクをリストします（例: Maven、Docker、SCP）。
    • 各Bambooエージェントにインストールされているソフトウェアバージョンを記録します。
    • すべての共有認証情報とその使用法を特定します。

  2. あなたのソースcodeリポジトリをGitLabに移行する:

  3. 同等のソフトウェアでRunnerをセットアップします:

    • あなたのBambooエージェントに存在する同じソフトウェアバージョンをインストールします。
    • 複雑なエージェントセットアップの場合は、必要なツールを含むカスタムDockerイメージを作成します。
    • Runnerがあなたのビルドコマンドを正常に実行できることをテストします。

  4. Bamboo仕様を.gitlab-ci.ymlファイルに変換します:

    • Bambooのプラン構造をGitLabのステージとジョブに置き換えます。
    • ${bamboo.variableName}構文を$VARIABLE_NAMEに変換します。
    • Bamboo固有の${bamboo.planKey}のような変数を、$CI_PIPELINE_IDのようなGitLabの同等物に置き換えます。
    • Bambooのチェックアウトタスクを削除します。GitLabは、各ジョブの開始時にあなたのソースcodeを自動的にチェックアウトする。

  5. アーティファクトの処理を移行する:

    • Bambooのartifact-subscriptionsおよびartifact-download設定を削除します。
    • ステージ間の自動アーティファクト継承を使用します。
    • アーティファクトパスをあなたのGitLabジョブ構造に合わせて更新します。

  6. Bambooのデプロイプロジェクトを変換する:

  7. シークレットと認証情報を移行する:

    • external secrets integrationsを使用するか、認証情報をマスクされ保護された変数であるCI/CD変数として保存します。

  8. 移行したパイプラインをテストして最適化します:

    • テストパイプラインを実行して機能を検証します。
    • パイプラインの結果を表示するためにマージリクエストインテグレーションを追加します。
    • パイプラインのパフォーマンスを最適化し、再利用可能なテンプレートを作成します。