基于Jenkins如何打造符合DevOps能力成熟度三级标准的持续集成流水线，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
DevOps的核心是自动化，自动化的核心是标准化。而DevOps最重要的一环节是持续交付，持续交付中建设的重点是流水线，所以如何打造标准的持续交付流水线则为DevOps建设中最重要的一环，也是评估DevOps能力的一个重要的打分点。
基于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建设的一个基石，并且成为贯穿你的整个建设周期中。
看完上述内容，你们掌握基于Jenkins如何打造符合DevOps能力成熟度三级标准的持续集成流水线的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注天达云行业资讯频道，感谢各位的阅读！