| Crear funcionalidad básica de la lógica que se va a implementar con TDD |
El integrante que se encargue de desarrollar el ticket. |
Al iniciar el ticket (tablero), debe existir una funcionalidad básica con una respuesta simple que permita iniciar las pruebas TDD. |
Repositorio local |
| Crear prueba TDD |
Los integrantes se turnarán de acuerdo a la organización del tablero |
Al momento de iniciar el ticket (tablero) y la funcionalidad básica ya esté creado, el integrante a cargo empezará a realizar la prueba. Se recomienda utilizar "pair programming". |
Se creará la prueba siguiendo los lineamientos en clase, ubicando el archivo en la carpeta "tests" del proyecto. El nombre del archivo debe iniciar con el prefijo test_. En el código, la clase debe tener un nombre que termina con el sufijo TestCase, y conservar la herencia. |
| Crear lógica de acuerdo a prueba TDD |
Integrante diferente al que esté realizando la prueba TDD. |
Cuando el primer integrante confirme que la prueba ya está implementada, el segundo integrante se encargará de realizar la parte de la lógica que permita cumplir que esa prueba pase. Se recomienda utilizar "pair programming". |
Repositorio local y clases de los modelos pertinentes a la lógica relacionada |
| Actualización de repositorio |
Todos los integrantes del equipo. |
Cada que un integrante haga un commit válido en el repositorio. Esto con el fin de asegurarnos de tener la última copia funcional del sistema |
Cada integrante en su máquina de trabajo |
| Ejecución de pruebas |
Todos los integrantes del equipo en conjunto |
Cuando las pruebas estén finalizadas, se correrá una validación completa de todos los tests creados |
En cualquier máquina con la última versión del repositorio. |
| Cambios en el modelo |
Integrante diferente al que esté realizando la prueba TDD. |
Si al cambiar algo de la lógica, se toca un modelo (o clase) en común; este integrante se debe asegurar que sus cambios no impactaran las pruebas ya realizadas. Se ejecutará un test de las pruebas creadas antes de hacer el commit con los últimos cambios |
Repositorio local |
| Creación de rama "feature" |
Cada integrante del equipo que se encargue de desarrollar una nueva funcionalidad del sistema |
Cuando se inicie el desarrollo de la funcionalidad, la persona a cargo creará la rama y se encargará de su integración a develop
|
Se creará primero en el repositorio local ( a partir de la rama "develop") y esta luego se integrará al repositorio remoto (develop). |
| Integrar rama "feature" en la rama "develop" |
El desarrollador que creó la rama. |
Fusiona los cambios al repositorio remoto (develop). |
Desde el repositorio local, se realiza un commit con la palabra "(pr_to_dev)" indicando que el último cambio en la rama ya está listo y que se puede mergear a develop. Esto lo toma el pipeline como un señal para disparar la acción de hacer las pruebas unitarias pertinentes y mezclar a la rama develop sólo si el resultado de las pruebas es exitoso. |
| Mensajes de "commit" |
Todos los integrantes que hagan cambios en el repositorio |
Cuando se haga algún cambio en el código fuente o funcionalidad de sistema, el mensaje de commit debe llevar en su inicio el número de la historia de la siguiente manera: "HUXXX: ". Esto con el fin de tener trazabilidad de los cambios realizados. |
Al momento de hacer "commit" sobre la rama que se esté trabajando |
| Crear rama "hotfix" para corrección de errores |
Desarrollador que estuvo relacionado con la funcionalidad |
Tan pronto se detecte el error, se creará un ticket marcado como "bug" y se asignará el responsable. |
Se realiza el cambio en el repositorio local |
| Integrar correcciones derivadas de "hotfix" |
El desarrollador encargado de realizar los cambios. |
Fusiona los cambios y correcciones en la rama principal, después de que estos hayan sido aprobados por el equipo. |
Desde el repositorio local se realiza el cambio dirigido a "main" y "develop". |
| Creación de rama "release" |
Todo el equipo |
Cuando se determine que todas las funcionalidades están listas (incluidas las pruebas) al finalizar la semana. |
Esta rama se mezclará con "main" para realizar su cambio de versión y liberación. Los cambios que se efectúen en esta rama también serán replicadas a la rama "develop".
Desde el repositorio local, se realiza un commit con la combinación de palabras "[release][major/minor/patch]" indicando que el último cambio en la rama ya está listo y que se puede "mergear" a develop y realizar el release de acuerdo a la versión que se desee liberar (major ó minor ó patch) de acuerdo al sistema de versionamiento semántico propuesto. |
| Creación de tags de versión |
Sistema (Pipeline release) |
Cuando se dispare el pipeline que crea la rama release |
Quedará guardado en el sistema de tags del repositorio. |