简介

持续集成、交付和deployment，，统称为CI/CD，是现代开发的一个组成部分，旨在减少集成和部署期间的错误，同时提高项目速度。CI/CD是一种哲学和一组实践，通常通过强调软件流水线每个阶段的自动化测试的健壮工具来增强。通过将这些想法结合到您的实践中，您可以减少为发布集成更改并在将其移入生产之前彻底测试每个更改所需的时间。

传播和信息/CD有许多潜在的好处，但成功实施往往需要大量考虑。在没有广泛的试验和错误的情况下，准确地决定如何使用这些工具以及在您的流程中可能需要哪些更改可能是具有挑战性的。然而，虽然所有的实现都是不同的，但遵循最佳实践可以帮助您避免常见问题并更快地改进。

在本指南中，我们将介绍一些关于如何实施和维护CI/CD系统以最好地满足您组织的需求的基本指导。我们将介绍一些可帮助您提高CI/CD服务效率的实践。你可以随意阅读，或者直接跳到你感兴趣的领域。

让你的管道保持快速

CI/CD管道帮助引导变更通过自动化测试周期，到试运行环境，最后到生产。您的测试管道越全面，您就越能确信更改不会给您的生产部署带来不可预见的副作用。然而，由于每个更改都必须经过这个过程，因此保持您的管道快速和可靠是非常重要的。

这两个要求之间的紧张关系可能很难平衡。您可以采取一些简单的步骤来提高速度，例如扩展您的CI/CD基础设施和优化测试。然而，随着时间的推移，您可能会被迫做出关于不同测试的相对价值以及它们运行的阶段或顺序的关键决定。有时，通过删除低值或不确定结论的测试来削减测试套件是保持大量使用的管道所需速度的最聪明的方法。

在做出这些重大决定时，请确保您了解并记录您正在做出的权衡。 与团队成员和涉众协商，以调整团队关于测试套件负责什么以及关注的主要领域应该是什么的假设。

隔离和保护您的CI/CD环境

从运营安全的角度来看，您的CI/CD系统代表着一些需要保护的最关键的基础设施。由于CI/CD系统可以完全访问您的代码库和要在各种环境中部署的凭据，因此必须确保其安全。由于其作为目标的价值很高，因此尽可能隔离和锁定您的CI/CD非常重要。

CI/CD系统应部署到内部受保护的网络，不暴露给外部各方。建议设置VPN或其他网络访问控制技术，以确保只有经过身份验证的运营商才能访问您的系统。根据您网络拓扑的复杂程度，您的CI/CD系统可能需要访问几个不同的网络以将代码部署到不同的环境。如果没有适当的保护或隔离，获得对一个环境的访问权限的攻击者可能能够通过CI/CD服务器的弱点获得对其他环境的访问权限。

所需的隔离和安全策略在很大程度上取决于您的网络拓扑、基础设施以及管理和开发需求。 需要记住的重要一点是，您的CI/CD系统是非常有价值的目标，在许多情况下，它们可以广泛访问您的其他重要系统。 屏蔽对服务器的所有外部访问并严格控制允许的内部访问类型将有助于降低CI/CD系统受到危害的风险。

让CI/CD管道成为部署到生产的唯一途径

CI/CD能够改进您的开发实践和代码质量的部分原因是，工具通常有助于执行测试和部署的最佳实践。通过您的CI/CD管道提升代码需要每次更改都要证明它符合您组织的编码标准和程序。CI/CD管道中的故障立即可见，并停止将受影响的版本推进到周期的较后阶段。这是一种守门机制，可保护更重要的环境免受不可信代码的攻击。

然而，要实现这些优势，您需要确保对生产环境的每一次更改都经过您的管道。CI/CD管道应该是代码进入生产环境的唯一机制。这可以在连续部署实践的成功测试结束时自动进行，也可以通过手动升级CI/CD系统批准并提供的已测试更改来实现。

通常，团队开始使用他们的管道进行部署，但在出现问题并面临快速解决问题的压力时，开始例外。虽然停机时间和其他问题应该尽快减少，但重要的是要了解CI/CD系统是一个很好的工具，可以确保您的更改不会引入其他错误或进一步破坏系统。将您的修补程序放入管道中(或仅使用CI/CD系统回滚)还将防止下一次部署擦除直接应用于生产的临时修补程序。无论这是常规的、计划的版本，还是解决持续问题的快速修复，管道都可以保护您部署的有效性。CI/CD系统的这种使用是努力[保持您的管道快速](# 保持您的管道-快速)的另一个原因。

尽可能保持与生产持平

CI/CD管道通过一系列测试套件和部署环境促进更改。通过一个阶段要求的更改要么自动部署，要么排队等待手动部署到更严格的环境中。早期阶段的目的是证明继续测试并将更改推向生产是值得的。

尤其是在后期阶段，在测试环境中尽可能接近地再现生产环境有助于确保测试准确地反映更改在生产中的行为。试运行和生产之间的显著差异可能会允许发布在测试中从未观察到错误的有问题的更改。您的实际环境和测试环境之间的差异越大，您的测试就越不能衡量代码在发布时的执行情况。

试运行和生产之间的一些差异是意料之中的，但保持它们的可控性并确保它们被很好地理解是至关重要的。一些组织使用蓝绿色deployments]在两个几乎相同的环境之间交换生产流量，这两个环境在指定生产和转储之间交替。不那么极端的策略包括将相同的配置和基础设施从生产部署到您的临时环境，但规模较小。像网络终结点这样的项目在您的环境中可能有所不同，但这种类型的变量数据的参数化有助于确保代码的一致性和环境差异的明确定义。

