普元从 2008 年开始研发持续集成平台（CIP）、自动化测试平台（UTP），2009 年内部的所有产品都实现了持续集成、自动化测试、自动化部署。
随着 DevOps 理念的兴起，企业的数字化转型的需求也愈发强烈，于是开始着手研发 DevOps 平台，并在这个过程中不断探索微服务、DevOps、容器云、ChatOps 等的关系和最佳实践。DevOps 先后历经 4 个大版本，目前已经完成了落地的实践。
2015.7~2016.4：为支撑企业数字化转型，普元开始研发数字化企业云平台（ThePlatform），于 2016 年 4 月完成 1.0 版本并进行内部上线。1.0 版本主要提供了持续集成和持续部署的能力，同时还包含了自己的容器云平台，与容器云平台对接，贯穿设计、开发、测试、上线、维护五大软件研发生命周期，打通代码提交、触发集成、自动部署到容器云的快速链路。
2016.5~2016.9：基于自己吃自己狗粮的思想，通过 1.0 版本研发了 2.0 版本，考虑到产品的发展，将数字化企业云平台中的产品各自独立拆分出来，包括 DevOps、容器云。每个产品都有着独立团队，持续发展。DevOps2.0 在 1.0 版本的基础上，打通规划、需求等环节，将产品管理、项目任务管理等能力纳入进来。
做了 2.0 版本，大家反倒有些困惑了，DevOps 平台真的就只是简单的通过和某些工具（如 Jenkins）集成，然后一键编译、部署到容器云上就可以了吗。我们开始借鉴很多国外的优秀产品，同时也开始和更多的其他公司进行深度交流。慢慢地发现，真正实现一个企业级的 DevOps 平台，远不止和 Jenkins 做集成、一键部署到容器云这么简单。以持续集成为例，一个企业要支持的集成环境肯定不止一种，包括 maven 编译、ant 编译、android 编译、ios 编译、前端应用编译（nodejs），在集成时还要考虑和代码质量分析，单元测试、单元测试覆盖率检查、介质上传等能力的结合，其实集成也是一个工作流。
最典型的一个流程如：maven 编译 (包含单元测试)–》代码质量分析 –》交付物上传到二方库。在构建后还应该看到详细结果：构建详情、日志、单元测试报告、代码质量分析报告、介质查看与下载等能力。想想，这样的一个过程是不是才能基本满足了企业的正常使用方式？
以部署而言，企业的真实环境又岂会是只有容器云。对于大部分企业而言，物理机是必须的，有的企业甚至物理机、虚拟机、容器云三种环境并存，那么在部署的能力上，只支撑容器云环境的部署显然是远远不够的，至于企业实际的部署能力，自然又更加的复杂：应用部署（springboot 应用，传统 war 包、纯前端应用）、中间件部署（数据库部署、分布式缓存、分布式消息队列）等都要一一考虑。所以在 2016.7~2016.8，我们开始研发 3.0 版本中，在持续集成和自动化部署的能力上，参考 tfs 和 oneops 的优秀设计，结合企业实际的使用场景，用了两个月的时间细化打磨持续交付的能力。
2016 年 10 月份开始，我们重新梳理了整个 DevOps 平台的需求，将整个平台划分成了三大领域：敏捷过程、持续交付、持续改进。
- 敏捷过程：包含产品管理、项目管理、任务管理、进度管理、计划管理等，覆盖产品、项目的全生命周期。
- 持续交付：包含代码库的管理、持续集成、部署、交付流水线等能力，意在打通从代码提交到部署上线的全流程。持续集成支持编译、打包、测试、工具四类构建任务，支持代码提交时触发构建、定时构建、手动构建三种构建触发策略。在部署方面，支持 springboot 应用、传统 war 包、html 站点、mysql 等部署，支持灰度发布、滚动升级、蓝绿发布等多种部署策略。
- 持续改进：包含质量标准、质量监控、以及产品项目全生命周期过程中的各种度量报表。支撑企业的精益度量。
这里为什么要强调“企业级”呢？一个小团队如果想要实现 DevOps 能力其实可以很简单，因为团队规模不大，比较容易管理，同时负责的应用也不会特别多，通过集成一些开源的工具完全可以做到持续集成、持续部署、持续交付，同样可以带来极大的效率提升，这其实也是一些互联网企业内部小团队的特色。但是当这一切放大到一个数百人，数千人甚至数万人的企业时，就会发现遇到的问题、阻碍呈几何级的上涨。一个企业要考虑的因素太多，历史越悠久的企业，内部的文化、流程越是根深蒂固，而当一个平台需要打通整个 IT 生命周期时，现有的文化、流程，现有的组织结构都不得不慎重推敲下是否能够满足。所以，如何建设适合自己企业的 DevOps 平台，即使现有市场的 DevOps 理念已经基本普及开了，但是到落地的时候，却总会发现困难重重。到底该怎么去落地呢？
对于 DevOps 平台的定位还是要再明确下，DevOps 代表的含义早已不仅仅是简单的开发运维一体化，而是在此基础上，打通产品、项目的软件研发全生命周期，覆盖持续交付、持续改进等能力，在纵向打通应用的全生命周期（需求、设计、开发、编译、构建、测试、部署、运维等），横向打通架构、开发、测试、质量、运维、运营等部门。
我们把 DevOps 分为三大领域，敏捷过程、持续交付、持续改进，三者相互独立却又相辅相成。通过 DevOps 平台将企业软件研发的全生命周期管理起来，在保证质量、安全的前提下，通过一些自动化的手段不断提升软件交付的效率，通过不断精益度量对过程、对技术持续改进，最终支撑起企业的 IT 精益运营。
可能很多人对于 DevOps 的理念还存在这样的误解：DevOps 来源于互联网，也只适合互联网企业。但 DevOps 思维和互联网思维还是有着一定的区别的，不能简单的认为只有互联网公司才适合 DevOps。恰恰相反，其实 DevOps 理念的提出以及最初的发展并非是互联网公司而是传统企业。互联网公司强调的是快速、用户口碑，性能，并且对于上线的大部分应用具有一定的容错性，严重的错误可以快速的修改和再上线。而 DevOps 追求的是质量、效率、精益、价值、稳定，企业尤其是金融类的企业对于线上应用的问题容忍度其实很很低的，很难想象如果一个交易业务出现问题后，会给企业带来多大的损失。
所以，DevOps 绝不只是互联网企业可以实行，对于传统企业而言，更加适合。通过建设 DevOps 平台来大幅提升软件研发效率，提升对市场的响应速度，支撑企业的数字化转型，也许对于传统企业而言，DevOps 平台带来的价值才是更大的。
清楚了 DevOps 平台的定位，也明白了 DevOps 平台对于任何企业都是可以实现的，那么还是回归到自身上，需要结合企业自身的现状思考下：到底 DevOps 能给自己的企业带来什么样的业务价值呢？DevOps 平台的理念固然是将软件研发的全生命周期管理起来，但是并不意味着一定要做到全生命周期的管理，落实到企业内部，终究还是要结合企业的现状和实际的需求，有选择性有目标的去建设。比如某企业由于组织的问题无法打通整个生命周期，那么通过持续集成、自动化测试、自动化部署等能力，提升软件交付的效率也是极好的。
对于企业而言，不管是提升 IT 的运营效率 70%，还是做到开发测试环境的持续集成、自动化测试、自动化部署，亦或是一天部署 10 次这种 DevOps最初的目标，最重要的还是要结合现状，先认清 DevOps 能给企业带来什么样的业务价值。
Step 1 梳理企业的流程和规范：
梳理企业的流程和规范是企业建设 DevOps 的前提，甚至即使不建设 DevOps 平台，这也是一个必不可少的行为。只有统一了企业的流程和规范，才能建设出一个适用于企业的 DevOps 平台，否则到最后，有可能会让 DevOps 平台脱离实际，导致没有人会去使用。那么有哪些流程和规范是要提前梳理和统一呢？这里列举几个如下：
- 产品（应用）管理规范：包括版本管理、需求管理的规范等
- 项目管理规范：包括团队的角色构成、过程工作流模板（Agile,CMMI,Scrum）、计划 / 任务管理规范等
- 开发和编译规范：包括代码开发规范（分支主干的使用）、代码提交规范、构建规范（触发策略，是否需要代码提交时构建等）、介质管理规范等
- 部署相关的流程和规范：比如部署架构的规范，环境的管理规范、软硬件资产管理规范等…
Step 2 总结自身的痛点和需求，规划建设路线图（MVP）
完整的 DevOps 平台是个很庞大的体系，如果全都靠自己建设的话，很显然不可能短时间建设完成，那么就要结合自身的痛点，从痛点入手，认清自己最迫切的需求，规划出 DevOps 平台的建设路线图。基于 MVP（ ）的理念，一步步有序的推 Minimum Viable Product进整个平台建设。假如自己的企业目前主要的瓶颈在于如何提升研发效率，那么就可以从统一开发平台、打通持续集成作为切入点。如果目前的主要问题是软件交付速度太慢，那么可以优先考虑持续集成、自动化部署、自动化测试、交付流水线的建设。
Step 3 从组织、技术、流程、文化四个维度持续优化与改进
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 的整体架构，正如最一开始所说，我们把 DevOps 平台划分为三大模块：敏捷过程、持续交付、持续改进。平台的概念模型如图所示，划分为 5 大领域：产品域、组织机构与权限域，项目域、部署域、持续集成域。
平台的逻辑架构如下：
DevOps 平台划分为领域层、基础服务层、工具层三层。领域层和概念模型的 5 大领域基本一一对应，包括项目管理、产品管理、交付中心、组织机构等。服务层则是封装的一些基础能力，如编译、部署、代码管理等。底层运行环境支撑传统主机、PaaS 平台、容器云平台。同时平台机制支持灵活的的扩展（如工具集成扩展、部署能力扩展等），面对复杂的场景或者特殊的需求时，平台也可以提供更加灵活地能力。
敏捷过程的架构核心在于工作项（WorkItem）的设计，工作项涵盖了需求（长篇故事、特性、用户故事）、开发（任务、缺陷）、测试（测试用例、测试计划）等。可以说，在整个项目周期中，将所有的工作项统一管理起来，工作流和工作项关联，不同的过程对应不同的工作项，比如 Agile 对应的需求相关工作项是 Feature/Story。Scrum 过程体系对应的需求工作项则是 Epic/Feature/UserStory。
通过对工作项的设计，可能支撑多种工作流的差异化，便于设计和扩展，同时，可以从统一的视角查看所有的工作项，更加便于统一管理、统计分析。其实 jira、tfs 也是类似的设计思路，只不过 jira 把一切看成是“issue”，tfs 则是把一切看成“工作项”。
以需求为例说明，需求分 Epic/Feature/UserStory 三层，每一层都是一种工作项，工作项有哪些属性，属性对应的值类型，控件类型都会在数据中定义，页面上表单页面通过数据库中定义的属性和控件数据动态生成表单。用户可以自定义项目中需求属性和状态。
持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中，DevOps 平台将构建任务分成了四种类型：
- 编译类任务：Maven、Ant、Gradle、纯前端构建等
- 测试类任务：Sonarqube、Jmeter、Selenium 等
- 打包类任务：Npm、Archive、Docker 等
- 其他工具类任务：Copyfile、、介质提交到 Nexus 仓库、介质上传二方库等。
在每个构建定义上可以选择若干个需要的构建任务，通过原子步骤编排，组装成一个完整构建流程。代码提交时触发构建（支持 gitlab、github、svn 等常用代码库版本管理工具）、日构建等不同的构建触发策略等支撑了持续集成的完整链路打通。
在持续集成的领域，绝大多数企业应该都会选择 Jenkins 吧，我们也不例外。持续集成模块的核心框架就是 Jenkins。每个构建任务对应 Jenkins 的一个 pipeline stage。在执行时，将所有构建任务结合构建定义的一些基础信息，创建 Jenkins 的 pipeline 进行执行。
Jenkins 的搭建采用 master/slave 集群模式，面对大量应用的编译压力时可以更好的分散压力，保证编译速度。如果想更灵活的话，可以考虑 Jenkins 集群部署在容器中，通过容器云的动态伸缩能力，可以更灵活的去使用资源。这里要提到一个关于异构环境的编译，如 ios 应用的编译，就必须在 mac os 系统中进行。这就要求编译机和其他的机器有所区别。我们是采用 Jenkins 的节点标签能力，如果是要进行 ios 编译任务的话，就会通过标签到 ios 的工作节点中执行任务。
在自动化部署模块中，为了更好的与实际结合，我们将部署分为三个阶段：设计、转换、运维。
设计阶段：将部署架构分为三层：部署装配（Assembly）、部署容器（Platform）、部署组件 (Component)。部署装配是对部署架构的描述，由多个部署容器组成，每个部署容器由若干个部署组件组成。
操作流程：
- 创建 Assembly
- 通过选择可用的系统模版 (Platform Template)，添加一个新的 Platform。
- 每一个 Platform 都对应一种应用（如 mysql，tomcat，springboot，nginx）。
- 每一个 Platform 都是有一组组件（Component）组成的，并且已定义好了组件之间的依赖关系。
- 管理 ComponentComponent 是最底层的部署（或者配置）单元，如 springboot 中的 secgroup, compute, os, jdk, fatjar, lb 都是一个组件每一个 Component 都有相应的配置模版。
- 提交设计提交的过程是将已经完成的设计做一次 Commit，做一次归档。
转换阶段：转换（Transition），是在 Assembly 内对应用 / 系统在某一具体部署环境内的部署过程。部署环境是配置、架构设计、运行资源、部署策略的结合。
操作流程：
- 创建部署环境（Deploy Environment）根据环境类型 (如 dev, test, prod 等)，添加属于某个 Assembly 的部署环境。部署之前，部署环境是应用 / 系统用于部署的配置的抽象。部署之后，部署环境就是管理和监控应用 / 系统的具体实例的集合。
- 配置部署环境设置每个 Platform 关联的资源（vm/container）、部署模式（单点，高可用）
- 选择 Assembly 内的一个或多个 Platform 生成并提交执行计划根据部署策略不同，一个 Platform 的执行计划可能包含几个子计划
- 执行部署每个 Assembly/Environment/Platform 下面的每个 Component 都有一个部署实例，这些实例可以进行单独操作
运维阶段：对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等
考虑到驱动的统一性以及 Jenkins2 插件的丰富性，DevOps 自动化部署框架底层同样使用了 Jenkins。采用 DevOps 平台（设计）＋Jenkins（执行）的方式完成。
DevOps 的职责：
- 完成部署架构设计；
- 根据部署架构设计和部署环境的配置创建生成相应的执行计划及子执行计划，每一个子计划对应一个 Jenkins pipelinejob 配置文件 (config.xml)；
- 查询 Jenkins 执行 job 的实时进度与结果。
Jenkins 的职责：
- 根据 config.xml 创建 Jenkins Pipeline Job；
- 执行 pipeline job；
- Jenkins job 通过 pipeline script 中 ansible／openshift 进行相应的部署等执行操作；
- 提供查询 job 执行情况的 Rest API。
DevOps 平台中的部署架构设计和 Jenkins pipeline 的映射关系如下图所示：
可以看到每个组件都会对应 Jenkins 的一个 stage。所有的 stage 组装成一个完整的 pipeline 在通过 Jenkins 执行。
为什么选择 Jenkins pipeline? 主要是结合以下几点进行考虑的
- durable 持久性：在 Jenkins 的 master 按计划和非计划的重启后，pipeline 的 job 仍然能够工作，不受影响。
- 可暂停性：pipeline 基于 groovy 可以实现 job 的暂停和等待用户的输入或批准然后继续执行。
- 更灵活的并行执行，更强的依赖控制，通过 groovy 可以实现 step，stage 间的并行执行，和更复杂的相互依赖关系。
- 可扩展性：通过 groovy 的编程更容易的扩展插件。
- 丰富插件：Jenkins 已经支持通过 groovy 调用 git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes 等插件，不需要我们再单独实现集成。
- Rest API：Jenkins 提供通过 Rest API 的方式获取每一个 stage 的执行情况。
有了持续集成、部署、测试的能力是否就足够了呢？其实还是不够，DevOps 的本质是 IT 生产线，交付流水线是持续交付的核心能力，它可以把分散的能力如构建、部署、测试等串联在一起，形成一个从代码提交到发布上线的流水线，通过流水线可以很直观的看到当前某个具体构建版本已经到了哪一个环节，从整体上对于软件交付进行更好的把控。
在设计流水线能力时，我们主要考虑到几点：
- 结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置
- 流程的每一个环节都要支持自动执行的配置
- 流程中每个环节的属性和配置信息可以自定义，灵活扩展
- 流程以构建开始，让 buildNumber 贯穿整个流程，方便追根溯源
- 要有一个看板，直观的看到整个产品的版本目前到了流程的哪个环节，是 SIT 还是 UAT，结果如何
- 要有一个看板，直观的看到每个环境下，有哪些介质在运行
以这些为基础准则，我们底层基于了普元的 BPS 流程引擎，支撑流程的自定义和扩展。并且，针对于每个环节，都可以配置前置后置事件、人工执行还是自动执行，责任人等。整个流水线从构建开始，以代码的 buildNumber 贯穿全流程。便于问题、进度的追溯。看板的设计如下：
Q1 ：实施DevOps过程中，持续集成上线有没有引入A/B测试？DevOps 如何开展主流程压力测试的？
A1： A/B测试现阶段我们还没有引进，压力测试我们是通过集成JMeter实现的，部署到LAB环境，调用JMeter实现压力测试。
Q2： 2009年就实现了CI CD和自动化测试，那DevOps和他们比起来最大的优势是？
A2： 最早之前都是自己内部的，主要做到了日编译。应用类型比较少，没有考虑移动应用、纯前端应用、中间件的部署。测试倒是涵盖了IDE测试以及WEB的自动化测试。并且没有真正的把持续集成、自动化部署、自动化测试彻底打通，很多数据都没有收集起来。DevOps的真正价值，除了更全面的交付能力，提升软件交付速度外，很大一方面在于打通了软件生产的全生命周期。从而对整个软件过程进行度量和管理，提升软件交付的质量。
Q3：我们公司现在的业务需求完全hold住，IT不是主要部门，我在思考是不是不需要DevOps?毕竟DevOps改造的过程成本很大吧？
A3： 是否要实施确实要结合企业实际情况的，如果业务或者应用不多，就几个应用，并且短时间看不到扩大的话，实施DevOps确实意义不大，反之则可以考虑下。并且实施DevOps并非要一口气就打通整个生命周期，可以有选择的一步步建设。比如可以先从持续交付开始实施，至少提升IT的交付效率也是一件很好的事情。以后有机会可以再考虑扩大到整个生命周期。
Q4：请问怎么通知到下一环节呢？通过什么样的方式
A4： 我们采用了我们自己的BPS流程引擎，在流程中进行环节的流转的。通知的方式可以结合企业不同的需求，比如集成邮件、内部通讯工具、OA系统等。
Q5：那传统的运维人员不转型DevOps是不是要失业了？
A5：呵呵，其实现在随着IaaS/CaaS/DevOps等理念的盛行和落地，并不是说传统运维人员要面临淘汰，而是传统运维的工作新挑战。压力更大，比如基础环境的维护，比如部署的管理。运维依旧是很关键的一环。
Q6：普元公司都涉及到哪些业务啊？
A6：普元为金融、通信、企业和政府用户提供软件平台产品和解决方案，产品包括 SOA、云计算、大数据 三方面，帮助用户实现数字化转型。
Q7：请问Jenkins是自动一键构建到开发、测试各个不通的环境吗？如果不是如何保证代码唯一性？
A7： 是的，正如文章里分享的一样，在整个发布流水线中，构建是第一步，后面到各个环境的部署，除了生产环境的部署外，其他都是用的同一份介质。生产部署前会将介质提交到release库中。
Q8：想请问王老师，devops和微服务之间是一个什么样的关系，或者说是如何结合在一起的，我们公司的业务大都使用PHP做主要开发语言，近期打算往服务化这方面去转变，但现在网上能找到的大多数微服务相关的资料都是基于Java，想请问王老师对于PHP有没有好的微服务框架或者书籍资料的推荐，谢谢！
A8：微服务其实和容器云结合的很好，但是二者结合，传统的单个应用，拆分成了N个微服务，跑在N个容器中，很难管理和运维。DevOps平台和微服务、容器云平台的关系，我认为是DevOps提供了一个平台，将微服务和容器云从很散、很裸的状态有效的管理起来，即使应用拆分的很散，依旧可以很方便的进行运维管理。对于PHP我确实也不是特别了解，不好意思~
Q9：DevOps一定是指完全打通吗？那就是开发运维职责有交叠了？
A9：DevOps的完整场景是打通软件生产的全生命周期，但是由于企业的现实情况，往往确实很难打通。可以考虑先有选择的部分建设DevOps，等到有机会了再整体打通。开发和运维的职责还是会切分开的，只是他们共同在平台上协作。包括测试和QA等角色。比如运维需要去管理和开通机器。如果是虚拟机和容器云的话，运维则只需要提供好相关的接口和保证资源充足，开发测试环境完全可以让开发和测试人员直接在平台去部署。平台会调用底层接口创建虚拟机和容器。
原文来自：
本文地址：//q13zd.cn/devops-open-linux.html编辑员：郭建鹏，审核员：逄增宝
本文原创地址：//q13zd.cn/devops-open-linux.html编辑：roc_guo，审核员：暂无
