发布管理

基础要点

发布内容既可以包括各种基础架构、应用组件、更新流程与工具，也可以包括文档与培训。

发布管理工作通常发生在部署之前。

在传统/瀑布环境中，发布管理和部署被合并为单个进程。

在Agile/DevOps 环 境中，软件和基础架构往往是一些较小的增量部署，因此既可以采用“蓝/绿发布”，即两个镜像生产环境同时供不同类型的用户使用；也可以采用“功能标记”，即新功能被部署到生产环境中但不全面释放，仅释放给单个用户或组。

解读

无论是新服务的启用，还是针对当前服务的修补，我们都需要在完成了测试审查、部署计划、回滚步骤，这三项前提条件之后，方可通过触发变更流程来予以正式发布。

也就是说，只有得到了变更管理委员会的批准，我们方可进行发布操作。而之所以要走这样的流程，就是为了在发布过程中一旦出现了不可接受的错误，我们还能及时地根据既定的回滚步骤，后退到发布之前的系统与服务状态。

由此可见，发布管理的最终目标应该是：

实现并达到了预定的系统功能与服务级别；

更新了相应的配置管理数据库（CMDB）；

保持了系统与服务的可用性与稳定性。

图3 常规发布管理流程

由于发布往往会给系统和服务带来更新，那么为了做好与配置相关的管理工作，我们势必需要对基础架构、应用组件、流程与工具、甚至是文档与培训等方面，做好相应的版本号编制工作。

就发布的类型而言，业界一般会采用三种传统的发布方式：

1.增量发布（Delta Release）

只是对从最近一次成功发布以来的累计更新部分予以发布，原有的部分保持不变。

2.全量发布（Full Release）

将更新部分连同原有不变的部分作为整体组件，发布到生产环境中。

包发布(Package Release)

将一组新的软件或服务进行打包，然后直接导入既有的生产环境之中。

如前所述，无论我们在实际操作中采取哪一种发布方式，都会涉及到对于CMDB 进行相关配置项（CI）的签出（check out）和签入（check in）的过程。即：

在执行发布之前，先读取系统与服务的当前状态，并锚定之。

在完成发布与部署之后，将软件的最新版本，写入在CMDB 中已构建的最终软件库（Definitive Software Library，DSL）；而将涉及到硬件的更新与安装，映射到CMDB 的最终硬件库（Definitive Hardware Store，DHS）中。

此举不但能够有效地保证了应用系统及其服务的可靠性，又能够及时地为后续的配置管理提供可参考的依据。也就是业界常说的“及时更新基线”。

实务

我们本着给系统和服务“尽量做加法而不要做减法”的初衷，针对本企业内部林林总总的产品类型，采用了如图3 所示常规发布管理流程。

其中，在发布策略的规划阶段，我们会着重管理如下方面：

1.我们将待发布目标区分为：标准/常规发布、紧急发布、以及项目发布，这三种类型，进而根据解读里提及的不同发布方式进行了预定义。例如：

标准/常规发布适合于增量方式；

紧急发布适合于包方式；

项目发布更适合于全量方式。

当然，我们也会根据实际情况略有调整。值得一提的是，我们在处理对外云端服务的相关更新与发布时，遵从了业界常用的灰度发布模式，即在保留一部分用户继续沿用老版本的同时，让另一部分用户开始使用新的版本。

在并行使用期间，能够及时地发现问题，限制影响，甚至回滚调整。待用户对于新版本体验反馈良好时，再逐步扩大部署范围，并最终将所有用户都迁移过来。

2.在规范版本号编制的方面，我们采用了在业界普遍使用的软件版本控制方法，即新的版本号由五个部分组成：“主版本号+子版本号+阶段版本号+日期_希腊字母”。其中：

（1）主版本号的累加是指：在整体技术架构上具有较大的变动与调整。

（2）子版本号的累加是指：在服务与功能上具有增加或变化，比如增加了访问控制与授权、或是自定义的视图等。

（3）阶段版本号的累加是指：对现有服务进行了Bug的修复或稳定性的提升。

（3）日期：记录的是修改完成的当前日期。

（4）希腊字母：标注的是当前版本处于哪个开发阶段。Base 仅为Demo 版本，Alpha 为内测版，Beta 为公测版，RC 为已成熟且无Bug的候选版，Release 为最终正式交付版。

在发布构建、安装与配置阶段，我们采取的是自动与手动互补的方式。无疑，自动化推送分发，包括DevOps里管道的运用，可以保持发布的一致性，而且突破了时间和空间上的限制，进而在一定程度上减轻了手动部署的工作量。但是，对于一些自动化过程中的遗漏，例如，未启动的主机和未上线的云端实例，则需要运维人员以主动拉取的方式，来完成并确认。

在验收阶段，我们除了需要确保只有正确的、被授权的以及经过测试的软/硬件版本出现在实际生产环境中之外，还应当及时更新CMDB里的CI，特别是对于已知错误知识库的维护。

在用户支持和培训阶段，我们可以充分利用已知错误知识库里的相关内容，以积极的态度与用户保持顺畅的沟通，合理地控制好用户在使用中的期望值和体验度，为“新品”保驾护航。