Flask: Integración Continua CI

La integración continua facilita que el código de un proyecto se pruebe y valide de forma automática cada vez que un desarrollador realiza un cambio. Al combinar Flask y Python con GitHub Actions, se puede crear un pipeline sencillo que verifique la calidad del software, ejecute pruebas unitarias y aporte confianza a los procesos de despliegue.

¿Por qué usar GitHub Actions?

GitHub Actions es un servicio nativo de GitHub que permite definir flujos de trabajo (workflows) para automatizar tareas en repositorios. Con un archivo de configuración basado en YAML, es posible especificar cuándo se deben ejecutar las pruebas, qué versiones de Python usar y qué acciones realizar si un test falla.

Las ventajas de GitHub Actions son:

1. Integración nativa con repositorios de GitHub, simplificando la configuración.
2. Escalabilidad para proyectos pequeños o grandes, con personalización flexible de los flujos de trabajo.
3. Notificaciones automáticas al equipo cuando la integración continúa falla o completa exitosamente.
4. Marketplace con acciones predefinidas que facilitan la configuración de entornos, la ejecución de tests o la publicación de artefactos.

Preparación del proyecto Flask

Antes de configurar la CI, se recomienda:

1. Definir en requirements.txt las dependencias, para que GitHub Actions pueda instalarlas con pip install -r requirements.txt.
2. Añadir los tests que garanticen que tu aplicación de Flask funciona correctamente, por ejemplo con pytest o unittest.
3. Contar con un archivo como app.py que muestre la estructura de la aplicación.

Un ejemplo mínimo de requirements.txt para un proyecto de Flask:

Flask==2.2.3
pytest==7.3.1

Y un sencillo test con pytest en la carpeta tests/test_app.py:

from app import app

def test_home_route():
    response = app.test_client().get('/')
    assert response.status_code == 200
    assert b"Hola Flask" in response.data

Creación del archivo de configuración en GitHub Actions

Para definir un flujo de trabajo (workflow), se crea un archivo YAML dentro de la carpeta .github/workflows/. Un nombre típico para el archivo podría ser ci.yaml:

name: CI Flask

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: "3.9"  # Puedes usar la versión que prefieras

      - name: Install dependencies
        run: |
          pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run tests
        run: |
          pytest --maxfail=1 --disable-warnings

Explicación de las secciones principales

• name: Da un nombre al workflow, en este caso "CI Flask".
• on: Indica cuándo se ejecuta el workflow, por ejemplo en cada push o pull_request a la rama main.
• jobs: Define qué tareas se llevan a cabo, en este caso build-and-test.
• runs-on: Especifica la imagen de sistema operativo donde se ejecutarán las acciones, ubuntu-latest en el ejemplo.
• steps: Son las instrucciones secuenciales, como clonar el repositorio, configurar Python, instalar dependencias y, por último, correr los tests.

Personalización y ampliación del flujo de trabajo

1. Varias versiones de Python: Para garantizar compatibilidad, puedes probar en múltiples versiones:

   with:
     python-version: ["3.8", "3.9", "3.10"]
   

2. Cacheo de dependencias: Agrega una acción de caching para acelerar futuras ejecuciones:

   - name: Cache pip
     uses: actions/cache@v3
     with:
       path: ~/.cache/pip
       key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
   

3. Cobertura de código: Integrar herramientas como coverage o pytest-cov permite medir la cobertura. Se puede publicar el reporte en GitHub Actions o servicios externos como Codecov.

4. Linting y formato: Añadir Flake8 o Black verifica la calidad del código y su estilo, fomentando consistencia en el proyecto:

   - name: Lint code
     run: |
       pip install flake8
       flake8 .
   

Notificaciones y control de fallos

Si se produce un fallo en el proceso de testing, GitHub Actions marca el workflow como fallido, notificando a los participantes del repositorio. Esto sirve para mantener un ciclo de desarrollo rápido y minimizar la introducción de errores en la rama principal.

Despliegue continuo

Tras las pruebas, es posible automatizar el despliegue hacia un servidor o un servicio de hosting, si estas validaciones resultan exitosas. En un escenario habitual, se implementa un job adicional que, por ejemplo, envie el proyecto a un servicio como Heroku, AWS u otro proveedor, ejecutándose únicamente cuando se cumplen criterios específicos (aprobaciones o merges en main).

Buenas prácticas

• Mantener un archivo de requirements.txt al día, para asegurar la reproducibilidad del entorno.
• Evitar exponer credenciales en el repositorio. Emplear secrets de GitHub para claves sensibles.
• Actualizar periódicamente la versión de Python o las dependencias, corrigiendo vulnerabilidades conocidas.
• Definir políticas claras de acceso y protección de la rama principal, de modo que solo se pueda hacer merge con la aprobación de la CI.