只需搭建一次，通过管道推广效果

CI/CD渠道的主要目标是建立对您的更改的信心，并将意外影响的可能性降至最低。我们讨论了在不同环境之间保持对等的重要性，但其中有一个部分非常重要，需要额外注意。如果您的软件需要构建、打包或捆绑步骤，则该步骤应该只执行一次，并且结果输出应该在整个流水线中重复使用。

该指导原则有助于防止在多次编译或打包软件时出现的问题，允许将轻微的不一致注入到结果构件中。在每个新阶段单独构建软件可能意味着，早期环境中的测试不是针对稍后部署的相同软件，从而使结果无效。

为了避免这个问题，CI系统应该包括一个构建过程，作为在一个干净的环境中创建和打包软件的管道的第一步。生成的构件应该被版本化并上载到构件存储系统，以便由流水线的后续阶段拉下，以确保构建不会随着它在系统中的进展而改变。

尽早运行您最快的测试

虽然保持整个流水线的速度是一个很好的总体目标，但测试套件的某些部分将不可避免地比其他部分更快。由于CI/CD系统充当进入系统的所有更改的管道，因此尽早发现故障对于最大限度地减少用于有问题的构建的资源非常重要。要实现这一点，首先确定优先级并运行最快的测试。将复杂的、长时间运行的测试保存到使用较小的、快速运行的测试验证构建之后。

这一策略有许多好处，可以帮助您保持CI/CD过程的健康。它鼓励您了解单个测试的性能影响，允许您提前完成大多数测试，并增加快速失败的可能性，这意味着有问题的更改可以在阻止其他成员的工作之前恢复或修复。

测试优先级通常意味着首先运行项目的单元测试，因为这些测试往往是快速的、独立的和专注于组件的。之后，集成测试通常代表下一级的复杂性和速度，然后是系统范围的测试，最后是验收测试，这通常需要一定级别的人工交互。

尽量减少版本控制系统中的分支

CI/CD的主要原则之一是尽早并经常将更改集成到主共享存储库中。当多个开发人员试图将大的、不同的和冲突的更改合并到存储库的主分支中以准备发布时，这有助于避免代价高昂的集成问题。通常，CI/CD系统被设置为仅监视和测试提交给一个或几个分支机构的更改。

要利用CI提供的好处，最好限制存储库中分支的数量和范围。大多数实现建议开发人员至少每天一次直接提交到主分支或合并来自本地分支的更改。

本质上，您的CI/CD系统没有跟踪的分支包含未测试的代码，这些代码应该被视为项目成功和势头的隐患。尽量减少分支以鼓励不同开发人员代码的早期集成有助于利用系统的优势，并防止开发人员否定其提供的优势。

提交到CI/CD管道之前在本地运行测试

与前面关于及早发现故障的观点相关，应该鼓励开发人员在提交到共享存储库之前在本地运行一些测试。这使得在某些有问题的更改阻止其他团队成员之前检测到这些更改成为可能。虽然本地开发人员环境不太可能能够在类似生产的环境中运行整个测试套件，但这一额外的步骤让个人更有信心，他们正在进行的更改通过了基本测试，值得尝试与更大的代码库集成。

为了确保开发人员能够有效地自己进行测试，您的测试套件应该可以使用可以在任何环境中运行的单个命令来运行。CI/CD系统应该使用开发人员在其本地计算机上使用的相同命令来启动对合并到存储库的代码的测试。通常，这是通过提供一个外壳脚本或Makefile来协调的，以便以可重复、可预测的方式自动运行测试工具。

尽可能在瞬息万变的环境中运行测试

为了帮助确保您的测试在不同阶段运行相同，尽可能使用干净、短暂的测试环境通常是个好主意。通常，这意味着在容器中运行测试以抽象主机系统之间的差异，并提供用于将各种规模的组件挂钩在一起的标准API。由于容器在最小状态下运行，测试的残留副作用不会被测试套件的后续运行继承，这可能会影响结果。

容器化测试环境的另一个好处是测试基础设施的可移植性。有了容器，开发人员可以更轻松地复制稍后将在管道中使用的配置，而不必手动设置和维护基础设施或牺牲环境保真度。由于容器可以在需要时很容易地旋转起来，然后销毁，因此用户在运行本地测试时可以在测试环境的准确性方面做出更少的妥协。通常，使用容器会锁定运行时环境的某些方面，以帮助最小化管道阶段之间的差异。

结论

虽然每个CI/CD实现将是不同的，但遵循其中一些基本原则将帮助您避免一些常见的陷阱，并加强您的测试和开发实践。与持续集成的大多数方面一样，过程、工具和习惯的混合将有助于使开发更改更成功和更有影响力。

要了解有关一般CI/CD实践以及如何设置各种CI/CD服务的更多信息，请查看其他CI/CD tag.文章