Visión global del proceso de desarrollo (postprocesado)
Tanto las tareas de desarrollo elegidas por el equipo de trabajo, como las incidencias puestas por otros módulos a nuestro subsistema, han seguido un mismo proceso de desarrollo definido por los coordinadores en las partes comunes y por el grupo de trabajo en las partes específicas a nuestro módulo. A continuación se expone este proceso, usando como ejemplo una de las incidencias creadas en nuestro submódulo, la #292.
Las incidencias pueden ser publicadas por el coordinador del grupo o por otros módulos. La incidencia elegida como ejemplo es una incidencia interna, por lo que ha sido creada por el coordinador de postprocesado, usando la plantilla de gestión de incidencias especificada en la sección de gestión de incidencias.
Para cada incidencia, se detalla una descripción del problema, las necesidades del subsistema y propuestas de mejora relacionadas con la incidencia. Las tareas son asignadas de forma voluntaria por el miembro del equipo que desee implementar la funcionalidad; si esta persona tarda demasiado tiempo en implementar la funcionalidad o desaparece, el equipo puede asignarle la tarea a otro miembro. Esta incidencia es asignada, en este caso a Daniel Sánchez Baleyrón. Por último, a esta incidencia se le añaden etiquetas que identifican el estado de la incidencia, el tipo de incidencia y la prioridad de la misma. Concretamente, esta incidencia tiene como estado abierta, una prioridad alta y es de tipo resolución error.
La herramienta usada para la publicación y gestión de incidencias es GitHub, a través de su funcionalidad para crear proyectos con tableros Kanban, como puede observarse en la siguiente imagen.
Las incidencias no contemplan únicamente incrementos funcionales y resolución de errores; también pueden crearse para tareas de documentación y desarrollo de pruebas.
En el caso de que el entorno de desarrollo esté preparado, la única tarea que se debe realizar antes de implementar es crearnos una rama de feature, siguiendo la política de ramas definida para nuestro grupo. Concretamente, la rama que Daniel creó para la implementación de esta incidencia es postprocesado-#292. El siguiente paso es obtener la rama creada en nuestro entorno local de trabajo, para poder trabajar. En este caso, el cambio implementado por Daniel consistió en resolver un aviso que se reportaba en la ejecución de las pruebas del módulo de postprocesado. Concretamente, este aviso indicaba un mal olor sintáctico en la definición de un if: se usaba la expresión is not con un literal, cuando en este tipo de comparaciones se recomienda usar !=.
Una vez realizada la implementación, se deben actualizar las pruebas unitarias en base a los cambios realizados, para adaptarlos y evitar que fallen. Seguidamente, se deben ejecutar las pruebas para comprobar que la adaptación se ha realizado correctamente y que la implementación realizada no ha introducido un bug en nuestro módulo, lo cual se realiza con el comando python manage.py test postproc.
Si las pruebas se ejecutan sin fallos, la funcionalidad está lista para ser subida al repositorio. Para ello, se realizará un commit siguiendo la política de commits del equipo de trabajo y se subirá a la rama de feature.
La funcionalidad implementada puede subirse a su rama de feature en el repositorio sin pruebas, pero no podrá ser fusionada con otras ramas hasta que las pruebas no estén implementadas.
Para la implementación, nuestro equipo usa la herramienta PyCharm, un IDE de Python desarrollado por JetBrains. Para la obtención de la rama y la realización del commit y la subida al repositorio se utiliza el cliente de Git GitKraken. Por último, para el despliegue local de la aplicación decide, nuestro equipo usa dos entornos distintos, dependiendo de las preferencias de los miembros del equipo: VirtualBox con Ubuntu Server 20.04 o WSL2.
Cada commit que se realiza al repositorio provoca una ejecución de los servicios de integración continua existentes en el repositorio. Nuestro repositorio decide hace uso de los servicios de Travis CI y de Codacy.
En primer lugar, Travis CI construye un entorno virtual preparado para arrancar el proyecto A continuación, se encarga de ejecutar todas las pruebas existentes en el sistema. Una vez ejecutadas, Codacy analiza el código fuente en busca de malos olores, problemas de seguridad y otras incidencias de código, además de usar el reporte de cobertura de código generado al ejecutar las pruebas para mostrar esta métrica.
Es fundamental asegurar que el proceso de integración continua se ha ejecutado correctamente sin fallos para poder distribuir la funcionalidad implementada al resto de grupos, moviendo el código de la funcionalidad a otras ramas. Por ello, antes de realizar pull request alguna, es imperativo comprobar que el build de Travis reporta que todas las pruebas han pasado satisfactoriamente. En el caso de la incidencia #292 no se pudo realizar este proceso porque la integración continua no estaba configurada correctamente aún en el repositorio.
En el caso de que la integración continua funcione correctamente y los tests no pasen, es obligatorio solucionar los errores reportados antes de incorporar la funcionalidad a cualquier rama. Para ello, se podrá trabajar en la misma rama de feature en la que se ha implementado la funcionalidad.
En la siguiente imagen se puede observar la pull request realizada por Daniel para incorporar su funcionalidad a la rama develop del módulo. Esta fue revisada por el coordinador e incorporada por Daniel.
Después de comprobar con la integración continua que las pruebas pasan y la integridad del sistema no ha sido corrompida por la nueva funcionalidad, el código debe ser distribuido para el equipo de trabajo. Para ello, se realiza una pull request, de nuestra rama a la rama postprocesado-dev. Se recomienda la pull request porque permite revisar los cambios implementados antes de incorporar los cambios a la rama. El coordinador se encarga, una vez realizada la pull request, de revisar los cambios y resolver los conflictos junto con el desarrollador asignado. Finalmente, la funcionalidad se incorpora a la rama postprocesado-dev.
Si la funcionalidad incluida en la rama develop del módulo contiene fallos, por lo que las pruebas no pasan en Travis, se deberá crear una incidencia para resolver estos problemas y crear una nueva rama de feature para la nueva implementación.
En el momento en el que el equipo de trabajo considere que hay un incremento funcional desarrollado en postprocesado-dev suficiente, o si un coordinador de otro grupo lo solicita, se realizará una pull request para incorporar los cambios realizados por nuestro módulo en la rama develop global. Esta pull request se realizará desde la rama postprocesado, por lo que habrá que realizar una pull request previa desde postprocesado-dev a postprocesado. Otro coordinador revisará el código y solucionará los conflictos con el coordinador que ha publicado la pull request. Finalmente, la funcionalidad se incorpora a la rama develop.
Si la funcionalidad incluida en la rama develop contiene fallos, por lo que las pruebas no pasan en Travis, se deberá crear una incidencia para resolver estos problemas y crear una nueva rama de feature para la nueva implementación, realizando todo el proceso descrito.
Una vez los equipos terminan sus implementaciones y las incluyen en develop, se prueba todo el sistema, comprobando que funciona y que el servicio de integración continua ejecuta todas las pruebas satisfactoriamente. En ese caso, los coordinadores en reunión de coordinación deben publicar una nueva versión del proyecto.
Para ello, se crea una rama de release a partir de develop. La rama que se ha creado para la publicación es release-3.2021, siguiendo la política de versionado definida. A continuación se realizan en la nueva rama los cambios en el código necesarios para publicar la nueva versión. Una vez realizados estos cambios, se comprueba por última vez que el servicio de integración continua ejecuta las pruebas satisfactoriamente. Posteriormente, se publica una pull request a master, para poner en producción los cambios realizados. En la siguiente imagen se puede observar la pull request realizada.
El siguiente paso es asignar una etiqueta de versión al incremento funcional puesto en producción. Para ello, se usa la herramienta de gestión de tags y releases de GitHub, creando una nueva publicación siguiendo la política de versionado del proyecto. Como se puede observar en la siguiente imagen, la tag es la v3.2021.
Por último, se realiza una pull request desde la rama de release a develop para incluir la versión en producción en la rama de desarrollo, y así poder empezar a desarrollar el siguiente incremento funcional.
El despliegue se realiza a través de la herramienta de integración continua Travis CI. Nuestro módulo usa la rama postprocesado para realizar su despliegue, modificando ligeramente el archivo travis.yml, como puede observarse en la gestión del despliegue. Básicamente, todo commit realizado a la rama de postprocesado se despliega en el servicio Heroku si el servicio de integración continua ejecuta satisfactoriamente todas las pruebas.
Una vez se publica una nueva versión en producción, puede ocurrir que alguna de las funcionalidades implementadas no funcione correctamente. Esto puede ser debido a que las pruebas realizadas no comprueben la casuística concreta del fallo. Cuando esto ocurre, el módulo cuya funcionalidad falle en producción deberá realizar una rama de hotfix para solucionarlo. La rama se crea desde master. Una vez arreglado el fallo, se realiza el mismo proceso descrito en la publicación de una nueva versión.