本文翻译自文章 Top 5 Reasons for CI Failure，主要介绍了 CI 失败的五个原因，包括 CI 服务的错误选择、CI 工程师的不专业性、随意更改 CI 服务器配置、CI 服务器性能差、缺乏管理等。由 flow.ci－Meng 编译整理。

---

敏捷开发不可能完美，必须有 CI 实践的助力。CI 是持续进行分析、构建、测试和部署的自动化流程，在正式发布到生产环境之前，CI 会检查代码质量和测试产品的业务逻辑。

理想情况下，在构建失败时不能让项目或软件部署到生产环境。但是，持续集成的理念并不被每一个敏捷团队适用。一些敏捷团队非常重视 CI 实践，有的只是为了做敏捷而做，而有些团队完全忽视 CI，更有甚者从未配置过 CI 服务器。

在团队中导致 CI 实践被忽视有各种原因。 我们都知道企业具有不同的优先级，产品经理可能并不理解内部质量、测试流程和完整构建的重要性。 技术经理不能分配时间来实施 CI 实践或修复出现问题的 CI 系统。 产品和技术经理无法了解彼此的优先级，导致部署了一个失败的产品交付给终端用户，并传递了一个非常糟糕的商业价值。

这种方法看似没有问题，但其实非常危险。可能不久的将来会导致严重的产品缺陷，从而严重影响业务运作。这种影响是不可预知的，一开始是金钱的损失，直至影响到企业声誉，最后可能直接导致整个业务完全失败。

然而，即使产品经理和技术团队同意投入更多的时间和金钱实施或修复 CI 问题，一些团队仍未成功。 这篇文章我们讨论了 CI 失败的五大原因，并提供一些潜在解决方案，希望能够帮助你。

1. CI 服务的错误选择

市场上有各种持续集成工具，CI 服务器解决方案可以是本地搭建也可以云端托管。这里列出了一堆的CI 服务器解决方案。

Jenkins 是目前流行的 CI 服务器之一，大家都倾向于盲目使用它。为了使用 Jenkins 的服务，我们不得不调整项目。现在，市场上出现了一些不错的 CI 服务 (国内如 flow.ci)，选择适合自己适合需求的 CI 服务确实是一个挑战。

推荐解决方案：

• 仔细调研市场并通过实验权衡各种需求，Slant 上已经对主流的各种 CI 产品进行了很详细的优劣评估，可参考一下；

• 关注特性，例如管道支持，容器支持，平台支持，易用型，可用性等等；

• 不要为了节省开支而选择一款通用的适应所有平台的 CI 产品，每个平台都有不同的技术需求和挑战；

• 和团队讨论并借鉴过去的经验。

2. 业余的 CI 工程师

敏捷团队的工程师应该具有出色的编码能力，但仅仅写代码和测试代码是不够的，还涉及搭建配置环境的能力，运行命令行和编写脚本的技能，还要有对自动化构建工具和依赖/包管理工具的知识储备。

最近，很多公司开始把基础设施​​转移到云端，所以还需要学习 DevOps 的技能，比如 AWS，Azure 和 Heroku 等云服务。配置工具，如 bash，Ansible 和 Chef；以及 Docker 和 Kubernetes 等容器服务。最重要的是掌握至少一种脚本语言，即 Bash，Ruby 或 Python。

这并不意味着你应该学习世界上的所有东西，但你需要了解平台上的东西。假设一名 iOS 开发工程师，可能需要知道 Cocoapods，Carthage 和 Swift 等依赖管理工具。

还有用于构建的自动化工具，如在 APPLE 命令行工具之上的 Fastlane，Rake 和 Make，并关注最新技术发展。

每个工程师都会有擅长的东西，有的擅长编写基本编程代码（即 Java，Objective-C 和 Swift），并对 DevOps 相关的构建自动化工具非常熟悉。有的工程师习惯于使用 IDE 环境开发（比如 Eclipse、IntelliJ 和 Xcode），有些工程师擅长构建工具但写程序代码则弱一些。

这里说的 CI 业余工程师是那些无法脱离 IDE，不会使用命令行和脚本工具的人。他们只喜欢 GUI 工具，拒绝使用命令行或脚本。但是，CI 服务器并没有 GUI 界面，所有的流程必须通过脚本完成。

如果你的团队有这类人，那 CI 实践永远不会成功。 他们可能写出一些低质量的自动化脚本，大家的时间都浪费在改进构建自动化以及 CI 服务器之间的切换上，而不是真正构建对业务有用的功能。

推荐解决方案：

• 招聘具有 CI 和 DevOps 基础知识的工程师；

• 培养 CI 业余工程师，最好的办法是去外部培训或者请内部有经验的 CI 专家培训；

• 短期招聘一些 CI 专家来建立 CI 流程和分享经验。

3. 随意更改 CI 服务器配置

大多数的 CI 服务器允许用户通过 Web 界面更改构建的配置。 这种方法使工程师轻松创建和编辑 CI 工作流。 但是经常更改构建配置可能会产生很多问题，例如忽略的一些重要的构建步骤。 还有，每个人都有访问构建机器的权限，这可能会导致混乱， 搞不清楚谁在什么时间做了什么更改。当互相不知道更改配置的内容，可能需要花费很长时间才能定位到构建失败的原因。频繁更改 CI 服务器可能会导致团队内的混乱。

推荐解决方案：

• 配置文件，bash 脚本或其他相关的文件放在代码库中集中管理；
• 避免手动更改 CI 服务器上；
• 控制 CI 服务器的访问权限，并由专人负责管理；
• 不允许用户修改特定的构建步骤；

4. CI 服务器性能差

在项目开发过程中，开发人员经常需要更新代码，这会触发 CI 服务器上的构建流程。 这意味着 CI 服务器需要持续运行大量任务，例如从远程服务器下载相关文件，备份数据库，运行 Docker 容器等，因此 CI 服务器必须快速可靠 ，并且稳定。 性能差的 CI 服务器不但浪费大家的构建时间，导致测试结果断断续续，也会影响让工程师们士气沮丧。

推荐解决方案：

• 选择更好更高配的服务器；
• 不要把 CI 服务器挂在 Wifi 上；
• 不要在 CI 服务器上安装不必要的软件；
• 科学调度 CI 服务器资源；
• 不要手动安装任何软件；
• 避免使用 GUI 访问机器，使用 SSH 访问即可。

5. 缺乏管理

项目管理在整个 CI 实施中起着关键作用，必须对整个构建流程设定严格的指引，同时对任何不遵守指引的行为零容忍。在任何情况下都不能发布 CI 流程中断的软件。任何构建中断都要被视为紧急事件并以最高优先级进行修复。很多技术经理可以做到这一点，但一些没有 CI 经验的管理人员可能会命令继续开发而不顾代码质量。在这样的管理下，CI 实施不可能成功。

推荐解决方案：

• 建立团队的 CI 流程并严格执行；
• 培训项目经理并用于 CI 实施。

结语

在敏捷团队中实施 CI 是非常有挑战的，但遵循一些严格的规则并避免常见错误更有效地实施 CI 流程。你在 CI 实践中有什么样的经验？你觉得 CI 流程有效吗？欢迎分享你的观点！

---

flow.ci ，融入了 workflow 机制的持续集成（CI）服务，也可以理解为自动化流程平台，除了集成代码、编译、测试之外，还可以集成常用的工具、灵活自定义流程。本文由 flow.ci－Meng 翻译整理，想阅读更多技术文章，请访问 flow.ci 官方技术博客。