Ejercicio de Propuesta de Cambio - Giratina-Votacion/decide GitHub Wiki

Analizaremos todos los pasos que hay que seguir en nuestro proyecto para poder llevar a cabo un cambio y añadir una nueva funcionalidad al propio sistema. Todos los pasos que abarcamos desde la propia propuesta de cambio, alabada por el equipo de desarrollo, hasta su completa implementación al final del proceso.

Cómo implementar una nueva funcionalidad

Para este caso, pongámonos en la siguiente situación hipotética:

Un desarrollador de Giratina-Votación quiere añadir un cambio en las votaciones para que en éstas se guarde una propiedad "Public", boolean, que indique si se quiere que la votación se muestre en la lista de votaciones del sistema, o que sólo sea posible acceder mediante el enlace.
El desarrollador dispone de un entorno de trabajo totalmente actualizado, con la última versión de Decide descargada (ver Entorno de desarrollo)

Documentando el cambio: Creación de la incidencia

El primer paso es crear una incidencia para el cambio que se va a realizar. Para nuestro ejemplo particular, se debe crear una incidencia de tipo "implementación" (Puede verse información detallada de las incidencias de implementación en la sección Gestión de incidencias)

La incidencia en cuestión debe quedar tal que así:

Una vez creada la incidencia y ajustados todos los parámetros según la guía, comenzaremos a trabajar en ella. (Nota: No olvidar mover la incidencia de la columna "To Do" a la columna "In Progress" cuando comencemos a trabajar en ella).

Cambiando el código

Una vez tengamos lista la documentación inicial del proyecto, debemos empezar a hacer los cambios necesarios en el código para la implementación, no sin antes crear nuestra rama de desarrollo, en la que trabajaremos en la incidencia en cuestión (para más información sobre las ramas de desarrollo, ver Gestión del código fuente). Para nuestro ejemplo, crearemos la rama Juanant1998-VistaVotsSoloPublicas, mediante un git checkout -b Juanant1998-VistaVotsSoloPublicas, o dentro de Visual Studio, introduciendo el comando Git: Checkout y eligiendo el nombre de la nueva rama.

Dentro de la rama, buscaremos los archivos que es necesario modificar para el cambio. En concreto, necesitaremos modificar los archivos decide/voting/models.py y decide/decide/urls.py

Cambios en los archivos

Cambio en decide/voting/models.py: --Introducir captura de pantalla
Cambio en decide/decide/urls.py: --Introducir captura de pantalla

Probando el nuevo código

Una vez hayamos hecho nuestros cambios, es muy importante asegurarse de que todo funciona correctamente. Para ello, lo primero que debemos comprobar es que, a priori, la funcionalidad que queríamos funciona correctamente. Para comprobarlo, basta con iniciar el servidor local e intentar acceder a la nueva funcionalidad (para ver cómo desplegar en local de una manera más detallada, ver la sección https://github.com/Giratina-Votacion/decide/wiki/Gestion-de-Liberaciones,-Despliegue-y-Entregas#despliegue-en-local).

A simple vista, parece que todo funciona correctamente, pero no es suficiente. Es normal que cambios que en principio parecen pequeños trastoquen partes importantes de otros módulos, y éstos dejen de funcionar correctamente. Por ello, debemos ejecutar los tests de Decide en local y, además, realizar manualmente una prueba simple de funcionamiento (Por ejemplo, crear una votación y seguir todos los pasos hasta visualizar los resultados).

Para ejecutar los tests en local, basta con iniciarlos mediante el comando python3 ./manage.py test -v 2. Una vez todos los tests funcionen correctamente, es buena idea probar la funcionalidad más a fondo creando tests concretos para ella. Para nuestro ejemplo, podemos crear pruebas de carga (con locust), y pruebas de vistas (con selenium). Una vez probada la funcionalidad, sólo queda subir nuestros cambios, mediante los comandos git necesarios:

git add ., para añadir los archivos que hemos modificado

git commit, para realizar el commit con los cambios. Puede ver la guía para realizar un buen commit en la sección Commits de la gestión del código fuente).

git push origin Juanant1998-VistaVotsSoloPublicas, para subir los cambios al repositorio.

Probando el nuevo código: Travis CI

Una vez hayamos subido los cambios al repositorio, Travis ejecutará un nuevo Build para probar nuestros cambios y ver si todo funciona correctamente. Aquí, encontramos dos opciones:

El nuevo build falla. En ese caso, debemos revisar si el fallo viene causado por uno de los nuevos tests, o por un fallo ajeno a nuestra nueva funcionalidad. En cualquier caso, se debe arreglar lo antes posible.
El nuevo build pasa las pruebas. En ese caso, podremos cerrar nuestra incidencia y avanzar hacia el siguiente paso: subir nuestros cambios a la rama develop.

Subiendo los cambios a la rama develop

Los cambios se implementarán en la rama develop mediante un pull request. Para ver más información sobre cómo se deben crear las pull request, consultar la sección Pull requests de la gestión del código fuente).

Una vez realizada la pull request, cuando sea aceptada, sólo resta mergear nuestros cambios para que la funcionalidad se encuentre integrada con el resto de cambios.

Nota: Cuando todos los cambios se encuentren integrados en la rama develop, será el momento de realizar un nuevo pull request a master con el código del proyecto, acompañado de su correspondiente release. Para ver más información sobre este proceso, consultar la Gestión de liberaciones, despliegue y entregas