转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：
DevOps的理念已经说了不少年，其带来的价值逐渐被接受，不少企业也逐渐引入了DevOps。目前普元DevOps平台发布到5.2版本，这期间为多个客户实施了DevOps平台。那么，实施的主要过程是怎样的，在实施过程当中会遇到哪些问题又是如何解决的，本文将和你们一块儿探讨这些问题。
目录：
1、DevOps平台简介
2、DevOps平台实施过程
3、问题和解决方案
4、实施效果
1、DevOps平台简介
首先简单介绍一下DevOps平台，看下能力矩阵和整合的工具链，对DevOps平台有一个大体的了解。微信
DevOps的能力矩阵
DevOps整合工具
2、DevOps平台实施过程
调研和评估
调研和评估过程主要为了了解客户的管理成熟度和重要流程，以此为依据制定提高目标及改进方案，为迁移到DevOps平台作准备。为此，咱们整理了调研问卷，涉及项目研发的整个过程。
在实施初期，咱们通常会选择比较有表明性的项目，进行调研和分析。咱们会从需求管理、开发、代码管理、构建、测试、部署、发布这几个方面进行调研和分析，判断项目是否适合迁移到DevOps平台，项目研发过程的某些环节是否须要进行改进和完善。
根据调研问卷，各方面的具体关注点以下：
需求管理：需求管理工具、用户故事、任务、迭代等 开发：开发语言、开发工具、技术框架、运行环境、组件划分及依赖关系等 代码管理：代码及文档管理工具、代码库分支及用途、分支策略、代码质量检测工具及质量指标等 构建：构建工具、构建过程及构建策略、构建介质策略、中间介质及最终介质管理等 测试：用例和Bug管理、自动化测试工具、验收标准等 部署：环境规划、环境配置、部署方式、依赖的中间件和公共组件等 发布：上线交付物、发布流程、应用及数据备份方式、回滚方式等
本阶段产出文档：调研问卷、提高建议和改进方案。
制定规范
通过对典型项目的调研和分析，结合客户的实际关切点，根据最佳实践制定相关规范，为后续项目迁移到DevOps平台提供条件。
这里主要介绍两个规范：
代码库规范：包括分支和标签命名规范、分支管理规范（管理流程、hotfix流程、分支策略）、代码提交规范。
以分支开发、主干发布为例，管理流程规范中会涉及代码库准备、开发集成、验收测试、发布环节，每一个环节中涉及的角色，角色的操做流程都有详细规范。
CICD流程规范：命名规范：组件、介质仓库、构建定义、构建产物别名、发布定义。流水线规范：开发流水线、用户验收测试流水线及回滚流水线、发布流水线及回滚流水线、hotfix流水线。
经过制定流水线的规范，造成不一样类型项目的CICD流程模版，能够做为组织级规范进行审计。
对于流水线的定义和设计，须要考虑客户的环境规划和网络策略。通常状况下，会设计和定义开发测试流水线、用户验收测试流水线、发布流水线这些常规流水线，对应开发测试环境、用户验收环境、生产环境。开发测试流水线通过屡次执行，业务系统造成稳定版本，交付到用户验收测试流水线，经过用户验收测试以后，再转到发布流水线进行发布上线；这个过程也设计到代码分支和标签的维护。
有的客户，阶段交付物是某个版本的工件介质，而且介质库能够多环境共享或者同步，这种状况下须要在开发测试流水线中设计构建环节和部署环节，在用户验收流水线和发布流水线不须要构建环节，由于交付介质像下一个环境同步便可。
流水线设计以下：
有的客户阶段交付物是代码，且各个环境有网络策略限制。这种类型的流水线，不一样环境须要根据对应的代码分支或标签将介质构建出来，而后再进行部署。
流水线设计以下：
产出文档：代码库规范文档、CICD流程规范、流程配置规范、度量指标等。
培训
主要是对DevOps平台和相关的规范的培训。DevOps平台的培训，主要是为了让用户熟悉DevOps的能力。规范培训，主要结合具体的使用场景和最佳实践让用户了解和熟悉代码库、CICD流程等规范。
项目试点及推广
项目试点是很是重要的环节，也是后续可否进行推广的重要评判依据。通过前期的项目改进，以及流程规范的普及推广，试点项目做出适当调整，试点项目的迁移是对以前全部工做的一个重要检验。
在试点阶段，一方面是要经过试点项目的规范化改造，打造同类项目的流程规范，造成可复制的流水线模式；另外一方面看迁移先后给试点项目带来哪些好的效果，是否符合预期，是否还有须要改进的空间，平台能力是否须要提高等等。项目试点阶段产出的文档和手册是后续推广的重要资源。
当试点项目的迁移达到预期效果，就能够进行DevOps平台的普及推广。
3、常见问题和解决方案
工具整合
在DevOps实施过程当中，工具链的打通必然涉及各类工具的整合。除了DevOps平台自己已经集成的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具，比较常见的是对客户已有工具等集成，如客户自建的项目管理平台、CMDB平台、自动化测试平台等等。
对于用户自建工具的整合，首先须要去理清整合的真正目的是什么，能为用户带来哪些价值。好比，对项目管理平台的整合，DevOps平台能够对项目等迭代、需求、任务等信息进行收集和汇总，最终项目的进度、成本一目了然。再好比，对CMDB的集成，对于CD过程当中使用的资源（主机、容器），直接从CMDB拉取数据便可，无需在DevOps平台中从新配置一遍。
这里建议，对已有工具的整合，整合的是数据，目的是让数据流转和汇总起来，而非作功能的整合。
环境
不一样的客户对环境的规划每每也不一样，好比有的客户规划为开发环境、集成测试环境、用户验收环境、生产环境，也有客户在生产环境前还有预发环境；对于不一样环境的隔离，不一样客户的作法也不尽相同。
某电信客户的部署架构，经过防火墙策略+Nginx管控环境间的网络通讯
某银行客户的部署架构，经过防火墙策略管控环境间的网络通讯，可是要经过堡垒机链接部署机
对环境和网络的管控，通常都是硬性要求，须要符合客户的管理规范。这就须要根据实际的环境和网络要求，调整DevOps平台的部署架构，并按照客户的规范开通相关策略，这里会有必定的沟通成本和实施成本。
任务类型支持
DevOps平台中的构建和部署流程通常由若干个可编排和可配置化的任务组成，平台中内置了经常使用的构建和发布相关的任务，能知足绝大部份构建和部署场景。
构建相关任务
发布相关任务
若是内置的任务中没法知足使用需求，还能够根据DevOps平台提供的扩展手册进行任务扩展。
4、实施效果
规范化、统一化
项目迁移到DevOps平台，各个项目能够在一个统一的DevOps平台进行CICD，无需各自搭建持续集成平台。经过制定合理的规范，不一样的项目遵照一致的规范，避免了代码库、CICD流程的管理混乱和不规范。制定度量指标和规范，对软件开发成果和开发过程的测量和分析，帮助对软件开发过程持续进行改进，有效提升软件交付质量和效率。
研发效能提高
可视化和可编排，无需编写pipeline脚本，一次配置，屡次执行。提交或合并代码出发、定时触发或手动一键执行构建和部署，提升研发人员效率。有效减小系统变动部署上线的时间，快速响应业务变化。
报表展现、可度量
从效率、质量、进度三个维度展现任务、代码、构建、部署相关数据，结合项目看板、报表和度量指标，各环节干系人能够对进度、质量等进行判断和干预。
总结： DevOps的建设是难以短时间内完成的，须要进行整体规划，而后分阶段实施。不管是工具的整合，仍是度量体系的实施，都须要循序渐进、按部就班，逐步完成建设，最终实现预期目标。