发布管理流程包括下列活动： 发布政策制定和发布规划。 发布设计、构建和配置。 测试和发布验收。 试运行（Rollout）规划。 沟通、准备和培训。 发布分发和安装。 这些活动实际上不是按时间先后顺序进行的。发布政策制定和发布规划可能每半年或每年进行一次，而其它活动通常都是每天都在进行。
发布管理流程包括下列活动：
• 发布政策制定和发布规划。
• 发布设计、构建和配置。
• 测试和发布验收。
• 试运行（Rollout）规划。
• 沟通、准备和培训。
• 发布分发和安装。
这些活动实际上不是按时间先后顺序进行的。发布政策制定和发布规划可能每半年或每年进行一次，而其它活动通常都是每天都在进行。
成功的发布管理依赖于其它ITIL流程提供的信息和密切配合（图1）。发布管理与这些流程的主要接口将在下面进行介绍。
1、规划和实施发布管理
规划和实施发布管理流程在很大程度上依赖于配置管理和变更管理实施的情况。It 它包括对发布管理能力的初始规划和实施，以及对下列多方面的日常审查和改进：
• 发布政策包括发布级别、发布类型、发布单元、发布识别、发布频率和发布阶段、以及受控发布项目和必要文档记录的范围。
• 发布程序涉及下面即将介绍的所有发布管理活动。
• 所有人员特别是发布管理人员的角色和职责。
• 工具包括：管理变更和发布进度的变更管理工具、在配置项生命周期的不同时点上记录其信息的配置管理数据库（CMDB）工具、管理软件代码不同版本的软件配置管理工具、自动化构建流程的构建管理工具、软件分发工具、软件和硬件审计工具以及桌上型电脑和服务器管理工具。
2、发布管理活动
图-2显示了发布管理活动及其在一项变更的生命周期中的位置。
2.1发布政策制定和发布规划
针对每一个系统，发布经理都应当制定一项发布政策来定义一项发布怎样以及在何时得以配置。重大发布应该提前对其发布识别或版本号进行规划，以便在恰当的时候可以考虑添加某项（些）变更。
发布经理还需要规定在什么层次上配置项可以彼此独立地进行分发（发布单元）。这取决于处于发布控制之下的系统的性质：
• 发布对其它组件的潜在影响。
• 相对于将多个变更集中起来同时实施所需要付出的努力，独立地构建和测试变更项目所需要的人小时数和周期时间长度。
• 在用户所在地进行安装的困难。安装一个完全的程序可能要容易一些，因为这种安装有标准的技巧可资利用。
• 新软件、新硬件和IT基础架构的其它组件之间的相互依赖关系的复杂程度。这种相互依赖关系对于独立的软件或硬件越简单，则对它们进行测试也越容易。
在对一项发布进行规划之前，需要收集有关产品生命周期、将要移交的产品、相关IT服务及其服务级别的描述以及相关变更请求的批准情况等方面的信息。
在规划一项发布时需要考虑下列问题：
• 协调发布的内容。
• 就发布日程安排、地点和组织单元进行协商。
• 制定发布日程安排。
• 制定沟通计划。
• 现场考察以确定正在使用的硬件和软件。
• 就角色和职责进行协商。
• 获取详细的报价单，并与供应商就新硬件、新软件和安装服务进行谈判协商。
• 制定撤销计划。
• 为发布制定质量计划。
• 由管理部门和用户共同对发布验收进行规划。
这项活动的结果是变更计划的一部分，具体包括发布计划、测试计划和验收标准。
2.2 设计、构建和配置
为发布的设计、构建和配置开发标准的程序是一种明智的做法。一项发布一般是基于自行开发或从第三方供应商购进并构建的一套组件（配置项）。安装指示和配置发布的指示也应当被视为是发布的一部分，也应当被作为配置项处于变更管理和配置管理的控制之下。
在现场安装之前在一个“实验室”中构建和测试所有的硬件和软件是一种明智的做法。对一项发布的软件和硬件组件应当审慎地进行配置和记录以便可以重复利用这种配置。还应当制定运营指示以确保同一套组件每次都能进行组合。通常，保留着标准化的硬件只是为了用于编译或制作这些硬件的图片。流程的这一部分最好是自动化的以保证其可靠性。在软件开发环境中，这项活动被称为构建管理，它属于发布管理的职责范围。
2.3 撤销计划
针对整个发布的撤销计划定义了在发布出现问题的情况下恢复服务所需进行的活动。变更管理负责撤销计划的制定，而发布管理需要确保撤销计划符合实际的要求。特别是在实施一项组合了多项变更请求的包发布时，对不同的撤销计划进行协调是非常必要的。一旦一则项全发布或德尔塔发布出现了问题，则明智的做法是将该发布完全撤回到原来假设的状态。如果某项发布不能被完全撤回到原来的状态，则需要采取应急措施来尽可能多地恢复服务。
最好的做法是事先就满足撤销计划的一些要求，如制作备份和提供备用服务器等。为了应对这样一些情形，即实施撤销计划的时间超出了预期水平，并且该时间的延迟将会危及正常的服务供应，撤销计划应该针对何时启动撤销计划以及时地（如在早上7点以前）恢复服务制定一些时间期限。一份撤销计划应当包括在变更的影响度分析之中，并且用户必须已经认可该计划。
发布的实际构建还包括编译和连接软件模块，将测试数据或诸如邮递区号表、税率、时区、汇率表以及用户信息等数据存入数据库等活动。这通常是由与撤销计划一起存储在最终软件库（DSL）中的自动安装指示来处理的。已完成的发布在配置管理数据库（CMDB）中应该被标识为标准配置以便将来再次进行配置。测试计划涉及发布前的软件、硬件、程序、运营指示和试运行（Rollout）指南的测试和验收，还可能涉及发布后的评估测试。安装指南也应该进行测试。该项活动需要的信息包括：
• 发布的定义。
• 发布日程安排。
• 配置和构建发布的指示。
• 关于需要购买和申请许可证的项目的描述。
• 自动安装指示。
• 纳入最终软件库（DSL）中的软件的原始拷贝。
• 撤销计划和程序。
3、测试和发布验收
不满意的变更和发布的最常见的原因是缺乏足够的测试。为了防止这一点，在实施之前，发布应该由用户代表对其进行功能测试并由IT管理人员进行运营测试，在测试的过程中，IT管理人员还可以考虑技术操作、功能、运营、绩效以及与基础架构其它部分集成等方面的问题。测试还应该涉及安装指示、撤销程序以及对管理程序的任何变更。对每一个步骤的正式验收必须由变更管理来进行。最后一个步骤是批准可以实施的发布。
在发布管理可以开始试运行（Rollout）之前，变更管理必须安排由用户进行的正式验收以及由开发人员签发的开发结束的标记。
发布应该在一个受控测试环境中进行验收以便该项发布可以被恢复至一个可知的配置状态。这种针对该项发布的基准状态应该在发布定义文件中进行明确的说明，并应记录在配置管理数据库（CMDB）中。如果发布没有通过验收，则应被作为失败的变更送回到变更管理。
该项活动产生的结果包括：
• 经过测试的安装程序。
• 经过测试的发布组件。
• 发布中存在的已知错误和缺点。
• 测试结果。
• 管理和支持文档。
• 受到影响的系统的清单。
• 运营指示和诊断工具。
• 应急计划和经过测试的撤销计划。
• 针对雇员、经理和用户的培训方案。
• 经过签字的验收文件。
• 针对该项发布的变更授权。
4、试运行（Rollout）规划
在前期阶段制定的发布计划现在要由有关确切的实施活动和日程安排方面的信息来加以补充。
试运行（Rollout）规划包括：
• 制定一份日程安排以及有关任务和所需的人力资源的清单。
• 制定一份关于将要安装的配置项、将要停止使用的配置项以及退出使用的具体方式的清单。
• 在考虑到国际性组织可行的发布时间以及所在的时区的情况下，为每个实施地点制定一份活动计划。
• 邮寄发布备忘录以及与有关方面进行其它沟通。
• 制定硬件和软件的采购计划。
• 购买、安全存储、识别和记录所有配置管理数据库（CMDB）中即将发布的新配置项。
• 与高层管理人员、管理部门、变更管理以及用户代表安排更新/评审会议。
实施一项试运行（Rollout）有以下几种方式：• 全面试运行（Rollout）－“大爆炸”的方法。
• 分阶段试运行（Rollout），包括以下几种方案：
－ 功能递增，在这种方式下，所有的用户都在同一时间获得新的功能。
－ 地点递增，在这种方式下，首先对某些用户群进行试运行（Rollout），然后再扩散至所有的用户。
－ 演进方式，功能是分阶段扩展的。
5、沟通、准备和培训
负责与客户沟通的人员（服务台和客户关系管理）、运营人员以及客户组织的代表都应该清楚发布计划的内容以及该计划将如何影响日常活动。这可以通过联合培训、合作和联合参与发布验收来实现。相关的职责应该得到充分的传达，并应该核实是否每个人都清楚他们的职责。此外，如果发布是分阶段进行的，则应该向用户告知计划的详细内容，并告诉它们什么时候可以期望新功能正式上线。
针对服务级别协议（SLA）、运营级别协议（OLA）和支持合同（UC）所作的变更应该提前向所有相关人员进行传达。
6、分发和安装
发布管理为软件和硬件的采购、存储、运输、交付和移交监控整个物流流程。该流程由一些相应的程序、记录以及包装单据等附属文档来支持，从而可以为配置管理提供可靠的信息。硬件和软件存储设施应该确保安全并且只有经过授权的人员才可以进入。
可能的话，最好使用自动工具来进行软件分发和安装。这样可以减少分发所需要的时间、提高发布的质量，而只需要更少的资源。通常，这些工具还可以帮助检验安装是否成功。在进行安装之前，最好检查发布即将导入的环境是否满足一些条件，如足够的磁盘空间，安全性，环境控制或限制像空气条件、房屋面积、UPS/电源，等等。
在安装后，配置管理数据库（CMDB）中的信息应立即进行更新以便可以检验任何的许可证协议。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved