Bamboo から TeamCity への移行ガイドライン

Bamboo プラン構成 (Bamboo UI から Java または YAML の Bamboo Specs としてエクスポートされたもの、または Spec リポジトリに保存されたもの) を TeamCity の Kotlin DSL ビルド構成フォーマットに変換することで、Atlassian Bamboo から TeamCity に移行できます。

Kotlin DSL (.teamcity/settings.kts) は推奨されるアプローチです。バージョン管理、レビュー、構成の再利用が可能です。コードを書かなくても、TeamCity UI から直接ビルド構成を作成および管理することもできます。

鍵となる移行時の考慮事項

構成アスペクト	Bamboo	TeamCity	移行タスク
構成ファイル	Bamboo Specs (Java または YAML)	Kotlin DSL (`settings.kts`)	TeamCity CLI を使用して Specs を Kotlin DSL に変換するか、TeamCity UI からビルド構成とパイプラインを再作成します。以下のサブタスクはすべてこの変換の一部です。各タスクは .kts ファイル内の特定の行に対応します。
変数構文	構成では `${bamboo.variableName}` 。スクリプトではドットがアンダースコアになります	構成フィールドでは `%param.name%` 。env. プレフィックス付きのパラメーターはスクリプト内で `$NAME` として使用できます	ビルド構成とスクリプト内のすべての変数参照を更新します
アーティファクト共有	サブスクリプション付きのお名前付きアーティファクト	ビルド構成間のアーティファクト依存関係	アーティファクトパスと依存関係ルールを再構成します
実行環境	エージェント (ローカルまたはリモート)	ビルドエージェント (クラウドまたはセルフホスト)	TeamCity エージェントをインストールして構成します
デプロイ	個別のデプロイプロジェクト	環境を持つデプロイビルド構成	ビルドチェーンでリンクされた個別のデプロイビルド構成を使用します
並列性	Bamboo エージェント数とライセンス階層によって制限されます	エージェント数と同時ビルドライセンスによって制限されます	十分なエージェントと同時ビルドライセンス容量を確保します

構成例

Bamboo Specs と TeamCity Kotlin DSL の比較

以下の例は、Bamboo Specs YAML プランと、それに対応する TeamCity Kotlin DSL を示しています。

Bamboo

Bamboo はネストされた階層でビルドを整理します: プロジェクトにはプランが含まれ、プランではステージングとジョブが定義され、ジョブは個々のタスクを実行します。プロジェクトは、複数のプランで使用される共有変数、資格情報、リポジトリ接続のコンテナーとして機能します。

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
            bundle config set --local deployment true
            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

   

TeamCity (Kotlin DSL)

TeamCity は、ネストされた Bamboo プロジェクト/プラン/ステージング/ジョブ階層を、プロジェクト (その中にビルド構成を含む) に置き換えます。各ビルド構成は、独自のビルド手順、トリガー、エージェント要件、アーティファクトルールを定義します。デフォルトでは、Kotlin DSL はリポジトリのルートにある .teamcity/ ディレクトリに配置されます。

// .teamcity/settings.kts
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.script
import jetbrains.buildServer.configs.kotlin.triggers.vcs

project {
    buildType(TestPlan)
}

object TestPlan : BuildType({
    name = "Test Plan"

    vcs {
        root(DslContext.settingsRoot)
        cleanCheckout = false
    }

    steps {
        script {
            name = "Run Bundler"
            scriptContent = """
                ruby -v
                bundle config set --local deployment true
                bundle install -j ${'$'}(nproc)
                rubocop
                rspec spec
            """.trimIndent()
        }
    }

    triggers {
        vcs {
            // TeamCity detects VCS changes automatically — no polling interval needed
        }
    }
})

   

ジョブとタスクからビルドステップ実行中へ

Bamboo では、ジョブはタスクで構成され、スクリプトまたは Atlassian マーケットプレイスから取得した事前定義済みタスクのいずれかで構成されます。同時実行ジョブの数は、利用可能な Bamboo エージェントの数によって決まります。

TeamCity では、タスクに相当するものはビルド構成内のビルドステップ実行中です。ステップはデフォルトでは順番に実行されます。同時ビルド数は、接続されているビルドエージェントの数と TeamCity ライセンスの並行性設定によって異なります。

Bamboo

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


   

