Guía: Proceso de release de repositorios de software
El presente documento tiene por fin describir el proceso general de release del software creado por el proyecto.
Como se establece en el plan de manejo de la configuración los repositorios se manejan bajo el flujo de git flow (ver aquí y aquí). Este documento entonces tiene por fin detallar los procedimientos específicos a este proyecto que se deben realizar al seguir el antedicho flujo.
Tipos de repositorios
El proyecto posee repositorios cuyo software se construye con la ayuda de CMake generando paquetes Debian compilados para Debian y Raspberry Pi OS (aka Raspbian). A estos repositorios los llamaremos "de paquetes Debian".
En el caso del repositorio esp32-firmware el código se compila utilizando herramientas de arduino.
Proceso de release para repositorios de paquetes Debian
Siguiendo el flujo dictaminado por git-flow se creará una rama release. Luego se seguirán los siguientes pasos.
Compilación de testeo
Utilizando la herramienta sbuild se procederá a hacer una compilación de testeo que a su vez correrá los tests unitarios definidos en el código.
Para esto primero creamos el archivo de fuentes a partir de un repositorio limpio:
cd <repositorio>
git clean -xdff
fakeroot debian/rules make_orig_tarball
Este procedimiento generará el archivo ../proyecto_x.y.z.orig.tar.xz necesario para la compilación.
En el siguiente paso realizaremos la compilación:
cd ../
dpkg-source -b repositorio/
sbuild --extra-repository="deb http://perezmeyer.com.ar/mosimpa/debian buster main" --extra-repository-key="/path/al/archivo/mosimpa.gpg.key" -sAd stable proyecto_x.y.z-1.dsc
El archivo mosimpa-gpg-key es la clave pública del repositorio y se puede obtener aquí.
Se recomienda crear un alias en ~/.bashrc para simplificar el proceso:
alias mosimpa-sbuild='sbuild --extra-repository="deb http://perezmeyer.com.ar/mosimpa/debian buster main" --extra-repository-key="/path/al/archivo/mosimpa.gpg.key"'
Para luego poder hacer:
mosimpa-sbuild -sAd stable proyecto_x.y.z-1.dsc
El proceso de compilación y creación de paquetes no debe fallar. Caso contrario se debe seguir el procedimiento de creación de un issue del tipo Testing descripto en el plan de CM.
Una vez resulto el issue repetir este proceso.
Cambio de versiones
Si el paso anterior se cumplió sin errores se pasa a establecer la versión de release final.
CMakeLists.txt en la raíz del proyecto
Se editará el archivo CMakeLists.txt en la raíz del proyecto para modificar la versión. Cada repositorio posee variables de versión de la forma:
<aplicación>_[MAJOR MINOR PATCH RC]_VERSION
Por ejemplo para el monitor:
# Application version.
set(MONITOR_MAJOR_VERSION "0")
set(MONITOR_MINOR_VERSION "0")
set(MONITOR_PATCH_VERSION "37")
# Release/beta candidate, keep empty on official versions.
set(MONITOR_RC_VERSION "~")
Se debe modificar \
set(MONITOR_RC_VERSION "")
debian/changelog
Se utilizará la herramienta debchange también conocida como dch para establecer un release:
dch -r
La herramienta abrirá el archivo debian/changelog en un editor de texto. Se deberá proceder a modificar la versión de release Debian a 1. Siguiendo el ejemplo anterior se debe pasar de:
mosimpa-monitor (0.0.37-0r0) unstable; urgency=medium
a
mosimpa-monitor (0.0.37-1) unstable; urgency=medium
Generación del release
Siguiendo el flujo de git flow se correrá
git flow release finish x.y.z
El commit de release será de la forma:
Release version x-y-z-1
Y la tag a aplicar será:
Version x.y.x
<Cambios del changelog>
Donde los cambios del changelog son las entradas en debian/changelog para esta versión. No es un procedimiento obligatorio pero auida a buscar cambios en los releases de GitLab.
Finalmente los cambios se integran a la rama develop.
Apertura de una nueva versión de desarrollo
CMakeLists.txt en la raíz del proyecto
Incrementar las variables de versión MAJOR, MINOR y PATCH según lo necesario. La variable RC deberá empezar con el caracter '~'.
Ejemplo: se pasa de la versión 0.0.37 a 0.0.38~.
debian/changelog
Establecer el nuevo changelog de desarrollo:
dch -v 0.0.38-0r0
La revisión Debian 0r0 es una revisión no válida según los estándares de empaquetado de Debian, pero técnicamente correcta. Esto permite iterar en varias versiones de desarrollo modificando el valor después de 'r' y sin generar conflictos con futuras releases.
Envío de los cambios al repositorio central
Se envían los cambios al repositorio central (en nuestro caso el alojado en GitLab):
git push origin master develop
git push origin --tags
Compilado de los binarios finales
Se repite el procedimiento descripto mas arriba esta vez con el contenido del HEAD de la rama master. Los binarios resultantes junto con sus logs y archivos relacionados se deberán guardar y, de considerarse necesario, publicados en un repositorio de paquetes Debian.
Proceso de release para el repositorio esp32-firmware
ESCRIBIR.