企业级DevOps平台建设方案.docx

企业级DevOps平台建设方案.docx

《企业级DevOps平台建设方案.docx》由会员分享，可在线阅读，更多相关《企业级DevOps平台建设方案.docx（19页珍藏版）》请在冰豆网上搜索。

企业级DevOps平台建设方案

一、DevOps平台建设历程  

随着DevOps理念的兴起，企业的数字化转型的需求也愈发强烈，于是开始着手研发DevOps平台，并在这个过程中不断探索微服务、DevOps、容器云、ChatOps等的关系和最佳实践。

这里为什么要强调“企业级”呢？

一个小团队如果想要实现DevOps能力其实可以很简单，因为团队规模不大，比较容易管理，同时负责的应用也不会特别多，通过集成一些开源的工具完全可以做到持续集成、持续部署、持续交付，同样可以带来极大的效率提升，这其实也是一些互联网企业内部小团队的特色。

但是当这一切放大到一个数百人，数千人甚至数万人的企业时，就会发现遇到的问题、阻碍呈几何级的上涨。

一个企业要考虑的因素太多，历史越悠久的企业，内部的文化、流程越是根深蒂固，而当一个平台需要打通整个IT生命周期时，现有的文化、流程，现有的组织结构都不得不慎重推敲下是否能够满足。

所以，如何建设适合自己企业的DevOps平台，即使现有市场的DevOps理念已经基本普及开了，但是到落地的时候，却总会发现困难重重。

到底该怎么去落地呢？

   明确定位：

DevOps是覆盖IT全生命周期的生产线

对于DevOps平台的定位还是要再明确下，DevOps代表的含义早已不仅仅是简单的开发运维一体化，而是在此基础上，打通产品、项目的软件研发全生命周期，覆盖持续交付、持续改进等能力，在纵向打通应用的全生命周期（需求、设计、开发、编译、构建、测试、部署、运维等），横向打通架构、开发、测试、质量、运维、运营等部门。

我们把DevOps分为三大领域，敏捷过程、持续交付、持续改进，三者相互独立却又相辅相成。

通过DevOps平台将企业软件研发的全生命周期管理起来，在保证质量、安全的前提下，通过一些自动化的手段不断提升软件交付的效率，通过不断精益度量对过程、对技术持续改进，最终支撑起企业的IT精益运营。

   理清思维：

DevOps思维和互联网思维的区别

可能很多人对于DevOps的理念还存在这样的误解：

DevOps来源于互联网，也只适合互联网企业。

但DevOps思维和互联网思维还是有着一定的区别的，不能简单的认为只有互联网公司才适合DevOps。

恰恰相反，其实DevOps理念的提出以及最初的发展并非是互联网公司而是传统企业。

互联网公司强调的是快速、用户口碑，性能，并且对于上线的大部分应用具有一定的容错性，严重的错误可以快速的修改和再上线。

而DevOps追求的是质量、效率、精益、价值、稳定，企业尤其是金融类的企业对于线上应用的问题容忍度其实很很低的，很难想象如果一个交易业务出现问题后，会给企业带来多大的损失。

所以，DevOps绝不只是互联网企业可以实行，对于传统企业而言，更加适合。

通过建设DevOps平台来大幅提升软件研发效率，提升对市场的响应速度，支撑企业的数字化转型，也许对于传统企业而言，DevOps平台带来的价值才是更大的。

   认清价值：

DevOps给你带来怎样的业务价值

清楚了DevOps平台的定位，也明白了DevOps平台对于任何企业都是可以实现的，那么还是回归到自身上，需要结合企业自身的现状思考下：

到底DevOps能给自己的企业带来什么样的业务价值呢？

DevOps平台的理念固然是将软件研发的全生命周期管理起来，但是并不意味着一定要做到全生命周期的管理，落实到企业内部，终究还是要结合企业的现状和实际的需求，有选择性有目标的去建设。

比如某企业由于组织的问题无法打通整个生命周期，那么通过持续集成、自动化测试、自动化部署等能力，提升软件交付的效率也是极好的。

对于企业而言，不管是提升IT的运营效率70%，还是做到开发测试环境的持续集成、自动化测试、自动化部署，亦或是一天部署10次这种DevOps最初的目标，最重要的还是要结合现状，先认清DevOps能给企业带来什么样的业务价值。

   建设步骤：

DevOps平台建设步骤

Step1梳理企业的流程和规范：

梳理企业的流程和规范是企业建设DevOps的前提，甚至即使不建设DevOps平台，这也是一个必不可少的行为。

只有统一了企业的流程和规范，才能建设出一个适用于企业的DevOps平台，否则到最后，有可能会让DevOps平台脱离实际，导致没有人会去使用。

那么有哪些流程和规范是要提前梳理和统一呢？

这里列举几个如下：

·产品（应用）管理规范：

包括版本管理、需求管理的规范等

·项目管理规范：

包括团队的角色构成、过程工作流模板（Agile,CMMI,Scrum）、计划/任务管理规范等

·开发和编译规范：

包括代码开发规范（分支主干的使用）、代码提交规范、构建规范（触发策略，是否需要代码提交时构建等）、介质管理规范等

·部署相关的流程和规范：

比如部署架构的规范，环境的管理规范、软硬件资产管理规范等...

Step2总结自身的痛点和需求，规划建设路线图（MVP）

完整的DevOps平台是个很庞大的体系，如果全都靠自己建设的话，很显然不可能短时间建设完成，那么就要结合自身的痛点，从痛点入手，认清自己最迫切的需求，规划出DevOps平台的建设路线图。

基于MVP（）的理念，一步步有序的推MinimumViableProduct进整个平台建设。

