Diferencias

Muestra las diferencias entre dos versiones de la página.

--- ada:howto:sicoferp:factory:softwareversioning:versionreleaseprocess [2021/05/05 13:38]
administraidor [Flujo de Liberación: Desarrolladores]
+++ ada:howto:sicoferp:factory:softwareversioning:versionreleaseprocess [2024/05/20 00:28] (actual)
192.168.177.78 [Flujo de Liberación: Implantación]
@@ Línea 34: / Línea 34: @@
   * 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.
+  * 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.
 ==== Flujo de Liberación: Desarrolladores ====
   - 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.
-  - Al finalizar el cambio se deben generar los documentos soporte de la solución los cuales son el **F13**, **F14** y documenta la solución en la **Wiki**((Si aplica)).
+  - 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**((Si aplica)).
   - Se debe generar el artefacto de la solución el cual estará a cargo del desarrollador que asuma el rol de generador de artefacto.
   - Al generar el artefacto, se debe bloquear en la rama **branches**((Para evitar modificaciones no controladas)).
@@ Línea 51: / Línea 51: @@
 ==== Flujo de Liberación: Tester (QA) Validación de Soluciones ====
   - 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.
-  - Al llegar un ticket a la cola de calidad, el Tester valida la documentación que lo sustenta **F13**, **F14** y **Wiki**((Si aplica)) y verifica que el artefacto este confirmado en la rama de calidad.
+  - 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**((Si aplica)) y verifica que el artefacto este confirmado en la rama de calidad.
   - 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.
   - 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.
-  - Si el artefacto no cumple con el alcance de la solución, se diligencia el documento de incidencias el cual es anexado al ticket, se devuelve a la cola de desarrollo y el artefacto es devuelto de la rama de calidad.
+  - 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.
-  - Si el artefacto cumple con el alcance de la solución, se diligencia el documento liberación, se adiciona el ticket al formato (transitorio) de liberación de versión, se copia el artefacto a la rama **pre** y por último se desbloquea el artefacto de la de calidad.
+  - 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.
+==== Flujo de Liberación: Líder (QA) Liberación de Versión ====
-===== Notas =====
+=== Consideraciones previas ===
-  * Toda actualización debe estar soportada por un ticket en el otrs o el MantisBT.
+  - 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.
+  - El Tipo de actualización de la versión se define según la clasificación de los ticket revisados en el corte.
+  - Todos los commit de la versi´pn a liberar deben estar realizados en la rama pre.
+  - Sólo QA tiene acceso a la rama pre ya es de uso exclusivo del área.
+=== Generación del corte de versión ===
+  - Verificar que los tickets que hagan parte del corte esten realizados en la rama pre.
+  - Copiar el artefacto de la rama pre a tags
+  - nombrar el artefacto con la numeración adecuada.
+  - Notificar a implantación con la información requerida del proceso.
+==== Flujo de Liberación: Implantación ====
+  - Obtener la notificación de QA
+  - Actualizar repositorio
+  - (Opcional) Actualizar Script
+  - Realizar despliegue
+  - Registrar versión (entregada por QA) en la tabla Versión de SicofConfig
+  - 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.
+{{:ada:howto:sicoferp:factory:softwareversioning:calendario_actuaizacion.png?400|}}
+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.
+===== Notas de Proceso =====
+  * 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.
@@ Línea 65: / Línea 106: @@
   * 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.
 [[ada:howto:sicoferp:factory:softwareversioning|←Volver atras]]

Wiki

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página