返回ITIL 4 Foundation中文翻译目录，点击

5.2.9 发布管理

关键词：发布管理实践的目的是使新的和变更的服务和功能可供使用。

发布定义：可供使用的服务或其他配置项的版本或配置项的集合。

版本可以包括许多不同的基础架构和应用程序组件，它们一起工作以提供新的或改变的功能它还可能包括文档，培训（针对用户或 IT 人员），更新的流程或工具以及所需的任何其他组件。发布的每个组件可以由服务提供商开发，或者从第三方获得并由服务提供商集成。

版本的大小范围从非常小，仅涉及一个小的变更功能，到非常大，涉及许多提供全新服务的组件。在任何一种情况下，发布计划都将指定要提供的新组件和已变更组件的确切组合，以及它们的发布时间。

发布计划用于记录发布的时间。该计划应与客户和其他利益相关者协商并达成一致。发布后实施审核可以实现学习和改进，并有助于确保客户满意。

在某些环境中，几乎所有发布管理工作都在部署之前进行，并且已制定计划以确切地在特定发行版中部署哪些组件。然后，部署使新功能可用。

图 5.25 显示了如何在传统/瀑布环境中处理发布管理。在这些环境中，可以将发布管理和部署组合并作为单个进程执行。

在 Agile / DevOps环境中，部署后可能会有重要的发布管理活动。在这些情况下，软件和基础架构通常以很小的增量部署，而发布管理活动在稍后的时间点启用新功能。这可以作为非常小的改变来完成。图 5.26 显示了在这样的环境中如何处理发布管理。

发布管理通常是暂定的，向少数用户提供试用版，以确保在向其他组发布之前一切正常。这种分阶段的方法可以与图 5.25 和 5.26 中所示的两个序列中的任何一个一起使用。有时，必须同时向所有用户提供版本，例如需要对基础共享数据进行重大重组时。

通常使用蓝/绿发布或功能标记来实现版本的暂存：

●蓝/绿发布使用两个镜像生产环境。通过使用将其连接到正确环境的网络工具，可以将用户切换到已使用新功能更新的环境。

●功能标记使特定功能可以以受控方式发布给各个用户或组。新功能部署到生产环境而不会被释放。然后，用户配置设置会根据需要向单个用户（或用户组）释放新功能。

在 DevOps 环境中，发布管理通常与持续集成和持续交付工具链集成。发布管理工具可能由专职人员负责，但开发团队可以做出有关发布的决策。在更传统的环境中，通过部署组件来启用发行版。每个版本都由 ITSM 工具上的发布记录描述。发布记录链接到 CI 和变更记录以维护有关发布的信息。

发行版的组件通常由第三方提供。第三方组件的示例包括云基础架构，软件即服务组件和第三方支持。将第三方软件或开源软件作为应用程序开发的一部分也很常见。发布管理需要跨组织边界工作，以确保所有组件兼容并为用户提供无缝体验。它还需要考虑变更对第三方组件的影响，并规划如何发布这些组件。

图 5.27 发布管理对价值链活动贡献的热图

图 5.27 显示了发布管理对服务价值链的贡献，实践涉及所有价值链活动：

●计划：发布的策略，指导和时间表由组织战略和服务组合驱动。应规划和管理每个版本的大小，范围和内容。

●改进：可能需要新的或变更的版本来提供改进，这些应该以与任何其他版本相同的方式进行规划和管理。

●驱动：必须设计版本的内容和节奏，以满足客户和用户的需求和期望。

●设计和转换：版本管理确保以受控方式向客户提供新服务或变更服务。

●获取/构建：组件的变更通常包含在发布中，以受控方式提供。

●交付和支持：版本可能会影响交付和支持。此实践提供了培训，文档，发行说明，已知错误，用户指南，支持脚本等，以便于服务恢复。

ITIL 的故事：Axle 的发布管理

Marco：当我们发布预订应用程序的更新时，我们会确保为用户，客户和团队提供用户意识和营销活动。 我们为内部和外部的服务台和支持团队提供特定培训。

Radhika：一些变化可能需要额外支持或引入新组件。 例如，Axle Aware 发布了一个新的用户手册来解释系统。 在发布之前，我们还确保 Aware 系统可以与 Axle 预订应用同步。

Henri：对新应用程序和 Axle Aware 的支持确实帮助了这两种新产品的发布，从而在我们的用户和客户以及我们自己的团队中获得了良好的第一印象和牛逼的使用率。

