如何设置持续集成
了解如何通过 5 个步骤采用持续集成和自动测试。
Sten Pittet
特约作家
持续集成 (CI) 是一种敏捷的 DevOps 最佳实践，开发人员可以尽早将其代码变更集成到主分支或代码存储库中。目标是通过等待项目或冲刺结束合并所有开发人员的工作来降低出现“集成地狱”的风险。由于它可以自动部署，因此可以帮助团队满足业务需求，提高代码质量并提高安全性。
采用 CI 的主要好处之一是，它可以及早发现和解决冲突，从而节省您在开发周期中的时间。这也是通过更加重视拥有一个好的测试套件来减少修复错误和回归所花费时间的好方法。最后，它有助于更好地了解您正在为客户开发的代码库和功能。
持续集成之旅的第一步：设置自动测试。
开始使用自动化测试
了解不同类型的测试
要获得 CI 的全部好处，您将需要自动化测试，以便能够针对主存储库所做的每一次变更运行测试。我们坚持要在存储库的每个分支上运行测试，而不仅仅是关注主分支。这样，您将能够尽早发现问题并最大限度地减少对团队的干扰。
已经实施了许多类型的测试，但如果您刚刚入门，则不必一次性完成所有测试。您可以从小规模的单元测试开始，然后随着时间的推移努力扩大覆盖范围。
- 单元测试范围狭窄，通常会验证单个方法或功能的行为。
- 集成测试可确保多个组件一起正常运行。这可能涉及多个类以及测试与其他服务的集成。
- 验收测试与集成测试类似，但它们侧重于业务案例而不是组件本身。
- 用户界面测试将确保应用从用户的角度正常运行。
查看解决方案
使用 Open DevOps 构建和操作软件
相关资料
了解有关自动测试的信息
并非所有测试都是相等的，您可以直观地看待使用 Mike Cohn 开发的测试金字塔所做的权衡。
单元测试实现起来既快又便宜，因为它们主要是对一小段代码进行检查。另一方面，用户界面测试实施起来很复杂，运行速度很慢，因为它们通常需要启动一个完整的环境以及多个服务来模拟浏览器或移动行为。因此，您可能需要限制复杂的用户界面测试的数量，并依靠基础上良好的单元测试来快速构建并尽快获得开发人员的反馈。
自动运行测试
要采用持续集成，您需要对推送回主分支的每一项变更进行测试。为此，您需要有一个可以监控您的存储库并监听对代码库的新推送的服务。您可以从本地和云端选择许多解决方案。在选择服务器时，您需要考虑以下几点：
- 您的代码托管在哪里？CI 服务可以访问您的代码库吗？您对代码的存放位置有特殊限制吗？
- 您的应用需要什么操作系统和资源？是否支持您的应用环境？您能安装正确的依赖关系来构建和测试您的软件吗？
- 您的测试需要多少资源？某些 Cloud 应用可能对您可以使用的资源有限制。如果您的软件消耗大量资源，则可能需要将 CI 服务器托管在防火墙后面。
- 您的团队共有多少开发人员？当您的团队练习 CI 时，每天都会将许多变更推送回主存储库。为了让开发人员快速获得反馈，您需要减少构建的队列时间，并且您需要使用能为您提供正确并发性的服务或服务器。
过去，您通常需要安装一个单独的 CI 服务器，例如 Bamboo 或 Jenkins，但现在您可以在 Cloud 找到更容易采用的解决方案。例如，如果您的代码托管在 Bitbucket Cloud 上，则可以使用存储库中的 Pipelines 功能在每次推送时运行测试，无需配置单独的服务器或构建代理，也不会限制并发性。
image: node:4.6.0 pipelines: default: - step: script: - npm install - npm test使用 Bitbucket Pipelines 测试 Javascript 存储库的配置示例。
使用代码覆盖率查找未经测试的代码
一旦您采用了自动测试，最好将其与测试覆盖率工具结合使用，这样您就可以知道您的测试套件覆盖了多少代码库。
最好将覆盖率定在 80％ 以上，但要注意不要将高覆盖率与好的测试套件混为一谈。代码覆盖工具可以帮助您找到未测试的代码，但归根结底，您的测试质量才会有所作为。
如果您刚刚起步，不要急于实现代码库的 100％ 覆盖率，而是使用测试覆盖率工具来找出应用中尚未进行测试的关键部分，然后从那里开始。
重构是添加测试的机会
如果您要对应用进行重大变更，则应首先围绕可能受到影响的功能编写验收测试。这将为您提供一个安全网，确保在您重构代码或添加新功能后，原始行为不会受到影响。
采用持续集成时的关键成功因素
虽然自动化测试是 CI 的关键部分，但它本身还不够。您可能需要改变团队文化，以确保开发人员如果不将他们的变更合并回主分支，就不会花几天时间在某项功能上工作，而且您需要强制推行绿色构建文化。
尽早且经常整合
无论您使用的是基于主干的开发还是功能分支，开发人员都必须尽快将他们的变更集成到主存储库中。如果您让代码在分支或开发人员工作站上停留的时间过长，那么当您决定将内容合并回主分支时，就会面临冲突太多而无法考虑的风险。
通过尽早集成，可以缩小变更的范围，从而在出现冲突时更容易理解冲突。另一个优势是可以更轻松地在开发人员之间共享知识，因为他们将获得更易于理解的变更。
如果您发现自己做了一些可能影响现有功能的变更，则可以使用功能标记关闭生产中的变更，直到工作完成。
始终保持绿色构建
如果开发人员破坏了主分支的构建，则修复它成为主要优先事项。版本被破坏时进入版本的变更越多，就越难了解是什么破坏了版本，而且还有引入更多失败的风险。
值得花时间在测试套件上，以确保它可以快速失败，并尽快向推送变更的开发人员提供反馈。您可以拆分测试，以便在长期运行的测试之前运行快速测试（例如单元测试）。如果您的测试套件总是需要很长时间才能失败，那会浪费大量的开发人员时间，因为他们必须切换上下文才能回到之前的工作并修复。
别忘了设置通知，以确保开发人员在构建中断时收到提醒，您还可以更进一步，在所有人都可以看到的仪表板上显示主分支的状态。
编写测试作为故事的一部分
最后，您需要确保开发的每个功能都经过自动测试。看起来您可能会减慢开发速度，但实际上，这将大大减少您的团队在修复每次迭代中引入的回归或错误上花费的时间。您还可以放心地对代码库进行变更，因为您的测试套件将能够快速确保所有以前开发的功能都能按预期运行。
要编写好的测试，您需要确保开发人员尽早参与用户故事的定义。这是更好地了解业务需求并促进与产品经理关系的绝佳方法。您甚至可以在实现完成测试的代码之前先编写测试。
修复错误时编写测试
无论您已有代码库还是刚刚起步，发布版本时肯定会出现错误。确保在解决问题时添加测试，以防止它们再次发生。
CI 将使您的 QA 工程师能够提高质量
随着 CI 和自动化的采用，另一个角色将发生变化，那就是 QA 工程师的角色。他们不再需要手动测试应用微不足道的功能，现在他们可以将更多时间用于提供工具来支持开发人员并帮助他们采用正确的测试策略。
一旦您开始采用持续集成，您的 QA 工程师将能够专注于使用更好的工具和数据集来促进测试，并帮助开发人员提高编写更好代码的能力。对于复杂的用例，仍会有一些探索性测试，但这应该是他们工作中不太突出的部分。
设置持续集成的五大步骤
您现在应该对持续集成背后的概念有了很好的了解，我们可以将其归结为：
- 开始为代码库的关键部分编写测试。
- 获取 CI 服务，在每次推送到主存储库时自动运行这些测试。
- 确保您的团队每天集成他们的变更。
- 一旦版本损坏，就立即修复。
- 为您实现的每个新故事编写测试。
虽然看起来很简单，但需要您的团队做出真正的提交才能发挥作用。一开始您需要放慢发布速度，并且需要产品负责人的支持，以确保他们不会在没有测试的情况下催促开发人员发布功能。
我们的建议是从小处着手，先进行简单的测试，以适应新的例程，然后再实施可能难以管理的更复杂的测试套件。
了解与 Bitbucket Pipelines 的持续集成。而且，如果您想构建 DevOps 工具链，请务必查阅 Open DevOps，其中包括与领先供应商和 Marketplace 应用的集成。
分享这篇文章
下一个主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
DevOps 社区
阅读博客文章
