Ohhnews

分类导航

$ cd ..
Jetbrains Blog原文

Bamboo 停止服务：如何准备并选择合适的 CI/CD 替代方案

#bamboo#ci/cd#迁移策略#配置即代码#技术债务

如果你的团队正在使用 Bamboo，你可能已经看到了相关消息：Bamboo Data Center 即将退役，这是 Atlassian 更广泛的数据中心过渡战略的一部分。官方支持还会持续几年，但许多团队已经开始考虑下一步了。

无论你是在考虑迁移到 Bamboo Cloud，还是彻底更换为一套全新的 CI/CD 解决方案，好消息是你不需要匆忙做决定。你不仅有足够的时间来评估迁移选项，甚至还可以借此机会重新思考你的整个 CI/CD 流程。

对某些团队来说，这正是一个绝佳的时机，可以退后一步，审视多年来积累的 CI/CD 工作流。在某些情况下，从头重建整个流程可能比直接迁移原有的流程更可行。

在本指南中，我们将探讨 Bamboo 退役在实际运营中意味着什么，如何为过渡做好准备，以及在评估替代方案时需要考虑哪些因素。

[LOADING...]

Bamboo 退役对团队意味着什么

根据 Atlassian 的时间表，针对新客户的许可证销售将于 2026 年停止，而 Bamboo Data Center 将在 2029 年 3 月 28 日完全终止生命周期。

CI/CD 系统位于软件交付流程的中心。它连接着源代码管理、测试、制品存储、部署工具、基础设施、密钥管理和开发者工作流。

如果你已经使用 Bamboo 5 到 10 年，你的 CI/CD 设置中可能已经积累了相当多的历史遗留问题。随着 Bamboo Data Center 的生命周期走到尽头，真正的问题与其说是用哪个工具来替代 Bamboo，不如说是你现有配置中的哪些部分值得保留，哪些不值得。

以下是为从本地 Bamboo 迁移做规划的一些实用步骤。

从审计开始，而不是比较工具

在评估替代方案之前，先花点时间审计你当前的 Bamboo 安装。记录以下内容：

  • 构建计划和任务
  • 代理配置
  • 部署项目
  • 制品存储和保留策略
  • 共享凭据和变量
  • 仓库集成
  • 自定义脚本和插件
  • Jira 和 Bitbucket 集成
  • 合规性和安全要求

识别哪些流水线是真正的业务关键型，哪些只是随着时间的推移而积累下来的。许多组织发现，他们 CI/CD 配置的很大一部分已经不再活跃使用了。

💡 另请阅读： Bamboo 到 TeamCity 迁移指南

不要迁移你的技术债务

启动迁移项目时，本能反应是原封不动地重建一切。这种方法感觉很安全。但现实中，彻底审查 CI/CD 流程通常更有意义。

总部位于荷兰、为保险和养老金行业提供软件的提供商 Keylane 就是一个很好的例子。该公司依赖 Bamboo 超过 15 年，支持着横跨多个产品线的大约 1000 名开发者，并运行着大约 200 个构建代理——这是现存最大的 Bamboo 部署之一。

与其直接迁移现有配置，该团队使用 TeamCity 的 Kotlin DSL 从头重建了其 CI/CD 流水线。

“我们决定不直接迁移旧的配置，因为那样我们也会迁移大量的历史遗留问题，”Keylane 的首席架构师 Barry Nijkamp 说道。

一个由三到四名工程师组成的迁移团队逐一按产品线重新设计了流水线，在此过程中移除了遗留的依赖和过时的步骤，而不是将它们带入新的系统。

最大的收获是构建速度的提升。Keylane 最大的一个应用由 2700 万行代码构成，其完整重建时间从原来的一小时以上缩短到了大约六分钟，减少了 90%。

“在我们的旧工作流中，一次构建需要超过一小时。现在完整重建只需要六分钟，”Barry 说。

但这说明了一个重要观点：迁移是你为数不多需要触及 CI/CD 基础设施的时刻之一。请利用这个机会来改进它。

在 Bamboo 替代方案中寻找什么

一旦你审计了你的环境并确定了需要改进的领域，就是时候看看替代方案了。

不同的团队优先考虑不同的事情，但在 CI/CD 迁移过程中，有几个标准总是很重要。

💡 另请阅读： 如何选择 CI/CD 工具

配置即代码

大多数成熟的工程组织都希望他们的 CI/CD 配置能够进行版本管理、可供审查，并与应用程序代码一起管理。

配置即代码支持透明度、代码审查，并使大规模更改更易于管理。

如果你的团队在 Bamboo Specs 上投入了大量精力，你可能会希望找到一个具有类似强大方法支持的平台。

可扩展性

Bamboo 之所以在大型工程组织中流行，是因为它将强大的 Atlassian 集成与支持分布式构建和可扩展 CI 工作负载的基于代理的架构结合在一起。

在评估替代方案时，请考虑：

  • 代理数量
  • 并行执行
  • 队列管理
  • 大型单体仓库
  • 多项目环境

随着组织的发展，可扩展性变得更加重要。一个对五十名开发者来说运行良好的平台，在五百名开发者时可能会表现得截然不同。

托管灵活性

决定你的构建需要在何处运行，应该是你评估的一部分。对于某些团队来说，计划只是将所有内容迁移到 SaaS。其他团队则需要权衡：

  • 本地执行
  • 混合基础设施
  • 访问内部网络
  • 专用硬件
  • 法规合规控制

可靠性

CI/CD 位于交付管道的核心，因此其不稳定会立即带来显著的成本。在比较这方面的替代方案时，要注意：

  • 平台稳定性
  • 支持响应能力
  • 构建可见性
  • 故障排除能力
  • 恢复选项

可靠性不会作为一项功能出现在对比表中，但它是团队在迁移后感受最深的一点：更少的构建失败和更少的宕机复盘。

集成

Bamboo 与 Jira、Bitbucket 以及 Atlassian 生态系统其他部分的紧密集成是吸引许多团队的最大因素之一。如果这个生态系统对你仍然重要，请检查任何替代方案能否很好地连接到：

  • 源代码管理
  • 问题跟踪
  • 部署工具
  • 通知
  • 开发者工作流

一个好的迁移应该承担较低的风险，避免扰乱你的团队已经依赖的系统。

常见的 Bamboo 替代方案

没有唯一正确的 Bamboo 替代方案。最佳选择取决于你的环境、现有的工作流以及你的长期战略。

[LOADING...] 2025 年开发者生态系统报告

Bitbucket Pipelines

对于已经投入 Atlassian Cloud 的组织来说，Bitbucket Pipelines 是最直接的选择。对于拥有相对简单的基于云的工作流的团队来说，这是很自然的选择。

GitHub Actions

GitHub Actions 已经成为行业内使用最广泛的 CI/CD 平台之一。根据 JetBrains 的 2025 年开发者生态系统报告，它在组织采用率上以 33% 领先，超过了 Jenkins 的 28% 和 GitLab CI/CD 的 19%。

对于已经标准化使用 GitHub 的团队来说，它提供了丰富的开发者体验和庞大的集成生态系统。

其局限性在于：GitHub Actions 支持自托管运行器，但它不是一个完全自托管的 CI/CD 平台。寻求真正本地替代 Bamboo 的团队应该根据他们的合规性和基础设施要求来权衡这一点。

💡 另请阅读： 2026 年最佳 CI 工具

GitLab CI/CD

对于希望将源代码管理、CI/CD 和 DevOps 工作流整合到一个平台的组织来说，GitLab CI/CD 是一个实用的选择。它往往能吸引那些已经致力于 GitLab 生态系统的团队。

Jenkins

Jenkins 仍然是最灵活、部署最广泛的 CI/CD 平台之一，拥有庞大的插件生态系统，几乎可以支持任何自定义需求。

其代价是运营的复杂性。选择 Jenkins 的团队需要自己拥有并维护该平台。

TeamCity

特别是对于 Bamboo 用户来说，TeamCity 经常被考虑，因为它提供了许多最初吸引组织使用 Bamboo 的相同特性：

  • 支持复杂的构建环境
  • 构建代理架构
  • 自托管、云和混合部署
  • 强大的集成
  • 高级配置即代码能力

在迁移过程中经常被提及的一个功能是 Kotlin DSL。几个组织依赖它，因为它使 CI/CD 配置可以作为代码进行管理，同时保持表达能力。

例如，Keylane 的团队发现 TeamCity 中的配置即代码明显比他们在 Bamboo 中使用的更强大，其 API 更能原生地集成到他们的工作流中。

将迁移视为一个过渡，而不是切换

组织通常将 Bamboo 迁移视为基础设施项目：选择新平台，迁移现有流水线，淘汰旧系统。

但实际上，迁移往往更具迭代性。

CI/CD 系统会随着时间的推移积累集成、部署流程、特定于环境的逻辑、制品流和操作惯例，其中大部分很少被统一记录在一个地方。许多这样的依赖关系只有在团队开始将工作负载转移到新平台时才会显现出来。

这就是为什么大规模迁移通常是分阶段进行的，而不是作为一次性切换来执行的原因。一个试点项目通常能揭示平台在处理制品、依赖关系、构建代理、权限或部署工作流方面的差异。

这些发现是过程中的正常部分，它们常常会促使团队重新审视那些多年来未被质疑的假设。

💡 另请阅读： Bamboo 到 TeamCity 迁移指南

上面提到的 Keylane 迁移遵循了同样的模式。该团队没有重建现有的工作流，而是利用这次过渡来审查依赖关系、简化构建链，并重新设计其交付流程中那些最难维护的部分。

这种经历并非特例。许多团队发现，迁移最有价值的成果往往与新平台本身关系不大，而与过程中所做的决策关系更大：淘汰过时的任务、减少不必要的复杂性、标准化环境、改进配置管理，或明确关键交付工作流的所有权。

出于这个原因，让新旧系统并行运行一段时间通常是值得的。

并行运行让你有机会比较输出结果、验证行为，并在将关键工作负载迁移过去之前建立信心。这也让团队有空间在迁移过程中改进工作流，而不是简单地将它们一对一地转换。

那些从 Bamboo 迁移中获得最大价值的组织，不一定是完成得最快的。他们是那些利用这次过渡来构建一个更易于维护、更易于理解、并且更符合工程团队实际工作方式的交付平台的组织。

最后思考

Bamboo 的退役设定了一个最后期限，但更有意义的问题是，你希望五年后运行什么样的交付平台。

那些能带来回报的迁移通常不是最快的。它们是那些利用这个最后期限作为理由，去简化工作流、质疑旧有假设、并修复那些多年来悄然失效的流水线部分的迁移。

无论你用什么样的工具来替代 Bamboo，目标不应仅仅是匹配它的功能。而是建立一个你的团队在短期内不需要再次迁移的环境。