TeamCity (Kotlin DSL)

steps {
    script {
        name = "Run Bundler"
        scriptContent = """
            ruby -v
            bundle config set --local deployment true
            bundle install -j ${'$'}(nproc)
        """.trimIndent()
    }
    script {
        name = "Run Tests"
        scriptContent = "bundle exec rspec spec"
    }
}

   

TeamCity には、Bamboo Marketplace で利用可能な定義済みタスクに対応する組み込みビルドステップ実行中 (Maven、 Gradle、 .NET、 Docker など) の大規模なライブラリがあるため、一般的なビルドツール用に生のシェルスクリプトを書く必要はほとんどありません。

それに加えて、TeamCity にはプラグインとレシピの独自の Marketplaceがあります。

コンテナーイメージ (Docker)

Bamboo

ビルドはデフォルトでは Bamboo エージェントのネイティブ OS 上で実行されますが、プランまたはジョブレベルで Docker キーワードを使用することで、Docker コンテナー内で実行するように構成できます。

docker: alpine:latest

Build Application:
  tasks:
    - script:
        - # Run builds
  docker:
    image: alpine:edge

   

TeamCity

TeamCity では、コンテナー内でビルドステップ実行中を実行するためのオプションが二つあります：

コンテナーラッパー (旧称 Docker ラッパー): Kotlin DSL の dockerImage プロパティを使用するか、ステップ実行中 UI の Docker 設定セクションから、ビルドステップ実行中ごとに構成します。これにより、指定されたコンテナー内で個々のステップが実行されます。
Docker で実行ビルド機能: ビルド構成レベルで構成され、サポートされているすべてのステップ実行中に単一のコンテナーイメージを一度に適用します。これは、Bamboo のプランレベルの docker: 設定に最も近いものです。

エージェントには Docker (または TeamCity 2023.05 以降でサポートされている Podman) がインストールされている必要があります。

// Option 1: Container Wrapper (per step)
steps {
    script {
        name = "Build Application"
        scriptContent = "# Run builds"
        dockerImage = "alpine:edge"
        dockerImagePlatform = ScriptBuildStep.ImagePlatform.Linux
    }
}

// Option 2: Run in Docker build feature (all steps in this Build Configuration)
features {
    runInDocker {
        imageName = "alpine:edge"
    }
}

   

変数

Bamboo

Bamboo には複数の変数名前空間があります。システム変数は ${system.variableName} を使用し、プラン変数は ${bamboo.variableName} を使用します。スクリプトタスク内では、ドットはアンダースコアに変換されるため、 ${bamboo.variableName} は $bamboo_variableName になります。

variables:
  username: admin
  releaseType: milestone

Default Job:
  tasks:
    - script:
        scripts:
          - echo "$bamboo_username is the DRI for $bamboo_releaseType"

   

TeamCity

TeamCity では、パラメーターはすべての構成フィールド (スクリプトコンテンツを含み、TeamCity が実行前に解決します) で %param.name% 構文を使用します。パラメーターをビルドプロセス自体の中でネイティブ環境変数として Exposed するには、定義時に 環境。 をプレフィックスとして付け、その後 Linux/macOS では $NAME 、Windows では %NAME% として参照します。

環境。 という接頭辞が付いていない設定パラメーターは、シェル環境変数として自動的には利用できません。

TeamCity は、豊富な設定の事前定義済みビルドパラメーターも提供します。

params {
    // Available as %username% in config fields; not a shell env var
    param("username", "admin")
    // Available as $RELEASE_TYPE in shell scripts (Linux/macOS)
    param("env.RELEASE_TYPE", "milestone")
}

steps {
    script {
        scriptContent = """
            echo "%username% is the DRI for ${'$'}RELEASE_TYPE"
        """.trimIndent()
    }
}

   

共通の変数対応表

Bamboo 変数	TeamCity での対応項目
`${bamboo.planKey}`	`%system.teamcity.buildType.id%`
`${bamboo.buildNumber}`	`%build.number%`
`${bamboo.planRepository.branch}`	`%teamcity.build.branch%`
`${bamboo.build.working.directory}`	`%system.teamcity.build.checkoutDir%`
`${bamboo.repository.revision.number}`	`%build.vcs.number%`

条件とトリガー

Bamboo

