No sabría entender este trabajo sin la investigación. Tras tres años en el CERN, al volver a Bilbao decidí trabajar por mi cuenta y seguir investigando y aprendiendo. Creo que emprender es el reto profesional definitivo, y a la vez una expresión de creatividad y un reclamo de libertad.
Zetesis viene del griego ζήτησις, indagación: buscar la causa antes de proponer la solución.
Un entorno entero por cada pull request, y que se borre solo
LaboratorioGitOpsKubernetesDevOps
Revisar un pull request leyendo el diff funciona para la lógica y no funciona para casi nada más. Si el cambio toca una migración, una plantilla de Helm o el comportamiento de una pantalla, aprobarlo es un acto de fe.
La alternativa es que cada pull request levante su propio entorno completo, y que se borre solo cuando se cierre.
Qué levanta exactamente
En el homelab, cuando un PR lleva la etiqueta preview, el Pull Request Generator de ArgoCD lo detecta en menos de un minuto y crea el entorno entero.
Recurso
Qué recibe el PR
Namespace
El suyo, con el número del PR
Base de datos
PostgreSQL propio, vía CNPG
Búsqueda
Su instancia de Typesense
Secretos
Los suyos, desde Infisical
Dominio
Un subdominio propio
Todo con nombre propio: nada se comparte con staging.
Lo importante no es la lista, sino que no comparte nada con staging. Una migración destructiva en un preview rompe ese preview y nada más.
Las dos mitades se encuentran en el SHA
El montaje son dos piezas que no se hablan entre sí: GitHub Actions construye las imágenes y ArgoCD despliega los manifiestos. Nadie llama a nadie. Lo que las mantiene alineadas es que ambas usan el commit del pull request como identificador.
Del lado de GitHub
El workflow escucha los eventos del PR —abierto, actualizado, reabierto, etiquetado y cerrado— y solo actúa si lleva la etiqueta preview. Construye los cuatro servicios en paralelo y etiqueta cada imagen con el número del PR y el SHA de su cabecera:
La matriz corre sin cancelar hermanas cuando una falla. No es despiste: el almacenamiento del registro público devuelve errores de certificado intermitentes, y con la cancelación activada un fallo transitorio en un servicio tiraba la construcción de los otros tres.
Del lado de ArgoCD
Aquí no hay ningún webhook. Un generador de pull requests pregunta a GitHub cada sesenta segundos por los PR que lleven esa etiqueta:
Por cada PR que encuentra, materializa tres aplicaciones en dos oleadas. Y cada una apunta al commit exacto del pull request, no a su rama:
Oleada
Aplicación
Qué crea
0
pr-secrets
ExternalSecrets desde Infisical
0
pr-infra
PostgreSQL con CNPG y Typesense
1
pr-app
El chart de Helm con sus dominios y sus tags
Tres ApplicationSets, dos oleadas. La aplicación no arranca hasta que sus secretos y su base de datos existen.
El ApplicationSet de la aplicación es donde se cierra el círculo: sobrescribe los parámetros del chart con el mismo esquema que usó el workflow al etiquetar.
Manifiesto e imagen salen del mismo commit sin que ninguna de las dos partes conozca a la otra. Empujar otro commit al PR cambia el SHA, y con él cambian a la vez el tag que construye el workflow y la revisión que despliega ArgoCD.
Gestión del ciclo de vida y activación
Al cerrar el pull request se desmonta por los dos lados: ArgoCD borra las aplicaciones —y con ellas el namespace entero, con su base de datos y sus secretos— porque el generador deja de verlo, y un último trabajo del workflow borra de Harbor las imágenes de ese PR. Ni entornos huérfanos ni un registro creciendo con imágenes que nadie va a descargar nunca más.
Un entorno efímero que no se limpia deja de ser efímero y pasa a ser un clúster lleno de basura. La limpieza va automática al cerrar el PR, y en el portal además hay un tope de veinticuatro horas.
La etiqueta también importa: solo se levanta preview si el PR la lleva. Sin eso, cada cambio de documentación arrastra una base de datos.
Cuándo no compensa
El coste no es el CPU: es que necesitas la plataforma debajo. Sin GitOps, sin secretos externos y sin una base de datos que sepa provisionarse sola, montar previews por PR es construir esas tres cosas primero.
Si ya las tienes, es de lo más barato que puedes añadir. Si no, el orden correcto es el inverso.
01
02
03
04
