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 重新创建构建配置和 Pipelines。下面的子任务均属于这一转换流程：每一项都对应 .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 Marketplace 预定义任务。并发作业数取决于可用 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 拥有丰富的内置构建步进库（Maven、 Gradle、 .NET、 Docker等），可映射 Bamboo Marketplace 的预定义任务，因此常用构建工具一般无需编写原始 shell 脚本。

此外，TeamCity 还有自身的 Marketplace插件和模板。

容器镜像（Docker）

Bamboo

构建默认运行于 Bamboo 代理的本地操作系统，但通过在方案或作业层级使用 docker 关键字，也可配置为在 Docker 容器内运行。

docker: alpine:latest

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

   

TeamCity

在 TeamCity 中，有两种选项可在容器内运行构建步进：

容器包装器（原 Docker Wrapper）：可在 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% 语法。如需将参数作为原生环境变量暴露到构建过程中，定义时添加 env. 前缀，然后在 Linux/macOS 上以 $NAME ，Windows 上以 %NAME% 引用。

未加 env. 前缀的配置参数默认不会以 shell 环境变量自动可用。

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 任务条件等效的分支逻辑，请使用逻辑条件构建步进执行条件（适用于 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 通过管理后台配置的 Git 缓存，存储于 Bamboo 服务器或远程代理。 TeamCity 同时支持每代理自动管理的 Git 镜像缓存，以及通过构建缓存功能实现的按构建缓存（自 TeamCity 2023.11 起提供）。在使用 cache { } 块前，请根据 TeamCity 版本核对 Kotlin DSL 的具体 import，因 API 可能有所不同。

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 Marketplace 的第三方任务。

TeamCity 通过专用构建执行器与插件集成主流安全工具。常见选项包括：

JetBrains Qodana: 静态分析和代码质量扫描，在 TeamCity 可作为 Qodana 专用构建执行器使用。
Trivy / Snyk / SonarQube：以脚本步进运行，或通过 JetBrains Marketplace 社区插件实现。
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，并在 TeamCity 内通过内置 Vault 连接引用。密钥会在运行时 inject 为构建参数，并在日志中自动屏蔽。
AWS Secrets Manager / Azure 密钥保管库：可通过 JetBrains Marketplace 插件获取。

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 Specs？
需要支持多少并发构建？需要多少个代理？

从 Bamboo 迁移到 TeamCity

前提条件

已设置并可访问的 TeamCity 服务器（云端或本地）。
至少有一个 TeamCity 构建代理已连接且已授权。
可访问的 Bamboo 项目 YAML Specs（可从 Bamboo UI 或 Spec 仓库导出）。
从 TeamCity 服务器可访问的源代码仓库。

迁移步进