Bamboo は、VCS ポーリング、スケジュール、他のプランの結果、オンデマンドに基づいてビルドをトリガーします。ブランチ条件は個々のタスクに適用できます。

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

triggers:
  - polling:
      period: '180'

   

TeamCity

TeamCity ワークフローは、VCS の変更 (プッシュベース、ポーリング間隔不要)、スケジュール、または他のビルド構成の完了をトリガーにします。ステップ実行中ごとのブランチ条件は、ビルドステップ実行中の実行条件またはスナップショット依存関係を使用して処理することができます。

triggers {
    vcs {
        branchFilter = "+:development"
    }
    schedule {
        schedulingPolicy = cron {
            hours = "2"
            dayOfWeek = "MON-FRI"
        }
        branchFilter = "+:<default>"
    }
}

steps {
    script {
        name = "Hello"
        scriptContent = "echo Hello"
        // Step-level conditions can be set via the UI or executionMode
        executionMode = BuildStep.ExecutionMode.RUN_ON_SUCCESS
    }
}

   

Bamboo タスク条件に相当するブランチ固有のロジックには、Logical Condition ビルドステップ実行中の実行条件 (TeamCity 2020.2 以降で利用可能) を使用します：

ビルドステップの実行条件に移動します。
条件を追加します: teamcity.build.branch equals development

アーティファクト

Bamboo

Bamboo では、アーティファクトは名前、場所、パターンで定義されます。ジョブは同じプラン内の他のジョブからアーティファクトを購読し、 artifact-download タスクは他のプランからアーティファクトを取得します。

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

   

TeamCity

TeamCity では、ビルド構成でアーティファクトパスを指定してアーティファクトを公開します。他のビルド構成はアーティファクト依存関係を介してそれらを利用でき、依存するビルドが開始される前に特定のパスをダウンロードするように構成できます。

// Publishing build configuration
object Build : BuildType({
    name = "Build"

    artifactRules = """
        target/reports/*.xml => test-reports
        target/reports/special/*.xml => special-reports
    """.trimIndent()

    // ... steps
})

// Consuming build configuration
object TestApp : BuildType({
    name = "Test App"

    dependencies {
        artifacts(Build) {
            buildRule = lastSuccessful()
            artifactRules = "test-reports/*.xml => deploy/"
        }
    }

    // ... steps
})

   

ビルドチェーン内では、スナップショット依存関係によって、ビルドが正解の順序で実行され、同じ VCS リビジョンが使用されます。ただし、ビルド間で実際のファイルを渡すには、明示的なアーティファクト依存関係が引き続き必要です。スナップショットの依存関係だけではアーティファクトは転送されません。

キャッシング

Bamboo は、管理設定で構成され、Bamboo サーバーまたはリモートエージェントに保存される Git キャッシュを使用します。 TeamCity は、Git ミラーキャッシング (エージェントごとに自動管理) と、ビルドキャッシングビルド機能 (TeamCity 2023.11 で導入) を使用したビルドごとのキャッシングの両方をサポートしています。 API が異なる場合があるため、 cache { } ブロックを使用する前に、TeamCity バージョンに対して正確な Kotlin DSL インポートを確認してください。

features {
    // Cache node_modules across builds on the same agent
    cache {
        name = "node-modules-cache"
        rules = "node_modules"
        publishCondition = publishAlways()
    }
}

steps {
    script {
        name = "Install Dependencies"
        scriptContent = """
            bundle config set --local path vendor/ruby
            bundle install
            yarn install --frozen-lockfile
        """.trimIndent()
    }
}

   

エージェントレベルのキャッシング (Bamboo の Git キャッシングに相当) では、TeamCity エージェントがローカル VCS ミラーを自動的に維持するため、チェックアウトを繰り返してもリポジトリ全体が再クローンされることはありません。

デプロイ

Bamboo

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

   

TeamCity

TeamCity では、デプロイはデプロイ型のビルド構成としてモデル化されます。これらは、スナップショットまたはアーティファクトの依存関係を介して、アップストリームのビルド構成からアーティファクトを利用します。

