Introducción a GitHub Actions

GitHub Actions es una plataforma de integración continua y entrega continua (CI/CD) que permite automatizar procesos de desarrollo directamente en los repositorios de GitHub. Utiliza workflows definidos en archivos YAML para ejecutar acciones en respuesta a eventos como commits, pull requests o liberaciones.

Esta herramienta facilita la creación de pipelines personalizados que pueden compilar, probar y desplegar aplicaciones automáticamente. Al estar integrada en GitHub, ofrece una experiencia fluida sin necesidad de configurar servicios externos, mejorando la eficiencia en el flujo de trabajo de desarrollo.

Una de las ventajas principales de GitHub Actions es su flexibilidad. Puede adaptarse a diferentes lenguajes y entornos, incluyendo Python y frameworks como Flask. Los runners de GitHub Actions permiten ejecutar tareas en sistemas operativos como Ubuntu, Windows o macOS, posibilitando pruebas multiplataforma.

Para utilizar GitHub Actions, es fundamental entender su estructura básica. Un workflow es un proceso automatizado definido en un archivo ubicado en .github/workflows/ dentro del repositorio. Este workflow se compone de uno o varios jobs, y cada job contiene múltiples steps que realizan acciones específicas.

Las acciones son los elementos fundamentales que llevan a cabo tareas individuales dentro de un workflow. Pueden ser acciones predefinidas proporcionadas por GitHub, acciones creadas por la comunidad o acciones personalizadas desarrolladas por el usuario. Esto permite reutilizar código y mantener los workflows organizados.

Un ejemplo sencillo de un archivo de workflow es el siguiente:

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout del repositorio
        uses: actions/checkout@v4
      - name: Configurar Python 3.13
        uses: actions/setup-python@v5
        with:
          python-version: '3.13'
      - name: Instalar dependencias
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Ejecutar pruebas
        run: |
          python -m unittest discover

En este ejemplo, el workflow llamado CI se activa con cada push al repositorio. El job build se ejecuta en un runner con Ubuntu, y los steps realizan tareas como hacer checkout del código, configurar la versión de Python 3.13, instalar las dependencias y ejecutar las pruebas unitarias.

Es importante conocer los diferentes eventos que pueden desencadenar los workflows en GitHub Actions. Algunos eventos comunes son push, pull_request, schedule y release. Al utilizar estos eventos, se pueden automatizar tareas en distintas etapas del ciclo de vida del desarrollo.

GitHub Actions también proporciona la posibilidad de utilizar variables de entorno y secrets para manejar información sensible, como tokens de acceso o claves de API. Esto garantiza que los datos confidenciales permanezcan seguros durante la ejecución de los workflows.

La comunidad de GitHub Actions es activa y ofrece una amplia variedad de acciones reutilizables. Esto facilita la integración con herramientas y servicios externos, como despliegues en plataformas en la nube, análisis de código o envío de notificaciones.

Al integrar GitHub Actions en proyectos de Flask, es posible automatizar procesos clave como la ejecución de pruebas, el análisis de calidad de código y el despliegue continuo. Esto contribuye a mejorar la eficiencia y la calidad en el desarrollo de aplicaciones web.

También puedes instalar la extensión Github Actions para Visual Studio Code:

Workflow de GitHub Actions para Flask

Para implementar un sistema de integración continua en una aplicación Flask, es fundamental configurar un workflow en GitHub Actions que automatice las tareas de construcción y prueba. Este proceso ayuda a mantener la calidad del código y asegura que la aplicación funcione correctamente con cada cambio realizado.

El primer paso es crear un archivo YAML en el directorio .github/workflows/ de tu repositorio. Este archivo define las acciones que GitHub Actions ejecutará en respuesta a eventos específicos, como un push o una pull request. Un ejemplo de archivo ci.yml para una aplicación Flask es el siguiente:

name: CI Flask

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

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout del código
        uses: actions/checkout@v4

      - name: Configurar Python 3.13
        uses: actions/setup-python@v5
        with:
          python-version: '3.13'

      - name: Instalar dependencias
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Ejecutar pruebas unitarias
        run: |
          flask test
        env:
          FLASK_APP: app.py
          FLASK_ENV: testing