审核你的 Bamboo 配置
- 通过 Bamboo UI 将 Bamboo 项目和方案导出为 YAML Specs。
- 列出每个作业中使用的所有 Bamboo 任务（如 Maven、Docker、SCP、自定义脚本等）。
- 记录每个 Bamboo 代理上安装的软件版本。
- 识别所有共享凭据及其在各方案中的用法。
运行 TeamCity 项目和 VCS 根目录设置
- 在 TeamCity 中创建一个与 Bamboo 项目对应的新项目。
- 配置 VCS 根，指向你的源代码仓库（Git、GitHub、GitLab、Bitbucket 等）。
- TeamCity 支持与主流 Git 托管服务的 OAuth 连接，便于快速设置。
用等效软件运行 TeamCity 构建代理
- 安装与 Bamboo 代理上相同的软件版本。
- 对于复杂的代理设置，创建包含所需工具的自定义 Docker 镜像，并在构建步进中通过 dockerImage 引用。
- 在迁移流水线前，先测试代理是否能成功执行你的构建命令。
将 Bamboo Specs 转换为 TeamCity 构建配置
- 在 TeamCity 项目中启用版本化设置，以便使用 Kotlin DSL。默认情况下，设置会存储在 .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 agent 技能获取 AI 协助的迁移支持。运行 teamcity skill install ，将 TeamCity 技能注册到你的 AI 编码助手（如 Claude、Cursor、Copilot 或任何 MCP 兼容工具）。该技能使 agent 直接掌握 TeamCity 的 Kotlin DSL、构建配置结构及常见的 Bamboo 到 TeamCity 的映射模式，因此可以提示其转换单个 Bamboo Specs 文件，并将输出直接应用到仓库。
- 用 TeamCity 构建配置和构建链（通过快照依赖项关联）替换 Bamboo 方案/阶段/作业层次结构。
- 将 ${bamboo.variableName} 语法转换为配置信息字段中的 %variable.name% ，Shell 脚本中的 $VARIABLE_NAME。
- 将 Bamboo 专有变量（如 ${bamboo.planKey} ）替换为 TeamCity 预定义参数（如 %system.teamcity.buildType.id%）。
- 移除显式的检出任务。 TeamCity 在每个构建步进前会自动检出源代码。
迁移工件处理方式
- 在构建配置之间，用 TeamCity 工件依赖替换 Bamboo artifact-subscriptions。
- 在每个构建配置中通过 artifactRules 定义工件发布路径。
- 在构建链中，工件传递会通过快照依赖自动处理。
转换 Bamboo 部署项目
- 将 Bamboo 部署任务迁移到 TeamCity 部署构建配置中。
- 用 TeamCity 部署环境（TeamCity 2024.03 及以上）替换 Bamboo 的环境定义。
- 对于 Kubernetes 部署，可使用 Kubernetes 支持插件，或在 Docker 容器中通过 kubectl 脚本步进实现。
- 通过每个构建配置的触发器设置和基于角色的权限，配置人工审批闸。
迁移密钥和凭据
- 将 Bamboo 的共享凭据重新创建为 TeamCity 中的密码型参数或连接项。
- 针对敏感令牌，可与 HashiCorp Vault 或其他受支持的密钥存储后端集成。
- 在提交到 VCS 之前，审核所有 Kotlin DSL 文件，确保未将密钥硬编码。
测试并优化已迁移的工作流

运行测试构建，以验证功能与现有 Bamboo 的结果一致。
启用拉取请求 / 合并请求构建触发器，用于在合并前验证变更。
使用 TeamCity 的构建链可视化功能以确认依赖项顺序。
通过依赖项缓存构建功能、并行测试以及复合构建优化大型项目的性能。

切换策略

避免在第一天就彻底切换。逐步并行运行可降低风险，并让团队有时间在 TeamCity 上构建信心后再下线 Bamboo。

推荐的发布流程：

从低风险项目开始。选择一个非关键服务或内部工具作为首次迁移目标。用它来验证代理配置、Kotlin DSL 模式和密钥配置，再迁移到生产流水线。
同时运行两套系统。对每个已迁移方案，保持 Bamboo 构建激活，并在每次提交时触发等价的 TeamCity 构建。对比结果（工件输出、测试报告、部署结果），直到确认一致。
分批迁移。按团队或服务领域分组方案，每次迁移一批，通常每批持续一至两个冲刺周期。这样可以降低异常时的影响范围。
重定向流量并进行监控。一旦 TeamCity 流水线已通过至少一个完整冲刺的并行验证，即可禁用 Bamboo 方案，将 TeamCity 设为权威构建。在前两周密切监控构建成功率和耗时。
停用 Bamboo。全部方案迁移及验证完成后，禁用剩余 Bamboo 代理，归档项目配置，再关闭 Bamboo 服务器。

验证工件一致性

在并行运行期间，仅 TeamCity 构建成功还不够。还需确认 TeamCity 产出的工件与 Bamboo 针对同一源码修订产出的一致。 Bamboo 与 TeamCity 代理间的环境差异（如编译器版本、依赖项解析、操作系统库）可能导致静默偏差，只有在 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 基线指标（平均构建耗时、队列等待、每周失败率），以便在切换后为相关方提供可量化的前后对比。

参考：Bamboo 概念与 TeamCity 对应项

Bamboo 概念	TeamCity 对应项
Project（项目）	Project（项目）
方案	Build Configuration（构建配置）
阶段	构建链步进（通过快照依赖项）
工作	构建配置（或并行步进）
任务	构建步骤
代理	Build Agent（构建代理）
Bamboo Specs（YAML/Java）	Kotlin DSL / 版本化设置
共享凭据	连接 / 密码参数
工件订阅	构件依赖
部署项目	部署构建配置
部署环境	部署构建配置（环境分组）
方案分支	分支构建配置
方案触发器	构建触发器（VCS、定时、构建完成）
全局变量	项目级参数
方案变量	构建配置参数

2026年 8月 6日