Wiki

Has cargado una revisión vieja del documento! Si la guardas crearás una versión nueva con estos datos.

====== [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.

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

^Término^Definición (en el proceso)^
|Artefacto|Se define como los cambios que se realizan a las ramas de código y se pasan en el flujo de liberación de versión desde branches hasta tags.|
|branches|Ambiente para desarrollo y/o ajustes de código fuente de las aplicaciones de la compañía|
|trunk|Ambiente para validación de las soluciones entregas por la fábrica de desarrollo.|
|pre|Ambiente transitorio donde se registran los cambios del siguiente corte de las versiones en mantenimiento y/o evolución.|
|tags|Ambiente que contiene las versiones estables|

==== Aclaraciones Artefacto ====
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.

===== Proceso de Liberación de Versión =====

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

{{ :ada:howto:sicoferp:factory:softwareversioning:flujo.png?800 |}}

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:

=== 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.

==== 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 **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)).
  - Se debe copiar el artefacto generado a la rama **QA** (calidad).
  - Posteriormente se debe documentar el ticket anexando los documentos requeridos por el proceso y pasar a la rama de calidad.

=== Consideraciones ===
  * 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**

==== 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 **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 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 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 ====

=== Consideraciones previas ===

- 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
  - Realziar despliegue
  - Registrar versión (entregada por QA) en la tabla Version de SicofConfig
  - Registrar version en los parametros del sistema del módulo.

===== 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.
  * 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.

[[ada:howto:sicoferp:factory:softwareversioning|←Volver atras]]

Resumen de la edición

Wiki

Herramientas de usuario

Herramientas del sitio

Herramientas de la página