object DeployToProduction : BuildType({
    name = "Deploy to Production"
    type = BuildTypeSettings.Type.DEPLOYMENT

    vcs {
        root(DslContext.settingsRoot)
    }

    dependencies {
        snapshot(Build) {
            onDependencyFailure = FailureAction.FAIL_TO_START
        }
        artifacts(Build) {
            buildRule = sameChainOrLastFinished()
            artifactRules = "**/* => ."
        }
    }

    steps {
        script {
            name = "Deploy"
            scriptContent = "./.ci/deploy_prod.sh"
        }
    }

    // Require manual confirmation before deploying
    requirements {
        // agent requirements here
    }
})

   

ゲート付きデプロイ (Bamboo の手動トリガー環境に相当) では、ビルド構成トリガーを手動に設定し、TeamCity のロールベースのアクセス制御を使用して権限を特定のロールに制限します。 TeamCity のビルド承認機能を使用することもできます。

セキュリティスキャン

Bamboo は、セキュリティスキャンに Atlassian マーケットプレイスのサードパーティ製タスクを利用しています。

TeamCity は、専用のビルドランナーとプラグインを通じて主要なセキュリティツールと統合します。一般的なオプションには以下が含まれます。

JetBrains Qodana：静的解析とコード品質スキャンは、TeamCity の専用 Qodana ビルドランナーとして利用できます。
Trivy / Snyk / SonarQube：: スクリプトステップとして実行するか、JetBrains マーケットプレイスで入手可能なコミュニティプラグインを介して実行してください。
OWASP 依存関係チェック：: Maven/Gradle ステップとして、またはスタンドアロンのスクリプトステップとして実行します。

steps {
    script {
        name = "Dependency Security Scan"
        scriptContent = """
            trivy fs --exit-code 1 --severity HIGH,CRITICAL .
        """.trimIndent()
        dockerImage = "aquasec/trivy:latest"
    }
}

   

シークレット管理

Bamboo は、共有認証情報（SSH キー、パスワード、API トークン）またはサードパーティの Atlassian Marketplace アプリケーションを通じてシークレットを管理します。

TeamCity はシークレット管理のためにいくつかのオプションを提供します：

型付きパラメーター：: 設定パラメーターはすべてパスワード型としてマークしてください。 TeamCity はビルドログと UI で値をマスクし、平文で Exposed することはありません。
HashiCorp Vault 統合: シークレットを Vault に保存し、組み込みの Vault 接続を使用して TeamCity で参照します。シークレットは実行時にビルドパラメーターとして挿入され、ログではマスクされます。
AWS Secrets Manager / Azure 鍵コンテナー: JetBrains マーケットプレイスのプラグインから入手可能です。

params {
    password("env.DEPLOY_API_TOKEN", "credentialsJSON:vault-token-ref")
    param("deploy.target", "production")
}

   

移行プランの作成

移行を開始する前に、以下の質問にお答えください。

現在、Bamboo のタスクはどのような用途で使われており、それぞれどのような機能を持っていますか？
Maven、Gradle、NPM、Docker などの一般的なビルドツールをラップするタスクはありますか？
Bamboo エージェントにインストールされていて、TeamCity エージェントにも必要なソフトウェアは何ですか？
Bamboo からの認証はどのように行っていますか？ : SSH キー、API トークン、その他の認証情報？
Bamboo で外部サービスにアクセスする際に、共有の認証情報を使用していますか？
共有されている設計図テンプレートや再利用可能な Bamboo スペック書は使用されていますか？
同時にサポートする必要のあるビルド数はいくつですか？また、必要なエージェント数はいくつですか？

Bamboo から TeamCity へ移行

前提条件

TeamCity サーバー (Cloud または On-Premises) が設定済みで、アクセス可能であること。
少なくとも一つの TeamCity ビルドエージェントが接続され、承認されていること。
Bamboo プロジェクトの YAML スペックファイル（Bamboo UI またはスペックリポジトリからエクスポートされたもの）へのアクセス。
TeamCity サーバーからアクセス可能なソースコードリポジトリ。

移行ステップ実行中

