企业DevOps平台架构解析

1、 m鶴学吧企业DevOps平台架构解析7中厂匕耳建设冃景企业项目研发管理成本相当之高，传统的管理方式很难高效率、高质量的进行管理和把控如此之多的产品和项目。并且随着虚拟化、容器云、微服务等技术的发展，应用底层的运行环境愈发多样化，物理机、虚拟机、容器云三种异构环境、移动应用、Springboot应用、纯前端应用等数十个异构应用都需要通过一个平台进行统一的部署和管理。建设目标简单可以归纳为如下三点：通过DevOps平台统一管理所有产品、项目，对团队、对人能进行数字化的考核实现所有应用的持续集成、100%自动化部署，提升应用的软件交付效率在两年内，将目前部门的研发、测试、运维发布的工作效率提升50

2、%。建设过程项目从2月初开始，到6月底上线交付。持续了5个月的时间。项目过程基于Scrum过程体系，以月迭代的方式侮个月发布一个版本。同时，基于MVP的理念，保证每个月上线的版本功能都是可用的，不断的完善平台能力。每个冲刺过程如下：Sprint1（2月份）：2月份主要进行了整体需求分析，完成我们现有产品的上线，以产品的现有能力作为第一个MVP版本。Sprint2（3月份）：3月份交付了产品管理、项目管理、持续集成等能力，并且最重要的，结合万达的流程和规范，打通持续交付的流水线。流水线从构建开始，一直到上线部署，有了持续交付流水线，即使中间的一些环节（如测试环境）暂时无法做到完全的自动化测试，但

3、是可以通过人工的参与，自动与人工结合，至少保障了整个软件交付过程便已经通过平台管理起来。后续便可以此流水线为基准，不断的完善中间环节的自动化能力。Sprint3（4月份）：完善了度量优化、部署、流水线协作看板等能力。在度量优化模块，结合万达的度量点和度量考核规范，从多个维度和视角，不断提升平台的度量能力。在部署管理模块，首先结合万达的环境资源规范，对接其CMDB系统，在DEV/LAB/SIT/UAT/PRE/PROD六大环境的基础上，统一纳管所有项目的环境资源。结合部署规范（操作系统、部署用户权限、目录要求、数据库版本、jdk版本、nginx版本等），定制出符合万达要求的自动化部署能力。在流水

4、线能力上，完善了两个协作看板：产品发布看板、环境看板。产品发布看板以产品为主视角，可以直观看到产品的每个版本到了持续交付的哪个环节。环境看板则是以环境为主视角，可以直观看到每个环境下，有哪些产品版本在运行。Sprint4（5月份）：5月份继续丰富了一些尚未完善的能力，比如针对vue的代码质量扫描等（sonarqube目前并不支持对于vue的代码质量扫描）,比如一些平台级的功能如角色权限的配置、首页看板的定制、操作日志、密码策略等等一些功能进行了完善。到此整个平台的全部功能就已经完成交付。Sprint5（6月份）：6月份是上线试运行阶段，这个阶段将20多个产品、30多个项目、50多个代码库都迁移

5、到平台上统一管理，做到了100%的持续集成、测试环境的自动化部署。并且在月尾的发布窗口，选择了一个试点应用成功通过平台进行发布上线。我们也是第一次尝试月迭代的方式，所以这个对于我们而言也是很大的一个挑战。在这个过程中，也在不断的思考和改进。总结下一期的建设成果：实现40+微服务的的持续集成、自动化部署基于Scrum体系，统一管理20+产品、30+项目统一持续交付流水线，9大环节，跨4大环境，驱动开发、测试、质量、运维、管理等多个角色协作支撑PMO精益度量，多维度统计20+报表平台架构解析总体架构解析从逻辑上我们把DevOps平台划分为三大领域：敏捷过程、持续交付、持续改进。敏捷过程针对于软件过

6、程进行管理，包括产品、项目、团队、计划、任务等，持续交付则关注从需求到上线交付的管理，包括持续集成、自动化测试、自动化部署、交付流水线等。持续改进则体现了平台的核心价值，不断的度量和优化软件过程，为提升IT运行效率打下坚实的基础。在上面三大领域的基础上，又做了一些模块拆分，平台的逻辑架构如下：软件的整个生命周期可以从不仅仅是项目的生命周期，而是应该也包括了产品的生命周期。在企业内部，通常我们先决定做哪个产品，然后需求调研、版本划分，确认了具体版本要实现的需求范围后，便可以组建项目进行研发。研发完成进行交付后，有进入产品的线上运营阶段。直至产品下线。一个产品可以对应多个项目，当然，对于有些企业而

7、言，一个项目也是持续稳定的维护一个产品。持续集成支持代餾咬时构逢/日阎進.打逓评竦整凤蔬耳iwnsts遡i1Androidhrtml持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中，DevOps平台将构建任务分成了四种类型：编译类任务：Maven、Ant、Gradle、纯前端构建等测试类任务：Sonarqube、Jmeter、Selenium等打包类任务：Npm、Archive、Docker等其他工具类任务：Copyfile、Shell、介质提交到Nexus仓库、介质上传二方库等。在每个构建定义上可以选择若干个需要的构建任务，通过原子步骤编排，组装成一个完

