Share via

  • 项目

在 System Center 2012 - Service Manager 中管理版本记录

 

适用于： System Center 2012 SP1 - Service Manager,System Center 2012 R2 Service Manager,System Center 2012 - Service Manager

理解 System Center 2012 – Service Manager 中的版本管理的关键在于了解诸如更改请求和活动等对象的互动方式 — 通过版本记录促进互动。 版本管理使用父和子版本记录来帮助实现以下过程的自动化：更新更改请求的状态及并行活动、连续活动和其中的活动之间的状态传播。

通常会存在这样的情况：一个项目的多个部分以及多个更改请求可在会影响项目的不同时间进行部署。 更改管理和版本管理的总体目标是要保护生产环境免受不必要的更改，让要对其进行的每一个更改都必须先获得批准。 版本管理仅处理获得批准的更改。

更改获得批准后，版本管理过程将对更改进行分组归在一起、计划这些更改以及部署这些更改。 根据更改的性质，有时开发会在项目阶段进行，其他时候开发会在版本管理阶段进行。 无论何时进行开发，版本管理都会确保更改经过测试以及这些更改的部署是安全的。 此外，版本管理还用于评估各个版本并将其打包在一起，以帮助将基础结构停机时间降至最低。 多个版本将在版本包中一起经过测试，以确认没有存在会影响基础结构可用性的任何技术或资源冲突。 多个更改将捆绑在一起并计划在下一个预定版本或维护时段一起部署这些更改。 版本管理的功能是利用版本记录合并多个更改，并以最安全和最有效的方法部署这些更改。

将这些更改捆绑在一起后，发行经理将定义含发布活动的发行所需的操作顺序。 例如，不同的更改可能有基础结构更新任务、数据库修改任务、应用程序更新任务或其他各个任务。 在有些情况下，建议将一些任务进行分组归在一起并执行基础结构更新或者执行数据库更新或应用程序更新。 有些任务可同时部署，而其他任务必须按顺序或单独部署。

在 Service Manager 中管理版本记录

发行经理或其他发行负责人可用版本记录定义操作顺序。 版本记录可能会使用并行活动、连续活动和其他活动描述不同更改的部署顺序。 发行经理可以将活动的责任委派给其他人。 委派活动后，该活动的负责人可以修改该活动并更新其状态。

修改活动时，其状态不会立即更新。 在工作流激活以及活动状态被更新之前有一个延迟时间。 通常情况下，在刷新项目的视图后可能需要经过 30 到 60 秒，在控制台中才能看到更新后的活动状态。 版本记录中的其他相关活动可能需要更长的时间来更新。 例如，假设你有一个版本记录包含十几项活动。 如果更新列表顶部附近的项目，则在控制台中更新可能需要花费 30 秒的时间。 然后，版本记录中的下一项活动可能会在 30 秒后自动更新，以此类推。 因此，你最初所做的更新可能要经过一段时间才能传播到版本记录中所有受影响的活动。

部分版本记录

由于版本通常都捆绑在一起，因此你可以使用父-子关系将多个版本记录分组归在一起。 从本质上讲，父版本记录就是一个用于容纳多个子版本记录的容器。 但默认情况下，新建的版本记录不是父版本记录。 你必须将版本记录转换成父版本记录，才可添加子版本记录。

类似于更改请求，版本记录包含要进行审批和执行手动操作的活动。 此外，版本记录还可以包含并行活动和连续活动。 并行活动和连续活动是用于容纳其他活动的容器，它们定义了必须如何实施构成活动 — 并行活动可以同时实施，同时其他并行活动也在实施中。 连续活动必须按其组织顺序依次完成。

版本记录主题

此组件的其他资源