[SECCION EN REVISON] Fabrica: Versionamiento de Software - Proceso de liberación de versión

Esta sección está dedicada al Proceso de liberación de versiones de las aplicaciones de la fabrica de software.

Tener presente las siguientes definiciones para la contextualización del proceso:

Tener presente el significado de artefacto según las tecnologías que intervienen en los procesos de QA de la fabrica de software:

• Powerbuilder: El artefacto se relaciona como librerías y scripts que hacen parte de la solución.
• Java: El artefacto se relaciona como el jar/war generado y scripts que hacen parte de la solución.
• .Net: El artefacto se relaciona con los dll y scripts que hacen parte de la solución.

Tener presente el siguiente gráfico de referencia para describir el proceso:

A continuación se describen los flujos de los roles de fabrica en el proceso de liberación de versiones. Sin embargo tener presente la siguientes consideraciones:

• Se asume que el cambio o ajuste fue autorizado y está en la fabrica de desarrollo.
• Los desarrolladores tienen acceso a la rama de desarrollo.
• El módulo que contendrá la solución está incluido en los procesos de validación de QA.
• En la tecnología Powerbuilder el generador del artefacto es el desarrollador de la solución.
• En tecnologías como Java y .Net el generador del artefacto es el desarrollador líder o el que asuma el rol de integrador de artefacto.

1. Para objetos (Clases) existentes, el desarrollador obtiene copia actualizada desde el repositorio branches y bloquea los que necesite para implementar la solución con el fin de evitar modificaciones concurrentes.
2. Al finalizar el cambio se deben generar los documentos soporte de la solución los cuales son el F013_ING_Pruebas Unitarias y de Integración.V1.0, F014_ING_Despliegues Desarrollos.V1.1 y documenta la solución en la Wiki¹⁾.
3. Se debe generar el artefacto de la solución el cual estará a cargo del desarrollador que asuma el rol de generador de artefacto.
4. Al generar el artefacto, se debe bloquear en la rama branches²⁾.
5. Se debe copiar el artefacto generado a la rama QA (calidad).
6. Posteriormente se debe documentar el ticket anexando los documentos requeridos por el proceso y pasar a la rama de calidad.

• Si la solución no pasa el flujo de QA el ticket se devuelve, el artefacto se libera en la rama de calidad y el desarrollador debe iniciar el flujo anterior explicado desde el punto 2.
• Si la solución pasa el flujo de QA el ticket se mantendrá en QA hasta la liberación de la versión y el artefacto pasa a la rama pre

1. Opcional: Si el ticket lo requiere desde el comité de cambio se hace el plan de pruebas para la validación de la solución.
2. Al llegar un ticket a la cola de calidad, el Tester valida la documentación que lo sustenta F013_ING_Pruebas Unitarias y de Integración.V1.0, F014_ING_Despliegues Desarrollos.V1.1 y Wiki³⁾ y verifica que el artefacto este confirmado en la rama de calidad.
3. Al pasar la validaciones de documentación el artefacto es bloqueado por el Tester y se inicia el proceso de validación de la solución de acuerdo al plan de trabajo del área.
4. Opcional: Si el ticket es de atención prioritaria debe estar respaldado por autorización del líder del producto y el jefe de fabrica.
5. Si el artefacto no cumple con el alcance de la solución, se diligencia el formato F070_QA_Reporte_Issue_V1.0 el cual es anexado al ticket, se devuelve a la cola de desarrollo y el artefacto es devuelto de la rama de calidad.
6. Si el artefacto cumple con el alcance de la solución, se diligencia el formato F069_QA_Informe_Final_QA_Ticket_V1.0, se adiciona el ticket al formato (transitorio) de liberación de versión F084_VV_Bugtracker_V1.0, se copia el artefacto a la rama pre y por último se desbloquea el artefacto de la de calidad.

1. De acuerdo al corte de versión (día, semana, mes) definida en el proceso, QA debe llevar por aplicación el control del commit inicial y final para la generación de la versión.
2. El Tipo de actualización de la versión se define según la clasificación de los ticket revisados en el corte.
3. Todos los commit de la versi´pn a liberar deben estar realizados en la rama pre.
4. Sólo QA tiene acceso a la rama pre ya es de uso exclusivo del área.

1. Verificar que los tickets que hagan parte del corte esten realizados en la rama pre.
2. Copiar el artefacto de la rama pre a tags
3. nombrar el artefacto con la numeración adecuada.
4. Notificar a implantación con la información requerida del proceso.

1. Obtener la notificación de QA
2. Actualizar repositorio
3. (Opcional) Actualizar Script
4. Realizar despliegue
5. Registrar versión (entregada por QA) en la tabla Versión de SicofConfig
6. Registrar versión en los parámetros del sistema del módulo.

Se deben realizar actualizaciones regulares, para garantizar que los clientes se encuentren operando la última versión del producto con las nuevas mejoras y soluciones de bugs. Para esto se establece un calendario de actualización por producto.

Estas actualizaciones se deben realizar como mínimo mensualmente, siempre y cuando el producto haya presentado evolución, en caso que no sea así, se debe garantizar que todos los clientes se encuentren en la última versión aprobada. A excepción de las soluciones de alto impacto, estas deben ser actualizadas de manera inmediata para todos los clientes, de no ser así solo se actualizara el cliente que reporto el requerimiento o los clientes notificados en el mismo para liberación inmediata.

Se establece calendario de actualización de productos.

También se establece realizar la cuarta semana de cada mes tuning a las bases de datos de todos clientes, se deben realizar las siguientes actividades:

• Validar objetos invalidos.
• Verificar ejecución de estadisticas.
• Validar tamaños de tablespaces, si alguno se encuentra por encima del 85% se deben ampliar para que queden como minimo un 30% de espacio libre por cada uno.
• Verificar permisos de cada schema de BD que si tengan los que corresponden para operar los aplicativos.
• Realizar cambios de claves de todos los schemas en producción y actualizar claves en Archivo de Bases de Datos.
• En las bases de datos donde se tienen DBlinks validar que estos esten activos y actualizar credenciales de conexión según las claves definidas en el punto anterior.

• Toda actualización debe estar soportada por un ticket en la herramienta de gestión para soluciones.
• Toda actualización debe estar validada exitosamente por QA.
• Los cortes de versión se realizarán únicamente en la frecuencia (día, semana, mes) definida en el proceso.
• Cualquier liberación de versión que requiera atención y liberación prioritaria debe estar validada y autorizada por el líder del módulo y el jefe de fábrica.
• El rol de QA puede ser realizado por personal que tenga conocimientos de la validación de la solución y debe cumplir con el proceso implementado por QA. Sin embargo no tendrá permisos para el paso de artefactos de la solución entre las ramas.
• El paso de artefactos entre rama está autorizado solo para desarrolladores, personal de QA y el administrador de liberación de versiones.
• Todo ticket que represente un cambio en el sistema debe indicar al menos un cliente que impacte.
• Las actualizaciones de mejoras se despliegan en la liberación mensual.
• Sólo QA tiene acceso a la rama pre ya es de uso exclusivo del área.

←Volver atras