DevOps的核心是自动化,自动化的核心是标准化。而DevOps最重要的一环节是持续交付,持续交付中建设的重点是流水线,所以如何打造标准的持续交付流水线则为DevOps建设中最重要的一环,也是评估DevOps能力的一个重要的打分点。
本文内容参照《研发运营一体化(DevOps)能力成熟度模型 第3部分:持续交付》,基于jenkins,对持续集成流水线建设的一些关键点进行技术应答,带领大家把方法论落地到具体的技术点上。
文中涉及到的几个名词解释:
- 流水线:pipeline,一个应用程序从构建、部署、测试和发布这个过程实现自动化
- 制品:构建过程的输出物,包括软件包、测试报告、应用配置文件等。
- 制品库:存储全语言制品的仓库,提供依赖解析及文件存储能力。
- 元数据:软件生命周期全过程数据,如需求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建设的一个基石,并且成为贯穿你的整个建设周期中。
学习更多技术知识可以关注我们的在线课堂
关注微信公众号:JFrog杰蛙DevOps, 获取课程通知
登录后评论
立即登录 注册