CI/CD para equipos pequeños: no necesitas la infraestructura de Netflix

Tu equipo despliega a mano. Sin CI/CD, alguien se conecta al servidor, hace un pull, ejecuta unos comandos y cruza los dedos. O quizá tenéis un script que automatiza parte del proceso, pero nadie se acuerda de quién lo escribió ni qué hace exactamente.

Sabes que deberíais tener un pipeline de CI/CD. Has leído sobre ello. Pero cada artículo que encuentras habla de Kubernetes, service mesh, canary deployments y herramientas con nombres que suenan a misiones espaciales.

El problema no es que CI/CD sea complejo. Es que la industria lo ha complicado innecesariamente. Para un equipo pequeño, un buen pipeline se monta en una tarde y cambia la forma de trabajar desde el primer día.

Qué es CI/CD (sin el ruido)

CI/CD son dos prácticas que se complementan pero que puedes adoptar por separado.

CI (Integración Continua) significa que cada vez que alguien sube código al repositorio, un sistema automatizado lo compila, ejecuta los tests y verifica que todo funciona. Si algo falla, el equipo se entera en minutos, no en días.

CD (Despliegue Continuo o Entrega Continua) significa que ese código verificado se despliega automáticamente en un entorno (staging, producción o ambos). Sin intervención manual. Sin conectarse a servidores. Sin cruzar dedos.

La diferencia entre Entrega Continua y Despliegue Continuo es sutil pero relevante. Entrega Continua lleva el código hasta un entorno de staging listo para producción, pero el despliegue final se dispara manualmente (un botón, una aprobación). Despliegue Continuo lo lleva directamente a producción. Para equipos pequeños, empezar con Entrega Continua suele ser más prudente.

Por qué un equipo pequeño lo necesita más que uno grande

Hay una idea equivocada de que CI/CD es un lujo para equipos grandes. En realidad, es al revés. Un equipo grande puede permitirse tener una persona dedicada a desplegar, a investigar por qué los tests fallan o a coordinar releases. Un equipo pequeño no.

Cuando sois tres o cinco desarrolladores, cada hora cuenta. Y los despliegues manuales consumen horas de forma invisible.

Desplegar a mano es lento. Según el informe DORA State of DevOps, los equipos sin automatización tardan entre una hora y un día en desplegar un cambio. Los equipos con CI/CD lo hacen en minutos. Multiplicado por dos o tres despliegues a la semana, las cuentas son claras.

Desplegar a mano es arriesgado. Cuando el proceso depende de que alguien ejecute los pasos correctos en el orden correcto, cualquier olvido o error genera incidentes. Un equipo pequeño no tiene margen para apagar fuegos que se podían haber evitado.

Desplegar a mano bloquea al equipo. Si solo una persona sabe desplegar, esa persona se convierte en un cuello de botella. Si está de vacaciones, enferma o simplemente ocupada, nadie despliega. El conocimiento de despliegue no puede vivir en la cabeza de una sola persona.

CI/CD libera tiempo para construir. El tiempo que tu equipo dedica a desplegar, verificar y apagar fuegos es tiempo que no dedica a construir producto. Un pipeline automatizado devuelve ese tiempo.

Qué montar primero (y qué puede esperar)

Aquí es donde la mayoría de guías se desvían. Te dicen que necesitas todo desde el principio: tests unitarios, tests de integración, tests end-to-end, análisis estático, escaneo de seguridad, despliegue blue-green, rollback automático.

No. Necesitas lo mínimo que funcione. Después iteras.

Paso 1: Un repositorio limpio con ramas protegidas

Si tu equipo trabaja directamente sobre main sin pull requests, ese es el primer problema. Antes de automatizar nada, establece un flujo básico: cada cambio va en una rama, se revisa mediante pull request y se mergea a main cuando está listo.

No hace falta un flujo de ramas complejo. Main como rama de producción y ramas de feature es suficiente para empezar. Git Flow, Trunk Based Development y otras estrategias pueden venir después.

Paso 2: Tests que se ejecutan en cada push

No necesitas un 80% de cobertura para empezar. Necesitas los tests que validan que tu aplicación arranca, que las rutas principales funcionan y que la lógica de negocio crítica no está rota.

Si tienes cero tests, empieza por tres o cinco que cubran los flujos más importantes. En un backend Django, por ejemplo, un par de tests sobre las vistas principales y la lógica de negocio crítica ya te dan una red de seguridad real. En una app Flutter, los widget tests de los flujos clave cumplen la misma función. Un pipeline con pocos tests buenos es infinitamente mejor que un pipeline sin tests.

La herramienta más accesible para esto es GitHub Actions. Si tu código está en GitHub, el CI viene incluido. Un archivo YAML en tu repositorio y los tests se ejecutan en cada push. GitLab CI/CD funciona igual si usas GitLab. Ambos tienen tiers gratuitos más que suficientes para equipos pequeños.

Paso 3: Despliegue automático a staging

Cuando main tiene código que ha pasado los tests, un paso automatizado lo despliega en un entorno de staging. No en producción (todavía). En un entorno donde el equipo pueda verificar que todo funciona antes de exponerlo a usuarios.