8、整构建流程。代码提交时触发构建（支持gitlab、github、svn等常用代码库版本管理工具、日构建等不同的构建触发策略等支撑了持续集成的完整链路打通。自动化部署在自动化部署模块中，为了更好的与实际结合，我们将部署分为三个阶段：设计、转换、运维。J*F冷止BFtfiWWt邮薯设计觀I转换Anw比设计阶段：将部署架构分为三层部署装配Assembly）、部署容器（Platform）、部署组件（Component）。部署装配是对部署架构的描述，由多个部署容器组成，每个部署容器由若干个部署组件组成。转换阶段：将部署架构与部署策略（全新、蓝绿、灰度、滚动升级等）、资源（具体资源如物理机、虚拟机、容器、

9、组件配置参数（端口号、JVM参数、健康检查url等、进行结合，生成部署计划，一键执行自动化部署。运维阶段：对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等。持续交付流水线为什么需要持续交付流水线？举个例子来说，我们常常苦恼最终上线版本和系统集成测试环境不一致。这一般是因为在系统集成测试完成后发现了问题，作了代码变更但没有重新构建，而是直接在介质里进行了调整进而发布上线。在持续交付流水线中是不允许这种情况出现的。所有上线入口一定是最初的构建，所有的后续产物都是基于这一介质，如果有变更必须重走流程。这样可以保证发布的安全性和统一性，线上出现问题也是可以追溯的。当然过程中的环境

10、可以配置人工介入或自动执行。发布流水线从构建到生产部署共9大环节，涵盖SIT/UAT/LAB/PROD四大环境。驱动了开发、测试、质量、运维等多个角色的协作。在设计流水线能力时，我们主要考虑到几点:结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置流程的每一个环节都要支持自动执行的配置流程中每个环节的属性和配置信息可以自定义，灵活扩展6mcs.LKtw*毎輕蛍*电。疑驷丘K-迢U忙州gs即迢U总迤只Y毀、營迢U呗湘量、翟舅iwca。枷Y史、Ihs蛊閻lh眨hyZSMSISI、雷、皿ft、-s-sdoagv徉H+M映世V徉、Ih逼曼圳赛、Kw克w丽*置m、回呂EK坡、一匸Ms

11、 度量优化精益运营的基础是度量，度量的三大维度：指标、执行监控、预测。首先是明确指标和执行监控，基于软件全生命周期的度量过程中企业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。当DevOps平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。示例如下：m舞咽回顾一下前文的发布

12、流水线的介绍，其实这其中我们在介绍时省略了大量的细节。比如，在开始构建时是否要打一个Tag，此时针对构建介质产物是否不应该是snapshot版本，而应该是Stage预发版本。如果UAT等测试通过之后，这个介质版本即为可发布版本，此时介质需要转移到Release版本的介质仓库。这就是一个完整的流程，也是需要加入到规范中去的。梳理企业的流程和规范是企业建设DevOps的前提，甚至即使不建设DevOps平台，这也是一个必不可少的行为。只有统一了企业的流程和规范，才能建设出一个适用于企业的DevOps平台，否则到最后，有可能会让DevOps平台脱离实际，导致没有人会去使用。我们在建设过程中，每一个模块

13、都需要结合万达的流程规范以及我们的最佳实践共同进行建设，在前期，当一些流程规范不是那么明确的时候，还需要一起讨论，同时规范也不是一蹴而就的，实施过程中发现一些不合适的地方就需要进行修改，这也就带来了需求的反复的可能。以持续交付流水线为例，这个就需要结合万达的环境、发布规范来定制流程，对于其他企业而言，持续交付流水线未必就是这样的一个流程，有可能会少一些环境，也有可能多个预发环境，又或者会把这一个流水线拆分成多个流水线。难点2:异构兼容期理机虔拟机r1L1畀构应用自动化部憲框架福要支撑异构环境、对于应用运行环境而言，需要同时支撑物理机、虚拟机、容器云、Android设备、IOS设备多种类型的环境

14、。而应用本身又分为纯前端应用、SpringBoot应用（FatJAR）、传统应用（WAR）、Android、IOS等各种类型。这就对自动化部署框架提出了很高的要求，一套架构要能同时支撑异构应用部署在异构环境上。m吧以移动应用的自动化部署为例，OS部署组件可以用来区分系统、computer可以用于校验机型。选择部署资源时，从cmdb中导出项目的移动设备资源，最后将应用自动化部署到移动设备上。难点3:职能切面自动化运维平台自动化测统一监控流程平台试平台平台统一账户平台RSBWIDevOps环境耳资源堂湮CMDB平旨kuberntesDevOps平台建设之前，企业可能已经有不少系统了，比如云资源管理

15、平台、容器云云平台、自动化测试平台、统一监控平台等等。那么很多时候一个困难点就在于DevOps的定位了,在测试的能力上QevOps平台要不要完整的把测试的能力都管理起来呢？在自动化部署的时候，要不要直接创建虚拟机对资源进行操作呢？我们在万达落地DevOps的过程中，也遇到了这些问题。我们认为：DevOps无法让每个人的工作都在上面，高级能力还是专人在专业系统上完成；如果专业系统足够自动和自助化，可考虑逐步纳入DevOps平台我们做的是工程效率平台，不是给多个系统做个统一门户本着这些理念我们就明确了对职能的切分。像对底层资源的管理是统一通过CMDB进行管理DevOps只是进行资源的申请与使用。在测试环节，则是对接自动化测试平台，将持续交付流水线中的测试环节拉起来，保障