返回ITIL 4 Foundation中文翻译目录，点击

5.2.9 发布管理

关键词：发布管理实践的目的是使新的和变更的服务和功能可供使用。

发布定义：可供使用的服务或其他配置项的版本或配置项的集合。

版本可以包括许多不同的基础架构和应用程序组件，它们一起工作以提供新的或改变的功能它还可能包括文档，培训（针对用户或 IT 人员），更新的流程或工具以及所需的任何其他组件。发布的每个组件可以由服务提供商开发，或者从第三方获得并由服务提供商集成。

版本的大小范围从非常小，仅涉及一个小的变更功能，到非常大，涉及许多提供全新服务的组件。在任何一种情况下，发布计划都将指定要提供的新组件和已变更组件的确切组合，以及它们的发布时间。

发布计划用于记录发布的时间。该计划应与客户和其他利益相关者协商并达成一致。发布后实施审核可以实现学习和改进，并有助于确保客户满意。

在某些环境中，几乎所有发布管理工作都在部署之前进行，并且已制定计划以确切地在特定发行版中部署哪些组件。然后，部署使新功能可用。

图 5.25 显示了如何在传统/瀑布环境中处理发布管理。在这些环境中，可以将发布管理和部署组合并作为单个进程执行。

在 Agile / DevOps环境中，部署后可能会有重要的发布管理活动。在这些情况下，软件和基础架构通常以很小的增量部署，而发布管理活动在稍后的时间点启用新功能。这可以作为非常小的改变来完成。图 5.26 显示了在这样的环境中如何处理发布管理。

发布管理通常是暂定的，向少数用户提供试用版，以确保在向其他组发布之前一切正常。这种分阶段的方法可以与图 5.25 和 5.26 中所示的两个序列中的任何一个一起使用。有时，必须同时向所有用户提供版本，例如需要对基础共享数据进行重大重组时。

通常使用蓝/绿发布或功能标记来实现版本的暂存：

●蓝/绿发布使用两个镜像生产环境。通过使用将其连接到正确环境的网络工具，可以将用户切换到已使用新功能更新的环境。

●功能标记使特定功能可以以受控方式发布给各个用户或组。新功能部署到生产环境而不会被释放。然后，用户配置设置会根据需要向单个用户（或用户组）释放新功能。

在 DevOps 环境中，发布管理通常与持续集成和持续交付工具链集成。发布管理工具可能由专职人员负责，但开发团队可以做出有关发布的决策。在更传统的环境中，通过部署组件来启用发行版。每个版本都由 ITSM 工具上的发布记录描述。发布记录链接到 CI 和变更记录以维护有关发布的信息。

发行版的组件通常由第三方提供。第三方组件的示例包括云基础架构，软件即服务组件和第三方支持。将第三方软件或开源软件作为应用程序开发的一部分也很常见。发布管理需要跨组织边界工作，以确保所有组件兼容并为用户提供无缝体验。它还需要考虑变更对第三方组件的影响，并规划如何发布这些组件。

图 5.27 发布管理对价值链活动贡献的热图

图 5.27 显示了发布管理对服务价值链的贡献，实践涉及所有价值链活动：

●计划：发布的策略，指导和时间表由组织战略和服务组合驱动。应规划和管理每个版本的大小，范围和内容。

●改进：可能需要新的或变更的版本来提供改进，这些应该以与任何其他版本相同的方式进行规划和管理。

●驱动：必须设计版本的内容和节奏，以满足客户和用户的需求和期望。

●设计和转换：版本管理确保以受控方式向客户提供新服务或变更服务。

●获取/构建：组件的变更通常包含在发布中，以受控方式提供。

●交付和支持：版本可能会影响交付和支持。此实践提供了培训，文档，发行说明，已知错误，用户指南，支持脚本等，以便于服务恢复。

ITIL 的故事：Axle 的发布管理

Marco：当我们发布预订应用程序的更新时，我们会确保为用户，客户和团队提供用户意识和营销活动。 我们为内部和外部的服务台和支持团队提供特定培训。

Radhika：一些变化可能需要额外支持或引入新组件。 例如，Axle Aware 发布了一个新的用户手册来解释系统。 在发布之前，我们还确保 Aware 系统可以与 Axle 预订应用同步。

Henri：对新应用程序和 Axle Aware 的支持确实帮助了这两种新产品的发布，从而在我们的用户和客户以及我们自己的团队中获得了良好的第一印象和牛逼的使用率。