【经验分享】提高应用系统发布效率，这十步就够了！

前言

回顾近年来企业的发展趋势，企业数字化转型的出现使得越来越多的业务演变成数字业务，数字化业务对信息技术提出了更高更严苛的要求，比如：快速响应市场需求，尽快交付让客户满意的高质量产品，并及时得到市场和客户的反馈，从而可以及时调整公司战略和产品方向，提升市场占有率和企业竞争力。

持续交付：指代码从本地提交后的构建、部署、测试和发布整个过程的自动化实现。

DevOps：通过整合工具、方法、技能和流程等建立一个流水线的过程，使业务更快的运营，并更快地应对变化。在EXIN DevOps体系中由三大支柱（规范敏捷、持续交付、IT服务管理）和一个基础（精益管理理念）组成。

新的数字化业务需要新的应用架构（如：微服务）来支撑，而新的应用架构需要新的基础架构（如：容器化）来支撑。同时，新的应用架构和基础架构变化带来了运维管理模式的转变。新的运维管理模式需要引入并借鉴新的理念和实践（如：持续交付和DevOps等）。

在过去这么多年，很多企业的研发团队已经采用了Agile，Scrum和XP等方法论来缩短开发周期和提升研发效能，但是发现整体的业务交付效率还是不够高，而且发布变更成功率仍然没有得到改善，传统的应用系统发布模式已难以支撑新业务的发布要求。

本文结合了我们的工作经验和思考，谈谈如何通过“十步法”实现应用系统的高效率发布，同时做到“事前审批、事中控制和事后审计”。

 

第一步：发布人员左移化

任何工具和系统的推广都是一种文化变革，应用系统的自动化发布也是如此。早期的发布模式中，往往是等开发人员完成软件开发后才向运维人员做正式的移交和发布工作（DevOps的反模式之一），这意味着：运维人员在此刻才拿到应用软件的信息和发布方式，没有足够的准备时间和充分的发布过程测试，随之而来的是，更长的发布变更时间和更高的发布失败率。

在新的发布模式中，需要引入“主动运维”方法，运维团队提前深入项目过程，与项目组讨论非功能需求，制定移交方案，使运维人员提前掌握运维技能，快速推进运维移交，并对发布过程和工具进行充分的测试。主动运维的左移模式让开发和运维部门不再存在无形的“沟通”壁垒，而是更好的协作。

 

第二步：发布对象应用化

当我们在实际运维工作需要对操作对象（比如：主机）执行脚本时，一般有如下3种情况：

1.通过远程登录（或通过堡垒机登录）实际的主机，在主机层面执行脚本操作；

2.通过类似Ansible等工具使用SSH协议远程登录并批量执行脚本操作；

3.在主机操作系统安装Agent，通过作业调度平台（如：蓝鲸作业平台）实现脚本的批量操作。

 

如果我们需要对一个包含100台机器的应用系统执行发布操作，我们如何记录这个应用系统包括哪些机器？实际操作中是否会遗漏机器或是发布到错误的机器呢？

对此，我们可以通过