Es una rama temporal que se define para pasos a producción criticos que aún no han sido validados al 100% por calidad o tienen tickets relacionados que no han sido probados y tienen impacto leve o moderado en los clientes que requieren la liberación.

A continuación se listan los tipos de impacto que deben ser considerados en las liberaciones de la rama transitoria.

Los tipos de impacto deben ser utilizados para evaluar el tipo de afectación en los clientes.

A continuación se listan los tipos de complejidad que deben ser considerados en las liberaciones de la rama transitoria.

Cambios sencillos o simples en el código como:

• Ajustes a columnas de (datawindows, entidades): Siempre y cuando la columna no modifique el agrupamiento de la consulta que genera el datawindow o entidad y la tabla exista previamente.
• Ajustes visuales en ventanas o formularios: Esto cubre ajustes de formato, agregar un campo oculto, ampliar tamaños.
• Ajustes a funcionalidades de impacto leve.

Cambios intemedio en el código como:

• Adición de fragmentos de código: Esto incluye validaciones, Reportes.
• Ajustes a funcionalidades de impacto moderado.

Cambios grandes en el código como:

• Inclusión de nuevas funcionalidades.
• Ajustes a funcionalidades de impacto crítico.

Los tipos de complejidad deben ser evaluados antes de enviar a QA.

A continuación se listan las condiciones previas que se deben cumplir para optar por la utilización de la rama transitoria.

• La solución a liberar y/o soluciones vinculadas¹⁾ aun no han sido validada(s) por calidad en su totalidad y se requiere liberación urgente en el cliente porque se está parando la operación critica²⁾.
• Las soluciones vinculadas³⁾ tienen impacto Leve o Moderado en los clientes que se realizará la liberación. Para estó se deben contar con la revisión del lider técnico del módulo.
• Autorización del Lider del Producto⁴⁾.
• Autorización del Jefe de Fábrica⁵⁾.

Esta liberación se presenta cuando existe un desarrollo en gestión en la rama branches que utiliza una libreria que contiene objetos

A continuación se describe el proceso de generación de la rama transitoria:

1. Solución a liberar: Cumplir las Condiciones de generación.
2. Lider Configuración: Generar el corte de versión de la rama tags (revert/update) y copiar la rama en el directorio transi⁶⁾
3. Calidad (QA): Copiar los artefactos de la solución a la rama transi y hacer el commit⁷⁾.
4. Calidad (QA): Pasar el ticket y notificar a implantación sobre la situación de la liberación indicando los clientes que afecta la liberación.
5. Implantación: Hacer la liberación a los clientes relacionados y pasar de nuevo el ticket a calidad indicando la actividad de liberación realizada.
6. Calidad (QA): Una vez es validada la solución en el ambiente de validación pasar el artefacto a tags⁸⁾.

• Solo se permite una rama transitoria por módulo.
• Las liberaciones transitorias no son acumulativas es decir solo se puede realizar una por liberación (ticket), a menos que sea actualización del mismo artefacto.
• Las liberaciones transitorias bloquean commits en la rama tags por lo tanto toda liberación transitoria debe ser validada antes de pasar cualquier otra solución a tags.
• El proceso de liberación transitoria se debe generar desde el flujo de calidad cuando un cliente o varios requieren liberación de una solución urgente que aún no ha sido completamente validada o tienen tickets de soluciones relacionadas pendientes.
• No se debe utilizar este mecanismo de liberación para cualquier liberación ya que el objetivo es permitir a los clientes la operación de sus procesos críticos o de valor.

←Volver atras