MAISON CODE .
/ DevOps · CI/CD · Automation · Quality · Infrastructure

El proceso de CI/CD: automatización de la confianza

Las implementaciones manuales son una responsabilidad. Una guía técnica para crear una canalización de CI/CD sólida con GitHub Actions, Vercel Preview Environments y Playwright.

AB
Alex B.
El proceso de CI/CD: automatización de la confianza

En los equipos amateurs, el despliegue es un “Evento”. El desarrollador principal grita: “¡Todos dejen de fusionarse! ¡Estoy implementando!” Ellos SSH en un servidor. Ejecutan “git pull”. Ellos rezan. Si se rompe, entran en pánico.

En equipos profesionales, la implementación es un No-Evento. Sucede 20 veces al día. Es aburrido. Es invisible. Si se rompe, el sistema retrocede automáticamente antes de que el usuario lo vea.

Esto se logra mediante Integración continua/Implementación continua (CI/CD). Pipeline es un robot que protege su entorno de producción. Su trabajo es simple: Rechazar sin piedad el código incorrecto.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

1. La Filosofía: La Rama Principal es Santa

El objetivo de CI/CD es garantizar que la rama “principal” sea siempre desplegable. Nunca presionas directamente a “principal”. Usted se adhiere al Desarrollo basado en troncales (o ramas de funciones de corta duración).

  1. El desarrollador crea la rama feat/new-checkout.
  2. El desarrollador introduce el código.
  3. Se ejecuta CI Pipeline. Pasan las pruebas.
  4. El desarrollador abre la Solicitud de extracción (PR).
  5. Se implementa Entorno de vista previa.
  6. Se produce la revisión por pares.
  7. Fusionarse con “principal”.
  8. Se ejecuta CD Pipeline. Se implementa en producción.

2. Capa 1: Análisis estático (La policía gramatical)

Los errores más baratos de corregir son los que se detectan antes de que se ejecute el código. Ejecutamos esto en cada “git push”.

  • Linting (ESLint): detecta errores de sintaxis y patrones incorrectos (no-unused-vars).
  • Formato (más bonito): aplica el estilo. No hay discusiones sobre tabulaciones o espacios durante la revisión del código.
  • Verificación de tipo (TypeScript): la verificación más crítica. “Pasaste una cadena a una función que esperaba un número”.
# .github/workflows/ci.yml
nombre: CI
en: [empujar]
trabajos:
  validar:
    se ejecuta en: ubuntu-latest
    pasos:
      - usos: acciones/checkout@v3
      - usos: acciones/setup-node@v3
      - ejecutar: npm ci
      - ejecutar: npm ejecutar type-check # tsc --noEmit
      - ejecutar: npm ejecutar pelusa

Costo: 30 segundos. Valor: Ahorra horas de depuración “indefinido no es una función”.

3. Capa 2: Pruebas unitarias (La verificación lógica)

(Ver Pruebas unitarias). ¿La función calculateTax() devuelve el valor correcto para un usuario alemán? Usamos Vitest. Debe ser rápido. Si las pruebas unitarias tardan más de 5 minutos, los desarrolladores dejarán de ejecutarlas localmente.

4. Capa 3: El entorno de vista previa (Vercel)

Este es el punto de inflexión. Cuando se abre un PR, Vercel implementa automáticamente ese código en una URL única: https://my-app-git-feat-checkout.vercel.app. Esto permite:

  1. Control de calidad visual: el diseñador puede hacer clic en el proceso de pago para ver si los píxeles son perfectos.
  2. Revisión del producto: el PM puede verificar que la función cumpla con los requisitos.
  3. Pruebas E2E automatizadas: Pipeline puede ejecutar un navegador en esta URL real.

5. Capa 4: Pruebas de extremo a extremo (E2E) (el simulador de usuario)

Las pruebas unitarias no son suficientes. “La conexión de la base de datos funciona. El botón se muestra. Pero al hacer clic en el botón no se guarda en la base de datos”. Sólo Dramaturgo (o Cypress) se da cuenta de esto.

El canal de CI activa un navegador sin cabeza y actúa como un usuario.

  1. Vaya a /producto/zapatilla.
  2. Haga clic en “Agregar al carrito”.
  3. Espere que aparezca “Carrito (1)”.
  e2e:
    necesidades: vista previa
    se ejecuta en: ubuntu-latest
    pasos:
      - usos: acciones/checkout@v3
      - nombre: Ejecutar dramaturgo
        ejecutar: prueba de dramaturgo npx
        entorno:
          BASE_URL: ${{ github.event.deployment_status.target_url }}

Bloqueador: si las pruebas E2E fallan, el botón “Fusionar” en GitHub se desactiva.

6. Despliegue continuo: el lanzamiento

