使用 DevOps 指标衡量 CI/CD 性能

CI 服务器充当协调所有 CI/CD 活动的中心点。使用 CI 服务器：

• 确保每次提交都经过 CI/CD：通过与您的 VCS 集成，CI 服务器可以确保所有代码更改都通过您的自动化构建、测试和部署流程 – 个人开发者无需任何额外的工作。
• 允许您协调业务逻辑：从您想强制执行的测试覆盖率水平到自动化测试流程每个阶段的“通过”的定义，CI 服务器为您组织的要求提供单一可信来源。
• 与您的工具链集成：除了您的 VCS 和构建工具外，CI 服务器还可与问题跟踪器和沟通平台集成，以提供来自构建、测试和部署流程的自动动态。
• 维护过去构建的记录：当您需要确定一个特别细微的 bug 进入您的代码库的时间点时，拥有构建工件的归档至关重要。
• 让利益相关者了解发布进度：作为构建和部署状态的中心可信来源，您可以使用您的 CI 服务器让更广泛的组织了解进度。
• 提供更改的审核日志：您的工作流和业务逻辑很可能会随着时间的推移而演变。使用 CI 服务器可以为您提供 CI/CD 流程如何更改的记录，以防您想要恢复到较早的实现。

反过来，使用 CI 服务器将帮助您利用 CI/CD 的诸多优势，包括对您的代码更改的快速反馈、早期 bug 识别和更频繁的发布。

在任何 CI/CD 流水线的起点，您都能找到与版本或源代码控制系统的集成。

通常，CI 服务器配置为侦听特定分支上的提交，并在每次更改时触发流水线的新运行。这样可以确保每次开发者共享其更改时，都会进行构建和测试，以确保整个代码库仍然可以正常运行。

某些 CI 服务器允许您更进一步，并要求开发者在将其更改共享到 CI 分支之前，在本地进行构建和测试。虽然这并不能保证下一步会成功通过，但它有助于减少损坏的构建及其可能导致的延迟。另一种选择是将您的 CI 服务器与您的代码审查工具集成，以便每次提交都必须通过代码审查阶段才能共享。

在流程开始时强制执行这些额外的业务逻辑层有助于保持代码库干净整洁并为发布做好准备，同时最大限度地减少流水线中的中断和延迟。

每次检测到更改并触发流水线运行时，CI 服务器都会协调构建和测试任务。通常，这些任务被分配给专用的构建计算机或“代理”。随后，您的构建代理会根据从 CI 服务器收到的指令运行构建和执行测试。

另一种选择是在 CI 服务器本身上运行构建和测试任务。不过，这可能会导致资源争用并降低繁忙代码库的性能。

当您使用 CI 服务器配置流水线阶段的逻辑时，您可以指定一系列详细信息和规则。例如，您可能希望：

• 在提交到 main 分支时运行所有自动化测试，但在功能分支上运行缩减的检查集。
• 控制有多少构建可以同时调用测试数据库。
• 将部署到暂存环境的次数限制为每周一次，以便进行更复杂的手动测试。

使用不同的构建代理同时运行某些任务可以使您的流水线更加高效。如果您需要在不同的操作系统上运行测试，或者您在处理包含数十万测试的庞大代码库，其中唯一实用的选择是并行化，这将非常有用。在后一种情况下，设置一个复合构建将聚合结果，以便您可以将任务视为一个单独的构建步骤。

与云托管基础架构（例如 AWS）集成的构建服务器将使您受益于可运行构建和测试的弹性可扩展资源。如果您的基础架构需求相当大，那么对容器化构建代理的支持以及与 Kubernetes 的集成将使您能够有效管理构建资源，无论其位于云端还是本地。

业务逻辑的一大关键部分涉及定义 CI/CD 流水线每个阶段的故障构成。

您的 CI 服务器应允许您配置各种失败条件。随后，它会检查是否已满足这些条件，以确定特定步骤的状态并决定是否继续进行流水线的下一阶段。

除了不言而喻的故障（例如构建返回错误代码或测试无法执行），您还可以根据构建服务器收集的数据定义其他失败条件。

示例包括测试覆盖率相对于上一个构建有所减小（表明没有为最新的代码更改添加测试），或者与上一个成功构建相比忽略的测试数量增加。

当代码质量可能恶化时，这些指标还可以作为有用警告。出于这些原因触发故障并限制有权重写这些故障的用户，您可以推动符合预期的行为。

当更改成功时，CI 服务器会存储构建流程的工件。这些工件可能包括二进制文件、安装程序、容器镜像，以及部署您的软件所需的任何其他资源。

随后，您可以将相同的工件部署到预生产环境中进行进一步测试，然后再最终部署到生产环境中。这样可以确保相同的输出在每个阶段都进行测试，并且比在每次部署之前从源代码重新构建更加可靠。特别是，它可以避免缺失依赖项和引入其他不一致的风险。

当您需要恢复到以前版本的软件或尝试确定特定问题何时引入时，维护成功构建的工件仓库也十分有用。

尽管“CI 服务器”这个名称表明其用途仅限于持续集成，但大多数 CI 服务器也提供对持续交付和部署的支持。

在持续集成阶段生成构建工件并运行一组初始测试后，下一步是将这些工件部署到 QA 环境以进行进一步的测试。接下来是暂存，此阶段让您的利益相关者有机会试用新构建。随后，如果一切看起来都正常工作，您通常会继续将其发布到实际环境。

您可以使用 CI 服务器来存储和管理流水线中每个环境的参数。这样，您就可以指定部署脚本是否根据上一阶段的结果自动触发。

CI 服务器的一个核心功能是在构建和测试的每个阶段提供快速反馈。与您的 IDE 或沟通平台集成的 CI 服务器可以在您的更改导致流水线失败时通知您，而无需您持续监测其进度。

构建服务器还可以：

• 提供正在进行的构建和测试的实时报告，并通知您已完成的构建步骤的状态。
• 与问题跟踪工具集成，以便您可以查看提交中包含的修正的详细信息，并快速调查失败的原因。
• 整理有关部署频率、下一次失败的时间以及平均解决时间的统计信息，以帮助您衡量和改进您的开发流程。
• 深入分析您的 CI 服务器和构建计算机的使用情况和性能，您可以利用这些信息优化您的流水线。

构建您自己的 CI 服务器听起来可能是一个极具吸引力的选择。通过设计自己的解决方案，您可以在避免任何许可证费用的同时根据自身的需求进行定制。

不过，构建自定义工具只是流程的开始。一旦部署到位，您将需要投入时间来使其保持最新状态 – 包括解决出现的任何 bug 以及随着需求的演变而开发新功能。

此外，还值得考虑将 CI 服务器与您的工具链集成所涉及的工作量。虽然您的初始设计支持您当前使用的版本控制系统、问题跟踪器、构建工具和测试框架，但当您切换到新产品或技术时会发生什么？

虽然构建您自己的 CI 服务器使您可以灵活地创建针对您的用例量身定制的工具，但初始工作和持续维护需要大量且不间断的投入。

TeamCity 是一种 CI 服务器，可与所有领先的版本控制系统（包括 Git、Perforce、Mercurial 和 Subversion）以及各种托管服务集成。您还会发现对各种构建工具和测试框架的广泛支持，以及与 IDE、问题跟踪器、即时通讯平台和容器管理器的集成。

您可以在本地或使用 TeamCity Professional 或 TeamCity Enterprise 在您选择的云中托管您的 CI 服务器，或者选择 TeamCity Cloud 以实现全托管式解决方案。一套灵活的流水线触发器允许您配置 CI/CD 流程以满足您的需求，包括预测试提交、功能分支支持和定时构建。通过 UI 配置流水线逻辑后，您可以将配置存储为代码，以实现完全版本控制的 CI/CD 流程。