传统企业级IT产品具有规模大、开发人数多、技术水平相对落后的缺点，每一代产品从源代码构建、测试到发布的过程都会跨越组织内部多个相对分离的领域，且产品开发完全外包，对产品迭代速度、交付质量有较大影响。因此，需要一种方法和技术：

​

企业引入DevOps理念，努力将支撑系统传统开发模式和系统运营方式向以业务价值为导向的开发运营融合模式转型。以平台形式固化开发运营一体化框架体系的流程，打通从敏捷需求管理、配置管理、个人构建、版本构建、系统测试、上线发布及产品运营的产品全生命周期，实现了产品全流程可视化、评价指标规范化、产品运营可持续化。

提供软件开发全生命周期管理和流程自动化，逐步解决研发、QA、运维三者之间的矛盾，促进产品需求快速响应、版本快速迭代、流程更清晰、管理可视可控等。

以上简单交代了DevOps的作用，下面详细讲述一个笔者经历过的DevOps实践案例。

以一家金融企业为背景的案例，该企业有各类项目500+，开发人员1000+。技术栈百花齐放，有JAVA、NPM、Python、Scala、GO等。以JAVA技术为例，有MAVEN、ANT编译、容器，有微服务、父子工程、传统技术架构，有配置分离与不分离的差别等。

由于历史原因，环境也存在差异，部分项目有SIT、UAT，部分项目只有SIT。制品提交生产的过程由各个项目组负责，不统一、标准化难落地。可以说国内大多数大中型企业都有类似情况。

综上所述，在集中、统一管理的前提下，如何快速、有效、稳定地给生产提供制品成为了首要目标。

先对比一下持续交付实施前后的情况，按客户要求，一次完整的制品交付应该包括：

拉取代码>>编译打包>>部署SIT>>通知SIT测试>>部署UAT>>通知UAT测试 >>提升生产

实施前：每个项目需要一个专人，一次交付大约需要3小时，如果出现错误，大约0.5-1天不等，人为误操作无法避免，规范、标准难落地。

实施后：一键触发无需专人，一次交付大约需要30分钟，不会有人为误操作，标准化流水线。单次交付时间能够减少2.5小时左右，交付效率大约提高6倍。

接入各类变更频繁的项目150+，工程数量800+，管理10000+制品，持续交付流水线已运行70000+次，月均运行超过10000+次，基本实现了快速、有效、稳定地给生产提供制品的目标，当然，我们还在不断改善中……

DevOps是一个较大的概念，持续交付只是一个组成部分。

关注持续交付，不同的企业、不同的团队站在不同的角度存在不同的定义。本文只是从软件研发的技术角度进行定义：

持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，制品（也就是常说的程序包）就进入生产阶段。

看下图胜过千言万语：

客户在做持续交付前遇到的主要问题如下：

当然还有其他问题，篇幅原因就不一一罗列了。

面对各种各样的问题，在这里跟大家分享几个主要的持续交付建设思路：

为了让交付标准能够落地，不再只是一个Word文档，我们先控制了交付流水线的源头，不再像使用开源Jenkins一样，可以自由创建。对于纳入交付标准的交付方式，都会为其创建对应的模板，项目接入后，可以根据自己的情况，选择不同的模板使用，交付过程只需要一键触发，不再依赖专人实施。

基于可选模板的流水线创建的实现技术逻辑如下：

二、制品存放、流转规则对操作人员透明

持续交付会频繁地产出制品，但并不是每一个制品都能推给生产，面对成千上万的制品如何存放才不会导致混乱，如何确保制品从开发到测试、从测试到验收，最后推给生产的过程是正确的，是需要有一套完备、细致的规则进行约束的。由于这一块工作繁重且容易出错，人力管理很难满足要求，所以在这里分享一下我们的做法。

首先是制品存放，从如下四个部分考虑存放规则：

例如：研发中心运维项目组—NPM技术—SIT测试—V1.0

那么这样的存放方式可以方便从不同角度快速定位需要的制品。

其次，为了保证软件上线部署准确性，每一个业务版本对应的是正确的制品包，一套自动化制品生命周期管理方法尤为重要，参考下图：

在研发阶段，代码检出时，根据工程的属性，如是应用配置未分离的情况，每次编译构建的时候，会出来各个环境制品，有多少个环境就有多少个制品，例如：dev（开发环境）的制品、sit（集成测试环境）的制品、uat（业务测试环境）的制品、pre（预生产环境）的制品，这些制品会存放在开发阶段的指定制品仓库中，当开发人员测试通过后，流水线会自动将在开发阶段仓库里的sit制品提升至sit测试的制品仓库里；当测试人员测试通过后，会将开发阶段仓库里的uat制品提升到uat制品仓库里；当业务测试人员测试通过后，会将开发阶段仓库里的pre制品提升到预发布库。

如是配置应用已分离的情况，只会编译出来一个制品，流水线的制品整体生命周期就只会针对该制品进行流转，当开发人员、测试人员完成之后，制品会相应提升至预发布库。

制品在提升到预发库时，项目经理会针对这次上线进行质量关卡的把关，同时会将此次制品全生命周期涉及到部署次数、构建信息、测试信息、质量代码等信息，收集到一起，作为上线发布的依据，如果项目经理担心制品流转出错，还可以通过MD5进行比对，按照如下流程：

例如用sit制品与提交生产的prod制品比对，对比文件差异如下图：

查看详细的差异：

三、线上跨团队交互，记录交互节点信息

如下图，先看看跨团交互节点：

没错了，这里交互的节点就是提交测试人员、应用程序包审核、应用程序包提升，以提交测试人员为例，简单功能描述如下：

开发者提交测试人员：开发人员在完成代码提交、编译部署流程后，使用提测功能供邮件通知提交测试人员进行测试。

开发人员——>提交测试人员——>测试人员

测试者提交业务人员：测试人员完成测试后，如果不通过，则线下通知开发人员修复；如果通过，则使用提测功能邮件通知业务人员进行验收测试。

测试人员——>提交业务人员——>业务人员

大家可能会想，这就是一个简单的通知功能，能有多大作用？别小看了，效果有两个：

以上是我们持续交付的经验分享，持续交付方式多种多样，能解决客户痛点，提升效率与质量，减少交互过程中的等待时间就是好办法。

• 《建设敏捷型消费金融中台及云原生下的DevOps实践》中邮消费金融总经理助理 李远鑫

• 《腾讯新闻DevOps实践》腾讯客户端高级开发工程师 褚佳义

• 《浙江移动AIOps实践》浙江移动云计算中心NOC及AIOps负责人 潘宇虹

• 《云时代下，传统行业的运维转型，如何破局？》新炬网络运维产品部总经理 宋辉

• 《数据智能时代：构建能力开放的运营商大数据DataOps体系》中国联通大数据基础平台负责人/资深架构师 尹正军

• 《银行日志监控系统优化手记》中国银行DevOps负责人 付大亮 & 中国银行高级软件工程师 李晓宁

• 《民生银行智能运维平台实践之路》民生银行智能运维平台负责人/应用运维专家 张舒伟