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

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

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

移行に関する重要な考慮事項

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

構成例

Bamboo Specs vs. TeamCity Kotlin DSL

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

竹

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 ライセンスの同時実行構成によって異なります。

竹

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 には独自のプラグインとレシピのマーケットプレイス(英語)があります。

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

竹

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

docker: alpine:latest

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

TeamCity

TeamCity では、コンテナー内でビルドステップを実行する方法として、以下の 2 つのオプションがあります。

コンテナーラッパー（旧称 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 には複数の変数名前空間があります。システム変数は ${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% 構文を使用します。ビルドプロセス内でパラメーターをネイティブ環境変数として公開するには、定義時に env. を接頭辞として付け、Linux/macOS では $NAME、Windows では %NAME% として参照します。

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

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()
    }
}

一般的な変数の等価物

竹のバリエーション	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 は、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 タスク条件に相当するブランチ固有のロジックについては、論理条件ビルドステップ実行条件（TeamCity 2020.2 以降で利用可能）を使用してください。

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

アーティファクト

竹

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 は、ビルドプランにリンクする個別のデプロイプロジェクトを使用して、ビルドアーティファクトを追跡、取得、指定された環境にデプロイします。

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 ビルドランナーとして利用可能です。
トリビー / スニック / ソナーキューブ : スクリプトステップとして実行するか、JetBrains マーケットプレイスで入手可能なコミュニティプラグインを介して実行してください。
OWASP Dependency-Check : 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 上で値をマスクし、平文で表示することはありません。
HashiCorp Vault との連携 : シークレットは Vault に保存し、組み込みの Vault 接続を使用して TeamCity 内で参照します。シークレットは実行時にビルドパラメーターとして挿入され、ログではマスクされます。
AWS Secrets Manager/Azure Key Vault : 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 サーバー（クラウドまたはオンプレミス）がセットアップされ、アクセス可能であること。
少なくとも 1 つの 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 のスペックを 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 を使用したスクリプトステップを実行してください。
- ビルド構成ごとのトリガー設定とロールベースの権限を使用して、手動承認ゲートを設定します。
シークレットと認証情報を移行する
- TeamCity で、Bamboo 共有認証情報をパスワード型パラメーターまたは接続エントリとして再作成します。
- 機密性の高いトークンについては、HashiCorp Vault またはその他のサポートされているシークレットバックエンドと統合してください。
- VCS にコミットする前に、すべての Kotlin DSL ファイルを監査し、機密情報がハードコードされていないことを確認してください。
移行したワークフローをテストして最適化する

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

切り替え戦略

初日にいきなり切り替えるのは避けましょう。段階的な並行運用アプローチを採用することでリスクを軽減し、Bamboo の廃止前にチームが TeamCity への信頼を築くための時間を確保できます。

推奨される展開方法:

リスクの低いプロジェクトから始めましょう。最初の移行対象として、重要度の低いサービスまたは内部ツールを選択してください。本番環境のパイプラインに手を加える前に、それを使用してエージェントの設定、Kotlin DSL パターン、およびシークレット構成を検証してください。
両方のシステムを並行して実行します。移行した各プランについて、Bamboo ビルドをアクティブな状態に保ち、コミットごとに同等の TeamCity ビルドをトリガーします。結果（アーティファクトの出力、テストレポート、デプロイの結果）を比較し、同等性が確認されるまで繰り返します。
波状移動します。チームまたはサービス領域ごとに計画をグループ化し、一度に 1 つの波ずつ移行します。通常、1 つの波につき 1 ～ 2 回のスプリントサイクルを要します。こうすることで、問題が発生した場合の影響範囲を最小限に抑えることができます。
トラフィックをリダイレクトして監視します。TeamCity パイプラインが少なくとも 1 スプリント分の並列検証に合格したら、Bamboo プランを無効にして、TeamCity を正式なビルドにします。最初の 2 週間は、ビルドの成功率と所要時間を綿密に監視してください。
竹の廃止。すべてのプランの移行と検証が完了したら、残りの 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()
})

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

チェックサム比較は最も単純な指標ですが、常に正しいとは限りません。ビルドツールによっては、タイムスタンプやランダムなソルトを埋め込んでいるため、同じ入力であってもバイト単位で完全に一致する出力を得ることは不可能です。そのような場合は、代わりに機能的な等価性を比較してください。アーティファクトを解凍してその内容を比較したり、両方に対して同じテストスイートを実行したり、エクスポートされたメタデータ（依存関係マニフェスト、クラスリスト、許容範囲内のバイナリサイズなど）を比較したりします。
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 のベースライン指標（平均ビルド時間、キュー待ち時間、週ごとの失敗率など）を確立しておきましょう。そうすることで、切り替え完了後に、関係者に対して具体的な前後比較を提供できます。

リファレンス: 竹の概念を TeamCity 相当品に置き換える

竹のコンセプト	TeamCity 相当品
プロジェクト	プロジェクト
プラン	ビルド構成
ステージ	チェーンステップの構築 (スナップショット依存関係経由)
ジョブ	ビルド構成 (または並列ステップ)
タスク	ビルドステップ
エージェント	ビルドエージェント
竹製スペック (YAML/Java)	Kotlin DSL/ バージョン管理された設定
共有認証情報	接続 / パスワードパラメーター
アーティファクト購読	アーティファクトの依存関係
デプロイプロジェクト	デプロイビルド構成
デプロイ環境	デプロイビルド構成 (環境グループ分け)
プランブランチ	ブランチビルド構成
プラントリガー	ビルドトリガー (VCS、スケジュール、ビルド完了)
グローバル変数	プロジェクトレベルのパラメーター
プラン変数	ビルド構成パラメーター

2026 年 6 月 01 日

TeamCity オンプレミス 2026.1 ヘルプ

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

移行に関する重要な考慮事項

構成例

Bamboo Specs vs. TeamCity Kotlin DSL

ステップを構築する作業とタスク

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

変数

条件とトリガー

アーティファクト

キャッシング

デプロイ

セキュリティスキャン

機密情報の管理

移行計画を作成する

Bamboo から TeamCity へ移行する

前提条件

移行手順

切り替え戦略

アーティファクトのパリティを検証する

移住後に期待できること

リファレンス: 竹の概念を TeamCity 相当品に置き換える

関連ページ：