目录：
一、万达DevOps平台建设历程
二、平台架构解析
三、建设过程中的难点分享
四、总结
一、万达DevOps平台建设历程
我们从2017年2月份开始帮助万达网络科技建设DevOps平台，2017年6月份完成试运行上线交付。目前万达网络科技公共平台研发中心的所有产品和项目都已经通过DevOps平台管理起来，实现了全面的持续集成、持续交付等能力，并持续进行过程度量和改进，不断提升IT运行效率。
建设背景
万达网科成立后，业务需求处于一个飞速增长的阶段，在短时间内已经发展到将近30个产品、40个项目，管理成本相当之高，传统的管理方式很难高效率、高质量的进行管理和把控如此之多的产品和项目。并且随着虚拟化、容器云、微服务等技术的发展，应用底层的运行环境愈发多样化，物理机、虚拟机、容器云三种异构环境、移动应用、Springboot应用、纯前端应用等数十个异构应用都需要通过一个平台进行统一的部署和管理。
建设目标简单可以归纳为如下三点：
1.通过DevOps平台统一管理所有产品、项目，对团队、对人能进行数字化的考核
2.实现所有应用的持续集成、100%自动化部署，提升应用的软件交付效率
3.在两年内，将目前部门的研发、测试、运维发布的工作效率提升50%。
建设过程
项目从2月初开始，到6月底上线交付。持续了5个月的时间。项目过程基于Scrum过程体系，以月迭代的方式，每个月发布一个版本。同时，基于MVP的理念，保证每个月上线的版本功能都是可用的，不断的完善平台能力。每个冲刺过程如下：
Sprint1（2月份）：2月份主要进行了整体需求分析，完成我们现有产品的上线，以产品的现有能力作为第一个MVP版本。
Sprint2（3月份）：3月份交付了产品管理、项目管理、持续集成等能力，并且最重要的，结合万达的流程和规范，打通持续交付的流水线。流水线从构建开始，一直到上线部署，有了持续交付流水线，即使中间的一些环节（如测试环境）暂时无法做到完全的自动化测试，但是可以通过人工的参与，自动与人工结合，至少保障了整个软件交付过程便已经通过平台管理起来。后续便可以此流水线为基准，不断的完善中间环节的自动化能力。
Sprint3（4月份）：完善了度量优化、部署、流水线协作看板等能力。在度量优化模块，结合万达的度量点和度量考核规范，从多个维度和视角，不断提升平台的度量能力。在部署管理模块，首先结合万达的环境资源规范，对接其CMDB系统，在DEV/LAB/SIT/UAT/PRE/PROD六大环境的基础上，统一纳管所有项目的环境资源。结合部署规范（操作系统、部署用户权限、目录要求、数据库版本、jdk版本、nginx版本等），定制出符合万达要求的自动化部署能力。在流水线能力上，完善了两个协作看板：产品发布看板、环境看板。产品发布看板以产品为主视角，可以直观看到产品的每个版本到了持续交付的哪个环节。环境看板则是以环境为主视角，可以直观看到每个环境下，有哪些产品版本在运行。
Sprint4（5月份）：5月份继续丰富了一些尚未完善的能力，比如针对vue的代码质量扫描等（sonarqube目前并不支持对于vue的代码质量扫描），比如一些平台级的功能如角色权限的配置、首页看板的定制、操作日志、密码策略等等一些功能进行了完善。到此整个平台的全部功能就已经完成交付。
Sprint5（6月份）：6月份是上线试运行阶段，这个阶段将20多个产品、30多个项目、50多个代码库都迁移到平台上统一管理，做到了100%的持续集成、测试环境的自动化部署。并且在月尾的发布窗口，选择了一个试点应用成功通过平台进行发布上线。
我们也是第一次尝试月迭代的方式，所以这个对于我们而言也是很大的一个挑战。在这个过程中，也在不断的思考和改进。
总结下一期的建设成果：
1.实现40+微服务的的持续集成、自动化部署
2.基于Scrum体系，统一管理20+产品、30+项目
3.统一持续交付流水线，9大环节，跨4大环境，驱动开发、测试、质量、运维、管理等多个角色协作
4.支撑PMO精益度量，多维度统计20+报表
二、平台架构解析
总体架构解析
从逻辑上我们把DevOps平台划分为三大领域：敏捷过程、持续交付、持续改进。
敏捷过程针对于软件过程进行管理，包括产品、项目、团队、计划、任务等，持续交付则关注从需求到上线交付的管理，包括持续集成、自动化测试、自动化部署、交付流水线等。持续改进则体现了平台的核心价值，不断的度量和优化软件过程，为提升IT运行效率打下坚实的基础。
在上面三大领域的基础上，又做了一些模块拆分，平台的逻辑架构如下：
DevOps平台划分为领域层、基础服务层、工具层三层。工具层封装了一些开源工具，提供基础能力。服务层在此基础上封装的一些基础服务，如编译、部署、代码管理等。领域层主要包括项目管理、产品管理、构建、部署、交付流水线、度量优化等模块。底层运行环境支撑物理机、虚拟机、容器云平台。
产品管理&项目管理
软件的整个生命周期可以从不仅仅是项目的生命周期，而是应该也包括了产品的生命周期。在企业内部，通常我们先决定做哪个产品，然后需求调研、版本划分，确认了具体版本要实现的需求范围后，便可以组建项目进行研发。研发完成进行交付后，有进入产品的线上运营阶段。直至产品下线。一个产品可以对应多个项目，当然，对于有些企业而言，一个项目也是持续稳定的维护一个产品。
持续集成
持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中，DevOps平台将构建任务分成了四种类型：
编译类任务：Maven、Ant、Gradle、纯前端构建等
测试类任务：Sonarqube、Jmeter、Selenium等
打包类任务：Npm、Archive、Docker等
其他工具类任务：Copyfile、Shell、介质提交到Nexus仓库、介质上传二方库等。
在每个构建定义上可以选择若干个需要的构建任务，通过原子步骤编排，组装成一个完整构建流程。代码提交时触发构建（支持gitlab、github、svn等常用代码库版本管理工具）、日构建等不同的构建触发策略等支撑了持续集成的完整链路打通。
自动化部署
在自动化部署模块中，为了更好的与实际结合，我们将部署分为三个阶段：设计、转换、运维。
设计阶段：将部署架构分为三层：部署装配（Assembly）、部署容器（Platform）、部署组件(Component)。部署装配是对部署架构的描述，由多个部署容器组成，每个部署容器由若干个部署组件组成。
转换阶段：将部署架构与部署策略（全新、蓝绿、灰度、滚动升级等）、资源（具体资源如物理机、虚拟机、容器）、组件配置参数（端口号、JVM参数、健康检查url等）进行结合，生成部署计划，一键执行自动化部署。
运维阶段：对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等。
持续交付流水线
为什么需要持续交付流水线？举个例子来说，我们常常苦恼最终上线版本和系统集成测试环境不一致。这一般是因为在系统集成测试完成后发现了问题，作了代码变更但没有重新构建，而是直接在介质里进行了调整进而发布上线。在持续交付流水线中是不允许这种情况出现的。所有上线入口一定是最初的构建，所有的后续产物都是基于这一介质，如果有变更必须重走流程。这样可以保证发布的安全性和统一性，线上出现问题也是可以追溯的。当然过程中的环境可以配置人工介入或自动执行。
发布流水线从构建到生产部署共9大环节，涵盖SIT/UAT/LAB/PROD四大环境。驱动了开发、测试、质量、运维等多个角色的协作。
在设计流水线能力时，我们主要考虑到几点：
结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置
流程的每一个环节都要支持自动执行的配置
流程中每个环节的属性和配置信息可以自定义，灵活扩展
流程以构建开始，让buildNumber贯穿整个流程，方便追根溯源
要有一个看板，直观的看到整个产品的版本目前到了流程的哪个环节，是SIT还是UAT，结果如何
要有一个看板，直观的看到每个环境下，有哪些介质在运行
以这些为基础准则，我们底层基于了我们的BPS流程引擎，支撑流程的自定义和扩展。并且，针对于每个环节，都可以配置前置后置事件、人工执行还是自动执行，责任人等。整个流水线从构建开始，保证全局介质唯一，避免人为修改介质导致的生产介质不可追溯。
在交付看板上，环境看板和发布看板如下
度量优化
精益运营的基础是度量，度量的三大维度：指标、执行监控、预测。首先是明确指标和执行监控，基于软件全生命周期的度量过程中企业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。当DevOps平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。
示例如下：
三、建设过程中的难点
难点1：统一流程和规范
回顾一下前文的发布流水线的介绍，其实这其中我们在介绍时省略了大量的细节。比如，在开始构建时是否要打一个Tag，此时针对构建介质产物是否不应该是snapshot版本，而应该是Stage预发版本。如果UAT等测试通过之后，这个介质版本即为可发布版本，此时介质需要转移到Release版本的介质仓库。这就是一个完整的流程，也是需要加入到规范中去的。
梳理企业的流程和规范是企业建设DevOps的前提，甚至即使不建设DevOps平台，这也是一个必不可少的行为。只有统一了企业的流程和规范，才能建设出一个适用于企业的DevOps平台，否则到最后，有可能会让DevOps平台脱离实际，导致没有人会去使用。
我们在建设过程中，每一个模块都需要结合万达的流程规范以及我们的最佳实践共同进行建设，在前期，当一些流程规范不是那么明确的时候，还需要一起讨论，同时规范也不是一蹴而就的，实施过程中发现一些不合适的地方就需要进行修改，这也就带来了需求的反复的可能。以持续交付流水线为例，这个就需要结合万达的环境、发布规范来定制流程，对于其他企业而言，持续交付流水线未必就是这样的一个流程，有可能会少一些环境，也有可能多个预发环境，又或者会把这一个流水线拆分成多个流水线。
难点2：异构兼容
对于应用运行环境而言，需要同时支撑物理机、虚拟机、容器云、Android设备、IOS设备多种类型的环境。而应用本身又分为纯前端应用、SpringBoot应用（Fat JAR）、传统应用（WAR）、Android、IOS等各种类型。这就对自动化部署框架提出了很高的要求，一套架构要能同时支撑异构应用部署在异构环境上。
以移动应用的自动化部署为例，os部署组件可以用来区分系统、computer可以用于校验机型。选择部署资源时，从cmdb中导出项目的移动设备资源，最后将应用自动化部署到移动设备上。
难点3：职能切面
DevOps平台建设之前，企业可能已经有不少系统了，比如云资源管理平台、容器云云平台、自动化测试平台、统一监控平台等等。那么很多时候一个困难点就在于DevOps的定位了，在测试的能力上，DevOps平台要不要完整的把测试的能力都管理起来呢？在自动化部署的时候，要不要直接创建虚拟机对资源进行操作呢？我们在万达落地DevOps的过程中，也遇到了这些问题。我们认为：
DevOps无法让每个人的工作都在上面，高级能力还是专人在专业系统上完成；
如果专业系统足够自动和自助化，可考虑逐步纳入DevOps平台
我们做的是工程效率平台，不是给多个系统做个统一门户
本着这些理念，我们就明确了对职能的切分。像对底层资源的管理，是统一通过 CMDB进行管理，DevOps只是进行资源的申请与使用。在测试环节，则是对接自动化测试平台，将持续交付流水线中的测试环节拉起来，保障整个流水线的完整。在对已部署应用的监控，可以对接企业的统一监控平台进行健康监控。
四、总结
虽然目前DevOps平台已经完成初步交付，并且已经将所有的产品、项目统一通过平台进行了管理。但是这仅仅做到了敏捷过程和持续交付。在持续改进领域还是有不少工作持续去做的，平台目前在度量优化部分的能力还是稍显不足，如何能完成最初的目标：”在两年内提升IT运营效率50%“。还需要更加丰富、更加可量化的一些统计分析数据来支撑。而这，也是我们认为DevOps最核心的价值，致力于提升企业IT运营效率。
关于作者
王海龙 现任普元信息高级研发工程师，毕业于华东师范大学，曾参与和负责银联Paas云平台项目、兴业银行CAP4J项目、交通银行信用卡中心统一监控平台项目、神华灾备云平台、万达DevOps平台等项目。
(本文于2017-09-14首次发布)
