发布管理和变更管理之间你中有我，我中有你的亲密关系已成为UITIL的共识，但正是这种亲密无间的关系也一直在困扰着很多人。互联网上有人提问“从流程上来看，这两个管理类似，都有提出计划，比如测试计划，实施计划等，但是我不知道这两个的分工具体怎么确定，比如说什么样的任务该由变更管理来处理，什么样的任务该由发布管理来处理？”有人回帖：“变更关心的是从变更发起到变更批准或拒绝之间的流程，变更管理中的内容包含发布管理,比如测试计划，回退计划等，但这些计划内容都在发布管理中执行和制作。”

“变更管理中的内容包含发布管理”回帖中的这句话在ITIL中已有描述 “发布管理流程的实施应当在变更管理的控制下进行，发布管理几乎贯穿整个变更管理生命周期”。由此，我们应该将发布管理看作是变更管理的一部分，而不是脱离于变更管理的另外一种管理分工。

图1 客户服务中心ITIL框架

图1的客户服务中心ITIL框架，让我们看到的是没有变更管理的发布管理。这种ITIL框架不论有何种解释，都有悖于发布管理是变更管理一部分的ITIL共识。如果用皮毛相依来比喻二者之间关系，那么“没有变更管理的发布管理”带给我们的将是一个“皮之不存，毛将焉附”式的疑问。在《面壁ITIL之变更管理》中，笔者也将客户服务中心变更管理的缺位作了一个说明。客户服务中心不久将会建立变更委员会，强化变更管理，以期达到变更风险可控的目的。同时也将改变了客户服务中心的ITIL框架中没有变更管理的设计缺陷。

现假定客户服务中心的变更管理缺位得到妥善解决，发布管理在变更管理的控制下按部就班地工作着，但是仍然有一个问题未得到清晰的回答。网上的问答，回帖者虽然说清了变更管理对发布管理的支配关系，可是仍未能解释清楚发布管理和变更管理之间存在的某种关系。笔者曾就此和一位朋友聊过。笔者当时问这位朋友：“变更都已经完成了，再来发布不是有点事后的意味吗？”朋友回答道：“不能孤立理解的。比如软件的发布，也许是和变更实施同时进行的。问题解决完成，成为一个已知问题，此时对问题进行发布，是在问题解决时完成的。”这段对话，倒是让笔者对变更和发布之间的关系作了一个小小总结：一次变更可以和发布同时发生，也可以在发布之前发生，但决不可能在发布之后发生。推而广之，变更管理可以在发布管理之前进行，也可以和发布管理同时进行，决不可能在发布管理之后进行。错！变更和发布之间可以这么下结论，但变更管理和发布管理之间是不能用这个推论来套用。因为，变更管理是由一个一个的变更控制过程构成，每一个变更控制过程都有可能涉及发布，涉及发布管理。至此，我们似乎找到了变更管理和发布管理之间存在的某种关系，即发布管理贯穿于变更管理流程之中，为变更控制过程服务，并随着变更可大可小，变更小时就作为变更管理的一份子来管理；变更大时，可以单独拿出来作为发布管理运作。

当了解了发布管理和变更管理之间的支配与服务的关系之后，仍然有一个问题需要深入理解。发布管理的范围究竟在哪里？

ITIL中变更管理的对象有两个：一个IT基础架构的变更（包含各种软硬件的变更），一个IT服务（服务支持形式或内容的变更等）的变更。从发布管理的定义看，凡经过测试后导入实际应用的新增或修改后的配置项都可以归入发布管理范围。定义似乎已经将发布管理的范围界定清楚，但是，在发布管理的定义之后还有一句话非常令人费解：发布管理以前又称为软件控制与分发。为什么要在这里强调发布管理的历史？再往下读又会发现，无论是在基本概念、目标范围还是主要的活动，发布管理都在讲述的是有关软硬件的发布。这前前后后的矛盾，实在令人有点晕乎。

在互联网上搜索配置管理、变更管理和发布管理这三项内容，我们会发现它们都和软件开发相关。可以说ITIL是借鉴了软件开发控制过程中的精华部分，也就不难理解发布管理为什么和软件开发这么近乎。所以，在介绍发布管理的时候，我们了解到更多的是有关软件发布的控制和分发。

“发布管理负责的主要组件包括内部开发的应用程序、单位外购的软件产品、外包服务商提供的系统和工具软件以及硬件产品等”ITIL在界定发布管理范围时最后将硬件内容考虑了进去。这也许是ITIL根据自身特点对源自软件开发控制过程的发布管理作的一个补充。现在的ITIL已经对IT基础架构中的软硬件组件实现了全面的控制。

于是，又一个问题随之而来。IT服务的变更是否也应该纳入发布管理？ITIL对于发布管理的通篇论述中并没有看到有关的字眼。IT服务的变更是否需要发布？如何发布？ ITIL没有给出答案，也不需要给出什么答案。其实IT服务的变更与发布皆可参照IT基础架构的变更与发布模式进行管理。二者之间没有本质的区别。

变更管理与发布管理之间的“灰色地带”是ITIL众多灰色地带中比较费解的一个。扯不清的你中有我，我中有你关系，再加之模棱两可的管理分工既让人苦恼，又使人着迷。如果要用一句话为发布管理做最后的陈述，应该是：发布管理只做正确的事。