前言

发布是持续交付的最后一公里。
传统上，软件的最终发布是个充满压力的过程，需要大量的手工配置、操作和团队配合。为了发布的可靠性，开发人员需要准备详尽的部署文档，然后再把相关信息同步给运维人员执行部署，由运维人员执行一系列个性化的发布脚本，部署完后还需要测试人员做详尽的手工验证。
每个步骤里都有很多需要人为判断和信息沟通的事情，稍有不慎就很会产生人为错误造成系统故障，发布时间和结果都不可预测，发布之后忙活到凌晨，绞尽脑汁想着怎么让刚刚部署的应用程序能够正常工作，最后常常不得不回滚，类似这样的场景都很常见。
要解决这样的痛点，除了在软件研发时采用小步迭代的方式，降低交付复杂度外，一套易用、快速、稳定、容错力强，必要时有能力快速回滚的发布系统必不可少，本文将重点建设微医在发布平台建设过程中的一些优秀实践。

核心特性

• 覆盖主流应用：Java、NodeJS、Python、PHP、Lua、Android、IOS等。
• 支持分批发布和灰度发布
• 支持发布暂停和恢复
• 支持历史版本的快速回滚
• 支持应用重启和停止等操作
• 支持多实例应用日志聚合查看
• 支持分布式的发布节点
• 发布前质量红线卡点
• 发布中实时监控分析
• 发布后质效度量

整体架构

• 典型应用发布流程：
  • 系统立项后，在WCP-应用管理中申请创建应用，输入包括开发语言、jdk版本、构建工具、部署方式、产物路径、代码地址、应用负责人等应用基础信息(应用信息是所有研发协作的基础)。
  • 应用创建后，在WCP-资源管理中申请申请资源，在CMDB中自动建立应用和IP/域名之间的关系（包括测试环境、预发环境、生产环境等）。
  • 应用建立后，发布平台自动生成发布job，发布时获取应用和资源等基础信息，可触发灰度发布或分批发布的执行。
  • 发布操作前，自动执行质量红线检查（主要包括pipeline执行结果以及发布检查表确认等），质量红线未达标拒绝发布。
  • 发布操作中，自动暂停监控，灰度发布或首批发布后，自动触发监控。若监控失败，停止发布；若监控通过，可继续发布。
  • 发布操作后，采集存储发布数据，输出给质效看板做发布数据度量（发布成功率，发布频率，发布时长等）。
  • 发布出问题，可执行快速回滚等功能，并提供发布日志以及应用聚合日志的查询，以快速定位问题。
• 发布平台界面：
  

发布前质量卡点

质量是持续交付的内置特性。在发布这最后一公里，如何通过发布平台自动化做好质量红线的卡点，是发布平台的一个重要特性。
在Pipeline流水线中，开发代码提交后自动触发单元测试,、静态代码扫描、安全测试、集成测试, 构成了开发和测试共同参与的一套流水线。
发布卡点是用于保障交互质量的重要手段，为了达到持续交付的目标，我们把研发pipeline执行结果作为质量红线（也可以增加人工的发布检查表结果），以此方式来保障整个持续交付的顺利进行。

常用的自动化质量卡点策略：

• 研发流水线状态
  • 单元测试结果
  • 单元测试覆盖率
  • 代码静态检查
  • 集成测试结果
  • 安全扫描结果
• 发布计划状态（发布计划管理系统）
  • 发布时间窗口
  • 发布评审结果等

发布中质量监控

为保障系统的稳定性，我们每个应用在监控平台都配置有对应的拨测监控点。
如何减少发布时的告警误报，或者避免发布过程中出现重大故障，这里需要发布平台和监控平台配合做一系列精密的控制策略。

• 发布场景1：
  • 描述：发布新版本，在重启某个实例服务时，有一定的概率会触发该实例的应用报警，对应用开发人员会造成一些不必要的干扰。
  • 策略：发布平台在将应用编译打包好，执行正式发布之前，调用监控平台API停止该应用下的监控任务，在发布完后同样调用监控平台API启用该应用下的监控任务。

• 发布场景2：

  • 描述：发布时应用实例因为各种原因（如代码部署出错，新版本存在明显BUG等），出现了系统故障。
  • 策略：采用分批发布策略，各个实例发布完后立即触发该实例的监控，如果监控发现异常，标识该批次发布操作失败，并强制中止后续批次的发布操作，以避免更多的实例出现问题。

• 逻辑流程

  

  这里需要强调的是，拨测监控覆盖率在微医会作为团队的重要指标。因为应用只有在配置监控点后，发布平台才能在发布过程中进行有效的监测和干预。

