基于Jenkins打造符合DevOps能力成熟度三级标准的持续集成流水线

 基于Jenkins打造符合DevOps能力成熟度三级标准的持续集成流水线_第1张图片

DevOps的核心是自动化,自动化的核心是标准化。而DevOps最重要的一环节是持续交付,持续交付中建设的重点是流水线,所以如何打造标准的持续交付流水线则为DevOps建设中最重要的一环,也是评估DevOps能力的一个重要的打分点。

本文内容参照《研发运营一体化(DevOps)能力成熟度模型 第3部分:持续交付》,基于jenkins,对持续集成流水线建设的一些关键点进行技术应答,带领大家把方法论落地到具体的技术点上。

 

文中涉及到的几个名词解释:

1, 流水线:pipeline,一个应用程序从构建、部署、测试和发布这个过程实现自动化

2, 制品:构建过程的输出物,包括软件包、测试报告、应用配置文件等。

3, 制品库:存储全语言制品的仓库,提供依赖解析及文件存储能力。

4, 元数据:软件生命周期全过程数据,如需求id、代码提交信息、构建环境、静态扫描结果、测试通过率、安全扫描结果等。

 

文章中涉及到的一些技术详解:见文章《打造企业级pipeline服务的18个疑问》

 

下面,我们来看一下持续集成流水线建设中的配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理、度量与反馈的七个维度的三级标准是如何定义的,并且哪些指标需要在jenkins流水线中体现,如何使用jenkins流水线达到此标准。

 

一, 配置管理

 


三级标准

Jenkins流水线落地建议方案

版本控制

版本控制系统

1)将配置文件、构建和部署等自动化脚本纳入版本控制系统管理。
2)有健全的版本控制系统管理机制,包括:代码库命名规范备份与可用性保障机制权限模型专人专岗管理。

流水线内容(Jenkinsfile)需要纳入版本管理
流水线的命名需要有明确规范
流水线应明确权限,开发人员应只有可读权限,模版由专门团队编写
技术点:可使用jenkins的Share library特性,由专门团队在源码仓库中统一管理流水线,

分支管理

短周期分支分支频繁地向主干合并

非流水线内容

制品管理

1)将依赖组件纳入制品库管理
2)将所有交付制品纳入制品库管理,比如:测试报告
3)制品库读写有清晰的权限管控制度

建设统一制品库,如Artifactory。设置完整的权限。
收集构建流水线过程中的所有工具的结果数据,并将此类数据定义成元数据,与制品绑定。如需求、代码提交信息、构建环境信息、依赖信息、静态扫描信息、单元测试信息、安全扫描信息等。
技术点:可采用商用制品库、如Artifactory。也可自行开发元数据管理系统,收集构建中过程数据。

单一可信数据源

版本控制系统和制品库作为单一可信数据源,覆盖生产部署环节

建立统一制品库,在jenkinsfile中指明制品库地址,构建时不使用pom文件中的依赖解析地址,而由其他方式修改依赖解析仓库到唯一可信仓库中
技术点:使用Artifactory统一管理制品库,保证唯一可信源

变更管理

变更过程

1)所有配置项变更由变更管理系统触发
2)针对每次变更内容进行评审,并使用自动化手段

不涉及流水线、注意配置与应用分离、及配置中心管理

变更追溯

实现版本控制系统和变更管理系统的自动化关联,信息双向同步和实时可追溯

不涉及流水线

变更回滚

1)实现变更管理系统和版本控制系统的同步回滚,保证状态的一致性
2)回滚操作实现自动化

不涉及流水线,

 

二, 构建与持续集成


三级标准

Jenkins流水线落地建议方案

构建实践

构建方式

1)定义结构化构建脚本,实现模块级共享复用
2)构建脚本由专人专岗统一维护

技术点:使用Jenkins ShareLibrary实现构建模块化管理,并实现全局共享

构建环境

1)构建环境配置实现标准化
2)有独立的构建资源池

打造少量固定的标准化构建节点作为独立的构建资源池,并用k8s集群创建动态构建节点作为动态资源池。
技术点:jenkins主从架构、jenkins on k8s

构建计划

