METODOLOGÍA

CI/CD

Continuous Integration / Continuous Delivery

Cada cambio de código se construye, prueba y prepara para release automáticamente. Algunos equipos van un paso más allá y publican a producción en cada build verde.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

Continuous Integration significa que el código del equipo se mergea y construye en cada cambio, no en una integración big-bang al final. Continuous Delivery significa que cada build exitoso está a un clic de producción. Continuous Deployment quita el clic: cada build verde sale solo.

La mayoría de equipos hace CI bien, CD a ratos y Continuous Deployment casi nunca. El cuello de botella rara vez es la herramienta. Es la confianza en la suite de tests y la voluntad del equipo de arreglar un build roto en una hora. Sin eso, los deploys automáticos solo envían bugs más rápido.

Wavect entrega cada proyecto con CI configurado desde el día uno. La configuración de CD depende de si el proyecto tiene la cobertura de tests y la disciplina operativa para que sea seguro. Te diremos cuál tienes.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Sí, desde el día uno. CI básico (build + tests en cada push) cuesta una hora de setup y previene horas de „funcionaba en mi máquina" cada semana. CD es más matizado, pero CI no es opcional ni en equipos pequeños.
La confianza en la suite de tests y la disciplina del equipo para arreglar un build roto en una hora, no la herramienta. GitHub Actions, GitLab CI o CircleCI dan resultados equivalentes. Equipos que culpan a la herramienta normalmente tienen un problema cultural disfrazado de problema técnico.
No. Solo cuando la monitorización, la cobertura de tests y la historia de rollback son lo bastante buenas como para que un humano en el loop ya no aporte señal. Llegar ahí es trabajo de meses. Para muchas empresas, Continuous Delivery (humano aprueba release) es el destino estable, no una parada intermedia.