ProcedimientosLiberacion - guadalinex-archive/guadalinex-v5 GitHub Wiki

Proceso de liberación

Descripción

Un problema recurrente en anteriores desarrollos de Guadalinex ha sido la falta de homogeneidad en los criterios previos a la liberación de versiones entregables.

Esta propuesta pretende dar forma a un procedimiento que regule el conjunto de condiciones que deben cumplirse como requisito previo a la entrega de cada producto, prestando especial atención a las distintas "releases" de la distribución.

Propuesta

La propuesta actual establece el siguiente esquema de trabajo para cada versión entregable.

El punto de partida para cada nueva versión serán un conjunto inicial de características o requisitos, con las que deberá contar antes de ser liberada.

Cada versión contará con dos hitos importantes a lo largo del desarrollo:

Recolección de requisitos

En esta fase se recogerán los requisitos que debe de cumplir la siguiente versión de Guadalinex que será publicada. Durante la recolección de requisitos se tendrán en cuenta las siguientes características por cada requisito:

  • El requisito es una nueva funcionalidad :

    • Se trata de la inclusión de nuevo software. Se tendrá en cuenta el espacio del CD y se valorará la importancia de dicha funcionalidad y la extracción de software del live CD.
    • El software existe y está disponible para linux utilizando una licencia que permita su distribución y uso libre.

  • El requisito es la resolución de un fallo o "bug" :

    • El bug está presente en la distribución madre.
    • El bug está sólo presente en Guadalinex.

El documento a entregar en este paso será una lista concreta de funcionalidades con los siguientes puntos:

  • Descripción de la funcionalidad.
  • Si dicha funcionalidad se encuentra en la distribución madre.
  • Lista de aplicaciones sugeridas que cubren dicha funcionalidad si existen.
  • Licencia de las aplicaciones anteriores.
  • Espacio ocupado por dichas aplicaciones junto con sus dependencias al instalarlas en la versión anterior liberada de Guadalinex.
  • Lista de aplicaciones que puede sustituir de la versión anterior publicada de Guadalinex.
  • Prioridad de desarrollo de dicha funcionalidad.

En el caso de ser una corrección de un fallo se entregará:

  • Descripción del fallo. Indicando urls, BTSs y toda la información posible.
  • Si dicho fallo se encuentra en la distribución madre.
  • Versión del paquete o paquetes afectada, si se conocen.
  • Versión del paquete o paquetes que corrige dicho fallo, si se conocen.
  • Prioridad del desarrollo debido al impacto de dicho error.
Feature-Freeze (congelación de requisitos)

(Punto 1 del diagrama anterior)

Hito a partir del cual no se deberán incorporar nuevos requisitos a la versión en la que se está trabajando. Las necesidades que surjan a partir de este momento deberán ejecutarse en la siguiente versión.

En cada F.F se congelará el repositorio de paquetes de la distribución madre hasta el momento de la siguiente versión. De este modo se constituye una base sólida sobre la que realizar las tareas de depuración.

La etapa de desarrollo se dividirá en nuevos hitos, de modo que se disponga de un mayor control de las tareas pendientes en periodos más cortos de tiempo, facilitando el seguimiento de las mismas hasta su consecución. Se definirá una prioridad a cada hito teniendo en cuenta el documento generado en la recolección de requisitos.

Desarrollo de requisitos

Cada desarrollo vendrá compuesto por:

  • Reunión de recursos de software necesarios en el repositorio derivado
  • Integración de dicho software en la distribución siguiendo las directrices de Guadalinex.
  • Pruebas de desarrollo de dicho software.
  • Liveración de un CD Live con el cambio del hito completado si la dependencia entre hitos y la prioridad lo permite.

En esta fase se generará la siguiente información que será entregada a control de calidad (puntos 2 y 6).

  • Listado de los cambios realizados en los paquetes de la distribución.
  • Descripción de pruebas realizadas en la fase de desarrollo.
  • Descripción de los cambios realizados en la distribución.
    • Paquetes cambiados.
    • Ficheros de configuración añadidos.
  • Imagen de CD Live con la versión que contempla los cambios anteriores.

#####Control de calidad

Comprobación de los requisitos realizados partiendo de la actualización de la versión anterior por paquetes, uso desde live y desde instalación de 0:

  • Comprobación de posibles regresiones teniendo en cuenta el listado de peticiones y fallos anteriores.
  • Comprobación de requisitos de la nueva funcionalidad o corrección realizada.

En el caso de marcar la funcionalidad como inválida se reportará (puntos 3 y 7):

  • Causa del rechazo.
  • Descripción del entorno de pruebas.
    • Descripción del hardware.
    • Descripción del estado del software.
    • Log del sistema, trazas de error, todo lo que pueda ayudar a reproducir dicha situación.
  • Listado de pruebas satisfactorias y no satisfactorias.

El control de calidad tendrá en cuenta los posibles fallos encontrados por la comunidad, filtrándolos y relacionándolos correctamente con los que ya hay.

#####Inicio de versiones RC

A partir de este instante (punto 5 del diagrama), se realizarán las mismas iteraciones que en la fase de desarrollo de funcionalidades pero de forma más rápida. No se desarrollarán nuevas funcionalidades, sólo se intentarán solventar los posibles fallos que haya en la distribución hasta llegar a una versión final estable.

#####Entrega de versión final

Versión final publicada de cara al público

Ejemplos

Beneficios
Autor Antonio Gonzalez, Alfredo Matas
Estado Borrador