1)实现定期自动执行构建和代码提交触发构建
2)明确定义构建计划和规则,并在研发团队内共享

技术点:jenkins触发器,可实现定时构建、轮询源码构建或webhook触发构建

构建职责

构建工具和环境由专门团队维护并细分团队人员职责

jenkins主从节点或构建镜像由统一团队维护。业务部门只使用,不能修改。

持续集成

集成服务

组建专门的持续集成团队,负责优化持续集成系统和服务

统一团队构建流水线模版与持续集成环境,供开发人员选择
技术点:可以通过jenkins on k8s方式,打造多种构建环境镜像,开发人员提交构建任务时定义所需环境。

集成频率

研发人员至少每天向代码主干集成一次

不涉及流水线

集成方式

每次代码提交触发自动化构建,构建问题通自动分析精准推送相关人员处理

每次提交代码触发jenkins进行构建,并在构建过程中执行完整的静态扫描、单元测试等步骤
技术点:jenkins的触发器功能,可以设置轮训scm或git的webhook触发

反馈周期

集成问题反馈和解决可以在几个小时内完成

jenkins pipeline中要通知构建工作完成或失败状态,发邮件或webhook给运维团队和业务团队

 

三, 测试管理


三级标准

Jenkins流水线落地建议方案

测试分层策略

分层方法

1)采用代码级测试对模块的函数或类方法进行覆盖全面的单元测试;
2)系统全面的进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能性测试

在流水线中进行单元测试,收集单元测试通过率作为元数据与制品绑定。

分层策略

1)测试设计以对接口/服务级测试为主,兼顾用户/业务级测试辅以少量的代码级测试
2)对非功能性测试进行全面系统的设计

在流水线中可以集成接口测试,并收集接口测试通过率作为元数据与制品绑定。

测试时机

1)测试在持续交付过程中的介入时间提前到开发的编码阶段
2)代码级测试在模块的函数或类方法开发完成后进行

提高单元测试覆盖率。

代码质量管理

质量规约

1)建立组织级代码质量规约
2)建立完整的质量规约,将安全漏洞检查、合规检查纳入规约
3)建立强制执行的质量门禁体系
4)建立规约固定更新机制

需要在jenkins流水线中增加安全扫描步骤,并对扫描测试结果设置质量关卡。
技术点:Xray作为安全扫描工具集成在流水线中、通过制品元数据作为质量门禁判断构建产物是否达标

检查方式

代码质量检查完全自动化,不需要手工干预

流水线集成sonar扫描工具,每次代码提交自动触发构建、自动化进行源码扫描,并将代买坏味道数量、代码重复率等结果数据以元数据方式回写制品库。
技术点:sonarqube代码静态扫描

反馈处理

根据代码质量检查结果反馈及时处理,根据质量规约维持一定的技术债

代码静态扫描结果与制品绑定,回写到制品库。通过制品携带的元数据是否通过质量门禁,来判断制品质量。

自动化测试

自动化设计

1)对接口/服务级测试进行自动化设计
2)对代码级测试进行自动化设计

jenkins 流水线增加接口测试及服务测试

自动化开发

1)建立统一的自动化测试框架,统一管理自动化测试用例
2)自动化测试脚本开发采用数据驱动、关键字驱动等方法;

不涉及流水线

自动化执行

1)对接口/服务级与代码级测试采用自动化测试
2)自动化测试由流水线自动化触发

在流水线中进行所需测试

自动化分析

对自动化测试结果具备较强的自动判断能力,误报少

流水线中收集各项测试结果,作为元数据与交付物关联,保障每个制品都能获取到完整的测试结果。

 

四, 部署与发布管理

 


三级标准

Jenkins流水线落地建议方案

部署与发布模式

部署方式

部署和发布实现全自动化

部署过程作为流水线的必要步骤
技术点:对接如saltstack、ansible等工具在流水线中部署

部署过程

1)使用相同的过程和工具完成所有环境部署
2)一次部署过程中使用相同的构建产物

为确保发布内容为测试过的内容,要实现一次构建多次部署。通过元数据与仓库名标识制品成熟度。流水线中要将制品在不同成熟度仓库移动,并收集各个环境中的结果数据作为元数据存储。
技术点:应用配置分离、Artifactory元数据及promotion功能

