×

扫描二维码登录本站

发布管理:“厚积”而“薄发”  

标签: 暂无标签

                                      学习资料: ITIL培训基地专家讲堂直播 300期视频回放



本文出自   转载等请务必保留此出处

发布管理(Release Management)是指,对经测试后导入实际应用的新增或修改后的配置项,进行分发和宣传的管理流程。

    发布

    管理与变更管理、配置管理紧密结合。当新发布引起IT基础架构的变更时,配置管理数据库(CMDB)也进行实时更新,同时发布的内容也要保存到最终软件库(DSL)中,其他如硬件规格说明、装配指南和网络配置等都要保存到DSL或CMDB中。

    从根本上说,发布管理流程是以前几个流程为基础的,没有前几个流程对IT基础设施的状况和问题、各组件之间的关系等多方面的发现和管理,发布管理也就失去了发布对象和发布内容。所以,我们说发布管理流程是一个“‘厚积’而‘薄发’”的过程。

    那么,如何实现“薄发”呢?我们可以从“薄发”对象和范围、“薄发”力度和“薄发”活动三个方面来理解。
   “薄发”对象和范围
发布管理负责对软件和硬件进行规划、设计、构建、配置和测试,以便为实际运行环境提供一系列的发布组件。需要发布管理进行控制的组件包括:


  • 自行开发的应用程序;

  • 外购软件;

  • 工具软件;

  • 供应商提供的系统软件;

  • 硬件和软件的规格说明;

  • 安装指南和文档,包括用户手册。


所有的组件,从开发和购买,到定制和配置、测试和实施,一直到最后的在现场环境的实际运作,都需要发布管理进行有效的管理。特别需要强调的是,发布管理应当应用于以下三种情况:



  • 重要或关键硬件的首次运行,特别是当业务系统对某个相关的软件变更具有较大依赖的情形;

  • 主要软件的首次运行,特别是新的应用程序与其协同软件同时发布的情形;

  • 将一组相关的变更打包成适当规模发布单元的情形。


   “薄发”力度
按照对IT基础架构改动程度的大小和实施的变更对业务影响程度的大小,可将发布分为全发布(Full Release)、德尔塔(Delta)发布和包发布(Package Release)三种。

         1. 全发布

        全发布是指同时构建、测试、分发和实施发布单元的所有组件的发布方式。全发布的最大优势在于:发布单元的所有组成部分都是集中进行构建、测试、发布和实施的,这样,对于那些被错误地假设无需变更的配置项的过时版本,就没有应用在新版本中的危险了;其不足之处在于:构建、测试、发布和实施一个版本需要付出更多的时间、精力和计算机资源。

        2. 德尔塔发布

        德尔塔发布,又称局部发布,是指仅仅对自上次全发布或德尔塔发布以来发布单元中实际发生变化或新增的那些配置项进行发布的一种发布方式。

        3. 包发布

        包发布是指将一组软件配置项以包(Package)的形式一起导入实际运作环境的发布方式。为了减少发布频率以使实际运作环境保持更长时间的稳定性,如果能确保稳妥地处理大量变更而不会出现问题,就可以将单个的发布(全发布、德尔塔发布或两者兼有)组合在一起形成一个包发布。全发布和德尔塔发布都可包括在包发布中
   “薄发”活动
发布管理流程的实施应当在变更管理流程的控制下进行,发布管理几乎贯穿整个变更生命周期。具体来说,发布管理可应用于组件的设计开发、控制测试和实际运作三种环境,其包含的主要活动如图1所示。



从图1可以看出,发布管理流程贯穿于IT组件的开发、测试和运作整个生命周期。发布管理流程的主要活动包括:

        1. 制定发布策略

        组织在实施发布管理之前必须制定发布政策(Release policy),以明确发布管理中的角色分配和责任划分。每个组织至少应制定一份发布政策文档,或者针对每个支持系统或每项IT服务制定一系列的指南和详细说明文档。

        2. 制定发布计划

        为保证发布管理流程的顺利实施,对发布管理流程的实施进行规划、制定发布管理计划是非常必要的。发布计划根据已批准的变更请求、发布策略、业务需求以及其它有关要求,进行争取各方对发布的认可、然后制定详细的发布日程、安排相应人员以及制定撤销计划(Back-out Plan)等活动,最后形成针对某个特定发布的计划、高级测试计划和发布的验收标准等。

        3. 设计、构建和配置发布

        发布的设计应当根据发布策略和组织的总体变更计划做出。通过发布设计,应当明确发布的类型(全发布、德尔塔发布和包发布)、发布的频率、发布的方式等问题。

        为构建软件发布,需要对流程进行规划和文档记录,并尽可能地重复使用标准化流程。一个特定的软件和硬件发布的配置可能基于一套可用的组件,这些组件中的一些可能是自主开发的,有些可能是外购的。

        需要发布的所有软件、参数、测试数据、运行中的软件和其他软件,都应当处于配置管理的控制之下。在软件被构建应用之前,需要对其执行质量控制审核。有关构建结果的完整记录也要求记录到CMDB中,这是为了确保在必要时能按照该配置记录重复构建。

        4. 测试和验收发布

        在一项发布最终引入实际运作环境之前,必须进行严格的测试和用户验收。这包括功能测试、运作测试、品质测试和综合测试。

        5. 制定首次运行计划

        首次运行计划拓展了当前的发布计划,它相对发布计划而言,增加了有关安装过程的详细信息和达成一致意见的实施计划。

        6. 沟通和培训

        对于发布管理流程而言,非常重要的一点是要向客户公开发布机制和对终端用户的约束。有关软硬件支持合同方面的变更也应当传达给相关的人员。这种沟通一般是由服务台负责的,但对于那些细节方面的沟通还是应由发布管理来进行。

        同时,为保证发布管理流程的顺利实施,需要对参与发布管理流程的人员、应用开发经理、项目经理、将服务导入业务领域的运作层用户,以及需要“新服务”满足业务需要的业务用户进行培训。

        7. 分发和安装

        依次经过构建环境、控制测试环境和实际运行环境后,发布的软件的分发也随之完成。软件分发程序也需要进行适当的设计以确保在整个处理、打包和移交过程中能够保持软件的完整性。


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:服务级别管理“量体裁衣”的流程
下一篇:配置管理:IT基础架构的控制中心
admin

写了 834 篇文章,拥有财富 28707,被 26 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies
孑孓0426 发表于 2011-3-18 10:09:25
怎么没有专题讲义啊?
kaka869 发表于 2011-3-20 00:41:18
看看
smaylou 发表于 2011-6-20 11:36:26
谢谢分享
心有鱼力 发表于 2011-9-6 10:29:15
本帖最后由 心有鱼力 于 2011-9-6 10:29 编辑

测试是否应该属于发布的一个内容?
12下一页
Powered by ITIL  © 2001-2025
返回顶部