什么是持续集成 源程序量( 二 )


这些作业被用于一个或多个功能(构建、测试、部署等) 。每个作业可能使用不同的技术或多种技术 。关键是作业是自动化的、高效的,并且可重复的 。如果作业成功,则工作流管理器将触发管道中的下一个作业 。如果作业失败,工作流管理器会向开发人员、测试人员和其他人发出警报,以便他们尽快纠正问题 。这个过程是自动化的,所以比手动运行一组过程可更快地找到错误 。这种快速排错称为 快速失败(fail fast),并且在抵达管道端点方面同样有价值 。
“快速失败”是什么意思?管道的工作之一就是快速处理变更 。另一个是监视创建发布的不同任务/作业 。由于编译失败或测试未通过的代码可以阻止管道继续运行,因此快速通知用户此类情况非常重要 。快速失败指的是在管道流程中尽快发现问题并快速通知用户的方式,这样可以及时修正问题并重新提交代码以便使管道再次运行 。通常在管道流程中可通过查看历史记录来确定是谁做了那次修改并通知此人及其团队 。
所有持续交付管道都应该被自动化吗?管道的几乎所有部分都是应该自动化的 。对于某些部分,有一些人为干预/互动的地方可能是有意义的 。一个例子可能是 用户验收测试(user-acceptance testing)(让最终用户试用软件并确保它能达到他们想要/期望的水平) 。另一种情况可能是部署到生产环境时用户希望拥有更多的人为控制 。当然,如果代码不正确或不能运行,则需要人工干预 。
有了对“持续”含义理解的背景,让我们看看不同类型的持续流程以及它们在软件管道上下文中的含义 。
什么是“持续集成”?持续集成(CI)是在源代码变更后自动检测、拉取、构建和(在大多数情况下)进行单元测试的过程 。持续集成是启动管道的环节(尽管某些预验证 —— 通常称为 上线前检查(pre-flight checks) —— 有时会被归在持续集成之前) 。
持续集成的目标是快速确保开发人员新提交的变更是好的,并且适合在代码库中进一步使用 。
持续集成是如何工作的?持续集成的基本思想是让一个自动化过程监测一个或多个源代码仓库是否有变更 。当变更被推送到仓库时,它会监测到更改、下载副本、构建并运行任何相关的单元测试 。
持续集成如何监测变更?目前,监测程序通常是像 Jenkins 这样的应用程序,它还协调管道中运行的所有(或大多数)进程,监视变更是其功能之一 。监测程序可以以几种不同方式监测变更 。这些包括:
轮询:监测程序反复询问代码管理系统,“代码仓库里有什么我感兴趣的新东西吗?”当代码管理系统有新的变更时,监测程序会“唤醒”并完成其工作以获取新代码并构建/测试它 。定期:监测程序配置为定期启动构建,无论源码是否有变更 。理想情况下,如果没有变更,则不会构建任何新内容,因此这不会增加额外的成本 。推送:这与用于代码管理系统检查的监测程序相反 。在这种情况下,代码管理系统被配置为提交变更到仓库时将“推送”一个通知到监测程序 。最常见的是,这可以以 webhook 的形式完成 —— 在新代码被推送时一个 挂勾(hook)的程序通过互联网向监测程序发送通知 。为此,监测程序必须具有可以通过网络接收 webhook 信息的开放端口 。什么是“预检查”(又称“上线前检查”)?在将代码引入仓库并触发持续集成之前,可以进行其它验证 。这遵循了最佳实践,例如 测试构建(test build)和 代码审查(code review) 。它们通常在代码引入管道之前构建到开发过程中 。但是一些管道也可能将它们作为其监控流程或工作流的一部分 。

推荐阅读