如何设置持续集成

并非所有测试都是相等的，您可以直观地看待使用 Mike Cohn 开发的测试金字塔所做的权衡。

来源

单元测试实现起来既快又便宜，因为它们主要是对一小段代码进行检查。另一方面，用户界面测试实施起来很复杂，运行速度很慢，因为它们通常需要启动一个完整的环境以及多个服务来模拟浏览器或移动行为。因此，您可能需要限制复杂的用户界面测试的数量，并依靠基础上良好的单元测试来快速构建并尽快获得开发人员的反馈。

要采用持续集成，您需要对推送回主分支的每一项变更进行测试。为此，您需要有一个可以监控您的存储库并监听对代码库的新推送的服务。您可以从本地和云端选择许多解决方案。在选择服务器时，您需要考虑以下几点：

• 您的代码托管在哪里？CI 服务可以访问您的代码库吗？您对代码的存放位置有特殊限制吗？
• 您的应用需要什么操作系统和资源？是否支持您的应用环境？您能安装正确的依赖关系来构建和测试您的软件吗？
• 您的测试需要多少资源？某些 Cloud 应用可能对您可以使用的资源有限制。如果您的软件消耗大量资源，则可能需要将 CI 服务器托管在防火墙后面。
• 您的团队共有多少开发人员？当您的团队练习 CI 时，每天都会将许多变更推送回主存储库。为了让开发人员快速获得反馈，您需要减少构建的队列时间，并且您需要使用能为您提供正确并发性的服务或服务器。

过去，您通常需要安装一个单独的 CI 服务器，例如 Bamboo 或 Jenkins，但现在您可以在 Cloud 找到更容易采用的解决方案。例如，如果您的代码托管在 Bitbucket Cloud 上，则可以使用存储库中的 Pipelines 功能在每次推送时运行测试，无需配置单独的服务器或构建代理，也不会限制并发性。

使用 Bitbucket Pipelines 测试 Javascript 存储库的配置示例。

一旦您采用了自动测试，最好将其与测试覆盖率工具结合使用，这样您就可以知道您的测试套件覆盖了多少代码库。

最好将覆盖率定在 80％ 以上，但要注意不要将高覆盖率与好的测试套件混为一谈。代码覆盖工具可以帮助您找到未测试的代码，但归根结底，您的测试质量才会有所作为。

如果您刚刚起步，不要急于实现代码库的 100％ 覆盖率，而是使用测试覆盖率工具来找出应用中尚未进行测试的关键部分，然后从那里开始。

虽然自动化测试是 CI 的关键部分，但它本身还不够。您可能需要改变团队文化，以确保开发人员如果不将他们的变更合并回主分支，就不会花几天时间在某项功能上工作，而且您需要强制推行绿色构建文化。

您现在应该对持续集成背后的概念有了很好的了解，我们可以将其归结为：

1. 开始为代码库的关键部分编写测试。
2. 获取 CI 服务，在每次推送到主存储库时自动运行这些测试。
3. 确保您的团队每天集成他们的变更。
4. 一旦版本损坏，就立即修复。
5. 为您实现的每个新故事编写测试。

虽然看起来很简单，但需要您的团队做出真正的提交才能发挥作用。一开始您需要放慢发布速度，并且需要产品负责人的支持，以确保他们不会在没有测试的情况下催促开发人员发布功能。

我们的建议是从小处着手，先进行简单的测试，以适应新的例程，然后再实施可能难以管理的更复杂的测试套件。

了解与 Bitbucket Pipelines 的持续集成。而且，如果您想构建 DevOps 工具链，请务必查阅 Open DevOps，其中包括与领先供应商和 Marketplace 应用的集成。