Para el control de versiones de código se utiliza sistema basado en GIT (https://git-scm.com/).
Flujo de trabajo
La base del flujo de trabajo aquí expuesto es el sistema GITFLOW
WORKFLOW. Este sistema define un modelo de ramificación estricto diseñado entorno al lanzamiento del proyecto y proporciona un marco robusto para la gestión de proyectos.
Visión general
La disposición de las ramas son las siguientes
- “master”: Una única rama donde se colocarán las versiones de producción (es decir, públicas).
- Todos los “commits” en esta rama deben estar numerados con su versión correspondiente.
- No se permite desarrollo, ni corrección de errores en esta rama.
- Todos los “commits” de esta rama deben ser funcionales:
- Su compilación no debe contener ni errores ni advertencias (“warning”).
- Debe haber pasado el sistema de prueba sin ningún problema.
- En esta rama no se desarrolla código, únicamente se puede hacer un “merge” con la rama máster desde las ramas de las carpetas “hotfix/” o “release/”.
- “develop”: Una única rama de desarrollo donde se colocarán las versiones de desarrollo.
- Todos los “commits” de esta rama deben ser compilables:
- Su compilación no debe contener ni errores ni advertencias “warning”).
- Es recomendable que pasen un test funcional.
- Todas las ramas deben hacer un “merge” a esta rama una vez que e ha terminado el desarrollo o solucionado el problema (“hotfix”).
- Esta rama es de desarrollo y pueden contener errores, nunca entregar una versión de producción desde esta rama.
- En esta rama no se desarrolla per se, sino que es donde van se juntan los desarrollos y corrección de errores realizados en el resto de ramas.
- “hotfix/”: Una carpeta donde se colocarán las ramas de corrección de errores de producción. Esta carpeta sirve para crear ramas donde se solucionan los errores no detectados por el sistema de prueba que han llegado a la rama “master”.
- En estas ramas sólo se solucionan problemas que han aparecido en la rama “master”. No se añaden nuevas características.
- Una rama nueva en esta carpeta debe implicar también un cambio en el sistema de prueba para detectar el error que no se había detectado antes.
- Antes de realizar un “merge” a la rama “master” se debe asegurar que el firmware resultante sea funcional:
- Su compilación no debe contener ni errores ni advertencias (“warning”).
- Debe haber pasado el sistema de prueba (corregido) sin ningún problema.
- Se realiza un “merge” adicional con la rama de “develop”, el “commits” resultante debe ser compilable:
- Su compilación no debe contener ni errores ni advertencias (“warning”).
- Es recomendable que se pase un test funcional
- “release/”: Una carpeta donde se colocarán as ramas de comprobación para generar una nueva versión de producción. Esta carpeta sirve para crear ramas donde se buscarán y solucionarán los errores del código antes de pasar a producción.
- En estas ramas sólo se solucionan problemas que han aparecido en la rama “develop” antes de realizar un “merge” con la rama “master”. No se añaden nuevas características.
- Antes de realizar un “merge” a la rama “master” se debe asegurar que el firmware resultante sea funcional:
- Su compilación no debe contener ni errores ni advertencias (“warning”).
- Debe haber pasado el sistema de prueba sin ningún problema.
- Se realiza un “merge” adicional con la rama de “develop”, el “commits” resultante debe ser compilable:
- Su compilación no debe contener ni errores ni advertencias (“warning”).
- Es recomendable que se pase un test funcional.
- “feature/”: Una carpeta donde se colocarán las ramas de desarrollo para añadir una nueva característica o solucionar un problema encontrado durante el desarrollo.
- En estas ramas se desarrolla o se solucionan problemas.
- Las ramas dentro de esta carpeta son de desarrollo y pueden contener errores, nunca generar una versión de producción desde estas ramas.
- Antes de realizar un “merge” a la rama “develop” se debe asegurar que el firmware resultante sea compilable:
- Su compilación no debe contener ni errores ni advertencias (“warning”).
- Es recomendable que se pase un test funcional.
Rama “master” y rama “develop”
Este flujo de trabajo usa dos ramas para registrar el historial del
proyecto. La rama “master” almacena el historial
de lanzamientos oficiales (firmware que ha pasado a producción),
y la rama “develop” sirve como una rama de
integración de características.
La rama “develop” contendrá el historial completo del
proyecto, mientras que la rama “master” contendrá una
versión resumida. Es decir, las dos ramas se crean al inicio del
proyecto y son paralelas.
Carpeta “features/”
Cada nueva característica debe residir en su propia rama, dentro de
la carpeta “feature/”. Cada nueva rama de característica
tiene siempre la rama “develop” como su rama
principal. Cuando se completa el desarrollo de una característica se
fusiona nuevamente en el desarrollo (rama “develop”).
Merge de “features/” en “develop”
Para añadir una nueva característica ya desarrollada en la rama
“develop” se siguen los siguientes pasos:
- Comprobar que el nuevo código desarrollado compila sin errores ni advertencias (“warning”). A ser posible pasar un test automático en el código.
- Realizar un “merge” de la rama “develop” a la rama de desarrollo (“feature/…”).
- Corregir los conflictos surgidos en el “merge”
- Comprobar que el código fusionado compila sin errores ni advertencias (“warning”). A ser posible pasar un test automático en el código.
- Realizar un “merge” de la rama de desarrollo (“feature/…”) a la rama “develop”.
Carpeta “release/”
Una vez que la rama “develop” ha adquirido suficientes
funciones para un lanzamiento se bifurca una
La creación de esta rama inicia el siguiente ciclo de lanzamiento,
por lo que no se pueden agregar nuevas características después de
este punto, solo las correcciones de errores, la generación de
documentación y otras tareas orientadas a la versión deben ir en
esta rama. Una vez que está listo para enviar, la rama
“release/…” se fusiona con “master” y se
etiqueta con un número de versión. Además, debe fusionarse
nuevamente con “develop”, lo que puede haber
progresado desde que se inició el lanzamiento.
Merge de “release/” en “master”
Para generar una nueva versión de producción se sigue los
siguientes pasos:
- Comprobar que el nuevo código desarrollado compila sin errores ni advertencias (“warning”).
- Realizar un test completo del código, incluyendo las funciones de actualización del firmware.
- Realizar un “merge” de la rama “release/…” a la rama de producción (“master”). No debería generar conflictos y si los genera todo se debe substituir con la rama de “release/…”
- Cambiar el nombre del archivo .bin al número de versión (ej.: 1.1.1a.bin)
- Actualizar el firmware del producto y leer el código .hex
- Copiar los dos archivos (.bin y .hex) a la carpeta correspondiente dentro del árbol de carpetas.
- Realizar la fusión de la rama “release/…” con la rama “develop” y corregir los conflictos.
Merge de “release/” en “develop”
Hay que tener en cuenta que la rama “develop” puede haber
progresado mientras se preparaba una nueva versión, por lo que para
realizar la fusión de estas dos ramas habrá que seguir los
siguientes pasos:
- Realizar un “merge” de la rama “develop” a la rama de preparación de la versión (“release/…”).
- Corregir los conflictos surgidos en el “merge”
- Comprobar que el código fusionado compila sin errores ni advertencias (“warning”). A ser posible pasar un test automático en el código.
- Realizar un “merge” de la rama de desarrollo (“release/…”) a la rama “develop”.
Carpeta “hotfix/”
Esta carpeta se utiliza para el mantenimiento (corrección de
errores) de la rama “master” y se utiliza para parchear de forma
rápida las versiones de producción.
Todas las ramas de esta carpeta parten de una versión estable
(versión de producción), es decir, de la rama “master”, y terminan
en una segunda versión estable (con el número de versión
actualizado) en la rama “master”, además se realizará un segundo
“merge” con la rama de desarrollo (“develop”).
Etiquetado de la versión
Tanto la rama “master” como la rama “develop” deben seguir el
mismo etiquetado de versiones, que será del tipo:
XX.YY.ZZaa
Donde:
XX corresponde al número de versión. Esta versión aumentará cuando haya un cambio de hardware o firmware suficientemente importante.YY corresponde al número de subversión. Esta versión aumentará cada vez que haya un nuevo “commits” en la rama “master” desde la rama “release/…”.ZZ corresponde al número de corrección.aa corresponde al número de compilación. Este número aumentará cada vez que haya un nuevo “commits” en la rama “develop”.
