示例方案: 管理版本记录
适用于: System Center 2012 SP1 - Service Manager,System Center 2012 R2 Service Manager,System Center 2012 - Service Manager
System Center 2012 – Service Manager 的此示例方案有助于你实现使用多个端到端方案管理版本记录的目标。 您可以将此示例方案视为案例研究,以帮助将单个方案和过程放入上下文中。
用于管理版本记录的方案
方案 | 描述 |
---|---|
如何创建版本记录 | 描述如何创建版本记录。 |
如何创建版本记录模板 | 描述如何创建版本记录模板。 |
将版本记录合并到父-子组 | 描述如何将版本记录合并到父-子组。 |
定义版本包配置项目 | 描述如何定义版本包配置项目。 |
如何为并行和连续活动创建模板 | 描述如何为版本记录中使用的并行活动和连续活动创建模板。 |
如何选择更改部署 | 描述如何审阅并选择要部署的更改。 |
如何规划版本活动 | 描述如何计划发布活动。 |
如何跳过失败的活动 | 描述如何跳过失败的活动。 |
如何确定版本记录中更改请求的状态和进度 | 描述如何确定版本记录中包含的更改请求的状态和进度。 |
管理版本记录方案
Woodgrove Bank 的信息技术 (IT) 经理同时管理多个项目。 通常情况下,组织中的 IT 项目团队无权访问受控生产环境。 此外,预生产环境也通过有限的访问权限加以限制。 IT 组织运行项目、开发财务应用程序以及开发基础结构改进功能。 当需要修改受控生产环境的某一部分时,IT 项目团队会提交更改请求,要求更新基础结构、更新应用程序、部署产品或实施一组新流程。
存在获批准的更改时版本管理将会启动。 按照公司的政策,更改必须通过版本管理流程进行部署。 版本经理 Garret 创建了一个父版本记录,然后他设计了该版本的一个高级图示并将高级活动与更改请求进行了关联。 版本记录中的发布活动与更改请求中的现有部署活动关联。 Garret 或委派的活动设计者随后会根据需要将子版本记录和新活动添加到版本记录中,它们详细介绍了部署更改需要完成的步骤。 为每个更改请求重复此过程,以允许所需的任何详细程度。 因此,版本记录中可包括任意数量的更改请求,具体视组织的需要而定。 当更改请求准备就绪可供实施时,更改实施者会将相应的活动标记为“已完成”。
Woodgrove Bank 通常每个月会对其生产环境部署一次更新(也称为版本)。 Garret 想要将他在 6 月份版本、7 月份版本等中定义的多个版本打包。 他将这些版本定义为父版本,然后将所有网络相关和数据库相关版本关联到 6 月份的父版本中,并将应用程序相关的版本关联到 7 月份的父版本中。 他还将新的“测试网络与数据库的集成”活动添加到 6 月份版本中,以确保这两个子版本能够共同发挥作用。
Woodgrove Bank 的下一个主要版本是部署其 HRWeb Web 应用程序的一个新版本。 HRWeb 开发人员已为版本管理团队提供了 HRWeb 应用的一个新内部版本。 Woodgrove 版本管理团队会在其测试环境中评估该内部版本,找出该内部版本中的关键性问题,然后让开发人员解决该问题并提供一个新的内部版本。 开发团队提供一个新的内部版本,而且版本管理团队在测试环境中成功对该内部版本进行重新测试。 该内部版本随后将移到预生产环境中进行测试并在该环境中试用两周。 成功完成测试后,该内部版本会部署到生产环境中。 在此过程中,Garret 创建了一个新的内部版本配置项目,并将其链接到 HRWeb 软件配置项目和版本记录的版本包。 在将最后一个内部版本部署到生产环境后,Garret 更新了 HRWeb 软件配置项目中的版本信息并关闭了该版本记录。
在 Woodgrove Bank,Garret 配置了版本的管理设置并创建了父版本记录。 他还创建了并行活动和连续活动的模板。 然后,Phil 根据 Garret 创建的模板创建了版本记录。 Phil 选择要部署的更改,然后根据需要添加、删除或修改针对各个版本的更改来更新发布活动。 Garret 配置了适用于版本记录的通知用以通知用户。 Garret 和 Phil 可根据需要随时审阅版本更改请求的状态和进度。