1.什么是DevOps流水线
流水线这个词起源于福特公司，1913年，福特公司在汽车城底特律市建成了世界上第一条汽车装配流水线，使T型车成为大批量生产的开端，汽车装配时间从12.5小时缩短到1.5小时。 持续交付流水线针对于软件来讲是指软件从版本控制库到用户手中这一过程的自动化表现形式。
在《持续交付》一书中对《 持续交付（Continuous delivery，缩写为 CD），作为如下定义，即持续交付一种软件工程方法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的编译、测试与发布变得更快更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
DevOps流水线继承了持续交付的特点，并引入了精益（Lean IT）、轻量级ITSM(lightweight-ITSM)、敏捷（Agile）的管理方法形成了持续交付流水线的加强版。DevOps流水线在业内有三种实践，分别是开发流水线、集测流水线、发布流水线
1.1开发流水线是指面向开发人员和开发环境。开发人员提交代码，触发构建，部署到开发环境中由开发人员进行自测。这个流水线在开发的过程中会频繁进行。
1.2集测流水线是指面向测试人员，同样以构建为开始，基于构建的产品（部署产物），部署到集成测试环境，进行系统集成测试。
1.3发布流水线是指每次发布的所有需求全部通过系统集成测试后，便可以进入后续测试如用户验收测试、非功能性测试等，通过后，则认为已经达到发布上线标准，触发上线申请审批流程，审批通过可以进行自动化发布上线。
2.ITIL与DevOps的关系
在最新的《DevOps Handbook》中，专门提到DevOps与ITIL相容，因为ITIL自1989年开始在IT业内广泛应用，并且在随后的几年中不断地进行更新，2018年ITIL也开始了最新的ITIL基础架构库的更新工作。
DevOps的实践本身与ITIL管理是相容的，并且在EXIN DevOps学习体系框架中进行了良好地融合
EXIN DevOps学习体系：DevOps学习体系框架
通过DevOps与ITIL的融合，可以更好地支持流程的自动化以、流程和技术地紧密集成，实现快速审批、自动化部署，解决配置管理与变更管理紧密集成的关系。
3.变更与DevOps的关系
无论是在大型组织还是中型组织，变更管理流程在企业中的重要作用显而易见地是非常明显，因为它可以帮助企业快速地识别风险、控制变更频率，实现高效地变更控制。但在组织实现变更管理过程，尤其是通过ISO/IEC20000的组织，变更管理流程给你的感觉是非常的官僚，并且效率很差。理想的情况下，变更管理引入DevOps建立如下原则：
建立组织变更管理自动化的文化
变更管理流程与DevOps流水线要一致
职责整合、流程与工具连动
建立整体协调性，减少冲突和潜在问题
防止生产环境中的未授权变更
建立自动化追踪变更的手段、发现未授权变更
变更窗口多样化，多阶段化、常态化
评估影响事先评估，前置于架构与研发
建立自动化反馈与流程化反馈的绩效评估
4.变更分类与DevOps的关系
在变更管理流程中引入DevOps流水线，可以帮助企业通过建立可靠的流水线管道，实现快速地持续交付工作。变更分类有三类，标准变更、紧急变更、常规变更。
标准变更是特定的变更（standard change），也可以称为“预授权的变更”。标准变更关键在于：
变更请求的发起是由一个已定义的触发来发起的（已知）。
变更时已知的，被记录和被证明的。
管理权限事先给予的（预先审批）
低风险且易于了解
预算审批通常是事先决定或者由变更请求者控制的
从实践角度去看当变更类型被定义为标准变更，那么就可以通过DevOps流水线进行持续交付。因为它的风险相对较低，并且工作频频，正是适用于引入DevOps流水线。
紧急变更是需要进行更快速处理的特殊变更，对于紧急变更，通过召开紧急变更顾问委员会（ECAB）进行评估。紧急变更关键在于：
变更请求的发起是由一个未定义的触发来发起的（未知）。
变更时未知的，被被事后记录。
管理权限事中给予的（临时审批）
风险未知,需要ECAB进行评估
预算审批由ECAB控制
从实践角度去看当变更类型被定义为紧急变更，首先要判断是否为通过DevOps流水线能够解决，如果可以通过DevOps流水线部署，并解决问题，应首先通过DevOps流水线解决。如果由于Jar或JDK等原因，无法通过DevOps流水线部署解决，应首先采用远程方法解决，最后选用现场解决方式。
常规变更是指正常通过CAB进行审批的变更活动，对于常规变更，通过召开变更顾问委员会（CAB）进行评估，常规变更的关键在于
变更审批计划性强，根据变更排程进行触发变更（已知）
变更时已知，应被被事先记录，并进行事先预估。
管理权限事先给给予的（计划审批）
高中风险且不易于了解，需要CAB进行评估
预算审批由CAB控制
常规变更由于从提交到审批，时间相对较长，从DevOps流水线角度看，需要进行全审批的可视化工作，以及技术阶段的可视化，包括提交、集成、预发布、发布等阶段，其中各阶段应引入DevOps流水线进行自动化发布。
5.变更与DevOps流水线的集成
针对三类变更的建议处理工作：
标准变更：不需要审批，可以?持续部署流?线完全?动化执?，留下?于追溯的变更单和流?线执??志等。
常规变更：将?量的低风险变更重新分类为标准变更（?需审批），??段时间的历史记录证明它的靠谱程度，运?Jenkins/Puppet/Ansible等部署?作，留下追溯路径变更单[Remedy]->代码库?的代码提交[GitLab]->项?计划?具[JIRA]
常规变更：保证快速部署，尽可能?动化执?变更操作，提?变更请求单的完整性和精确性（%C/A），提供丰富的上下?加速审批决策过程
在设计和规划变更流程与DevOps集成时时应考虑一下几个问题
变更流程应和发布、配置管理一起被设计。充分考虑DevOps流水线。有助于快速实施与交付。
变更管理流程的需求和设计应包括自动化设计、流程设计、自助设计、智能设计（AI）
组织结构作用和责任及自动化触发工单
分组及相关变更的自动化分类、
程序及自动分派
其他服务管理接口、自动化接口、流水线接口、配置管理接口
处理变更、发布、配置管理与问题事故管理流程的接口来确认、减少事故变化