Changes for page 服务管理实践 - 07 发布

Last modified by roll tech on 2024/12/30, 17:25

From version < 9.1 >

edited by superadmin
on 2021/02/18, 22:20

To version < 20.1 >

edited by superadmin
on 2021/02/19, 16:15

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Title

@@ -1,1
          +1,1 @@
--07 发布管理（尚未发布）
++07 发布管理（已发布）

Content

@@ -1,19
          +1,16 @@
--(% class="jumbotron" %)
--(((
--(% class="container" %)
--(((
--=   =
++{{box cssClass="floatinginfobox" title="**Contents**"}}
++{{toc/}}
++{{/box}}
--
--
--
--
++(((
  )))
--)))
  需要下载 **ITIL 4发布管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“发布”即可。
++[[image:微信截图_20210206234644.png||height="153" width="152"]]
++
++
  **申明：**
  本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
@@ -23,14
          +23,10 @@
  翻译：李威    审校：郑中珮    审核：刘晓慧
--(% class="row" %)
--(((
--(% class="col-xs-12 col-sm-4" %)
--(((
--
--)))
--)))
++
++----
++
  = **1 关于本文件** =
  本文档为发布管理实践提供了实用指南。它分为五个主要部分，内容包括：
@@ -41,7
          +41,6 @@
 . 支持实践的信息和技术
 . 实践中关于合作伙伴和供应商的注意事项
--
  == **1.1 ITIL 4 鉴证方案** ==
  本文档的内容可作为以下课程的一部分检验标准：
@@ -64,7
          +64,7 @@
  |(((
  关键信息
--发布管理实践的目的是使新的和变更的服务及功能均可用。
++发布管理实践的目的是使新的和变更的服务及功能均可用。
  )))
  发布管理实践是为了确保组织及其服务使用者在符合组织政策和协议的前提下，服务可以正常使用而产生的最佳实践。
@@ -76,23
          +76,20 @@
  == **2.2 关键术语和概念** ==
--
--== **2.3 发布管理和部署管理** ==
--
--
  |(((
--**发布**
++发布
--使服务或任何其他配置项的版本或配置项的集合可用。
++使服务或仸何其他配置项的版本或配置项的集合可用。
  )))
++=== **2.2.1 发布管理和部署管理** ===
++
  组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
--一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
++一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产的环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
--另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活动启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
++另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活劢启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
--
  |(((
  CI （持续集成）/ CD（持续部署）和发布管理
@@ -100,23
          +100,24 @@
  * 持续集成通常是指在软件开发环境中集成、构建和测试代码。
  * 持续交付扩展了持续集成，涵盖了生产部署的最后阶段。持续交付意味着构建的软件可以随时发布到生产中。
--* 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
++* 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。
++* 持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
  在组织中，将发布的连续部署管理作为单独的实践来使用是普遍且有效的。新版本的软件、文档和数字基础设施配置一准备就绪，便会立即部署到运行环境中，然后使用发布管理实践为用户“打开”它们。
  如果使用不带持续部署的持续交付，则部署新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
--最后，如果组织不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
++最后，如果组细不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
  )))
--组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组织的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
++组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组细的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
--== **2.4 发布管理的方法、模型和计划** ==
++=== **2.2.2发布管理的方法，模型和计划** ===
--如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于：
++如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于∶
--* 商定的高级方法
++*  商定的高级方法
  * 针对用户及发布对象设置规则
  * 发布单元和打包规则
  * 推/拉条件
@@ -127,43
          +127,39 @@
  组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
--|(((
--发布单元
--
++|发布单元
  配置项或部分配置项的预定义集合，它是发布包含的基本大小。
--)))
--=== **2.4.1 发布单元** ===
++=== **2.2.3 发布单元** ===
--发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源、文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明；但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
++发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明;但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
--某些发布实例可能包含不完整的发布单元，但这种情况应作为特例：如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
++某些发布实例可能包含不完整的发布单元，但这种情况应作为特例∶如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
  重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
--=== **2.4.2 推/拉条件** ===
++=== **2.2.4 推/拉条件** ===
  发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
--“推”式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，“拉”式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
++"推"式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，"拉"式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
--通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了“拉”或“推”方法。无论对内部和外部用户，都有很多亲和性。这包括：
++通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了"拉"或"推"方法。无论对内部和外部用户，都有很多亲和性。这包括∶
  * 在整个用户群中使用单一版本（可维护性，兼容性）
  * 用户体验更灵活（更好的可视化，灵活的定价选项）
  * 提供在运行环境中管理多个版本的技术和组织能力
--* 关键变更（严重的安全漏洞更新这种场景更适合“推”模式）
++* 关键变更（严重的安全漏洞更新这种场景更适合"推"模式）
  * 功能和其他客户的需求（如果实现了所需的新功能，客户可以要求所有用户进行更新）
  * 监管要求
++=== **2.2.5 假设检验和实验** ===
--=== **2.4.3 假设检验和实验** ===
--
  发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
--这些实验需要其他实践的共同参与。这包括但不限于：
++这些实验需要其他实践的共同参与。这包括但不限于∶
  * 基础设施平台管理
  * 软件开发管理
@@ -172,9
          +172,8 @@
  * 服务台
  * 事件管理
++== **2.3 实践的范围** ==
--== **2.5 实践的范围** ==
--
  发布管理实践的范围包括以下内容：
  * 开发和维护组织中新的和变更的服务与组件[[1 >>path:#_bookmark2]]的发布方法
@@ -199,7
          +199,7 @@
  |管理项目|项目管理
--== **2.6 实践成功因素** ==
++== **2.4 实践成功因素** ==
  PSF不仅仅是任务或实现价值，因为它包含所有服务管理四维模型的组件。在实践中，
@@ -215,7
          +215,7 @@
  * 确保在组织的价值流和服务关系的上下文中有效地发布服务和服务组件
--=== **2.6.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
++=== **2.4.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
  发布管理实践包括为新的和变更的服务和服务组件建立发布的方法和模型。组织可能会结合多种方法，并为他们管理的每个产品定义多个发布管理模型。
@@ -232,7
          +232,7 @@
  发布的方法、模型以及一般的实践应该进行持续改进，不断寻找消除浪费并增加效果和效率的方法。
--=== **2.6.2 确保在组织的价值流和服务关系的背景中，服务和服务组件的发布是有效的** ===
++=== **2.4.2 确保在组织的价值流和服务关系的背景中，服务和服务组件的发布是有效的** ===
  要确保有效的发布，可能需要在所有服务管理四维模型中组织资源。
@@ -248,7
          +248,7 @@
  有效的协调软件开发和管理，基础设施和平台管理，部署管理，服务验证以及测试与发布管理尤为重要。
--== **2.7 关键指标** ==
++== **2.5 关键指标** ==
  ITIL实践的效果和表现应该在每个实践所贡献的价值流的背景下进行评估。与任何工具的表现或效果一样，只能在应用范围内评估。但是，工具的设计和质量可能会有很大的差异，这些差异定义了工具在使用过程中的不同能力。
@@ -296,6
          +296,7 @@
  图3.1中显示了发布管理实践对服务价值链的贡献点。
++(% style="text-align:center" %)
  [[image:图片1.png]]
@@ -313,7
          +313,6 @@
  == **3.2 流程** ==
  |(((
--
  流程是一组将输入转化为输出的相互关联或交互的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了动作的执行顺序及其依赖性。
  )))
@@ -360,10
          +360,10 @@
  表3.1 发布规划流程的输入活动和输出
--====   ====
  图3.2显示了流程的工作流程
++(% style="text-align:center" %)
  [[image:图片2.png]]
@@ -447,10
          +447,10 @@
  表3.3 发布协调流程的输入、活动和输出
--=====   =====
  图3.3显示了工作流的流程图
++(% style="text-align:center" %)
  [[image:图片3.png]]
  图3.3 发布协调流程的工作流程图
@@ -458,9
          +458,477 @@
  表3.4显示了发布协调流程活动。
++(% style="width:783px" %)
++|(% colspan="2" rowspan="1" %)活动|(% colspan="2" style="width:435px" %)软件组件的自动化发布|(% colspan="3" rowspan="1" style="width:493px" %)复杂发布项目
++|(% colspan="2" rowspan="1" %)确定适用的模型或计划|(% colspan="2" style="width:435px" %)基于生产或服务、目标环境或开发团队，发布流水线需要按照自动化发布模型和计划有条不紊的执行。|(% colspan="3" rowspan="1" style="width:493px" %)(((
++生产/ 服务负责人和开发团队一起评估已更改服务组件是否可以发布。
++
++团队评估发布实例与现有服务之间的相互依赖性，评估发布的风险（包括技术债务影响），并选择使用的合适发布模型。
++
++团队可以根据发布模型要求进行更新。
++)))
++|(% colspan="2" rowspan="1" %)服务组件的验证|(% colspan="2" style="width:435px" %)发布实例组件运行预置的组件测试。在CI 流水线中，提交的每个软件变更都需要通过自动化测试。|(% colspan="3" rowspan="1" style="width:493px" %)基于发布模型进行组件验证，也可以基于风险评估和技术债务进行一些其他的测试。
++|(% colspan="3" style="width:59px" %)服务组件的验证|(% colspan="2" style="width:277px" %)验证可以自动将组件发布给开发团队或者测试用户组，进行功能测试，或者发布给专门的用户组进行非功能测试，例如体验测试、安全测试、性能测试。|(% colspan="2" style="width:395px" %)如果某些组件未根据模型部署，则验证还需要额外触发其他构建，部署或测试动作。
++|(% colspan="3" style="width:59px" %)发布程序的验证|(% colspan="2" style="width:277px" %)根据组件属性自动选择发布规程。|(% colspan="2" style="width:395px" %)所选模型的发布过程将针对发布实例进行验证。只有满足所选发布模型的所有要求（全部所需的资源可用，过程已准备好运行），发布程序才会开始执行。
++|(% colspan="3" style="width:59px" %)发布执行|(% colspan="2" style="width:277px" %)根据预定义脚本执行的发布（例如，能将包含新特性的组件或环境路由到部分被授予权限的用户组），并自动通知受影响的用户组。|(% colspan="2" style="width:395px" %)基于事件触发（例如，项目团队决策，生产/ 服务经理批准或消费者请求）执行发布，并结合其他相关实践。内部和外部团队都可能参与其中。
++|(% colspan="3" style="width:59px" %)发布验证|(% colspan="2" style="width:277px" %)自动化脚本验证所有功能特性/组件均已发布。|(% colspan="2" style="width:395px" %)发布团队和专用用户检查是否所有功能/组件已发布。
++|(% colspan="3" style="width:59px" %)发布评审|(% colspan="2" style="width:277px" %)(((
++开发团队会分析自动发布流程的任何异常和日志。
++
++开发团队运行调试器，更新知识库并记录所汲取的教训。
++)))|(% colspan="2" style="width:395px" %)(((
++反馈来自用户组。
++
++发布团队运行发布调试器，更新知识库并记录汲取的经验教训。最终的发布评审报告可能会触发发布规划过程。
++)))
++
  表3.4 发布协调流程活动
  ----
--
++= **4 组织和人员** =
++
++
++== **4.1 角色，能力和职责** ==
++
++实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。实践指南着重于每个专门角色的实践经验。每个组织架构中，对不同角色的命名可能都不同，因此ITIL中定义的任何被推荐的角色都不是强制的。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
++
++流程和活动的背景中描述了角色。每个角色都具有基于表4.1中所示的模型的能力概况。
++
++|能力代码|描述
++|L|**领导者** 决策、授权，监督其他活动，提供激励和动力，并评估结果
++|А|**管理员** 分配任务并确定优先级，保存记录，持续报告并启动基本改进
++|C|**协调者 /沟通者** 协调多方，维护利益相关者之间的沟通,并开展宣传活动
++|М|**方法和技巧专家** 设计和实施工作技术、文化步骤、流程咨询、工作分析和持续改进
++|Т|**技术专家** 提供技术（IT）专业知识并执行基于专家经验的作业
++
++表4.1能力代码和资料
++
++在组织中发布管理实践会有一个特定的角色：发布经理。该角色通常是在发布大量产品的组织中，尤其是在需要手动规划和执行发布动作的组织中引入的。在其他组织中，产品或服务所有者可以承担发布经理的职责。
++
++
++=== **4.1.1 发布经理角色** ===
++
++在定义发布经理角色的情况下，通常将此角色分配给对组织的业务，产品和服务，技术，平台，框架和流程有深入了解的专家。该角色需要全面的规划能力和项目管理技能以及权威来协调团队合作。
++
++该角色的能力要求是AMCT。该角色通常负责规划、管理和协调整个发布管理实践以及各个发布实例，包括：
++
++* 审查和开发发布方法和模型
++* 促进整个组织采用被认可的的发布管理方法和模式
++* 规划复杂发布方式
++* 管理和传达发布日程
++* 确保实践与其他实践保持一致性和协调性
++* 审查并不断开发新实践
++
++在某些复杂的组织中，发布经理的部分职责可能委派给发布协调员。
++
++
++== **4.2 发布管理中涉及的角色活动** ==
++
++表4.2中列出了发布管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。
++
++|实现价值|负责角色|能力简介|具体技能
++|(% colspan="4" %)发布规划流程
++|生产架构和服务关系分析|(((
++企业架构师
++
++服务负责人
++
++产品负责人
++
++关系经理
++
++开发团队成员
++
++客户经理
++
++交付经理
++
++设师
++)))|ATC|(((
++服务关系的知识
++
++商业分析
++
++服务架构的知识
++
++发布和部署方法的知识
++
++基础架构和平台方面的专业知识
++
++沟通技巧
++)))
++|发布管理方法|(((
++服务负责人
++
++产品负责人
++)))|AMTC|(((
++服务关系知识
++
++发布和部署方法的知识
++)))
++|评审和开发|(((
++关系经理
++
++开发团队成员
++
++客户经理
++
++交付经理
++)))| |(((
++基础设施和平台方面的专业知识
++
++沟通技巧
++)))
++|发布管理模型评审和开发|(((
++服务负责人
++
++产品负责人
++
++开发团队成员
++
++客户经理
++
++交付经理
++)))|AMTC|(((
++服务关系的知识
++
++发布和部署方法的知识
++
++基础架构和平台方面的专业知识
++
++沟通技巧
++)))
++|发布实例规划| |TA|(((
++基础架构和平台方面的专业知识
++
++服务/ 生产的技术知识
++
++服务架构的知识
++
++发布和部署方法的知识
++
++管理服务/ 生产的专业知识
++
++服务关系的知识
++)))
++|发布计划沟通|(((
++服务负责人
++
++产品负责人
++
++关系经理
++
++客户经理
++
++交付经理
++)))|C|(((
++服务关系知识
++
++沟通技巧
++
++营销知识
++)))
++|(% colspan="4" %)发布协调流程
++|确定适用的模型或计划|(((
++服务负责人
++
++产品负责人
++
++开发团队成员
++
++客户经理
++
++交付经理
++
++设计师
++)))|AT|(((
++服务/ 产品的管理知识
++
++用户服务体验
++
++基础架构和平台方面的专业知识
++
++发布和部署方法的知识
++
++服务/ 产品的技术知识
++)))
++|服务组件的验证|(((
++服务负责人
++
++产品负责人
++
++开发团队成员
++
++客户经理
++
++交付经理
++
++客户代表
++)))|TA|(((
++基础设施和平台方面的专业知识
++
++发布和部署方法的知识
++
++服务/ 产品的技术知识
++
++服务/ 产品的管理专业知识
++)))
++|发布程序的验证|(((
++开发团队成员
++
++系统管理员
++
++信息安全专家
++)))|TA|(((
++基础架构和平台方面的专业知识
++
++服务/ 产品的技术知识
++
++服务/ 产品的管理知识
++)))
++|发布执行|(((
++开发团队成员
++
++系统管理员
++
++信息安全专家
++)))|T|(((
++基础设施和平台方面的专业知识
++
++发布和部署方法的知识
++
++服务/ 产品的技术知识
++)))
++|发布验证|(((
++服务负责人
++
++产品负责人
++
++客户经理
++
++交付经理
++
++开发团队成员
++
++客户代表
++
++用户
++)))|A|(((
++服务/ 产品管理的专业知识
++
++用户的服务体验
++)))
++|发布评审|(((
++服务负责人
++
++产品负责人
++
++关系经理
++
++客户经理
++
++交付经理
++
++开发团队成员
++
++设计师
++
++客户代表
++
++用户
++)))|ATC|(((
++服务关系的知识
++
++业务分析
++
++服务架构的知识
++
++发布和部署方法的知识
++
++基础设施和平台方面的专业知识
++
++服务/产品的技术知识
++
++沟通技巧
++
++营销知识
++)))
++
++表4.2 发布管理活动涉及的角色示例
++
++
++== **4.3 组织架构和团队** ==
++
++只有在发布任务量巨大，或发布场景复杂的组织中，才适合建立指定的发布管理团队。大多数情况下，发布管理不需要专门的团队，只需建立临时的项目团队，或者将发布管理实现高度自动化就可以满足需求。
++
++但是，在许多情况下，发布经理的角色仍然有用。该角色可以充当教练，以确保发布实践被整个组织采用。根据组织对发布管理的处理方式，此角色可以与部署经理的角色结合。
++
++
++
++----
++
++= **5 信息和技术 ** =
++
++
++== **5.1 信息交流** ==
++
++发布管理的效果取决于所使用信息的质量。该信息包括但不限于以下信息：
++
++1. 生产架构
++1. 服务消费组织和用户
++1. 软件开发和管理实践
++1. 计划的和正在进行的部署
++1. 正在进行和过去的事件
++1. 新兴的发布管理技术
++
++该信息可以采用各种形式。实践的输入和输出的详细列表在第3节中列出。
++
++
++== **5.2 自动化和工具** ==
++
++在数字化工作环境中的发布管理是高度自动化的。但是，即使在传统环境中，发布管理实践也可以从自动化中显著受益。在表5.1中，有很多可行且有效的解决方案。
++
++|实现价值|自动化手段|(% colspan="2" %)关键功能|实践上的影响
++|(% colspan="5" %)发布计划过程
++|生产架构和服务关系分析|(((
++架构工具
++
++业务分析和建模工具产品/ 服务建模工具
++)))|(% colspan="2" %)生产/ 服务架构以及关系，连接和约束的可视化|中
++|发布管理方法评审和开发|(((
++流程建模工具
++
++产品/ 服务建模工具
++
++业务分析工具
++)))|(% colspan="2" %)对过程与程序的建模，可视化和评估|低
++|发布管理模式评审和开发|流程建模工具|(% colspan="2" %)对过程与程序的建模，可视化|中
++|发布实例规划|(((
++流程建模工具
++
++发布和部署管理工具
++
++流水线管理工具
++
++软件交付和集成工具
++
++开发环境
++)))|(% colspan="2" %)自动化发布管理|高
++|发布计划沟通|(((
++社交网络
++
++门户
++
++知识库工具
++)))|(% colspan="2" %)自动通信、消息、状态更新|高
++|(% colspan="5" %)发布协调流程
++|确定适用的模式或计划|(% colspan="2" %)(((
++流程建模工具
++
++发布和部署管理工具
++
++流水线管理工具
++)))|流程和过程的建模与可视化|低
++|服务组件的验证|(((
++发布和部署管理工具
++
++流水线管理工具
++
++软件交付和集成工具
++
++开发环境
++)))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
++|发布程序的验证|(((
++发布和部署管理工具
++
++流水线管理工具
++
++软件交付和集成工具
++
++开发环境
++)))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
++|发布执行|(((
++发布和部署管理工具
++
++流水线管理工具
++
++软件交付和集成工具
++
++开发环境
++)))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
++|发布验证|(((
++发布和部署管理工具
++
++流水线管理工具
++
++软件交付和集成工具
++)))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
++|发布评审|(((
++监控工具
++
++协作工具
++
++沟通工具
++)))|(% colspan="2" %)(((
++提供信息和警告
++
++知识共享
++
++问题沟通
++)))|中
++
++表5.1 发布管理活动的自动化解决方案
++
++
++
++----
++
++= **6 合作伙伴和供应商** =
++
++只有很少量的服务是完全由组织自己的资源提供的，绝大多数需要依赖于外部服务。这些外部服务通常是由组织外的第三方供应商提供的（请参阅“ITIL Foundation 2.4：服务关系的模式的ITIL 4版）。
++
++如前所述，合作伙伴和供应商充当的角色与组织对其产品和服务组件的控制级别有关。如果组织控制整个产品或服务生命周期（包括开发和部署）时，它在做出有关发布管理的决策方面就具有更大的自由度。相反，如果组织的产品或服务依赖于第三方组件，或者开发和部署由供应商管理，那么通常这种情况下，组织必须考虑引入的约束带来的影响了。虽然组织可以决定是否在其服务中引入更新的组件，但在一定程度上还是受到一些限制的。
++
++组织有时可以将发布管理的某些内容外包。例如，用户沟通，发布的市场推广，用户培训，在假设测试中收集反馈等等。组织应该适当地管理那些合作伙伴和供应商活动，因为它们会直接影响用户的满意度和是否为此服务付费。
++
++组织之间的关系可能涉及各种级别的整合和形式。（有关组织之间的关系的更多信息，请参见ITIL®Foundation：ITIL 4 Edition的表3.1）。与发布管理中的合作伙伴的集成级别取决于合作的形式，应通过发布管理，供应商管理，关系管理，服务级别管理和其他相关实践来决定和管理合作的形式。
++
++
++
++----
++
++= **7 重要提醒** =
++
++实践指南中大部分内容都应作为组织在建立和培养自己的实践时可以尝试的不同领域的建议。实践指南是组织可以尝试的的事情的目录，而不是答案的列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则：
++
++1. 聚焦价值
++1. 从你所处的地方开始
++1. 基于反馈迭代推进
++1. 协作和提升可视化程度
++1. 通盘思考和工作
++1. 保持简单实用
++1. 优化和自动化
++
++更多有关指导原则及其应用程序的信息，请参见以下内容的第4.3节。
++
++ITIL®基础：ITIL 4版出版物。
++
++
++
++----
++
++= **8 致谢** =
++
++AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
++
++
++== **8.1 作家** ==
++
++Vinod Kumar Agrasala, Konstantin Naryzhny, Roman Jouravlev
++
++
++== **8.2 审稿人** ==
++
++Oleg Skrynnik Jon Hall Anton Lykov, Samantha Robertson

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司