• Artículo

Administración de registros de versión en System Center 2012 - Service Manager

 

Se aplica a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

La clave para comprender la administración de versión en System Center 2012 – Service Manager es ser consciente de cómo interactúan los objetos, tales como las solicitudes de cambio y actividades (algo que facilitan los registros de versión). La administración de versión utiliza registros de versión principales y secundarios para facilitar la automatización del proceso de actualización del proceso de solicitudes de cambio y la propagación del estado entre actividades paralelas, las actividades secuenciales y las actividades que estas contienen.

A menudo, los proyectos tienen varias partes y hay más de una solicitud de cambio que se puede implementar en momentos diferentes que pueden afectar a un proyecto. El objetivo general tanto de la administración de cambios como de la administración de versión es proteger el entorno de producción de cambios innecesarios, por lo que antes de realizar cualquier cambio es preciso aprobarlo. La administración de versión sólo afecta a los los cambios aprobados.

Cuando se aprueban los cambios, los procesos de administración de versión son los que se encargan de agrupar dichos cambios, programarlos y desarrollarlos. En función de la naturaleza del cambio, a veces dicho desarrollo puede darse en la fase de proyecto, mientras que otras puede darse en la fase de administración de la versión. Independientemente del momento en que se produzca el desarrollo, la administración de versión garantiza que todos los cambios se prueban y que se pueden implementar con total seguridad. Además, la administración de versión se utiliza para evaluar y empaquetar varias versiones juntas, con el fin de reducir al mínimo el tiempo de inactividad de la infraestructura. El paquete de versiones se prueba conjuntamente para comprobar que no hay conflictos técnicos ni de recursos que puedan afectar a la disponibilidad de la infraestructura. Se agrupan múltiples cambios y se planea su implementación conjunta en la siguiente ventana de mantenimiento o publicación programada. La función de la administración de versión mediante registros de versión, es consolidar varios cambios e implementarlos mediante el método más seguro y eficiente posible.

Después de que se hayan agrupado los cambios, un administrador de versión define la secuencia de acciones necesarias para una versión con actividades de versión. Por ejemplo, los distintos cambios pueden tener tareas de actualización de la infraestructura, tareas de modificación de la base de datos, tareas para actualizar aplicaciones u otras tareas individuales. En algunos casos, puede tener sentido agrupar varias tareas junto con las actualizaciones de la infraestructura o realizar actualizaciones de la base de datos o de la aplicación. Algunas tareas se pueden implementar simultáneamente, mientras que otras deben implementarse de forma secuencial o por separado.

Administración de registros de versión en Service Manager

El administrador de versión o cualquier otra persona responsable de la versión, define la secuencia de acciones de los registros de versión. El registro de versión puede representar la secuencia de implementación de los diferentes cambios mediante actividades paralelas, actividades secuenciales y otras actividades. El administrador de versión puede delegar la responsabilidad de las actividades a otros usuarios. Cuando se delega una actividad, la persona responsable de la actividad puede modificarla y actualizar su estado.

Cuando se modifica una actividad, su estado no se actualiza inmediatamente. Posteriormente, se produce un retraso hasta que se activa el flujo de trabajo y se actualiza el estado de la actividad. A menudo, pueden transcurrir entre 30 y 60 segundos antes de que aparezca el estado actualizado de la actividad en la consola después de actualizar la vista de un elemento. Otras actividades dependientes del registro de versión pueden tardar más en actualizarse. Por ejemplo, supongamos que tiene un registro de versión que contiene una docena de actividades. Si actualiza un elemento que esté cerca del principio de la lista, la actualización en la consola puede tardar 30 segundos en realizarse. Posteriormente, la siguiente actividad del registro de versión puede actualizarse automáticamente 30 segundos después, y así sucesivamente. Por lo tanto, la actualización que efectuó originalmente puede tardar un tiempo en propagarse a todas las actividades afectadas del registro de la versión.

Partes de los registros de versión

Dado que a menudo se agrupan las versiones, puede agrupar varios registros de versión mediante el uso de una relación de elementos principales-secundarios. Básicamente, un registro de versión principal sirve como contenedor de varios registros de versión secundaria. Sin embargo, de manera predeterminada un registro de versión recién creado no es un registro de versión principal. Debe convertir un registro de versión en un registro de versión principal para poder agregar registros de versión secundarios.

Al igual que las solicitudes de cambio, los registros de versión contienen actividades que deben aprobarse, así como acciones manuales. Además, los registros de versión pueden contener actividades paralelas y secuenciales. Las actividades paralelas y secuenciales son contenedores para otras actividades y definen cómo se deben implementar las actividades constituyentes (las actividades paralelas se pueden implementar simultáneamente, mientras que otras actividades paralelas están en curso). Las actividades secuenciales deben finalizarse en el orden en que estén organizadas, una tras otra.

Temas sobre registro de versión

Otros recursos para este componente