Rev-Trac Release Management Workbench permite a una organización reconocer y controlar por separado los cambios SAP que no están asignados a una versión SAP.

Esto puede beneficiar a una organización de varias maneras y puede utilizarse de forma diferente en función del tipo de cambio.

En este artículo discutiré algunos de los beneficios de la característica de cambios no asignados tanto en un proyecto SAP como en un entorno de soporte SAP.

Variantes útiles

Utilizando una variante en el Release Management Workbench, es posible realizar vistas muy específicas para los controles deseados.

Dado que la gestión de versiones está configurada para utilizar un Rev-Trac-Project común, es probable que los distintos SAP support tracks y SAP project Tracks de una organización se distingan por el campo Rev-Trac-Project.

Por lo tanto, es importante configurar variantes específicas para las versiones de SAP que la organización desea controlar.

Para controlar aún más el Release Management Workbench, las variantes deben filtrar de la vista las solicitudes no deseadas que suelen ser solicitudes Rev-Trac completas o eliminadas.

Entorno de apoyo

En un entorno de soporte de SAP, es posible que los cambios individuales de SAP funcionen por separado sin interactuar nunca con una versión hasta que se hayan probado por completo, se haya revisado el código y estén listos para la producción.

En un entorno ideal, la Junta Consultiva de Cambios (CAB) iniciará sesión en la Release Management Workbench durante su reunión de lanzamiento de producción y tendrá una lista de cambios SAP en la columna de cambios sin asignar, que se encuentran en distintos estados.

Un mayor control de la variante permitirá al CAB filtrar los cambios no asignados a los que se encuentren en estado de listos para la producción.

Todos los cambios de SAP marcados como listos para producción se encuentran en un estado que permitirá añadirlos a una versión de soporte de SAP y aprobarlos para su migración a producción en un nivel de versión.

El CAC tendrá pleno control de los cambios que pueden añadirse a la versión de apoyo correspondiente a ese período arrastrando y soltando los cambios desde los cambios no asignados, o a través de las versiones.

Entorno del proyecto

Debido a la naturaleza del trabajo de los proyectos SAP, a menudo está claro a qué versión de SAP debe pertenecer un cambio en una fase temprana de la vida del cambio SAP.

De este modo, cuando el CAB se disponga a aprobar la publicación de un proyecto, ya sea para preproducción o producción (a nivel de publicación), la publicación ya se habrá creado e incluirá una lista propuesta de cambios de SAP para la migración al siguiente entorno (preproducción o producción, en función de la configuración del entorno).

Es probable que el CAC encuentre cambios que aún no están listos para la producción y corra el riesgo de retrasar la publicación.

En este momento, el CAB o el gestor de versiones pueden arrastrar los cambios prematuros fuera de la versión, bien a la siguiente versión programada, bien a la columna de cambios no asignados.

En este momento, el CAC también puede revisar los cambios no asignados, para ver si alguno es adecuado para ser incluido en la versión actual (quizás relegado de una versión anterior debido a problemas en el desarrollo, retrasos en las pruebas, colisiones de objetos o dependencias).

Los cambios no asignados pueden utilizarse como una potente función de Release Management Workbench para mejorar la calidad, la transparencia y la agilidad durante el lanzamiento de una versión.

En los próximos meses ofreceré más información sobre las capacidades y los enfoques recomendados para gestionar las versiones de SAP con el nuevo Release Management Workbench.