Cuando hago un cambio en una web, no lo subo directamente. Primero pasa por una pipeline de integración continua en GitHub Actions, que lo revisa de forma automática. Si algo falla, el cambio no se publica.
Seguridad antes que nada
Lo primero que se comprueba es que no se haya colado ninguna clave ni contraseña en el código (gitleaks) y que el código nuevo no introduzca patrones inseguros (análisis estático con Semgrep). Además, cada semana se revisan las dependencias en busca de vulnerabilidades conocidas.
Dependencias de confianza
Las librerías externas se instalan siempre en la versión exacta registrada, y las acciones de terceros están fijadas a una versión concreta. Así, una actualización maliciosa o rota de un paquete no entra sola en tu web.
Código limpio y con tipos
Lint, formato y comprobación de tipos de TypeScript en frontend y backend, además de detección de código muerto. Son errores baratos de arreglar si se pillan pronto.
Tests a varios niveles
Tests unitarios del frontend y del backend, tests de la API contra una base de datos real y tests E2E con Playwright que recorren la web como lo haría un usuario. Los E2E se reparten en varias máquinas en paralelo para que la espera sea corta. También se mide la cobertura, y la pipeline falla si baja del mínimo fijado.
Solo se publica lo que se ha probado
El despliegue comprueba que el código que se va a publicar es exactamente el que pasó la pipeline. El frontend se despliega en Vercel y el backend en Fly.io.
Qué gana el cliente
Menos sustos. Los fallos los encuentra una máquina antes de que lleguen a tu web, no tus visitantes después.