En este workflow, el job build-test se ejecuta en respuesta a eventos en la rama main. Los steps definidos realizan las siguientes acciones:

Checkout del código: Clona el repositorio actual en el runner de GitHub Actions utilizando actions/checkout@v4.

Configurar Python 3.13: Establece la versión de Python a 3.13 con actions/setup-python@v5, asegurando la consistencia del entorno de ejecución.

Instalar dependencias: Actualiza pip y luego instala las dependencias listadas en requirements.txt, donde debe estar incluida Flask 3.1.0. Por ejemplo:

Flask==3.1.0

Ejecutar pruebas unitarias: Ejecuta las pruebas de la aplicación utilizando el comando flask test, que debe estar definido en el entorno de pruebas de tu aplicación.

Configurar variables de entorno: Define variables necesarias para la aplicación Flask, como FLASK_APP y FLASK_ENV, dentro de la ejecución de las pruebas unitarias, estableciendo el entorno de testing.

Es vital que las pruebas unitarias estén bien diseñadas para cubrir la funcionalidad crítica de la aplicación. Esto garantiza que los cambios no introduzcan errores y que la aplicación se mantenga estable.

Si utilizas una base de datos, puedes agregar servicios a tu workflow. Por ejemplo, para incluir PostgreSQL:

services:
  postgres:
    image: postgres:15
    env:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: test_db
    options: >-
      --health-cmd pg_isready
      --health-interval 10s
      --health-timeout 5s
      --health-retries 5

Y luego configurar la conexión en los steps:

      - name: Configurar base de datos
        run: |
          export DATABASE_URL=postgresql://postgres:postgres@localhost:5432/test_db

Esto permite que las pruebas accedan a una base de datos real, simulando el entorno de producción y detectando posibles problemas de interacción con la base de datos.

Para asegurar la calidad del código, es recomendable incluir análisis estático con herramientas como Flake8 o Black. Agrega estas dependencias en requirements.txt:

Flask==3.1.0
Flake8
Black

Y añade nuevos steps al workflow:

      - name: Analizar código con Flake8
        run: |
            flake8 .
  
      - name: Verificar formato con Black
        run: |
            black --check .

Estos steps ayudan a mantener un código limpio y conforme a los estándares de estilo de Python, lo que facilita el mantenimiento y colaboración en el proyecto.

En caso de que necesites manejar secretos o información sensible, GitHub Actions permite utilizar variables de entorno seguras. Puedes definir estos secretos en la configuración del repositorio y acceder a ellos en el workflow:

      - name: Configurar secretos
        env:
          SECRET_KEY: ${{ secrets.SECRET_KEY }}
          API_TOKEN: ${{ secrets.API_TOKEN }}

Esto garantiza que datos confidenciales no se expongan en el código ni en los logs del workflow.

Para proyectos más complejos, es posible dividir el workflow en varios jobs. Por ejemplo, puedes separar las pruebas unitarias y las pruebas de integración:

jobs:
  test-unit:
    runs-on: ubuntu-latest
    steps:
      # Steps para pruebas unitarias

  test-integration:
    runs-on: ubuntu-latest
    needs: test-unit
    steps:
      # Steps para pruebas de integración

El atributo needs: test-unit asegura que el job de test-integration se ejecute únicamente si el job de test-unit ha finalizado con éxito, estableciendo una dependencia entre jobs.

Finalmente, si deseas automatizar el despliegue después de que las pruebas hayan pasado, puedes agregar steps que realicen el deployment. Por ejemplo, desplegar a Heroku:

      - name: Desplegar a Heroku
        uses: akhileshns/heroku-deploy@v4.1.6
        with:
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: "nombre-de-tu-app"
          heroku_email: "tu-email@example.com"

Recuerda que para realizar despliegues, necesitas configurar los secretos correspondientes y asegurarte de que solo se ejecuten en las ramas apropiadas, como main o release.

Con este workflow de GitHub Actions, tu aplicación Flask estará respaldada por un proceso de integración continua sólido, mejorando la calidad y la confiabilidad del proyecto.