发布后质效度量

质效度量是研发协作平台的一个重要组成部分，主要质效指标将按照研发质量、研发效率、研发成本三方面进行细分。

其中在发布过程中产生的数据，将会输送给质效度量系统进行质效分析，重点包括

• 发布频率
• 发布时长
• 发布成功率等。

所有团队和研发成员可以结合这些发布数据指标，发现自己存在的问题和短板，并进行有效改进。

分批发布

分批发布是批次进行应用部署，每次仅对应用的一部分实例进行升级。分批发布过程中如果出现故障，则终止回退，待问题修复后重新发布。
这里我们采用了比较简洁的批次分配算法，因为公司目前使用的是双机房IDC，当应用进行分批发布时，首批发布会在两个机房中随机各选择一个实例执行，其他的实例则放到了第二批发布。

选择发布暂停，则可在首批发布完后暂停发布，等人工确认首批发布的实例没有问题后，再执行后续其他实例的发布，如此可有效保障发布的稳定性。
发布过程中，可在发布平台中实时查看运行日志，若发现问题，可随时执行暂停、取消或者回滚等操作。

• 最佳实践

每个实例进行部署时，需要保证没有请求会派发到该实例，否则用户就会看到502的错误。所以需要有一个“下线”的操作，把当前机器从负载均衡中摘除，然后在部署完成之后，再把自己挂回到负载均衡中，这个过程称为“上线”。
为了实现该目的，可基于OpenResty自研Nginx网关对实例上下线进行实时调度，基于 OpenResty 的 Nginx 网关的实现过程比较复杂，这里不再详尽展开。

问题响应

在发布过程中，如果出现了一些意料之外的情况，发布平台也提供了一些常用的功能，满足开发人员定位和处理问题的需要，同时也尽量避免开发人员直接登录服务器操作。

• 查看日志

主要对接了公司统一的日志平台系统，可实时查看应用日志，并且聚合了多实例的日志信息，减少几个实例不停切换寻找问题的痛苦。

• 重启或停止实例

某个实例故障时，可快速重启或停用实例。

• 快速回滚

每个发布的版本发布平台都会有备份，当发布新版本发现问题时，可快速回滚到历史版本

Jenkins Pipeline

在整套发布平台中，Jenkins Pipeline提供了核心的构建、打包、部署以及分布式调度的底层基础能力，只不过为了更灵活的调度发布操作、管理应用与发布任务之间关系等，我们摒弃了Jenkins自身的UI界面，而通过发布平台调用Jenkins API的方式将其定位为基础引擎。
其中Jenkins Pipeline的共享库特性，让我们通过groovy编程的方式，很好的实现了发布脚本的版本管理，再也不用发愁怎么管理那堆凌乱的shell脚本了。
这里只截取一部分结构代码，Jenkins共享库的具体使用可参见之前的系列文章。

import groovy.json.JsonSlurperdef call(Map map) {pipeline {agent anyparameters { //java应用参数string(name: 'BUILD_TOOL', defaultValue: 'maven', description: '构建工具')string(name: 'MAVEN_VERSION', defaultValue: 'maven3', description: 'maven构建工具版本')string(name: 'GRADLE_VERSION', defaultValue: 'Gradle3.3', description: 'gradle构建工具版本')string(name: 'WAR_RELATIVE_PATH', defaultValue: '', description: 'war包地址')string(name: 'WAR_STD_NAME', defaultValue: '', description: 'war包地址')string(name: 'POM_RELATIVE_PATH', defaultValue: '/pom.xml', description: 'pom文件地址')string(name: 'HAS_TEMPLATES', defaultValue: 'false', description: '是否有模板文件')string(name: 'TEMPLATES_RELATIVE_PATH', defaultValue: '', description: '模板文件路径')string(name: 'JETTY_VERSION', defaultValue: '', description: 'jetty版本')string(name: 'GRADLE_TASK', defaultValue: 'war', description: 'gradleTask打包方式')......}tools {gradle "${params.GRADLE_VERSION}"jdk "${params.LANGUAGE_VERSION}"maven "${params.MAVEN_VERSION}"}stages {stage('部署正式环境') {steps {script {def pmap = [:]

try {//应用参数传递pmap.put('BUILD_TOOL', BUILD_TOOL.trim())pmap.put('WAR_RELATIVE_PATH', WAR_RELATIVE_PATH.trim())pmap.put('WAR_STD_NAME', WAR_STD_NAME.trim())pmap.put(