-
Notifications
You must be signed in to change notification settings - Fork 5
Documentación para la Integración Continua Votaciones
Para implementar integración continua en el proyecto se han estudiado las diversas técnicas posibles que se podían implementar y las herramientas que se podían utilizar para ello.
Finalmente, se ha decidido implementar un sistema de integración continua que permitiera ejecutar un conjunto de instrucciones dentro del repositorio por cada push o pull de cada rama a este, realizando una build que procesa todos los tests del proyecto y los ejecuta, y que ha sido Travis-CI, y otro sistema de integración continua que permitiera realizar un análisis continuo de código y aportar datos acerca de distintos factores de calidad de los que dispone el proyecto, para lo cual se ha optado por implementar la herramienta Codacy. Con ello, se han cubierto diferentes principios de la integración continua, como son mantener un repositorio único para todos los grupos, automatizar los builds o hacer que sean auto-testeables.
Respecto a la configuración para la implementación de la herramienta Travis-CI, primero se ha activado el uso de la herramienta en el repositorio del proyecto, tal y cómo se ha explicado en las clases prácticas, y tras realizar el primer build y obtener el esperado mensaje de ‘CODACY_PROJECT_TOKEN missing’, se ha obtenido el token que genera la plataforma Codacy y, de nuevo cómo se indica en la práctica, se ha editado las propiedades del build de Travis-CI para incluir esta variable de entorno.
El archivo más importante para la ejecución de Travis-CI, ‘.travis.yml’, que indica la configuración y las instrucciones que debe realizar Travis-CI cuando se lance una build, se ha configurado de forma que, antes de ejecutar el conjunto de instrucciones que se definirán posteriormente, instale las dependencias y librerías que necesita el proyecto y que están definidas en el fichero requirements.txt, la librería ‘codacy-coverage’, cuyo uso se explicará a continuación, y Selenium para las diferentes pruebas de vista integradas en el proyecto con la herramienta Selenium IDE. Tras esto, instala también ChromeDriver y GeckoDriver, que son los dos drivers utilizados en el proyecto para la ejecución de las pruebas de vista con Selenium. Así se permite comprobar el correcto funcionamiento de estas pruebas independientemente del driver usado para lanzarlas. Ambos drivers son descargados, descomprimidos y movidos a la carpeta /usr/bin, que es la ruta que toma por defecto estos drivers como ruta de instalación.
install:
- pip install -r requirements.txt
- pip install codacy-coverage
- pip install selenium
- sudo apt-get install chromium-browser
- sudo apt-get install -y firefox
- wget -N https://chromedriver.storage.googleapis.com/87.0.4280.88/chromedriver_linux64.zip
- unzip chromedriver_linux64.zip
- rm chromedriver_linux64.zip
- sudo mv -f chromedriver /usr/bin
- sudo chmod +x /usr/bin/chromedriver
- wget "https://github.com/mozilla/geckodriver/releases/download/v0.27.0/geckodriver-v0.27.0-linux64.tar.gz"
- tar xfz geckodriver-v0.27.0-linux64.tar.gz
- sudo mv -f geckodriver /usr/bin
- sudo chmod +x /usr/bin/geckodriver
En siguiente lugar, se ha configurado para que antes de ejecutar los diferentes scripts que suponen el conjunto de instrucciones que debe seguir, cree un usuario y una base de datos únicamente para la ejecución de la build que se esté lanzando y copie el archivo creado denominado ‘local_settings.travis.py’ y le cambie el nombre a ‘local_settings.py’, para que este haga la función de ajuste local de la aplicación, conteniendo los módulos que usa la aplicación, la url de cada API, que será la de localhost, y los datos de la base de datos de la aplicación.
before_script:
- psql -U postgres -c "create user decide password 'decide'"
- psql -U postgres -c "create database test_decide owner decide"
- psql -U postgres -c "ALTER USER decide CREATEDB"
- cp decide/local_settings.travis.py decide/local_settings.py
- "export DISPLAY=:99.0"
- sleep 3
En el último paso, el script está configurado para que tras la instalación previa necesaria, entre en la carpeta ‘decide’ y ejecute un comando denominado ‘coverage run –branch –source=. ./manage.py test –keepdb –with-xunit’, que se encarga de lanzar todos los tests de la aplicación, realizando un análisis de la cobertura que tienen sobre el código fuente (coverage) e indicando que mantenga la base de datos después de terminar una prueba, con lo que la siguiente prueba no tendría que volver a crearla.
Tras esto, se ejecuta el comando ‘coverage xml’, para generar un informe acerca de la cobertura previamente analizada y, por último, se ejecuta la instrucción ‘python-codacy-coverage –r coverage.xml’, para que la cobertura previamente realizada actualice la que se ha realizado en la herramienta Codacy, actualizando sus datos.
Este script se ha configurado para que se ejecute 9 veces, una por cada módulo que contiene algún tipo de prueba, para así lanzar simultáneamente 9 jobs dentro de la build y que no se ejecute en un único job, ya que este se ejecutaría más lento y tardaría más de 50 minutos, siendo este el límite de Travis-CI para un job.
jobs:
include:
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test authentication/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test base/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test booth/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test census/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test mixnet/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test postproc/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test store/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test visualizer/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
- script:
- cd decide
- coverage run --branch --source=. ./manage.py test voting/ --keepdb --with-xunit
- coverage xml
- python-codacy-coverage -r coverage.xml
Para finalizar, se ha configurado para que al ejecutar un build cuyo resultado sea fallido envíe una notificación por correo electrónico a los coordinadores de los diferentes grupos, para informar a estos que la ejecución de las pruebas ha fallado, pero que no envíe un correo si se ha realizado correctamente, para evitar que la herramienta produzca demasiado spam.
notifications:
email:
recipients:
- carsantir@alum.us.es
- marmarser5@alum.us.es
- marmolpen3@alum.us.es
- josvilgar1@alum.us.es
- ramonfernandez1999@gmail.com
on_success: never
on_failure: always
Una vez se haya ejecutado el script, en el log del build realizado se mostrarán los resultados de la ejecución, realizando las instalaciones previas y mostrando el resultado de cada instrucción definida en el script, teniendo un valor de 0 si se ha ejecutado correctamente o un valor 1 si por el contrario ha fallado.
Si se han ejecutado correctamente las instrucciones previas al lanzamiento de las pruebas, realizará las pruebas y mostrará, en caso de que falle alguna, la prueba que ha fallado y la razón por lo que lo ha hecho y obtendrá un valor 1 la instrucción. Por el contrario, si se realizan correctamente, se obtendrá un valor 0 en esta instrucción y podrá generar el informe de cobertura y, con ello, el build se habría realizado correctamente.
Para finalizar la configuración, se ha modificado el README.md del proyecto en Github para que incluya gráficamente el resultado del último build ejecutado del proyecto.
Este es el enlace al repositorio de la asignatura en la herramienta Travis-CI.
En cuanto a Codacy, se ha habilitado la integración con el repositorio conjunto de todos los grupos. Se ha configurado para que el sistema analice de manera automática las ramas master y develop, y las ramas equivalentes para cada subsistema. Además, se ha modificado la configuración acerca de la calidad del repositorio, concretamente la cobertura mínima de las pruebas: el valor requerido ha pasado de ser del 60% al 85%, para asegurar que el porcentaje de líneas de código probadas no disminuye del valor inicial del sistema previo a la modificación.
Este es el enlace al repositorio de la asignatura en la herramienta.
También se ha llevado a cabo la integración de ambas herramientas, utilizando la Project API aportada por Codacy, y se ha modificado el README.md del proyecto para que muestre el estado de la integración aportado por Travis y Codacy.
Además de las build de integración, es necesario llevar a cabo builds privadas antes de subir cambios al repositorio para comprobar que los cambios realizados funcionan bien y no interfieren con otros componentes de los subsistemas modificados, con el objetivo de evitar futuros hotfixes. En ningún caso se deberán subir cambios sin antes haber realizado una build, por muy inocuos que pudieran parecer. Se recomienda también que, una vez se realice un merge en la rama dev del subsistema, se descargue dicha rama y se vuelvan a realizar las comprobaciones pertinentes. Deberá realizarse obligatoriamente en caso de que al hacerlo aparezcan conflictos que hayan que resolver manualmente, o si el merge se realiza en la rama develop general. Esto se debe a que, por muy bien desarrolladas que estén las pruebas, la cobertura nunca será del 100%.
Tras realizar el merge, aquellos que lo hayan llevado a cabo tendrán que verificar que tanto la build de Travis CI y el análisis de Codacy ha sido satisfactorio. En caso contrario, tendrán que observar qué metrica de Codacy no cumple con los requisitos de calidad o qué test/tests han fallado en la build de Travis. En caso de que el error provenga de Travis, se deberá analizar las causas del mismo, y bien:
a) abrir y resolver una incidencia, si el fallo de la(s) prueba(s) es causado por los cambios introducidos
b) derivar una incidencia al debido subsistema, si el fallo es causado por una mala construcción de los tests por parte de un subsistema distinto al nuestro
En caso de que el problema provenga de Codacy, se deberá identificar el causante del problema, y corregirlo (si no se trata de un falso positivo).
- Los indicadores de calidad de los builds utilizados.
- Cobertura: Porcentaje de líneas de código cubiertas por los test realizados
- Código no usado: Líneas de código que se han implementado pero que no se usan ni se llaman en ningún sitio
- Complejidad: Porcentaje de archivos con complejidad ciclomática. Codacy calcula esta complejidad analizando los bucles y el coste computacional del código
- Duplicación: Porcentaje de archivos duplicados en el código: archivos que tienen la misma funcionalidad y es innecesario mantener ambos.
- Seguridad: Total de archivos con posible código no seguro, por ejemplo: contraseñas fáciles de adivinar, código generado pseudoaleatoriamente que puede dar problema al codificar, etc
- Code Style: Declaraciones de código que varían de la forma estándar
- Issue: Cambios como problemas, mejoras o fallos que se detectan al analizar el código y se deben solucionar. Codacy cuenta los issues añadidos a cada commit y los que ya existian y se han resuelto.