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.

==== 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)).
  - 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 **F13**, **F14** 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 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.

===== Notas de Proceso =====
  * Toda actualización debe estar soportada por un ticket en el otrs o el MantisBT.
  * 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.

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

Resumen de la edición

Wiki

Herramientas de usuario

Herramientas del sitio

Herramientas de la página