DEVOPS落地实践分享

DEVOPS落地实践分享

转载本文需注明出处：微信公众号EAWorld，违者必究。

引言：

DevOps的理念已经说了很多年，其带来的价值逐渐被接受，很多企业也逐渐引入了DevOps。目前普元DevOps平台发布到5.2版本，这期间为多个客户实施了DevOps平台。那么，实施的主要过程是怎样的，在实施过程中会遇到哪些问题又是如何解决的，本文将和大家一起探讨这些问题。

目录：

一、DevOps平台简介
二、DevOps平台实施过程
三、问题和解决方案
四、实施效果

一、DevOps平台简介

首先简单介绍一下DevOps平台，看下能力矩阵和整合的工具链，对DevOps平台有一个大致的了解。

DevOps的能力矩阵

DevOps整合工具

二、DevOps平台实施过程

调研和评估

调研和评估过程主要为了了解客户的管理成熟度和重要流程，以此为依据制定提升目标及改进方案，为迁移到DevOps平台做准备。为此，我们整理了调研问卷，涉及项目研发的整个过程。

在实施初期，我们一般会选择比较有代表性的项目，进行调研和分析。我们会从需求管理、开发、代码管理、构建、测试、部署、发布这几个方面进行调研和分析，判断项目是否适合迁移到DevOps平台，项目研发过程的某些环节是否需要进行改进和完善。

根据调研问卷，各方面的具体关注点如下：

需求管理：需求管理工具、用户故事、任务、迭代等 开发：开发语言、开发工具、技术框架、运行环境、组件划分及依赖关系等 代码管理：代码及文档管理工具、代码库分支及用途、分支策略、代码质量检测工具及质量指标等 构建：构建工具、构建过程及构建策略、构建介质策略、中间介质及最终介质管理等 测试：用例和Bug管理、自动化测试工具、验收标准等 部署：环境规划、环境配置、部署方式、依赖的中间件和公共组件等 发布：上线交付物、发布流程、应用及数据备份方式、回滚方式等 
本阶段产出文档：调研问卷、提升建议和改进方案。

制定规范

经过对典型项目的调研和分析，结合客户的实际关切点，根据最佳实践制定相关规范，为后续项目迁移到DevOps平台提供条件。

这里主要介绍两个规范：

代码库规范：包括分支和标签命名规范、分支管理规范（管理流程、hotfix流程、分支策略）、代码提交规范。 
以分支开发、主干发布为例，管理流程规范中会涉及代码库准备、开发集成、验收测试、发布环节，每个环节中涉及的角色，角色的操作流程都有详细规范。

CICD流程规范：命名规范：组件、介质仓库、构建定义、构建产物别名、发布定义。流水线规范：开发流水线、用户验收测试流水线及回滚流水线、发布流水线及回滚流水线、hotfix流水线。 
通过制定流水线的规范，形成不同类型项目的CICD流程模版，可以作为组织级规范进行审计。

对于流水线的定义和设计，需要考虑客户的环境规划和网络策略。一般情况下，会设计和定义开发测试流水线、用户验收测试流水线、发布流水线这些常规流水线，对应开发测试环境、用户验收环境、生产环境。开发测试流水线经过多次执行，业务系统形成稳定版本，交付到用户验收测试流水线，通过用户验收测试之后，再转到发布流水线进行发布上线；这个过程也设计到代码分支和标签的维护。

有的客户，阶段交付物是某个版本的工件介质，并且介质库可以多环境共享或者同步，这种情况下需要在开发测试流水线中设计构建环节和部署环节，在用户验收流水线和发布流水线不需要构建环节，因为交付介质像下一个环境同步即可。

流水线设计如下：


有的客户阶段交付物是代码，且各个环境有网络策略限制。这种类型的流水线，不同环境需要根据对应的代码分支或标签将介质构建出来，然后再进行部署。

流水线设计如下：



产出文档：代码库规范文档、CICD流程规范、流程配置规范、度量指标等。