Una vez que el código se fusiona con “principal”, se inicia la canalización del CD. Para Vercel/Netlify, esto es automático. Para AWS (Docker/ECS), utilizamos GitHub Actions para crear el contenedor, enviarlo a ECR y actualizar la definición de tarea.

Cero tiempo de inactividad (azul/verde)

Nunca reiniciamos un servidor en vivo.

  1. Gira Verde (Nueva versión).
  2. Espere la verificación de estado (200 OK).
  3. Cambie el equilibrador de carga a Verde.
  4. Mata a Azul (Versión antigua). Esto garantiza que si la nueva versión falla al arrancar, ningún usuario la vea.

7. La regla del “despliegue del viernes”

Hay un meme: “No despliegues el viernes”. En Maison Code, realizamos despliegues los viernes. Si tiene miedo de implementar el viernes, significa que no confía en su canalización. Significa que confía en el control de calidad manual o en la esperanza. Una tubería sólida le brinda la confianza para realizar envíos en cualquier momento.

8. Escaneo de seguridad (desplazamiento a la izquierda)

La seguridad suele realizarse “al final” mediante un Pentest. Lo movemos a Pull Request.

  1. Snyk / Dependabot: analiza package.json en busca de dependencias vulnerables.
  2. Trivy: analiza los contenedores Docker en busca de vulnerabilidades del sistema operativo.
  3. SonarQube: escanea el código en busca de puntos de acceso (por ejemplo, contraseñas codificadas). Si confirma una clave de AWS, la canalización explota. Evita que el secreto llegue al historial de la rama “principal”.

9. Gestión de costos (Infracost)

A los desarrolladores les encanta crear instancias grandes. “Necesito una base de datos X1.Large para realizar pruebas”. Usamos Infracost. Se ejecuta en el PR y comenta:

“Este RP aumenta la factura mensual en €150 (actualización a X1.Large)”. Esto hace que los costos sean transparentes. El CTO puede aprobar o rechazar el “Cambio Financiero” como si fuera un “Cambio de Código”. Lleva FinOps a DevOps.

10. Gestión de secretos (Env Vars)

Nunca confirme archivos .env. Usamos Vercel Env Management o AWS Secrets Manager. La canalización de CI los inyecta en el momento de la compilación. Para las comprobaciones de código abierto (como npm audit), nos aseguramos de que los secretos no se registren en la consola.

9. GitOps (ArgoCD): El Santo Grial

Para nuestros clústeres de Kubernetes, utilizamos GitOps. El estado del clúster se define en Git. Si desea escalar de 3 pods a 5 pods, no ejecute “kubectl scale”. Editas deployment.yaml en Git. ArgoCD ve el cambio y sincroniza el clúster. Detección de deriva: si un ingeniero vaquero cambia el clúster manualmente (SSH), ArgoCD detecta la deriva y sobrescribe el estado Git. Esto hace cumplir religiosamente la “infraestructura como código”.

10. Semilla de base de datos para vistas previas

Un entorno de vista previa es inútil si tiene una base de datos vacía. Te registras y no hay productos. Implementamos Siembra Automatizada.

  1. Implementar DB (sucursal Neon/Supabase).
  2. Ejecute npm run seed.
  3. Inyecciones: 10 Productos, 2 Usuarios (Administrador/Cliente), 5 Pedidos. Ahora el PM puede probar la página “Historial de pedidos” inmediatamente. Ésta es la diferencia entre una “Implementación Técnica” y un “Producto Utilizable”.

11. Reversión avanzada: implementaciones canarias

Para aplicaciones de alto riesgo, Azul/Verde es demasiado binario. Usamos Implementaciones Canary.

  1. Implementar v2 al 5% del tráfico.
  2. Tasa de errores de vigilancia de tuberías.
  3. Si la tasa de error <0,1%, aumente al 20%.
  4. Si la tasa de error aumenta, Reversión automática al 0 %. Esto limita el “radio de explosión” de un error grave. Sólo el 5% de los usuarios vio el error. Esto requiere equilibradores de carga sofisticados (AWS ALB / Cloudflare), pero es la red de seguridad definitiva.

12. Conclusión

Las operaciones manuales son enemigas de la escala. Cada vez que un humano toca un servidor, el riesgo de error es del 10%. Cada vez que un script toca un servidor, el riesgo es del 0% (después de la primera ejecución exitosa). Automatiza todo. Haga de “Hacer lo correcto” algo “fácil”.

Lea sobre [Pruebas automatizadas](/es/blog/tech-automated-testing-es) e [Infraestructura como código](/es/blog/tech-infrastructure-code-es).

Las operaciones manuales son enemigas de la escala. Cada vez que un humano toca un servidor, el riesgo de error es del 10%. Cada vez que un script toca un servidor, el riesgo es del 0% (después de la primera ejecución exitosa). Automatiza todo. Haga de “Hacer lo correcto” algo “fácil”. Contrate a nuestros arquitectos.