部署策略

1)采用定期部署策略,具备按天进行部署的能力
2)应用和环境整体作为部署的最小单位
3)应用和配置进行分离

不涉及流水线

部署质量

1)部署失败率低
2)部署活动集成自动化测试功能,并以测试结果为部署前置条件
3)每次部署活动提供变更范围报告和测试报告

部署后会在流水线中进行简单验证,收集验证结果数据。测试结果收集到元数据中,部署时验证元数据,判断是否通过质量门禁,来实现部署。               技术点:Artifactory元数据

 

持续部署流水线

协作模式

通过定义完整的软件交付过程和清晰的交付规范,保证团队之间交付的有序

标准化工具链及持续集成流水线,收集个阶段结果数据作为元数据,用元数据标识制品的质量标准,供各个团队间进行使用。

流水线过程

软件交付过程中的各个环节建立自动化能力以提升处理效率

不涉及流水线

过程可视化

1)交付过程在团队内部可见,信息在团队间共享
2)交付状态可追溯

流水线中收集整个构建过程结果数据,与制品绑定,供所有团队查看。
技术点:Artifactory元数据

 

五, 环境管理

 


三级标准

Jenkins流水线落地建议方案

环境管理

环境类型

建立标准的研发环境

不涉及流水线

环境构建

1)环境的构建通过自服务的资源交付平台来完成
2)环境准备时间小时级

可在流水线中自动创建所需环境。
技术点:使用k8s的helm自动拉起整套环境,helm是最佳的实现方式

环境依赖于配置管理

以应用为中心,有服务级依赖的配置管理能力,比如:依赖的关联服务,数据库服务、缓存服务、关联应用服务等等

不涉及流水线

 

六, 数据管理


三级标准

Jenkins流水线落地建议方案

测试数据管理

数据来源

导出部分生产环境数据并清洗敏感信息后形成基准的测试数据集

不涉及流水线

数据覆盖

建立体系化测试数据,进行数据依赖管理,覆盖全部测试分层策略要求的测试类型

不涉及流水线

数据独立性

1)每个测试用例拥有专属的测试数据有明确的测试初始状态
2)测试用例的执行不依赖其他测试用例执行所产生的数据

不涉及流水线

数据变更管理

变更过程

将数据变更纳入持续部署流水线,经人工确认后自动完成

流水线与审批系统集成。

兼容回滚

每次数据变更同时提供明确的回滚机制,并实现进行变更测试,如:提供升级和回滚两个自动化脚本

不涉及流水线

数据监控

针对不同环境和危险程度对数据变更建立分级监控机制

不涉及流水线

 

七, 度量与反馈

 


三级标准

Jenkins流水线落地建议方案

度量指标

度量指标定义

建立跨组织度量指标,进行跨领域综合维度的度量

不涉及流水线

度量指标类型

度量指标覆盖过程指标,客观反映组织研发现状

流水线中需要收集元数据,作为后续度量指标

度量数据管理

持续收集度量数据历史度量数据有明确的管理规则

流水线中需要收集元数据,作为后续度量指标

度量指标更新

1)度量指标可以按照需求定期更新
2)度量指标的优先级在团队内部达成一致

不涉及流水线

度量驱动改进

内容和生成方式

度量报告进行分类分级并按需生成内容

流水线中需要收集元数据,作为后续度量指标。对元数据进行二次清晰,生成报告

数据时效性

通过可视化看板实时展示数据

看板需要展示流水线状态,如构建时间、通过率、故障率等

覆盖范围

全部团队成员均可查看报告

不涉及流水线

反馈改进

度量反馈问题纳入研发迭代的待办事项列表,作为持续改进的一部分

不涉及流水线

 

通过上述数据及分析,可以看出,打造出一个标准的流水线服务可以匹配到60%的三级标准。那么我们可以在整个DevOps的建设中投入较大的力量来打造流水线。一套标准的流水线服务和稳定的工具链将会成为DevOps建设的一个基石,并且成为贯穿你的整个建设周期中。