一、为什么要聊这个话题？
有太多的朋友问过我持续交付（简称CD）与应用发布的问题，发现大家常常会混淆两者的概念，常见的问题例如：
CD是不是等于应用发布？
CD的概念已经涵盖了部署，是不是可以理解为CD包含应用发布？
我们已经具备了CD自动化能力，为什么还要建设应用发布的能力？
因此针对这些问题，谈一谈我的浅见。
二、持续交付与应用发布的定义
持续交付（Continuous delivery）指的是频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，制品（也就是常说的程序包）就进入生产阶段。
应用发布（Release）指的是将线上流量转移到新版本的过程。这个过程与上线新的制品所有风险有关，例如：发布失败会导致服务中断、会影响用户使用而被投诉等等。
通过上图简单区分，胜过千言万语，CD与应用发布分别处于软件生命周期的开发测试阶段与运维阶段，那么有些朋友可能会疑惑，开发/测试阶段的部署，运维阶段的发布，是不是一个意思呢？ 或者说部署的对象是测试环境，发布的对象是生产环境？在这里通过两幅图简要说明一下，帮助大家理解。
部署（Deploy）指的是在指定环境的基础设备中安装新版本服务的过程。部署不需要向用户提供新版本的服务，如下图：
发布（Release）不仅需要把新版本服务安装到指定环境，更重要的是让用户体验新版本的服务，可以简单理解为发布=部署+流量控制，如下图：
这里用图帮大家区分发布与部署，由于不是本文的主题，这里不再累述。
三、CD与应用发布的差异
1、从作用范围角度上看
CD主要作用在开发测试域，支撑需求设计、开发、测试等人员的软件交付工作。
应用发布主要作用在生产域，支撑运维人员的软件交付工作。
2、从能力要求上看
我们以一个业务系统A为例，如下图：
系统A由产品服务、订单服务、用户服务组成。
CD面向的就是服务，强调标准化的过程提高服务交付的效率与质量，这个过程包括需求—代码—编译打包—部署—测试验证—提交生产等。服务之间互不影响，可独立变更。
应用发布是面向业务系统的，把通过审核的服务组合在一起，按照一定的先后顺序安装到生产环境并让用户体验；强调的是服务之间版本的匹配是否正确。
有朋友可能会问，为什么还要组合呢？直接上生产不就好了，也不复杂啊。但试想一下，如果一个业务系统由10+，20+服务组成呢？（我遇到过由50+服务组成的业务系统，不要低估企业业务的复杂性），如果需要管理100+业务系统呢？更复杂的情况是业务系统之间还有依赖呢。
对于不太了解DevOps领域的朋友，是不是依然觉得比较抽象，不好理解？下面，我用造车再做个比喻吧。
CD就是汽车组件（服务）生产线，例如轮胎、座椅、车门、发动机等等，每一条生产线都是标准化的，生产线之间是互相独立的，相互不影响。那么轮胎、座椅的好坏取决于原材料（源代码）质量与加工技术（软件架构、算法等）的先进性。
应用发布就是整车（业务）的组装流水线，例如不同的汽车（不同的业务）奥迪、奔驰，不同的型号A4、 A6、GLS、GLK（不同版本），组装过程必定是有差异的，这就需要组装线条支持灵活配置，以应对业务变化的需要。
聊到这里，相信朋友们对应用发布的定义已经有了比较清晰的理解，那么，应用发布应该具备哪些自动化专业能力？ 我们从应用发布工作模式开始说起。
四、应用发布工作模式
当前应用发布工作模式，如下图：
发布当晚，业务验证、中间件、数据库、开源组件、配置管理、流量控制、监控管理等等相关事项都要留下实施人员，由发布管理者居中协调，统一安排，大家风风火火地拼搏一通宵，保障顺利上线，然后回家美美睡上一天。然而这只是最好的情况，过程中一旦稍有不慎，就是鸡飞狗跳，甚至版本回退，一地鸡毛，更别说回家睡觉了。
这种发布模式，对企业而言不仅人力投入大，业务停机时间长，还容易造成误操作；对个人而言，长期以往会造成工作过劳，生物钟混乱，影响健康。
那我们看看一些大企业的应用发布工作模式，如下图：
如果我们把程序包、DB、配置文件、流量切换等实施工作分别封装成可以自动化的最小单元，那么在生产发布之前，我们就可以把所有的实施操作预先编排成待执行的流程，如此中间件、数据库、开源组件、配置管理、流量控制等环节的实施人员就可以不用参与到发布工作中来，从而大大减少对这些专业团队的依赖，缩减了发布人员的的沟通范围。
接下来通过专家审核把控编排流程的质量，由管理人员分配待发布任务，就可以合理的把发布过程中不同角色的职责解耦开，让大家不必要扎堆一起干活。
注意这里的发布编排与发布审核不影响生产业务，是可以在5*8的正常工作时间里开展的，所以说专家和管理人员也可以从通宵工作中释放出来。
这样一来，发布当晚只需要留下少数人员，一键触发发布流程即可，有问题才呼叫专家，甚至对于比较稳定的系统，直接交给服务台触发流程都可以。
如此，大量的专业人员不需要扎堆通宵发布，正常工作时间完成编排/审核即可；管理人员也不用担心找不到问题原因，因为流程会留下详细的记录；发布执行人员不用担心命令过多或者过于繁杂，因为只需一键触发流程。这样不但解决了通宵人力投入过大的问题，也解决了容易误操作的问题，还可以大大降低发布人员技能门槛，避免过度依赖于专家。
五、自动化发布能力
当然要做到这种模式的应用发布，只是依靠人力肯定不行的，需要有专业的自动化发布能力支持才行，具体需要什么专业能力？我们根据工作模式分析如下：
1、版本闭环管理：支持新版本关联上载—按版本配置—版本更新—旧版本备份/归档的版本生命周期管理，实时掌握生产系统版本的最新状态。
2、发布能力：支持制品、配置文件、SQL等基础发布能力，避免线上线下交叉实施，支持流量控制、告警控制、工单等快速对接。
3、仓库管理：支持制品包、配置文件、SQL脚本、容器镜像等发布物料的统一存储、清理策略等。
4、发布流程编排：支持一条流水线编排业务系统所有服务组件的能力，例如后端服务Jar、C/C++、Tomcat等；前端服务Nginx；容器镜像；DB变更脚本；配置文件变更；流量控制等等。
5、发布任务管理：支持发布流程编排人员（可以是开发、测试或者运维人员）、发布流程审核人员（可以是运维专家、运维管理人员）、发布执行人员（可以是一线运维或者服务台值班人员）的职责分工与任务传递。
当然，我们这里只是聊一聊专业能力，从平台角度看，高可用、高并发也是要考虑的，本文就不做展开了。
聊到这里，可能有朋友会问，这个工作模式可以把专家、管理人员从苦海中解救出来，那测试验收怎么办，能一并解救吗？
当然是有办法的，灰度、蓝绿就能解决，虽然有一定的限制条件，但办法总比问题多，我们下回分解。
上一篇：新炬网络助力某城商行落地全生命周期SQL质量管理，践行数据库DevOps
下一篇：新炬网络助力中国信通院编制智能运维（AIOps）能力成熟度模型系列标准，驱动企业IT运维效能提升
新炬网络公众号