培训

主要是对DevOps平台和相关的规范的培训。DevOps平台的培训，主要是为了让用户熟悉DevOps的能力。规范培训，主要结合具体的使用场景和最佳实践让用户了解和熟悉代码库、CICD流程等规范。

项目试点及推广

项目试点是非常重要的环节，也是后续能否进行推广的重要评判依据。经过前期的项目改进，以及流程规范的普及推广，试点项目作出适当调整，试点项目的迁移是对之前所有工作的一个重要检验。

在试点阶段，一方面是要通过试点项目的规范化改造，打造同类项目的流程规范，形成可复制的流水线模式；另一方面看迁移前后给试点项目带来哪些好的效果，是否符合预期，是否还有需要改进的空间，平台能力是否需要提升等等。项目试点阶段产出的文档和手册是后续推广的重要资源。

当试点项目的迁移达到预期效果，就可以进行DevOps平台的普及推广。

三、常见问题和解决方案

工具整合

在DevOps实施过程中，工具链的打通必然涉及各种工具的整合。除了DevOps平台本身已经集成的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具，比较常见的是对客户已有工具等集成，如客户自建的项目管理平台、CMDB平台、自动化测试平台等等。

对于用户自建工具的整合，首先需要去理清整合的真正目的是什么，能为用户带来哪些价值。比如，对项目管理平台的整合，DevOps平台可以对项目等迭代、需求、任务等信息进行收集和汇总，最终项目的进度、成本一目了然。再比如，对CMDB的集成，对于CD过程中使用的资源（主机、容器），直接从CMDB拉取数据即可，无需在DevOps平台中重新配置一遍。

这里建议，对已有工具的整合，整合的是数据，目的是让数据流转和汇总起来，而非做功能的整合。

环境

不同的客户对环境的规划往往也不同，比如有的客户规划为开发环境、集成测试环境、用户验收环境、生产环境，也有客户在生产环境前还有预发环境；对于不同环境的隔离，不同客户的做法也不尽相同。

某电信客户的部署架构，通过防火墙策略+Nginx管控环境间的网络通信



某银行客户的部署架构，通过防火墙策略管控环境间的网络通信，但是要通过堡垒机连接部署机



对环境和网络的管控，一般都是硬性要求，需要符合客户的管理规范。这就需要根据实际的环境和网络要求，调整DevOps平台的部署架构，并按照客户的规范开通相关策略，这里会有一定的沟通成本和实施成本。

任务类型支持

DevOps平台中的构建和部署流程一般由若干个可编排和可配置化的任务组成，平台中内置了常用的构建和发布相关的任务，能满足绝大部份构建和部署场景。

构建相关任务



发布相关任务



如果内置的任务中无法满足使用需求，还可以根据DevOps平台提供的扩展手册进行任务扩展。

四、实施效果

规范化、统一化

项目迁移到DevOps平台，各个项目可以在一个统一的DevOps平台进行CICD，无需各自搭建持续集成平台。通过制定合理的规范，不同的项目遵守一致的规范，避免了代码库、CICD流程的管理混乱和不规范。制定度量指标和规范，对软件开发成果和开发过程的测量和分析，帮助对软件开发过程持续进行改进，有效提高软件交付质量和效率。

研发效能提升

可视化和可编排，无需编写pipeline脚本，一次配置，多次执行。提交或合并代码出发、定时触发或手动一键执行构建和部署，提高研发人员效率。有效减少系统变更部署上线的时间，快速响应业务变化。

报表展示、可度量

从效率、质量、进度三个维度展示任务、代码、构建、部署相关数据，结合项目看板、报表和度量指标，各环节干系人可以对进度、质量等进行判断和干预。

总结：

DevOps的建设是难以短期内完成的，需要进行总体规划，然后分阶段实施。无论是工具的整合，还是度量体系的实施，都需要按部就班、循序渐进，逐步完成建设，最终实现预期目标。