Bamboo 構成を監査する
- Bamboo のユーザーインターフェースから、Bamboo プロジェクトとプランを YAML スペックとしてエクスポートします。
- 各ジョブで使用されているすべての Bamboo タスク（Maven、Docker、SCP、カスタムスクリプトなど）を一覧表示します。
- 各 Bamboo エージェントにインストールされているソフトウェアのバージョンを記録してください。
- すべての共有認証情報と、それらがプラン間でどのように使用されているかを特定します。
TeamCity プロジェクトと VCS ルートをセットアップする
- Bamboo プロジェクトに合わせて、TeamCity に新しいプロジェクトを作成します。
- VCS のルートを、ソースコードリポジトリ (Git、GitHub、GitLab、Bitbucket など) を指すように設定してください。
- TeamCity は主要な Git ホスティングプロバイダーへの OAuth 接続をサポートしており、簡単にセットアップできます。
同等のソフトウェアで TeamCity ビルドエージェントをセットアップする
- Bamboo エージェントにインストールされているものと同じバージョンのソフトウェアをインストールしてください。
- 複雑なエージェント設定の場合は、必要なツールを含むカスタム Docker イメージを作成し、 dockerImage を使用してビルド手順で参照します。
- パイプラインを移行する前に、エージェントがビルドコマンドを正常に実行できるかどうかをテストしてください。
Bamboo Specs を TeamCity ビルド構成に変換します
- Kotlin DSL を使用するには、TeamCity プロジェクトでバージョン対応設定を有効化します。デフォルトでは、設定はリポジトリルートの .teamcity/ ディレクトリに保存されますが、TeamCity では専用の VCS リポジトリに別途保存することもサポートされています。
- TeamCity CLI を使用して、変換を自動化し高速化します。 brew install jetbrains/utils/teamcity (macOS)、 winget install JetBrains.TeamCityCLI (Windows)、または curl -fsSL https://jb.gg/tc/install | bash (Linux/macOS) と一緒にインストールしてください。 CLI は、パイプライン構成のエクスポート、検証、プッシュのためのスクリプトワークフローをサポートしています。 Bamboo 専用の teamcity migrate コマンドは現在開発中で、リリースされると Specs から DSL への変換の大部分を自動化します。
- CLI の AI エージェントスキルを使用して、AI による変換支援を受けることができます。 teamcity skill install を実行して、TeamCity スキルを AI コーディングエージェント (Claude、Cursor、Copilot、または任意の MCP 互換ツール) に登録します。このスキルにより、エージェントは TeamCity の Kotlin DSL、ビルド構成構造、一般的な Bamboo から TeamCity へのマッピングパターンに関する直接的な知識を得られるため、個々の Bamboo Specs ファイルを変換し、その出力をリポジトリに直接適用するよう確認できます。
- Bamboo のプラン/ステージング/ジョブ階層を、TeamCity ビルド構成とビルドチェーン (スナップショット依存関係でリンク) に置き換えます。
- 設定フィールドでは ${bamboo.variableName} 構文を %variable.name% に、シェルスクリプトでは $VARIABLE_NAME に変換します。
- Bamboo 固有の変数 (例: ${bamboo.planKey}) を TeamCity の事前定義パラメーター (例: %system.teamcity.buildType.id%) に置き換えます。
- 明示的なチェックアウト作業は不要です。 TeamCity は各ビルドステップ実行中の前にソースコードを自動的にチェックアウトします。
アーティファクト処理を移行する
- ビルド構成間で、Bamboo artifact-subscriptions を TeamCity のアーティファクト依存関係に置き換えます。
- 各ビルド構成において、 artifactRules を使用してアーティファクトの公開パスを定義します。
- ビルドチェーン内では、アーティファクトの受け渡しはスナップショット依存関係を介して自動的に処理されます。
Bamboo デプロイプロジェクトを変換する
- Bamboo のデプロイタスクを TeamCity デプロイビルド構成に移動します。
- Bamboo 環境定義を TeamCity デプロイ環境 (TeamCity 2024.03 以降) に置き換えます。
- Kubernetes デプロイの場合、Kubernetes サポートプラグインを使用するか、Docker コンテナー内で kubectl を使用したスクリプトステップを実行してください。
- ビルド構成ごとのトリガー設定とロールベースの権限を使用して、手動承認ゲートを設定します。
シークレットと資格情報を移行する
- Bamboo 共有資格情報を、TeamCity のパスワード型パラメーターまたは接続エントリとして再作成します。
- 機密性の高いトークンについては、HashiCorp Vault またはその他のサポートされているシークレットバックエンドと統合してください。
- VCS にコミットする前に、すべての Kotlin DSL ファイルを監査し、機密情報がハードコードされていないことを確認してください。
移行したワークフローをテストして最適化する

