Vision Global del Proceso de Desarrollo - Giratina-Votacion/decide GitHub Wiki

Proceso de desarrollo

Para el proceso de desarrollo, pensamos que el control de versiones es indispensable. La herramienta empleada para ello ha sido el sistema de repositorios GitHub. Para las implementaciones de nuestro grupo, hemos utilizado el framework Django 2.0 bajo Python3. Una vez que se decide implementar un cambio en Decide, hay que seguir una serie de pasos indispensables:

Proceso de desarrollo: Creación de una incidencia

Una incidencia, o tarea, es la manera de especificar todo lo referente al cambio que estamos implementando: Qué es, cómo esperamos hacerlo, qué personas están asignadas para realizar este cambio... En nuestro repositorio, disponemos de un proyecto al cual deben pertenecer todas las incidencia, para que el equipo de desarrollo pueda ver qué tareas se están realizando, qué queda por hacer, qué se ha dejado de lado... Dentro de la incidencia, hay varios factores a tener en cuenta, que se señalan en el apartado de la documentación Gestión de Incidencias. Por ello, vamos a saltarnos lo referente a cómo crear una buena incidencia en el repositorio, y vamos a pasar al siguiente punto: La creación de una rama específica.

Proceso de desarrollo: Creación de una rama para el cambio

Para crear una rama de desarrollo de un cambio, se sigue el siguiente esquema para su nombrado: "Usuario-Característica". Puede verse el por qué de esta nomenclatura, además de otras cosas sobre el trabajo en el repositorio, en el apartado Gestión del Código Fuente. Cada desarrollador debe crear su rama de desarrollo para su característica (En caso de que varias personas trabajen en la misma característica, pueden o bien trabajar en la misma rama de desarrollo, o bien crear dos ramas distintas con la división del trabajo que hayan decidido hacer, para luego introducir los cambios de una en la otra y terminar la funcionalidad). Una vez creada la rama de desarrollo concreto, podemos proceder al siguiente paso: Edición del código

Proceso de desarrollo: Edición del código

Como IDE de desarrollo para el código, usamos Visual Studio Code (Podemos ver más información sobre el entorno de desarrollo en el apartado de la documentación Entorno de desarrollo).

Dentro del IDE, debemos realizar los pasos pertinentes para clonar el repositorio y cambiar a la rama concreta que creamos para el cambio (Puede verse cómo hacerlo en el enlace anterior). Una vez configurado todo, sólo queda empezar a tocar el código para conseguir que nuestros cambios funcionen. En cuanto a esto, es necesario dar unas cuantas aclaraciones sobre el código en pruebas, o inestable, es decir, código que "aparentemente funciona", pero que no ha sido probado adecuadamente:

  • Nunca se debe subir al repositorio código que no funcione. Esto incluye:
    1. Código con errores de sintaxix
    2. Código que impedirá que la aplicación despliegue correctamente
    3. Código que provocará el mal funcionamiento de una característica que ya funcionaba correctamente Entre otras cosas. Lógicamente, se pueden contemplar excepciones: Por ejemplo, en el caso de que una característica quede dividida entre varias personas, depende de cómo se haga la división de tareas, puede que una parte del código no pueda funcionar correctamente sin la otra. En ese caso, puede indicarse en el commit correspondiente al código.
  • Siempre se debe probar el código antes de subirlo. Se considera el código "correcto" si se cumple lo siguiente:
    1. La funcionalidad implementada funciona correctamente a nivel de experiencia de usuario (Esto es, no hay errores aparentes durante el uso de la funcionalidad).
    2. Legibilidad del código: Se considera un código fácilmente legible aquel que incluye comentarios y explicaciones de los cambios, que esta bien indexado, no deja variables sin utilizar...
    3. Se han añadido tests para la funcionalidad, y se han ejecutado en local (usando el entorno virtual) correctamente. La ejecución correcta de los tests contempla tanto la ausencia de fallos en los tests nuevos, como en todos los anteriores.
    4. Se han añadido tests para la funcionalidad, y se han ejecutado en local (utilizando docker) correctamente. De nuevo, la ejecución correcta de los tests contempla tanto la ausencia de fallos en los tests nuevos, como en todos los anteriores.