Ejecutar el workflow de GitHub Actions

Una vez configurado el workflow en GitHub Actions para la aplicación Flask, es esencial verificar que se ejecuta correctamente y cumple con su propósito de automatizar tareas como pruebas y despliegues.

El workflow se activa automáticamente según los eventos definidos en el archivo YAML, específicamente en la sección **on**. Por ejemplo, si se ha configurado para ejecutarse en cada **push** o pull request a la rama **main**, cada vez que se realice un commit y se envíe al repositorio remoto, GitHub Actions iniciará el proceso.

Para revisar la ejecución de los workflows, dirígete a la pestaña "Actions" en el repositorio de GitHub. Aquí encontrarás una lista de las ejecuciones recientes, con indicadores de estado que muestran si han sido exitosas, fallidas o están en progreso. Es crucial monitorear estos estados para asegurarse de que el código mantiene su integridad.

Al seleccionar una ejecución específica, puedes acceder al log detallado de cada job y sus steps. Esto es especialmente útil para identificar y depurar errores en caso de que el workflow falle. Cada step mostrará su salida en la consola, incluyendo posibles mensajes de error o advertencias.

Si una ejecución falla, GitHub Actions resaltará el step problemático. Es buena práctica revisar cuidadosamente los mensajes de error y la traza proporcionada para comprender el origen del problema. A menudo, los errores pueden deberse a dependencias faltantes, fallos en las pruebas unitarias o problemas de configuración en el entorno.

En caso de que necesites re-ejecutar un workflow, GitHub proporciona la opción de "Re-run jobs" en la interfaz de la acción fallida. Esto es útil si ya has corregido un problema en el código o si sospechas que el fallo fue temporal debido a un problema externo.

Además de las ejecuciones automáticas, es posible desencadenar workflows de forma manual. Para ello, puedes añadir un evento **workflow_dispatch** en la sección **on** de tu archivo YAML:

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

Con esta configuración, en la pestaña "Actions" aparecerá un botón que permite iniciar el workflow manualmente. Esto es útil para pruebas o para ejecutar acciones en momentos específicos sin necesidad de hacer un commit.

Es importante también definir correctamente las credenciales y secrets necesarios para la ejecución del workflow. Si algún secreto está mal configurado o falta, el workflow puede fallar al intentar acceder a recursos protegidos. Asegúrate de que los secretos estén almacenados en la configuración del repositorio y que estén referenciados correctamente en el archivo YAML.

Para mejorar el rendimiento y la eficiencia de los workflows, GitHub Actions permite utilizar caché de dependencias. Por ejemplo, puedes agregar un step que cachee los paquetes de pip:

      - name: Cachear dependencias de pip
        uses: actions/cache@v3
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
          restore-keys: |
            ${{ runner.os }}-pip-

Esto reduce el tiempo de instalación de dependencias en ejecuciones posteriores, ya que reutiliza paquetes ya descargados.

Cuando el workflow incluye pruebas que interactúan con servicios externos, como una base de datos o una API, es recomendable simular estos servicios o utilizar entornos de testing para evitar efectos no deseados. Además, puedes configurar matrices de ejecución para probar tu aplicación en múltiples versiones de Python o diferentes sistemas operativos.

Para asegurar que solo los cambios de código aprobados se desplieguen, es común implementar una política de branch protection en GitHub. Esto exige que los pull requests superen con éxito los workflows de GitHub Actions antes de poder fusionarse en ramas protegidas como **main**.

Finalmente, es esencial mantener el archivo de workflow actualizado y revisar periódicamente las versiones de las acciones utilizadas (por ejemplo, actions/checkout@v4, actions/setup-python@v5). Las acciones pueden recibir actualizaciones que mejoren la seguridad o añadan nuevas funcionalidades, por lo que es recomendable seguir las buenas prácticas y actualizar los tags o utilizar referencias a versiones específicas.

Con el workflow correctamente ejecutándose, tu proyecto Flask gozará de un proceso de integración continua robusto, mejorando la calidad del código y facilitando la colaboración dentro del equipo de desarrollo.