既存の Bamboo の結果と比較して、テストビルドを実行して機能性を確認してください。
マージ前に変更内容を検証するために、プルリクエスト／マージリクエストのビルドトリガーを有効にしてください。
TeamCity のビルドチェーン可視化を使用して、依存関係の順序を確認します。
依存関係キャッシングビルド機能、並列テストによる並列性、大規模プロジェクト向けの複合ビルドを使用してパフォーマンスを最適化します。

カットオーバー戦略

初日にいきなり切り替えるのは避けましょう。段階的な並列実行アプローチによりリスクを軽減し、Bamboo を廃止する前にチームが TeamCity への信頼をビルドする時間を確保できます。

推奨される展開方法:

低リスクのプロジェクトから始めます。最初の移行ターゲットとして、重要度の低いサービスまたは内部ツールを選択します。本番パイプラインに触れる前に、それを使ってエージェントのセットアップ、Kotlin DSL パターン、シークレット構成を検証します。
両方のシステムを並列に実行します。移行した各プランについて、Bamboo ビルドをアクティブなままにし、対応する TeamCity ビルドをすべてのコミットでトリガーします。同等性が確認されるまで、結果 (アーティファクト出力、テストレポート、デプロイ結果) を比較します。
段階的に移行します。プランをチームまたはサービスドメインごとにグループ化し、通常はウェーブあたり一から二スプリントサイクルかけて、一度に一つのウェーブを移行します。これにより、問題が発生した場合の影響範囲を制限できます。
トラフィックをリダイレクトして監視します。 TeamCity パイプラインが少なくとも一回の完全なスプリントで並列検証に合格したら、Bamboo プランを無効化し、TeamCity を正式なビルドにします。最初の二週間は、ビルド成功率と所要時間を注意深く監視します。
Bamboo を廃止します。すべてのプランの移行と検証が完了したら、残っている Bamboo エージェントを無効化し、Bamboo サーバーをシャットダウンする前にプロジェクト構成をアーカイブします。

アーティファクトの同等性の検証

並列実行期間中は、TeamCity ビルドが成功することを確認するだけでは不十分です。同じソースリビジョンに対して、TeamCity が Bamboo と同じアーティファクトを生成することも確認する必要があります。 Bamboo と TeamCity エージェント間の環境の違い (コンパイラーバージョン、依存関係の解決、OS ライブラリ) により、Bamboo の廃止後に初めて表面化する、気づきにくい相違が発生する可能性があります。

推奨される方法は、移行期間中にコミットごとに自動的に実行される専用のアーティファクトパリティ検証ビルド構成を使用することです。新しい TeamCity ビルドによって生成されたアーティファクトと、同じリビジョンの対応する Bamboo ビルドによって生成されたアーティファクトをダウンロードし、それらの差分を比較して、相違がある場合はビルドを失敗させます。

例: アーティファクトの同等性検証用ビルド構成

object ArtifactParityCheck : BuildType({
    name = "Artifact Parity Check (Bamboo vs TeamCity)"

    // Trigger on the same VCS root as your main build
    vcs {
        root(DslContext.settingsRoot)
    }

    // Pull in the artifact freshly built by TeamCity on this revision
    dependencies {
        artifacts(TeamCityBuild) {
            buildRule = sameChainOrLastFinished()
            artifactRules = "build/app.jar => tc-artifact/"
        }
    }

    steps {
        script {
            name = "Download Bamboo artifact for the same revision"
            scriptContent = """
                REVISION="%build.vcs.number%"

                # Use the Bamboo REST API to find the build for this revision
                # and download its artifact. Replace PLAN_KEY and ARTIFACT_NAME.
                BAMBOO_BUILD=${'$'}(curl -s -u "%bamboo.user%:%bamboo.token%" \
                  "%bamboo.url%/rest/api/latest/result/PLAN-KEY.json?expand=results.result" \
                  | jq -r ".results.result[]
                    | select(.vcsRevisionKey == \"${'$'}REVISION\")
                    | .buildResultKey" | head -1)

                echo "Matching Bamboo build: ${'$'}BAMBOO_BUILD"

                curl -s -u "%bamboo.user%:%bamboo.token%" \
                  "%bamboo.url%/rest/api/latest/result/${'$'}BAMBOO_BUILD/artifact/\
shared/ARTIFACT_NAME/app.jar" \
                  -o bamboo-artifact/app.jar
            """.trimIndent()
        }

        script {
            name = "Compare artifacts"
            scriptContent = """
                echo "TeamCity artifact checksum:"
                sha256sum tc-artifact/app.jar

                echo "Bamboo artifact checksum:"
                sha256sum bamboo-artifact/app.jar

                if ! diff <(sha256sum tc-artifact/app.jar | awk '{print $1}') \
                          <(sha256sum bamboo-artifact/app.jar | awk '{print $1}'); then
                  echo "MISMATCH: TeamCity and Bamboo artifacts differ on revision %build.vcs.number%"
                  exit 1
                fi

                echo "Artifacts match."
            """.trimIndent()
        }
    }

    // Store both artifacts for manual inspection if the check fails
    artifactRules = """
        tc-artifact/app.jar => parity-check/tc/
        bamboo-artifact/app.jar => parity-check/bamboo/
    """.trimIndent()
})

   