Una vez se han comprobado todos estos puntos, se da el código por válido, y se procede a hacer el commit correspondiente a la finalización de la issue

Proceso de desarrollo: Commit

El commit es una de las partes más importantes del proceso de desarrollo: es lo primero que verá alguien que entre a ver nuestro cambio. Por eso, es importante que el commit sea lo más explicativo posible, sin ser por ello redundante. Se recomienda seguir los siguientes consejos a la hora de hacer un commit:

  • Título del commit: Debe ser conciso, y tratar el cambio concreto que se ha realizado, de forma que una persona pueda entender bien qué es lo que se está haciendo, sin entrar en detalles del propio cambio.
  • Comentario del commit: En el comentario, es muy importante referenciar a la issue correspondiente a la característica que se está implementando en el sistema, para así evitar caer en la redundancia de explicar dos veces los mismos detalles, y en segundo lugar, para que cualquier persona que entre a la issue pueda ver que se ha realizado un commit para esa issue. En resumen, es importante enfatizar más en el qué y en el por qué que en el cómo (pues los detalles de implementación de código ya pueden verse dentro del propio código), y evitar duplicar información que ya esté en la issue en el mensaje del commit.

Una vez creado nuestro commit, sólo queda subirlo a nuestra rama correspondiente. Así, tendremos un nuevo cambio funcional dentro de nuestro repositorio. Sin embargo, no hemos terminado todavía, pues quedan varias acciones por realizar: Debemos cerrar la issue correspondiente a la característica, y ésta debe ser movida a la columna "Done", dentro del proyecto del equipo de desarrollo. Por último, una vez que se esté listo para integrar con la rama de desarrollo principal (develop), se debe ejecutar el proceso de implementación.

Proceso de desarrollo: Implementación en develop

Para implementar los cambios en la rama develop, se hará uso de las pull request.

Creación de una Pull request

En primer lugar, se debe crear una pull request para desde la rama de desarrollo hacia la rama develop. Para ello, podemos seguir la guía que se incluye en la sección Pull requests del apartado Gestión del Código fuente.

Proceso de revisión

Una vez hayamos creado nuestra pull request de manera satisfactoria, es trabajo de los revisores, ayudados por la herramienta de GitHub, decidir si el incremento funcional producirá errores en el sistema. En ese caso, se debe rechazar la pull request, indicando específicamente los motivos que han llevado al rechazo de la misma, para que se arreglen dichos conflictos antes de realizar una nueva pull request. Un ejemplo de esta clase de conflictos, basado en nuestra experiencia personal, puede ser el siguiente:

  • Disponemos de una rama develop que se encuentra funcionando correctamente.
  • Un usuario creó una rama de desarrollo, y subió sus cambios, incluyendo un cambio en el archivo .travis.yml que, aparentemente, no provocaba ningún error. Posteriormente, crea una pull request a develop para integrar sus cambios.
  • El revisor se da cuenta de la pequeña edición del archivo .travis.yml, y descubre que ese cambio puede provocar una incompatibilidad con los tests que se ejecutan en develop en este momento tras, por ejemplo, una pull request anterior.
  • El revisor indica el motivo del rechazo, para que pueda ser solucionado por el usuario creador de la tarea, y procede a rechazar y cerrar la pull request.

Sin embargo, en el caso de que no encontráramos ningún error como el anterior, se procedería a mergear la pull request en la rama develop, y a cerrar la pull request.

Ejemplo de proceso de desarrollo

Para el ejemplo, vamos a utilizar la tarea "Cambios para favorecer votaciones binarias". A continuación, se ofrecen una serie de enlaces en los que puede verse el procedimiento seguido durante el proceso de desarrollo: