什么是 CI 服务器？
持续集成 (CI) 是一种 DevOps 做法，旨在避免后期集成更改带来的问题：合并冲突和构建错误以及无数的后续错误，且您的软件实际上并未真正满足用户需求。
使用持续集成，您可以随时提交、构建和测试每个人的代码更改。 在整个项目中频繁集成意味着您可以最大限度地减少冲突，了解每个人的更改如何交互，并在错误根深蒂固和被其他功能依赖之前加以解决。
CI forms the first half of a continuous integration and delivery/deployment (CI/CD) pipeline – the ongoing process of committing, building, testing, staging and releasing each change, which delivers feedback at every stage and enables you to constantly iterate and improve.
实现 CI/CD 需要改变文化以实现不同部门之间的协作、采用新流程和工作流，以及自动化相关步骤并启用高效管道的工具。
CI 服务器（或构建服务器）在实现和管理整个流程中发挥着关键作用。 它作为粘合剂，应用您的业务逻辑协调自动化任务并整理和发布反馈，将管道的所有阶段结合在一起。 在本文中，我们将更详细地审视 CI 服务器及其帮助您充分利用 CI/CD 的途径。
与源控制集成
At the start of any CI/CD pipeline is an integration with your version or source control system.
基本实现包括配置 CI/CD 服务器以侦听 master 分支上的提交并在发生更改时触发管道。
虽然这确保了每个提交都经过验证和测试，但也为个人提交破坏构建的内容留下了足够的空间，可能会使过程停止并阻止其他更改得到验证，直到有问题的代码被撤销或修正为止。
将 CI 服务器配置为在提交更改之前构建和测试更改有助于防止此类问题，并可为每个开发者创建额外的反馈循环。
重要的是，构建服务器同时扮演推动者和执行者的角色，负责在远程机器上运行构建和测试，并将结果反馈给个人，但也使该过程成为提交到 master 分支或 feature 分支的条件。
您可能需要考虑的另一个步骤是将 CI 服务器与代码审查工具集成，使每个提交都必须通过代码审查，并在成功构建和测试后才能提交。
在流程开始时强制执行这些额外的业务逻辑层有助于保持代码库干净整洁并为发布做好准备，同时最大限度地减少管道中的中断和延迟。
管理构建
在 CI/CD 管道的构建和测试阶段，您的 CI 服务器是运营的大脑，协调任务并根据各种标准将作业分配到构建代理。
但是，您的构建代理会根据从 CI 服务器收到的指令运行构建和执行测试。
至少在生产设置中，最好将构建服务器与运行构建和执行测试的构建代理区分开，以避免资源争用和性能问题。
当您使用 CI 服务器配置管道阶段的逻辑时，您可以指定一系列详细信息和规则。 例如，您可能希望某些测试对 master 分支的提交运行，但在开发分支的提交前构建上不运行，或者您可能希望控制可以同时调用测试数据库的构建数量。
使用不同的构建代理同时运行某些任务可以使您的管道更加高效。 如果您需要在不同的操作系统上运行测试，或者您在处理包含数十万测试的庞大代码库，且唯一实用的选择是并行化，这将非常有用。 In the latter case, setting up a composite build will aggregate the results so you can treat the tasks as a single build step.
与云托管基础架构（例如 AWS）集成的构建服务器将使您受益于可运行构建和测试的弹性可扩展资源。 如果您的基础架构需求相当大，那么对容器化构建代理的支持以及与 Kubernetes 的集成将使您能够有效管理构建资源，无论其位于云端还是本地。
定义故障
业务逻辑的一大关键部分涉及定义 CI/CD 管道每个阶段的故障构成。
Your CI server should allow you to configure various failure conditions, which it will then apply and use to determine the status of a particular step and whether to proceed to the next stage of the pipeline.
除了不言而喻的故障（例如构建返回错误代码或测试无法执行），您还可以根据构建服务器收集的数据定义其他类型的故障。
示例包括测试覆盖率相对于前一个构建有所减少（表明没有为最新的代码更改添加测试），或者与前一个成功构建相比忽略的测试数量增加。
这些指标可作为代码质量可能恶化的有用警告。 出于这些原因触发故障并限制有权重写这些故障的用户，您可以推动符合预期的行为。
实现持续交付
尽管“CI 服务器”这个名称表明其用途仅限于持续集成，但大多数 CI 服务器也提供对持续交付和部署的支持。
在持续集成阶段生成构建工件并运行一组初始测试后，下一步是将这些工件部署到 QA 环境以进行更高级别的测试，然后进入暂存让利益相关者试用。当没有任何问题后，即可发布上线。
As well as providing an artifact repository to store the outputs from each build so you can deploy them as needed, a CI/CD server can also store and manage parameters for each environment in your pipeline. 然后，您可以指定部署脚本是否根据上一阶段的结果自动触发。
跟踪进度
从每个阶段提供快速反馈是 CI/CD 管道的关键要素。
构建服务器可以提供有关队列中作业、进行中构建和测试的实时报告以及已完成构建步骤的状态的信息。
启用通知，您可以确保您和团队在出现问题时立即知晓，与错误跟踪工具集成意味着您可以查看提交所包含修正的详细信息，并快速深入了解故障原因。 历史数据可以为改进管道以及将条件定义为管道逻辑的一部分提供实用见解。
收尾工作
持续集成服务器在实现 CI/CD 管道、协调和触发流程各步骤以及整理和交付各阶段数据方面发挥着重要作用。 Have a look at our Guide to CI/CD tools for tips on how to choose the right CI server for your organization.