返回ITIL 4 Foundation中文翻译目录,点击
5.3.1 部署管理
部署管理实践的目的是将新的或变更的硬件,软件,文档,流程或任何其他组件移动到实时环境中。 它还可能涉及将组件部署到其他环境以进行测试或暂存。
部署管理与发布管理和变更控制密切配合,但这是一个单独的实践。在某些组织中,术语“供应”用于描述基础架构的部署,而部署仅用于表示软件部署,但在这种情况下,术语“部署”用于表示两者。
有许多不同的方法可用于部署。许多组织使用这些方法的组合,具体取决于它们的特定服务和要求以及发布大小,类型和影响。
●分阶段部署:新的或变更的组件一次仅部署到生产环境的一部分,例如部署到一个办公室或一个国家/地区的用户。根据需要重复此操作多次,直到部署完成。
●持续交付:组件在需要时进行集成,测试和部署,为客户反馈循环提供频繁的机会。
●大爆炸部署:新的或变更的组件同时部署到所有目标。当依赖性阻止同时使用旧组件和新组件时,有时需要这种方法。例如,可能存在与某些组件的先前版本不兼容的数据库架构变更。
●拉动部署:在受控存储库中提供新的或变更的软件,用户在选择时将软件下载到客户端设备。这允许用户控制更新的时间,并且可以与服务请求管理集成,以使用户能够仅在需要时请求软件。
可以部署的组件应保存在一个或多个安全位置,以确保在部署之前不会对其进行修改。这些位置统称为软件和文档的权威媒体库,以及硬件组件的权威硬件存储。
支持部署的工具有很多种。它们通常与配置管理工具集成,可以为审计和变更管理提供支持。大多数组织都有用于部署客户端软件的工具,这些工具可以与服务门户集成,以支持请求管理实践。
围绕部署的通信是发布管理的一部分。在发布之前,用户和客户通常不会对单个部署感兴趣。如果基础架构作为服务提供,则组织通常会管理新的或变更的服务器,存储或网络的部署,通常将基础架构视为代码,以便组织可以自动部署。在这些环境中,某些部署可能在供应商的控制之下,例如安装固件更新,或者如果它们提供操作系统以及它们可能部署操作系统补丁的基础结构。 IT 组织必须确保他们知道计划的部署以及已发生的部署,以维护受控环境。如果应用程序开发作为服务提供,则可以由外部应用程序开发人员,内部 IT 部门或服务集成商执行部署。同样,组织必须了解所有部署,以便维护受控环境。
在具有多个供应商的环境中,了解每个组织的部署活动的范围和边界以及这些活动将如何交互非常重要。大多数组织都有一个部署过程,这通常由标准工具和详细过程支持,以确保以一致的方式部署软件。对于不同的环境,通常有不同的过程。例如,可能存在一个用于部署客户端应用程序软件的过程,以及用于部署服务器操作系统补丁的完全不同的过程。
图 5.37 显示了部署管理对服务价值链的贡献,实践主要应用于设计和转换,获取/构建价值链活动,以及改进活动:
●改进:某些改进可能需要在交付之前部署组件,并且应该以与任何其他部署相同的方式对这些组件进行规划和管理。
●设计:和转换部署管理将新的和已变更的组件移动到实时环境中,因此它是此价值链活动的重要元素。
●获取/构建:可以作为此价值链活动的一部分,逐步部署变更。这在 DevOps 环境中尤其常见,它使用完整的自动化工具链进行持续集成,交付和部署。
ITIL 故事:Axle 的部署管理
Marco:在我们将变更部署到我们的预订应用程序之前,我们会将变更发布到测试环境。经过全面测试后,我们会向用户和客户提供变更。
Radhika:我们最近意识到,同样的逻辑可以应用于我们的一些非数字服务和组件。例如,上个月我们在一些大城市推出了两种全新的混合动力车型。我们为新车创建了促销服务,更新了我们的营销材料,培训了我们的技术人员以使用新车型,并提前部署了所有内容 - 包括车辆。这发生在制造商正式推出混合动力汽车之前。当然,这是在他们允许的情况下发生的。
苏:到发布日期到了,我们准备好了。我们当天就开始租车。
Henri:与我们的制造商合作意味着我们有一个成功且准备充分的发布会,为我们的客户和他们的客户创造了一个热门话题。
|