Last modified by roll tech on 2024/12/30, 17:25
From version < 14.1 >
edited by superadmin
on 2021/02/18, 22:25
To version < 16.1 >
edited by superadmin
on 2021/02/19, 14:43
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -3,7 +3,7 @@
3 3  {{/box}}
4 4  
5 5  (((
6 -
6 +
7 7  )))
8 8  
9 9  需要下载 **ITIL 4发布管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“发布”即可。
... ... @@ -35,7 +35,6 @@
35 35  1. 实践中关于合作伙伴和供应商的注意事项
36 36  
37 37  
38 -
39 39  == **1.1 ITIL 4 鉴证方案** ==
40 40  
41 41  本文档的内容可作为以下课程的一部分检验标准：
... ... @@ -58,7 +58,7 @@
58 58  |(((
59 59  关键信息
60 60  
61 -发布管理实践的目的是使新的和变更的服务及功能均可用。
60 +发布管理实践的目的是使新的和变更的服务及功能均可用。
62 62  )))
63 63  
64 64  发布管理实践是为了确保组织及其服务使用者在符合组织政策和协议的前提下，服务可以正常使用而产生的最佳实践。
... ... @@ -70,7 +70,109 @@
70 70  
71 71  == **2.2 关键术语和概念** ==
72 72  
72 +|(((
73 +发布
73 73  
75 +使服务或仸何其他配置项的版本或配置项的集合可用。
76 +)))
77 +
78 +
79 +=== **2.2.1 发布管理和部署管理** ===
80 +
81 +
82 +组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
83 +
84 +
85 +一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产的环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
86 +
87 +另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活劢启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
88 +
89 +|(((
90 +CI （持续集成）/ CD（持续部署）和发布管理
91 +
92 +敏捷和DevOps中部署的关键概念包括持续集成、持续交付和持续部署。Martin Fowler 将它们定义为：
93 +
94 +* 持续集成通常是指在软件开发环境中集成、构建和测试代码。
95 +* 持续交付扩展了持续集成，涵盖了生产部署的最后阶段。持续交付意味着构建的软件可以随时发布到生产中。
96 +* 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。
97 +* 持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
98 +
99 +在组织中，将发布的连续部署管理作为单独的实践来使用是普遍且有效的。新版本的软件、文档和数字基础设施配置一准备就绪，便会立即部署到运行环境中，然后使用发布管理实践为用户“打开”它们。
100 +
101 +如果使用不带持续部署的持续交付，则部署新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
102 +
103 +最后，如果组细不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
104 +)))
105 +
106 +组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组细的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
107 +
108 +
109 +=== **2.2.2发布管理的方法，模型和计划** ===
110 +
111 +
112 +如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于∶
113 +
114 +* 商定的高级方法
115 +* 针对用户及发布对象设置规则
116 +* 发布单元和打包规则
117 +* 推/拉条件
118 +* 验证和验收标准
119 +* 假设验证和实验的发布使用条款
120 +
121 +产品可能有多个发布管理模型。例如，当产品用于在不同的市场上提供服务，或用于企业和个人服务消费者。
122 +
123 +
124 +组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
125 +
126 +|发布单元
127 +配置项或部分配置项的预定义集合，它是发布包含的基本大小。
128 +
129 +===
130 +**2.2.3 发布单元** ===
131 +
132 +
133 +发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明;但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
134 +
135 +某些发布实例可能包含不完整的发布单元，但这种情况应作为特例∶如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
136 +
137 +重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
138 +
139 +===
140 +**2.2.4 推/拉条件** ===
141 +
142 +
143 +发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
144 +
145 +
146 +"推"式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，"拉"式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
147 +
148 +
149 +通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了"拉"或"推"方法。无论对内部和外部用户，都有很多亲和性。这包括∶
150 +
151 +* 在整个用户群中使用单一版本（可维护性，兼容性）
152 +* 用户体验更灵活（更好的可视化，灵活的定价选项）
153 +* 提供在运行环境中管理多个版本的技术和组织能力
154 +* 关键变更（严重的安全漏洞更新这种场景更适合"推"模式）
155 +* 功能和其他客户的需求（如果实现了所需的新功能，客户可以要求所有用户进行更新）
156 +* 监管要求
157 +
158 +
159 +=== **2.2.5 假设检验和实验** ===
160 +
161 +
162 +发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
163 +
164 +
165 +这些实验需要其他实践的共同参与。这包括但不限于∶
166 +
167 +* 基础设施平台管理
168 +* 软件开发管理
169 +* 部署管理
170 +* 架构管理
171 +* 服务台
172 +* 事件管理
173 +
174 +
74 74  == **2.3 发布管理和部署管理** ==
75 75  
76 76  
... ... @@ -128,7 +128,6 @@
128 128  )))
129 129  
130 130  
131 -
132 132  === **2.4.1 发布单元** ===
133 133  
134 134  发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源、文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明；但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
... ... @@ -154,7 +154,6 @@
154 154  * 监管要求
155 155  
156 156  
157 -
158 158  === **2.4.3 假设检验和实验** ===
159 159  
160 160  发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
... ... @@ -169,7 +169,6 @@
169 169  * 事件管理
170 170  
171 171  
172 -
173 173  == **2.5 实践的范围** ==
174 174  
175 175  发布管理实践的范围包括以下内容：
... ... @@ -196,7 +196,6 @@
196 196  |管理项目|项目管理
197 197  
198 198  
199 -
200 200  == **2.6 实践成功因素** ==
201 201  
202 202  PSF不仅仅是任务或实现价值，因为它包含所有服务管理四维模型的组件。在实践中，
... ... @@ -213,7 +213,6 @@
213 213  * 确保在组织的价值流和服务关系的上下文中有效地发布服务和服务组件
214 214  
215 215  
216 -
217 217  === **2.6.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
218 218  
219 219  发布管理实践包括为新的和变更的服务和服务组件建立发布的方法和模型。组织可能会结合多种方法，并为他们管理的每个产品定义多个发布管理模型。
... ... @@ -310,7 +310,6 @@
310 310  * 交付和支持
311 311  
312 312  
313 -
314 314  == **3.2 流程** ==
315 315  
316 316  |(((
... ... @@ -325,7 +325,6 @@
325 325  * 发布协调
326 326  
327 327  
328 -
329 329  === **3.2.1 发布规划** ===
330 330  
331 331  该流程专注于发布方法、模式和复杂发布实例方法的开发，以及发布管理实践的持续改进。它定期执行，并由事件或请求触发，根据模型和程序的有效性，每两到三个月或者更频繁的进行定期审查。该流程包括以下活动，并将以下输入转换为表3.1中所示的输出。
... ... @@ -448,8 +448,8 @@
448 448  
449 449  表3.3 发布协调流程的输入、活动和输出
450 450  
451 -===== =====
452 452  
546 +
453 453  图3.3显示了工作流的流程图
454 454  
455 455  (% style="text-align:center" %)
深圳市艾拓先锋企业管理咨询有限公司