怎样才能建设一个完美的企业级的DevOps平台

    随着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的优秀设计，结合企业实际的使用场景，用了两个月的时间细化打磨持续交付的能力。