いくつか実用的な注意点があります。

チェックサム比較は最も単純なシグナルですが、常に適切とは限りません。一部のビルドツールはタイムスタンプやランダムソルトを埋め込むため、同じ入力でもバイト単位で同一の出力にすることはできません。そのような場合は、代わりに機能的な同等性を比較します: アーティファクトをアンパックして内容の diff を取り、同じテスト suite を両方に対して実行するか、エクスポートされたメタデータ (依存関係マニフェスト、クラスリスト、許容範囲内のバイナリサイズ) を比較します。
Bamboo REST API（/rest/api/latest/result ）を使用すると、VCS リビジョンごとにビルドを照会できます。ログにマスクされるように、Bamboo API トークンをパスワード型パラメーター（%bamboo.token% ）として保存する必要があります。
移行期間中にクリティカルパスを増やさないよう、このチェックはメインの TeamCity ビルドと順次ではなく並列で実行します。
Bamboo の廃止が完了したら、このビルド構成は削除してください。切り替えが完了した後は、この構成は不要になります。

移行後に期待できること

Bamboo から TeamCity に移行するチームでは通常、いくつかの側面で改善が見られますが、正確な結果は現在の Bamboo セットアップ、エージェントハードウェア、パイプラインの複雑さによって異なります：

メトリクス	一般的な改善
ビルドキューの待ち時間	大幅に短縮: TeamCity のエージェントプールとクラウドエージェントの自動スケーリングにより、Bamboo で一般的な固定エージェントのボトルネックが解消されます
同時ビルド容量	クラウドエージェントによりオンデマンドでスケールします。Bamboo の固定エージェント数とは対照的です
パイプライン構成のオーバーヘッド	低減: Kotlin DSL はバージョン管理、レビュー、構成の再利用が可能です。プランのクローン時に UI で手動再入力する必要はありません
シークレットと資格情報の管理	より構造化: パスワードパラメーターと Vault 統合により、Bamboo の分散した共有資格情報を置き換えます
可視性とデバッグ	改善: TeamCity のビルドチェーン表示、ステップ実行中ごとのログ、テスト履歴により、失敗の診断が速くなります

移行を開始する前に、Bamboo のベースラインメトリクス (平均ビルド時間、キュー待ち、週次失敗率) を確立しておくと、カットオーバー完了後に関係者向けの具体的な移行前後の比較を作成できます。

リファレンス: Bamboo の概念と TeamCity での対応項目

Bamboo の概念	TeamCity での対応項目
プロジェクト	プロジェクト
プラン	ビルド構成
ステージ	ビルドチェーンステップ実行中 (スナップショット依存関係経由)
ジョブ	ビルド構成 (または並列ステップ実行中)
タスク	ビルドステップ
エージェント	ビルドエージェント
Bamboo Specs (YAML/Java)	Kotlin DSL / バージョン対応設定
共有資格情報	接続 / パスワードパラメーター
アーティファクトサブスクリプション	アーティファクトの依存関係
デプロイプロジェクト	デプロイビルド構成
デプロイ環境	デプロイビルド構成 (環境グループ化)
プランブランチ	ブランチビルド構成
プラントリガー	ビルドトリガー (VCS、スケジュール、ビルド完了)
グローバル変数	プロジェクトレベルのパラメーター
プラン変数	ビルド構成パラメーター

2026 年 9 月 11 日