Extensiones ChaRMante

Cuando hablamos con los clientes sobre la gestión de solicitudes de cambio (ChaRM), siempre hacemos hincapié en que existen dos tipos principales de procesos denominados que ya están incluidos en la personalización de las entregas: la "corrección normal" y la "corrección urgente".

Ambos flujos de trabajo mapean la gestión de los cambios de software y se integran de forma óptima en el sistema de transporte.

La principal diferencia entre los dos tipos: Las modificaciones normales sólo pueden ponerse en producción como una liberación. Las correcciones urgentes, en realidad destinadas por SAP a ajustes inmediatos en los que el tiempo es un factor crítico, pueden ponerse en producción en cualquier momento sin asignación de liberación.

En una primera entrega, estos dos "flujos de trabajo" están disponibles en el sistema y aún pueden personalizarse, pero la forma de implementación en producción (como versión o individualmente) está predefinida por el sistema.

Muchos clientes no pueden vivir con la visión orientada a la publicación. Por un lado, esto se debe a que los responsables de TI no quieren meterse con el departamento de negocio y sólo quieren poner funciones en producción en determinados momentos. Por otro lado, se utiliza la excusa de que "somos ágiles y, por tanto, no podemos comprometernos con una versión".

Por ello, la mayoría de los usuarios de ChaRM sólo utilizan la corrección urgente. Sin embargo, en los proyectos de aplicación existe más de un flujo de trabajo, por lo que este tipo de proceso se asigna en el sistema en diferentes variantes - por ejemplo, como Cambio preaprobado y como Cambio importante.

El contexto subyacente sigue siendo siempre la corrección urgente y la oportunidad asociada de aplicar individualmente los cambios de forma productiva.

Si los responsables informáticos se inician en la corrección normal y su proceso de software, suele haber una ventaja significativa sobre la corrección urgente: Funciona con transportes de copias.

Como los desarrolladores no suelen disponer en el sistema de desarrollo de los datos de prueba pertinentes para una prueba más amplia, los cambios deben transferirse al sistema de aseguramiento de la calidad y probarse allí.

En el contexto clásico, esto significa que el transporte debe ser liberado e importado. Esto no es un problema en sí mismo; la mayoría de las empresas han mapeado el sistema de autorización de tal forma que los transportes pueden ser liberados por los desarrolladores y se define una importación automática para la cola de importación del sistema de garantía de calidad.

En la práctica, sin embargo, suele conducir a desarrollo, pruebas, desarrollo y luego pruebas de nuevo. Ya he visto ciclos de este tipo para requisitos en los que se crearon más de cien transportes.

En el uso clásico de una corrección urgente, esto se puede asignar a través del flujo de trabajo y la protección de adelantamiento hace el resto, pero las implementaciones productivas de tales cambios siguen siendo extensas.

Con los transportes de copias, la cola de importación sigue siendo escasa, ya que los objetos se colocan en el sistema posterior utilizando el tipo de solicitud "Transporte de copias", pero estos "intentos" nunca acaban en la cola de importación del sistema de producción. En este contexto, más de cien intentos no suponen ningún problema.

Hay que tener en cuenta una característica importante: El transporte original permanece abierto hasta que finalizan las actividades de desarrollo y, a continuación, los objetos se bloquean permanentemente para este cambio. Esto tiene la ventaja de que ya no pueden producirse adelantamientos.

Con una manipulación hábil y un poco de codificación, este procedimiento puede transferirse a la corrección urgente. También solemos configurar el flujo de trabajo para que el transporte original no se libere hasta que el usuario clave haya completado las pruebas.

En este flujo de trabajo, los adelantamientos son cosa del pasado. Sobre todo en entornos en los que solo se utilizan correcciones urgentes, el usuario clave quiere ver los cambios en el sistema de producción en cuanto terminan las pruebas.

Como la diferencia de tiempo entre la liberación de los objetos en el sistema de desarrollo y su importación en el sistema de producción es pequeña (normalmente menos de un día), ya no hay problemas de adelantamiento.