Estudio y aplicación de la práctica software CI (Integración continua)

[gcm1001]

• Github, Building and testing code with continuous integration - https://help.github.com/en/actions/building-and-testing-code-with-continuous-integration

[gcm1001]

Integración continua

La Integración Continua (CI) es una práctica utilizada en el desarrollo de software mediante la cual es posible automatizar operaciones tales como la compilación o ejecución de tests. Las ventajas principales de esta técnica son:

• Detecta fallos muy rápidamente.
• Mejora la calidad del software.
• Reduce el tiempo empleado en validar y publicar nuevas actualizaciones de software.

Github Actions

A través de Github Actions podemos introducir la Integración Continua en nuestro proyecto, es decir, nos permite automatizar:

• Tests
• Compilación
• Despliegue

Implementación

La implementación de acciones en Github es verdaderamente sencilla, simplemente hay que definir un archivo en nuestro repositorio. Sus dos requisitos principales son:

1. Estar alojado en .github/workflows
2. Tener formato .yml

En la primera línea del archivo .yml tenemos que indicar el nombre de la acción a desarrollar.

name: TFG CeniehAriadnePlus CI/CD

En las siguientes líneas debemos definir el disparador de la acción, es decir, el evento que activará la acción. Además, se pueden indicar condicionales como, por ejemplo, que un evento determinado active la acción únicamente cuando sea ejecutado sobre una rama específica.

...
  on:
    push:
      branches:
        - master
    pull_request:
      branches:
        - master

Como se puede observar, mi flujo de trabajo solo se activará cuando se haga push o pull request sobre la rama master.

El siguiente paso es especificar los trabajos que se van a llevar a cabo.

...
  jobs:
      Docker:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v1
          - name: Login
            run: docker login -u ${{ secrets.DOCKER_USER }} -p ${{ secrets.DOCKER_PASSWORD }}
          - name: Build
            run: docker build -t omeka_cenieh .
          - name: Tags
            run: |
                docker tag omeka_cenieh ${{ secrets.DOCKER_USER }}/omeka_cenieh:${{ github.sha }}
                docker tag omeka_cenieh ${{ secrets.DOCKER_USER }}/omeka_cenieh:latest
          - name: Push
            run: |
                docker push ${{ secrets.DOCKER_USER }}/omeka_cenieh:${{ github.sha }}
                docker push ${{ secrets.DOCKER_USER }}/omeka_cenieh:latest
          - name: Deployment
            run: |
                docker swarm init
                echo ${{ secrets.DB_PASSWORD }} | docker secret create omeka_db_password -
                echo ${{ secrets.DB_ROOT_PASSWORD }} | docker secret create omeka_db_root_password -
                cp ./db.ini.modificar ./db.ini
                docker stack deploy -c docker-compose.yml omeka_cenieh

En este caso, solo especifico un único trabajo llamado Docker. A continuacón, explicaré brevemente en que consiste cada término utilizado:

• runs-on: SO donde queremos ejecutar nuestro trabajo.
• steps: agrupa el conjunto de pasos a ejecutar.
  • uses: selecciona una acción para ejecutar como parte de un paso en el trabajo.
    • Con la action checkout se descargada el código fuente de nuestro repositorio.
  • name: nombra un paso.
    • He decidido implementar cinco pasos:
      • Login : accedo a mi cuenta de Docker Hub.
      • Build : compilo la imagen a través del Dockerfile alojado en mi repositorio.
      • Tags : asocio un nombre y una versión a la imagen.
      • Push : actualizo el repositorio donde almaceno el código asociado a la imagen.
      • Deployment : despliego la aplicación al completo.
  • run: ejecuta el comando indicado sobre la shell del SO asociado al trabajo.

Como podemos observar en el código, hago uso de secrets. Estos son muy sencillos de crear:

1. Accedemos a la pestaña de configuración del proyecto Settings.
2. Nos desplazamos a la ventana Secrets
3. Clicamos sobre Add a new secret e introducimos el nombre y valor del secreto.
4. Finalizamos el proceso clicando sobre Add secret.

Con todo esto ya tendríamos implementada la Integración Continua (aplicada únicamente a Docker).

[gcm1001]

Excluir rutas

Dado que no me interesa que se ejecute la acción cuando realice cambios sobre la documentación, configuraré el workflow para que ignore la ruta donde está almacenada toda la documentación del proyecto.

Filtros

Se pueden excluir rutas usando dos tipos de filtros.

• paths-ignore: se ignoran todas las rutas incluidas en este filtro.
• paths: sirve para incluir rutas específicas, sin embargo, si precedemos la ruta con el signo !, esta se ignorará.

P.D: No se pueden usar los dos filtros a la vez en un mismo evento.

Implementación escogida paths-ignore

...
  on:
    push:
      branches:
        - master
      paths-ignore:
        - 'docs/**'
    pull_request:
      branches:
        - master
      paths-ignore:
        - 'docs/**'
...

Implementación alternativa paths

...
  on:
    push:
      branches:
        - master
      paths:
        - '**'
        - '!docs/**'
    pull_request:
      branches:
        - master
      paths:
        - '**'
        - '!docs/**'
...