Bamboo End of Life: How to Prepare and Choose the Right CI/CD Replacement

Bamboo 停止支持：如何准备并选择合适的 CI/CD 替代方案 - JetBrains 博客

TeamCity

面向 DevOps 团队的强大 CI/CD 工具

关注

• 关注：

• X X

• YouTube YouTube

• RSS RSS

获取 TeamCity

TeamCity

工具

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

Olga Bedrina

如果你的团队正在使用 Bamboo，你可能已经看到相关新闻：作为 Atlassian 更广泛的 Data Center 过渡战略的一部分，Bamboo Data Center 正在被停用。虽然支持还会持续几年，但许多团队已经开始考虑下一步的方案。

无论你是考虑使用 Bamboo Cloud 还是转向全新的 CI/CD 解决方案，好消息是，你不需要急于做出决定。你有足够的时间不仅评估迁移选项，还可以重新思考整个 CI/CD 流程。

对于某些团队来说，这是一次很好的机会，可以回顾多年来积累的 CI/CD 工作流程。在某些情况下，重建整个流程可能比继续使用当前的流程更加可行。

在本指南中，我们将探讨 Bamboo 停止支持在实际操作中的含义，如何为过渡做准备，以及在评估替代方案时需要考虑哪些因素。

Bamboo 停止支持对团队意味着什么

根据 Atlassian 的时间表，从 2026 年起，将不再向新客户销售 Bamboo 的许可证，而 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 年，支持大约 1,000 名开发人员，涉及多个产品线，并运行大约 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 替代方案。最佳选择取决于你的环境、现有的工作流程以及你的长期战略。

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

GitLab CI/CD 是那些希望在一个平台上整合源代码控制、CI/CD 和 DevOps 工作流程的组织的实用选择。它通常会吸引那些已经致力于 GitLab 生态系统的团队。

Jenkins

Jenkins 仍然是最灵活且部署最广泛的 CI/CD 平台之一，拥有一个大型的插件生态系统，几乎可以满足任何定制需求。

权衡是操作复杂性。选择 Jenkins 的团队需要自行拥有并维护该平台。

TeamCity

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

• 对复杂构建环境的支持

• 构建代理架构

• 自托管、云和混合部署

• 强大的集成能力

• 高级的配置即代码功能

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

例如，Keylane 的团队发现，TeamCity 中的配置即代码功能比他们在 Bamboo 中使用的更加健壮，其 API 与他们的工作流程集成得更加自然。

将迁移视为过渡，而非一次性切换

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

实际上，迁移往往比这更加迭代。

CI/CD 系统随着时间的推移会积累集成、部署流程、特定环境的逻辑、制品流和操作惯例，其中大部分很少在一个地方进行记录。当团队开始将工作负载迁移到新平台时，这些依赖关系才会变得明显。

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

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

如上所述，Keylane 的迁移遵循了相同的模式。团队并未重新创建其现有工作流程，而是利用这次过渡来审查依赖项、简化构建链，并重新设计其交付过程中最难维护的部分。

这种经历并不罕见。许多团队发现，迁移过程中最有价值的成果与其说是新平台本身，不如说是迁移过程中所做出的决策：淘汰过时的任务，减少不必要的复杂性，统一环境，改进配置管理，或者明确关键交付工作流程的所有权。

因此，通常值得在一段时间内将旧系统和新系统并行运行。

并行运行可以让你有机会比较输出结果，验证行为，并在迁移关键工作负载之前建立信心。同时，它也为团队提供了改进工作流程的机会，而不是简单地一对一地进行转换。

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

最后的一些想法

Bamboo 的生命周期结束设定了一个截止日期，但更有用的问题是，你希望五年后运行什么样的交付平台。

那些真正带来回报的迁移，通常不是最快的那些。而是那些利用这个截止日期作为简化工作流程、质疑旧有假设、并修复多年来悄然损坏的流水线部分的迁移。

无论你用什么来替代 Bamboo，目标不仅仅是匹配它的功能。目标是建立一个你的团队不会很快再次需要迁移的系统。

CICD

• 分享

• Facebook

• Twitter

• Linkedin

上一篇

TeamCity 2026.1.1 现已发布