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


持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障(通过持续测试) 。
持续交付包含持续集成(自动检测源代码变更、执行构建过程、运行单元测试以验证变更),持续测试(对代码运行各种测试以保障代码质量),和(可选)持续部署(通过管道发布版本自动提供给用户) 。
如何在管道中识别/跟踪多个版本?版本控制是持续交付和管道的关键概念 。持续意味着能够经常集成新代码并提供更新版本 。但这并不意味着每个人都想要“最新、最好的” 。对于想要开发或测试已知的稳定版本的内部团队来说尤其如此 。因此,管道创建并轻松存储和访问的这些版本化对象非常重要 。
【什么是持续集成 源程序量】在管道中从源代码创建的对象通常可以称为 工件(artifact) 。工件在构建时应该有应用于它们的版本 。将版本号分配给工件的推荐策略称为 语义化版本控制(semantic versioning) 。(这也适用于从外部源引入的依赖工件的版本 。)
语义版本号有三个部分: 主要版本(major)、 次要版本(minor) 和 补丁版本(patch) 。(例如,1.4.3 反映了主要版本 1,次要版本 4 和补丁版本 3 。)这个想法是,其中一个部分的更改表示工件中的更新级别 。主要版本仅针对不兼容的 API 更改而递增 。当以 向后兼容(backward-compatible)的方式添加功能时,次要版本会增加 。当进行向后兼容的版本 bug 修复时,补丁版本会增加 。这些是建议的指导方针,但只要团队在整个组织内以一致且易于理解的方式这样做,团队就可以自由地改变这种方法 。例如,每次为发布完成构建时增加的数字可以放在补丁字段中 。
如何“分销”工件?团队可以为工件分配 分销(promotion)级别以指示适用于测试、生产等环境或用途 。有很多方法 。可以用 Jenkins 或 Artifactory 等应用程序进行分销 。或者一个简单的方案可以在版本号字符串的末尾添加标签 。例如,-snapshot 可以指示用于构建工件的代码的最新版本(快照) 。可以使用各种分销策略或工具将工件“提升”到其它级别,例如 -milestone 或 -production,作为工件稳定性和完备性版本的标记 。
如何存储和访问多个工件版本?从源代码构建的版本化工件可以通过管理 工件仓库(artifact repository)的应用程序进行存储 。工件仓库就像构建工件的版本控制工具一样 。像 Artifactory 或 Nexus 这类应用可以接受版本化工件,存储和跟踪它们,并提供检索的方法 。
管道用户可以指定他们想要使用的版本,并在这些版本中使用管道 。
什么是“持续部署”?持续部署(CD)是指能够自动提供持续交付管道中发布版本给最终用户使用的想法 。根据用户的安装方式,可能是在云环境中自动部署、app 升级(如手机上的应用程序)、更新网站或只更新可用版本列表 。
这里的一个重点是,仅仅因为可以进行持续部署并不意味着始终部署来自管道的每组可交付成果 。它实际上指,通过管道每套可交付成果都被证明是“可部署的” 。这在很大程度上是由持续测试的连续级别完成的(参见本文中的持续测试部分) 。
管道构建的发布成果是否被部署可以通过人工决策,或利用在完全部署之前“试用”发布的各种方法来进行控制 。
在完全部署到所有用户之前,有哪些方法可以测试部署?由于必须回滚/撤消对所有用户的部署可能是一种代价高昂的情况(无论是技术上还是用户的感知),已经有许多技术允许“尝试”部署新功能并在发现问题时轻松“撤消”它们 。这些包括:
蓝/绿测试/部署在这种部署软件的方法中,维护了两个相同的主机环境 —— 一个“蓝色” 和一个“绿色” 。(颜色并不重要,仅作为标识 。)对应来说,其中一个是“生产环境”,另一个是“预发布环境” 。

推荐阅读