来源：https://www.linkedin.com/pulse/relationship-between-release-change-configuration-abhishek-srivastava

https://www.bmc.com/blogs/itil-asset-configuration-management/

https://www.bmc.com/blogs/asset-management-vs-configuration-management/

发布管理与变更和配置管理紧密结合。人们需要清楚地了解这三者之间的关系，这样才能了解整体情况。

一、什么是发布管理?

发布管理是一个软件管理过程，它指导从代码开发到测试再到生产的技术工作，专注于协调各种产品的可交付件，这些可交付件必须作为一个集成的解决方案和结果一起工作，从而有效地交付业务所需的新的和增强的IT服务/功能，同时保护现有服务的完整性。

二、什么是变更管理?

变更管理是一个用于管理对配置管理数据库(或CMDB中的“CIs”)中所有配置项进行变更的计划部署的过程，这些配置项是业务的活动(“生产”)环境的一部分。变更管理的目标是确保采用标准化的方法和程序，以有效和迅速地处理所有变更，以控制IT基础设施，以尽量减少任何相关事件对服务的数量和影响。

三、什么是配置管理?

配置管理(CM)是一种由标准过程和技术组成的软件工程规程，组织经常使用这些标准过程和技术来管理引入到其软件产品中的变更。配置管理有助于识别单个元素和配置，跟踪变更，以及版本选择、控制和基线。它精确地回答了配置管理数据库(或CMDB中的“CIs”)中所有配置项configuration items的谁、什么、什么时候和为什么。

四、这些学科是如何相互关联的?

变更管理Change management 提供授权和跟踪机制(变更请求(RFC)、变更日志和评审)，以确保只部署已批准的变更。

配置管理Configuration management 为变更日志、rfc、权威软件库(DSL)、权威硬件存储(DHS)、发布包和所有CIs提供了一个托管数据库(CMDB)。

发布管理Release management为部署到生产中的所有变更提供了一个打包的发布。

这种相互依存关系可以清楚地理解为:

1、变更管理

（1）需要配置管理来评估变更对所有潜在CI的影响。

（2）需要发布管理来打包变更，以便在对生产造成最小干扰的情况下成功部署。

２、配置管理

（１）需要变更管理，以确保只部署已批准的变更，并完成对授权过程的所有跟踪。

（２）需要发布管理来在部署后使用发布包更新CMDB。

３、发布管理

（１）需要变更管理来批准变更，并在整个发布过程中跟踪变更。

（２）需要配置管理来评估变更对ci的影响，并为发布包提供一个确定的存储。

变更管理角色和职责

来源：https://www.greycampus.com/blog/it-service-management/itil-change-management-roles-and-responsibilities

变更管理是以受控的方式访问、批准、实施和审查变更的一组。每个角色负责完成特定的任务。在变更管理中确定的角色是：

一、变更经理Change Manager

变更经理作为一个促进者，负责整个变更管理过程。他的主要职责是：

（1）授权和批准小的/低 minor/low的变更；

（2）与变更顾问委员会(CAB)协调并组织会议，讨论高风险变更；

（3）实施或拒绝变更的权力；

（4）确保所有为实施变更而设计的活动都符合标准。政策和程序应得到很好的定义、承认和审查；

（5）准备变更摘要表，总结所有RFC的变更。此表帮助CAB团队理解和评估所提议的变更。

二、变更咨询委员会Change Advisory Board (CAB)

它是一组个人，作为一个顾问委员会的变化被分类为主要或重要的。CAB，与变更经理一起负责最终评审;他们有权重新评估风险级别或影响级别。他们可以在批准变更前要求提供额外的信息，也可以根据需要拒绝变更。

三、紧急变更咨询委员会Emergency Change Advisory Board (CAB/EC)

CAB的一个子集，作为紧急变更的决策者。紧急变更需要立即批准和授权。

四、变更请求者或变更启动者Change Requestor or Change Initiator

提出改变或要求改变的人。变更请求者需要为变更提供所有必要的信息和理由。除此之外，他的其他职责还包括组织和计划变更活动。

（1）向变更的所有者提供必要的信息

（2）参加CAB会议并提供必要的信息

（3）评审和记录变更计划

（4）解决与变更相关的问题

（5）使用变更活动更新用户

（6）支持并参与变更实施前后的测试活动

五、变更受让人/测试人员/实现者Change Assignee/Tester/Implementer

变更的所有者——如果变更请求者是其他人。他的职责包括:

（1）就业务和技术问题与变更请求者保持联系

（2）创建一个RFC(变更请求)，并在需要时更新它的状态。检查并确定实现日期，确保它不会与其他活动冲突

（3）评估和管理相关的风险

（4）测试并实现变更

（5）在提交变更之前，与其他受影响的团队进行协调和沟通

（6）一旦变更被批准，为计划的变更创建一个补救案例。按照预定的日期和时间执行更改。更新补救案例

（7）成功完成后提供关闭状态

（8）变更程序实施后的文件记录

六、变更批准人Change Approver

在RFC进入CAB评审之前，向RFC提供第一级批准的经理。他的职责包括:

（1）审查变更受让人提交的所有RFC

（2）确保所有必要的沟通;文件编制和测试在批准之前完成

（3）请求技术同行进行评审，以确保所有技术步骤都是正确的

（4）批准或拒绝RFC

（5）变更是通过变更管理系统来维护和控制的，这是一种用来跟踪和记录与拟议变更相关的所有活动(初始化、批准、更新、关闭)的工具。