假如自己的企业目前主要的瓶颈在于如何提升研发效率，那么就可以从统一开发平台、打通持续集成作为切入点。

如果目前的主要问题是软件交付速度太慢，那么可以优先考虑持续集成、自动化部署、自动化测试、交付流水线的建设。

Step3从组织、技术、流程、文化四个维度持续优化与改进

DevOps的实施和企业的组织、技术、流程、文化紧密结合，根据我们的经验，在企业中，技术方面的实践最容易在团队中实践，流程次之，组织的优化与变革则是最为困难的。

很多时候，不是技术上打不通整个生命周期，而是一些客观的因素导致无法打通各个部门。

我们建议，在实践的过程中，由易入难，持续优化和改进。

   细节至上：

DevOps平台建设关键点

在建设DevOps平台中，有一些关键点是不得不注意的，简单列举几点：

·如何支持异构环境、异构应用自动化部署？

企业的应用类型多样，纯前端应用（通过nginx等运行），传统war包（通过tomcat等应用服务器运行），springboot应用（fatjar包直接运行）、android应用、IOS应用等等，运行环境复杂的要同时支持物理机、虚拟机、容器云。

如何做到异构环境、异构应用的部署支撑，并且考虑到后续的可扩展性，对于平台架构的设计是有一定要求的，这个会在后面的部署架构的章节中详细介绍。

·如何打通工具链的集成？

其实大部分企业，现状都是在软件研发生命周期各个环节，已经有了一批的工具，只是这些没有串联起来，如果是小工具随便用用还好，但是如果是一些用的比较根深蒂固的，可能就不是那么好替换了，方案会更加倾向于集成。

集成除了技术因素外，还必须要想清楚哪些工具去集成，哪些不集成。

集成到什么程度，比如针对于底层的IaaS平台或者容器云平台，我们就只是进行接口调用，而并非功能的接管。

对于Jenkins这种敏感资源，更倾向于把整个Jenkins封装起来，不对外进行暴露。

·如何与现有的企业流程紧密结合？

不同企业有着不同的流程和规范，以持续交付流水线为例，可以是构建、SIT部署、SIT测试、提测、UAT部署、UAT测试、LAB部署、LAB测试、预发演练、生产部署等环节构成的一个大流程，也有会拆分成集测流程（开发过程中不断运行）、发布流程（从提测开始，UAT和LAB可以是并行的）两个流程，当然也有可能流程和这完全不一样。

这也就对DevOps平台的建设提出了要求，如何和现有的实际流程紧密结合。

除此之外，还有一些问题也是要考虑进去的，如何快速支持流程使用过程中的一些微调（如环节的配置字段属性等）？

如何做到流程手工和自动执行的自定义？

如何让buildNumber贯穿整个流程，让后续环境部署的介质对应的是哪个buildNumber有迹可循？

如何直观的查看交付？

当做到这些的时候，才能让整个交付流程目前到了哪个环节、每个环节的状态是什么样的？

如何以环境为视角，看到该环境下正在运行哪些应用流水线真正的实现价值。

关于这一部分我们的设计同样在后面的持续交付流水线架构章节中进行详细介绍。

·如何支撑企业IT精益运营？

精益运营的基础是度量，度量的三大维度：

指标、执行监控、预测。

首先是明确指标和执行监控，基于软件全生命周期的度量过程中企执行监控业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。

当DevOps平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。

当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。

我们目前主要从质量、效率、进度三个维度，普通员工、团队负责人、部门领导等角色视角出发，提供如下能力：

三、DevOps平台架构剖析     1.总体架构解析

先看看DevOps的整体架构，正如最一开始所说，我们把DevOps平台划分为三大模块：

敏捷过程、持续交付、持续改进。

平台的概念模型如图所示，划分为5大领域：

产品域、组织机构与权限域，项目域、部署域、持续集成域。

平台的逻辑架构如下：

DevOps平台划分为领域层、基础服务层、工具层三层。

领域层和概念模型的5大领域基本一一对应，包括项目管理、产品管理、交付中心、组织机构等。

服务层则是封装的一些基础能力，如编译、部署、代码管理等。

底层运行环境支撑传统主机、PaaS平台、容器云平台。

同时平台机制支持灵活的的扩展（如工具集成扩展、部署能力扩展等），面对复杂的场景或者特殊的需求时，平台也可以提供更加灵活地能力。

   2.敏捷过程

敏捷过程的架构核心在于工作项（WorkItem）的设计，工作项涵盖了需求（长篇故事、特性、用户故事）、开发（任务、缺陷）、测试（测试用例、测试计划）等。

可以说，在整个项目周期中，将所有的工作项统一管理起来，工作流和工作项关联，不同的过程对应不同的工作项，比如Agile对应的需求相关工作项是Feature/Story。

Scrum过程体系对应的需求工作项则是Epic/Feature/UserStory。

通过对工作项的设计，可能支撑多种工作流的差异化，便于设计和扩展，同时，可以从统一的视角查看所有的工作项，更加便于统一管理、统计分析。

其实jira、tfs也是类似的设计思路，只不过jira把一切看成是“issue”，tfs则是把一切看成“工作项”。

以需求为例说明，需求分Epic/Feature/UserStory三层，每一层都是一种工作项，工作项有哪些属性，属性对应的值类型，控件类型都会在数据中定义，页面上表单页面通过数据库中定义的属性和控件数据动态生成表单。

用户可以自定义项目中需求属性和状态。

   3.持续集成

持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。

在构建定义管理模块中，DevOps平台将构建任务分成了四种类型：

·编译类任务：

Maven、Ant、Gradle、纯前端构建等

·测试类任务：

Sonarqube、Jmeter、Selenium等

·打包类任务：

Npm、Archive、Docker等