Si tu infraestructura está en AWS, servicios como Elastic Beanstalk o ECS permiten despliegues automáticos desde el pipeline. Si usas un VPS con buena relación coste/rendimiento (Hetzner, por ejemplo), un script de despliegue que se ejecute vía SSH desde GitHub Actions o GitLab CI consigue lo mismo sin pagar de más. No necesitas orquestadores ni servicios managed si tu proyecto no los justifica. Lo importante es que el despliegue a staging ocurra sin que nadie se conecte a mano al servidor.

Paso 4: Despliegue a producción con un botón

No automatices el despliegue a producción desde el primer día. Empieza con un paso manual: alguien revisa staging, confirma que todo está bien y pulsa un botón en el pipeline para desplegar a producción.

Ese botón es importante. Da control sin quitar automatización. El 95% del proceso es automático (build, tests, staging). Solo el último paso —la decisión de ir a producción— es humano. Con el tiempo, si tu pipeline es fiable y tus tests son sólidos, puedes eliminar ese paso y pasar a despliegue continuo completo.

El pipeline mínimo viable

Para que quede concreto, esto es lo que debería hacer tu pipeline en cada push a una pull request:

Instalar dependencias. Ejecutar linter (para mantener el estilo de código). Ejecutar tests. Si todo pasa, marcar la PR como lista para review. Si algo falla, bloquear el merge.

Y cuando la PR se mergea a main:

Ejecutar tests otra vez (por si hay conflictos del merge). Construir la aplicación. Desplegar a staging automáticamente. Notificar al equipo (Slack, email, lo que uséis).

Esto se monta en GitHub Actions o GitLab CI en menos de un día. Para un proyecto Django con Python, el workflow cabe en 40-50 líneas de YAML: instalar dependencias con pip, ejecutar pytest y desplegar a tu servidor (AWS, un VPS en Hetzner o donde lo tengas). Para una app Flutter, el pipeline incluye flutter analyze, flutter test y la generación del build para iOS y Android. No necesitas un experto en DevOps. Necesitas un desarrollador con media hora y la documentación abierta.

Errores que cometen los equipos pequeños

Automatizar demasiado pronto. Si tu equipo no tiene ni tests ni pull requests, montar un pipeline de despliegue automático es construir la casa por el tejado. Primero las bases (repo limpio, tests básicos), después la automatización.

Copiar pipelines de proyectos grandes. Un pipeline de una empresa con 200 ingenieros tiene pasos que tu equipo no necesita: escaneos de seguridad complejos, matrices de tests en 15 versiones de Python, aprobaciones de tres niveles. Copia el concepto, no la implementación. Tu proyecto Django necesita un linter, pytest y un despliegue a tu servidor. No Kubernetes ni un cluster de contenedores que nadie va a mantener.

No mantener los tests. Un test que falla intermitentemente y que el equipo ignora es peor que no tener test. Si un test es inestable, arréglalo o bórralo. El pipeline debe ser fiable: si dice que algo falla, debe ser verdad.

Olvidar las notificaciones. Un pipeline que falla en silencio no sirve. Configura notificaciones para que el equipo se entere inmediatamente cuando algo se rompe. Si nadie se entera, nadie lo arregla.

Invertir en herramientas caras. GitHub Actions y GitLab CI/CD tienen planes gratuitos que cubren de sobra las necesidades de un equipo pequeño. No necesitas Jenkins, no necesitas un servidor de CI dedicado, no necesitas herramientas enterprise. Lo mismo aplica a la infraestructura: un VPS bien configurado despliega igual de bien que un servicio managed a una fracción del coste. Si algún día necesitas escalar, migrar es sencillo.

Lo que cambia cuando lo tienes

El efecto de un buen pipeline de CI/CD en un equipo pequeño es desproporcionado respecto al esfuerzo de montarlo.

Dejas de tener miedo a desplegar. Los viernes a las 17:00 dejan de ser una zona de riesgo porque desplegar ya no implica downtime ni incertidumbre. Desplegar se convierte en algo que haces varias veces al día sin pensarlo.

Los bugs se detectan antes. Un test que falla en la PR te ahorra descubrir el problema en producción con un usuario enfadado al teléfono.

El equipo gana confianza. Saber que cada cambio pasa por un filtro automático antes de llegar a producción reduce la ansiedad y permite moverse más rápido.

Y quizá lo más importante: dejas de depender de una persona para desplegar. Cualquiera del equipo puede llevar un cambio a producción siguiendo el mismo proceso, con las mismas garantías.

Empieza hoy, no la semana que viene

Montar un pipeline básico de CI/CD no es un proyecto de dos semanas. Es un día de trabajo. Quizá dos si nunca has tocado GitHub Actions. El ROI se nota desde la primera semana.

Si tu equipo tiene entre 3 y 10 personas y desplegáis a mano, hoy es el mejor día para dejar de hacerlo. No porque sea lo que hacen las empresas grandes. Sino porque es lo que necesita tu equipo para dejar de perder tiempo en cosas que una máquina hace mejor.