背景

持续集成和持续部署这两个术语倾向于组合成首字母缩略词CI / CD，通常两者之间没有任何区别。由此可以很容易地假设持续部署是持续集成的扩展，并且两个过程的执行都是单个工具的责任。

假设CI / CD 只是具有部署步骤的CI，则忽略了两个进程之间的一些基本差异。在文中，我们将看看：

• CI和CD是不同流程的原因。
• 优秀的CD工具提供的功能。
• 为什么您可以考虑为CI / CD工作流程使用单独的工具。

什么是持续集成？

在高层次上，CI就是将开发人员编写的代码编译打包，运行自动化测试并捕获日志文件，以便解决任何失败的构建或测试。CI服务器通过在每次提交时运行构建和测试来实现此过程。

CI过程可以描述为等式：

代码+依赖项+构建工具+执行环境=测试结果+日志+编译包

等式的左边是开发人员编写的代码，代码的任何依赖关系，构建工具以及执行构建和测试的环境。当这些输入可用时，CI服务器完成构建以生成等式右侧的元素。

正确配置CI服务器后，对存储库的每次提交都会导致构建正在运行，从而解决方程式而无需人工干预。

这意味着CI过程是机器驱动的，因此CI服务器通常具有只读用户界面，如Jenkins Blue Ocean UI。

CI方程的另一个重要方面是开发人员提供输入，并为开发人员或其他技术角色的人员创建输出。IT部门以外的员工很少与CI服务器交互。

什么是持续部署？

从字面上看，CD从CI服务器执行的成功构建中获取编译的包，并将它们部署到生产环境中。在这种情况下，CD完全正确地是CI的扩展，并且两者之间的区别变得简单。

这种提交到消费者的管道在简单的项目中很常见。只要已经建立了适当的测试和监控系统，更复杂的项目也可以拥有完全自动化的开发流程。

但是，虽然完全自动化部署具有许多优点，但部署涉及人为决策的情况并不少见。有许多正当理由不能自动将每个提交到主分支的部署到生产中，包括：

• 从产品所有者处获得人工批准。
• 可用性测试，不可能自动化。
• 企业内部要求。
• 遇到一些配置技术问题
• 对测试没有100％的信心。

CI是机器驱动的，对于许多团队而言，CD是人为驱动的。执行部署的大部分工作仍然是自动化的，但是促进从发布到生产的决定是人为的。重要的是，技术人员可能不会做出决定，而是产品所有者，经理或熬夜到午夜点击部署按钮的人。

为什么要使用单独的CI和CD工具？

这是一个典型的例子，说明简单的项目如何将CI和CD合并到一个流程中，一旦编译完代码就开始生产部署。

这个过程没有任何问题，只要管道的每个部分都保持完全自动化，它就可以按预期工作。但是，如果人需要在应用程序发布之前测试并批准该应用程序，会发生什么？

要做出此决定，必须中断部署过程。例如，我们首先将应用程序部署到测试环境，允许相关方验证更改，并且当每个人都满意时，将版本提升为生产。

这个单一决策点意味着我们曾经的机器驱动方程式：

• 需要提供操作界面，对测试环境进行的发布。
• 需要提供操作界面显示审计和安全问题，以便我们可以限制并审查谁将哪些版本推广到哪些环境。
• 需要提供操作界面，以允许将部署提升到下一个环境。
• 需要提供操作界面和操作API和日志宝贝界面，可靠地保护和管理操作。

面板与手动部署按钮。

当CI / CD被呈现为仅在编译代码之后自动执行的部署步骤时，这种对人为干预的关注经常丢失。

例如：Jenkins文档建议将测试和生产环境建模为CI管道中的阶段。

乍一看，这个例子似乎为人工审核部署提供了一个过程，但是从未考虑将其推向生产的构建会发生什么？在应用程序向客户公开之前，此类构建将被取消，从而导致构建失败。这些失败的构建很难与未能编译或未通过测试的构建区分开来，即使在此实例中未提升到生产是CD过程的预期行为。

简而言之，一个好的CD工具可以提高人工决策过程，这种过程对于部署来说是如此常见（如果不是必不可少的话），或者至少是环境之间部署的当前状态，并使部署自动化。

认识到机器驱动的CI流程和人工驱动的CD流程之间的不同要求，对于以快速，可靠和可重复的方式向客户交付功能至关重要，这就是为什么使用专用工具进行持续集成和持续部署，提高效率。

快乐的部署！