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, añadimos una nueva guía a la documentación que recoge las mejores prácticas comunes para verificar en CI y presenta ent/contrib/ci: una GitHub Action que mantenemos y que las codifica.
En esta publicación, quiero compartir algunas de nuestras sugerencias iniciales sobre cómo podrías incorporar CI a tu proyecto Ent. Hacia el final de este artículo, compartiré detalles sobre proyectos en los que estamos trabajando y para los que nos gustaría recibir comentarios de la comunidad.
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: 1.18
- 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, alertándote de cualquier posible pérdida de datos que puedan causar tus migraciones mucho antes de que lleguen a tu base de datos de producción.
El linting detecta cambios dependientes de datos que podrían fallar durante el despliegue y requieren una revisión más cuidadosa por 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
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.0.1
with:
fetch-depth: 0 # Mandatory unless "latest" is set below.
- uses: ariga/atlas-action@v0
with:
dir: ent/migrate/migrations
dir-format: golang-migrate # Or: atlas, goose, dbmate
dev-url: mysql://root:pass@localhost:3306/test
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:10.7 container to be used as the dev-database for analysis.
maria:
image: mariadb:10.7
env:
MYSQL_DATABASE: test
MYSQL_ROOT_PASSWORD: pass
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.0.1
with:
fetch-depth: 0 # Mandatory unless "latest" is set below.
- uses: ariga/atlas-action@v0
with:
dir: ent/migrate/migrations
dir-format: golang-migrate # Or: atlas, goose, dbmate
dev-url: maria://root:pass@localhost:3306/test
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:10 container to be used as the dev-database for analysis.
postgres:
image: postgres:10
env:
POSTGRES_DB: test
POSTGRES_PASSWORD: pass
ports:
- 5432:5432
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3.0.1
with:
fetch-depth: 0 # Mandatory unless "latest" is set below.
- uses: ariga/atlas-action@v0
with:
dir: ent/migrate/migrations
dir-format: golang-migrate # Or: atlas, goose, dbmate
dev-url: postgres://postgres:pass@localhost:5432/test?sslmode=disable
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.
Qué viene para la CI de Ent
Para complementar este comienzo modesto, quiero compartir algunas funcionalidades que estamos probando en Ariga con la esperanza de recibir comentarios de la comunidad.
Análisis para Migraciones Online - muchos proyectos de Ent utilizan el mecanismo automático de migración de esquemas disponible en Ent (usando
ent.Schema.Createal iniciar las aplicaciones). Asumiendo que el código fuente del proyecto está gestionado en un sistema de control de versiones (como Git), comparamos el esquema en la rama principal (master/main/etc.) con el de la rama de características actual y usamos la capacidad de comparación de esquemas de Atlas para calcular las sentencias SQL que se ejecutarán contra la base de datos. Luego podemos utilizar la capacidad de análisis de Atlas para proporcionar información sobre posibles riesgos derivados del cambio propuesto.Visualización de cambios - para ayudar a los revisores a comprender el impacto de los cambios propuestos en una pull request específica, generamos un diff visual (usando un diagrama ER similar a entviz) que refleja las modificaciones en el esquema del proyecto.
Análisis de Esquemas - utilizando el paquete oficial go/analysis para crear analizadores que examinen el código Go del esquema de Ent y apliquen políticas (como convenciones de nomenclatura o indexación) a nivel de definición del esquema.
Para finalizar
En este artículo hemos presentado el concepto de CI y discutido formas de implementarlo en proyectos de Ent. Además, hemos mostrado verificaciones de CI que estamos probando internamente. Si te gustaría que estas verificaciones formen parte de Ent o tienes otras ideas para proporcionar herramientas de CI para Ent, contáctanos en el Servidor de Discord de Ent.
- Suscríbete a nuestro Newsletter
- Síguenos en Twitter
- Únete a #ent en Gophers Slack
- Únete al Servidor de Discord de Ent