Integración Continua

[Traducción Beta No Oficial]

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Para garantizar la calidad de su software, los equipos suelen implementar flujos de trabajo de Integración Continua, comúnmente conocidos como CI. Con CI, los equipos ejecutan continuamente un conjunto de verificaciones automatizadas en cada cambio del código base. Durante la CI, los equipos pueden ejecutar varios tipos de verificaciones:

Compilación o construcción de la versión más reciente para asegurar que no está dañada.
Linting para hacer cumplir los estándares de estilo de código aceptados.
Pruebas unitarias que verifican que los componentes individuales funcionan según lo previsto y que los cambios en el código no provocan regresiones en otras áreas.
Escaneos de seguridad para asegurar que no se introducen vulnerabilidades conocidas en el código.
¡Y mucho más!

De nuestras conversaciones con la comunidad de Ent, hemos aprendido que muchos equipos que usan Ent ya utilizan CI y les gustaría incorporar algunas verificaciones específicas de Ent en sus flujos de trabajo.

Para apoyar a la comunidad en este esfuerzo, iniciamos esta guía que documenta las mejores prácticas comunes para verificar en CI e introduce ent/contrib/ci, una acción de GitHub que mantenemos y que las codifica.

Verificar que todos los archivos generados están incluidos en el control de versiones

Ent depende en gran medida de la generación de código. Según nuestra experiencia, el código generado siempre debe incluirse en el control de código fuente. Esto se hace por dos razones:

Si el código generado está en el control de código fuente, puede leerse junto con el código principal de la aplicación. Tener el código generado presente durante las revisiones de código o al navegar por el repositorio es esencial para obtener una imagen completa de cómo funcionan las cosas.
Las diferencias entre los entornos de desarrollo de los miembros del equipo pueden detectarse y solucionarse fácilmente. Esto reduce aún más la posibilidad de problemas del tipo "funciona en mi máquina", ya que todos ejecutan el mismo código.

Si usas GitHub para el control de código fuente, es fácil verificar que todos los archivos generados están incluidos con la GitHub Action ent/contrib/ci. De lo contrario, proporcionamos un sencillo script bash que puedes integrar en tu flujo de CI existente.

GitHub Action
Bash

Simply add a file named `.github/workflows/ent-ci.yaml` in your repository:

name: EntCI
on:
  push:
  # Run whenever code is changed in the master.
    branches:
      - master
  # Run on PRs where something changed under the `ent/` directory.
  pull_request:
    paths:
      - 'ent/*'
jobs:
  ent:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3.0.1
      - uses: actions/setup-go@v3
        with:
          go-version-file: 'go.mod'
      - uses: ent/contrib/ci@master

go generate ./...
status=$(git status --porcelain)
if [ -n "$status" ]; then
    echo "you need to run 'go generate ./...' and commit the changes"
    echo "$status"
    exit 1
fi

Linting de archivos de migración

Los cambios en el esquema Ent de tu proyecto casi siempre resultan en una modificación de tu base de datos. Si usas Migraciones Versionadas para gestionar los cambios en el esquema de tu base de datos, puedes ejecutar linting de migraciones como parte de tu flujo de integración continua. Esto se hace por varias razones:

El linting reproduce tu directorio de migraciones en un contenedor de base de datos para asegurar que todas las sentencias SQL son válidas y están en el orden correcto.
Se aplica la integridad del directorio de migraciones, asegurando que el historial no se modificó accidentalmente y que las migraciones planificadas en paralelo se unifican en un historial lineal limpio.
Se detectan cambios destructivos que notifican cualquier posible pérdida de datos causada por tus migraciones mucho antes de que lleguen a tu base de datos de producción.
El lint detecta cambios dependientes de datos que podrían fallar durante la implementación y requieren una revisión más cuidadosa de tu parte.

Si estás utilizando GitHub, puedes emplear la Acción Oficial de Atlas para ejecutar el análisis de migraciones durante la integración continua.

Añade un archivo .github/workflows/atlas-ci.yaml a tu repositorio con este contenido:

MySQL
MariaDB
PostgreSQL
SQLite

name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    services:
      # Spin up a mysql:8.0.29 container to be used as the dev-database for analysis.
      mysql:
        image: mysql:8.0.29
        env:
          MYSQL_ROOT_PASSWORD: pass
          MYSQL_DATABASE: test
        ports:
          - "3306:3306"
        options: >-
          --health-cmd "mysqladmin ping -ppass"
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 10
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: ariga/setup-atlas@v0
        with:
          cloud-token: ${{ secrets.ATLAS_CLOUD_TOKEN }}
      - uses: ariga/atlas-action/migrate/lint@v1
        with:
          dir: 'file://ent/migrate/migrations'
          dir-name: 'my-project' # The name of the project in Atlas Cloud
          dev-url: "mysql://root:pass@localhost:3306/dev"

name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    services:
      # Spin up a maria:11 container to be used as the dev-database for analysis.
      mariadb:
        image: mariadb:11
        env:
          MYSQL_DATABASE: dev
          MYSQL_ROOT_PASSWORD: pass
        ports:
          - "3306:3306"
        options: >-
          --health-cmd "healthcheck.sh --su-mysql --connect --innodb_initialized"
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 10
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: ariga/setup-atlas@v0
        with:
          cloud-token: ${{ secrets.ATLAS_CLOUD_TOKEN }}
      - uses: ariga/atlas-action/migrate/lint@v1
        with:
          dir: 'file://ent/migrate/migrations'
          dir-name: 'my-project' # The name of the project in Atlas Cloud
          dev-url: "maria://root:pass@localhost:3306/dev"

name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    services:
      # Spin up a postgres:15 container to be used as the dev-database for analysis.
      postgres:
        image: postgres:15
        env:
          POSTGRES_DB: dev
          POSTGRES_PASSWORD: pass
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 5
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: ariga/setup-atlas@v0
        with:
          cloud-token: ${{ secrets.ATLAS_CLOUD_TOKEN }}
      - uses: ariga/atlas-action/migrate/lint@v1
        with:
          dir: 'file://ent/migrate/migrations'
          dir-name: 'my-project' # The name of the project in Atlas Cloud
          dev-url: postgres://postgres:pass@localhost:5432/dev?sslmode=disable

name: Atlas CI
on:
  # Run whenever code is changed in the master branch,
  # change this to your root branch.
  push:
    branches:
      - master
  # Run on PRs where something changed under the `ent/migrate/migrations/` directory.
  pull_request:
    paths:
      - 'ent/migrate/migrations/*'
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: ariga/setup-atlas@v0
        with:
          cloud-token: ${{ secrets.ATLAS_CLOUD_TOKEN }}
      - uses: ariga/atlas-action/migrate/lint@v1
        with:
          dir: 'file://ent/migrate/migrations'
          dir-name: 'my-project' # The name of the project in Atlas Cloud
          dev-url: sqlite://file?mode=memory&_fk=1

Observa que ejecutar atlas migrate lint requiere una base de datos de desarrollo limpia que se provee mediante el bloque services en el código de ejemplo anterior.

Verificar que todos los archivos generados están incluidos en el control de versiones​

Linting de archivos de migración​

Verificar que todos los archivos generados están incluidos en el control de versiones

Linting de archivos de migración