持续集成和持续部署这两个术语倾向于组合成首字母缩略词CI / CD,通常两者之间没有任何区别。由此可以很容易地假设持续部署是持续集成的扩展,并且两个过程的执行都是单个工具的责任。
假设CI / CD 只是具有部署步骤的CI,则忽略了两个进程之间的一些基本差异。在文中,我们将看看:
在高层次上,CI就是将开发人员编写的代码编译打包,运行自动化测试并捕获日志文件,以便解决任何失败的构建或测试。CI服务器通过在每次提交时运行构建和测试来实现此过程。
CI过程可以描述为等式:
代码+依赖项+构建工具+执行环境=测试结果+日志+编译包
等式的左边是开发人员编写的代码,代码的任何依赖关系,构建工具以及执行构建和测试的环境。当这些输入可用时,CI服务器完成构建以生成等式右侧的元素。
正确配置CI服务器后,对存储库的每次提交都会导致构建正在运行,从而解决方程式而无需人工干预。
这意味着CI过程是机器驱动的,因此CI服务器通常具有只读用户界面,如Jenkins Blue Ocean UI。
CI方程的另一个重要方面是开发人员提供输入,并为开发人员或其他技术角色的人员创建输出。IT部门以外的员工很少与CI服务器交互。
从字面上看,CD从CI服务器执行的成功构建中获取编译的包,并将它们部署到生产环境中。在这种情况下,CD完全正确地是CI的扩展,并且两者之间的区别变得简单。
这种提交到消费者的管道在简单的项目中很常见。只要已经建立了适当的测试和监控系统,更复杂的项目也可以拥有完全自动化的开发流程。
但是,虽然完全自动化部署具有许多优点,但部署涉及人为决策的情况并不少见。有许多正当理由不能自动将每个提交到主分支的部署到生产中,包括:
CI是机器驱动的,对于许多团队而言,CD是人为驱动的。执行部署的大部分工作仍然是自动化的,但是促进从发布到生产的决定是人为的。重要的是,技术人员可能不会做出决定,而是产品所有者,经理或熬夜到午夜点击部署按钮的人。
为什么要使用单独的CI和CD工具?
这是一个典型的例子,说明简单的项目如何将CI和CD合并到一个流程中,一旦编译完代码就开始生产部署。
这个过程没有任何问题,只要管道的每个部分都保持完全自动化,它就可以按预期工作。但是,如果人需要在应用程序发布之前测试并批准该应用程序,会发生什么?
要做出此决定,必须中断部署过程。例如,我们首先将应用程序部署到测试环境,允许相关方验证更改,并且当每个人都满意时,将版本提升为生产。
这个单一决策点意味着我们曾经的机器驱动方程式:
面板与手动部署按钮。
当CI / CD被呈现为仅在编译代码之后自动执行的部署步骤时,这种对人为干预的关注经常丢失。
例如:Jenkins文档建议将测试和生产环境建模为CI管道中的阶段。
乍一看,这个例子似乎为人工审核部署提供了一个过程,但是从未考虑将其推向生产的构建会发生什么?在应用程序向客户公开之前,此类构建将被取消,从而导致构建失败。这些失败的构建很难与未能编译或未通过测试的构建区分开来,即使在此实例中未提升到生产是CD过程的预期行为。
简而言之,一个好的CD工具可以提高人工决策过程,这种过程对于部署来说是如此常见(如果不是必不可少的话),或者至少是环境之间部署的当前状态,并使部署自动化。
认识到机器驱动的CI流程和人工驱动的CD流程之间的不同要求,对于以快速,可靠和可重复的方式向客户交付功能至关重要,这就是为什么使用专用工具进行持续集成和持续部署,提高效率。
快乐的部署!