CI/CD para equipos que no tienen equipo de DevOps
El problema real: desplegar da miedo
Conocemos el patrón. Un equipo de 3-8 desarrolladores. El “proceso de despliegue” es: alguien hace SSH al servidor, hace un git pull, reza, y ejecuta los comandos de build. Si algo falla, el mismo alguien pasa las siguientes dos horas arreglándolo a mano mientras el equipo espera.
Los despliegues se hacen los viernes a las 6 de la tarde (porque “así no molestamos a los usuarios”). Nadie quiere desplegar. Las features se acumulan en una rama de desarrollo durante semanas. Cuando por fin se fusionan, el merge conflict es épico y el despliegue es una ruleta.
Si esto te suena, no necesitas un equipo de DevOps. Necesitas un pipeline de CI/CD que un equipo de desarrollo pueda mantener sin un perfil dedicado. Este artículo explica cómo montarlo con herramientas que cuestan entre 0 y 50 euros al mes.
Qué es CI/CD (sin la jerga)
Integración Continua (CI): cada vez que alguien hace push a una rama, se ejecutan automáticamente los tests y las comprobaciones de calidad. Si fallan, la rama no se puede fusionar. Esto evita que código roto llegue a la rama principal.
Despliegue Continuo (CD): cada vez que la rama principal recibe un merge, se despliega automáticamente a producción (o a un entorno de staging, dependiendo de tu configuración). Esto evita la acumulación de cambios y reduce el riesgo de cada despliegue individual.
Junto, CI/CD convierte “desplegar” de un evento traumático a algo que pasa 5 veces al día sin que nadie lo piense dos veces.
El stack mínimo viable
No necesitas Jenkins. No necesitas Kubernetes. No necesitas Terraform. Necesitas tres cosas.
1. GitHub Actions (o GitLab CI)
GitHub Actions es gratuito para repositorios públicos e incluye 2.000 minutos/mes en el plan gratuito para repositorios privados. Para la mayoría de equipos pequeños, eso es suficiente. Si lo superas, el plan Team a 4 USD/usuario/mes incluye 3.000 minutos.
Un pipeline mínimo viable tiene tres etapas:
Lint y formato. Verifica que el código cumple las convenciones del equipo. ESLint para JavaScript/TypeScript, Ruff para Python, PHP_CodeSniffer para PHP. Tiempo: 10-30 segundos. Esta etapa es barata y atrapa el 40% de los problemas antes de que alguien los revise manualmente.
Tests. Ejecuta los tests unitarios y de integración. Si tu proyecto no tiene tests, empieza por aquí: escribe tests para las 5 funciones más críticas. No necesitas 90% de cobertura el primer día. Necesitas que las rutas críticas estén cubiertas. Tiempo: 30 segundos a 5 minutos.
Build. Compila el proyecto y verifica que la build es exitosa. Para Next.js, npm run build. Para WordPress con tema custom, verifica que el tema compila. Para Python, verifica que las dependencias se resuelven. Tiempo: 1-5 minutos.
Si las tres etapas pasan, la rama está lista para review. Si cualquiera falla, el PR se marca como fallido y no se puede fusionar.
2. Un servicio de hosting con deploy automático
El deploy debería activarse cuando un merge llega a la rama principal. Sin SSH, sin scripts manuales, sin rezos.
Railway. Nuestro favorito para equipos pequeños. Conectas tu repositorio, configuras el branch de producción, y cada push despliega automáticamente. Soporta Node.js, Python, PHP, Go, y prácticamente cualquier cosa que corra en un contenedor. Starter plan: 5 USD/mes. Lo usamos para todos nuestros proyectos WordPress en Railway y para las APIs que sirven a nuestros agentes.
Vercel. Si tu proyecto es Next.js, Vercel es la opción obvia. Deploy automático, preview deployments para cada PR, y un CDN global. Plan gratuito generoso para proyectos pequeños.
Render. Similar a Railway, con un modelo de pricing ligeramente diferente. Buen soporte para bases de datos incluidas.
Hostinger/cPanel. Si tu hosting es tradicional, puedes configurar un webhook que ejecute un script de deploy cuando GitHub Actions completa exitosamente. No es tan elegante, pero funciona. Hemos montado esto para varios sitios WordPress en Hostinger usando GitHub Actions que hacen SSH al servidor y ejecutan los comandos de deploy.
3. Un canal de notificaciones
El pipeline necesita comunicar resultados al equipo. Un mensaje en Slack o Teams cuando un deploy se completa (o falla) es suficiente. GitHub Actions tiene integraciones nativas con ambos. Si usas otra cosa, un webhook a un bot es trivial de configurar.
No subestimes esta pieza. Sin notificaciones, nadie mira el pipeline hasta que algo falla visiblemente en producción.
El pipeline que usamos en nuestros proyectos
Este es el pipeline real que ejecutamos para un proyecto típico (Next.js o WordPress):
Push a rama feature
└── GitHub Actions: lint + tests + build
├── Falla → PR marcado como fallido, notificacion
└── Pasa → PR listo para review
Review aprobado + merge a main
└── GitHub Actions: build completo
├── Falla → Notificacion urgente, merge revertido automaticamente
└── Pasa → Deploy automatico a staging
Tests en staging (manuales o automatizados)
└── Aprobacion manual (un click en GitHub Actions)
└── Deploy a produccion + notificacionPara proyectos de bajo riesgo (blogs, webs corporativas), eliminamos el paso de staging y desplegamos directamente a producción. Para proyectos con datos de usuario (ERPs, plataformas transaccionales), el staging es obligatorio.
El tiempo total desde merge hasta producción es: 3-8 minutos para proyectos sin staging, 3-8 minutos más aprobación manual para proyectos con staging. Compáralo con la hora que tardabas haciendo SSH.
Los cuatro errores que vemos en equipos sin DevOps
Error 1: No tener tests y por tanto no tener CI. “No tenemos tests así que CI no nos sirve.” Falso. El lint y la verificación de build ya son CI. Atrapan problemas reales. Añade tests incrementalmente: 5 tests esta semana, 5 la siguiente. En dos meses tienes una red de seguridad funcional.
Error 2: Pipelines que tardan 20 minutos. Si tu pipeline tarda más de 10 minutos, los desarrolladores dejarán de prestarle atención. Optimiza: ejecuta lint y tests en paralelo, cachea dependencias (node_modules, pip cache), usa imágenes de Docker ligeras. Nuestro pipeline más lento tarda 6 minutos. La mayoría están en 2-4.
Error 3: Deploy a producción sin rollback automático. Tener una estrategia de despliegue sin downtime es fundamental. Railway y Vercel tienen rollback con un click. Si tu servicio de hosting no lo tiene, configúralo tú: mantén las últimas 3 versiones desplegadas y un script que revierta a la anterior. No es opcional. Es lo que te permite desplegar sin miedo.
Error 4: No proteger la rama principal. Sin branch protection, alguien hará push directo a main a las 11 de la noche “porque es un cambio pequeño.” Configura branch protection en GitHub: require PR, require CI passing, require at least 1 approval. Son 5 minutos de configuración que previenen días de debugging.
Costes reales
Para un equipo de 5 desarrolladores con 2-3 repositorios activos:
| Componente | Herramienta | Coste/mes |
|---|---|---|
| CI/CD | GitHub Actions (plan free) | 0 EUR |
| Hosting | Railway Starter | 5-20 EUR |
| Notificaciones | Slack free tier | 0 EUR |
| Monitorización | UptimeRobot free | 0 EUR |
| Total | 5-20 EUR |
Si necesitas más minutos de CI o ejecutar tests más pesados:
| Componente | Herramienta | Coste/mes |
|---|---|---|
| CI/CD | GitHub Team (5 usuarios) | 20 EUR |
| Hosting | Railway Pro | 20-50 EUR |
| Notificaciones | Slack Pro | 7.25 EUR/usuario |
| Monitorización | Better Uptime | 20 EUR |
| Total | 96-127 EUR |
Ambos escenarios son órdenes de magnitud más baratos que un ingeniero DevOps dedicado (3.500-5.000 EUR/mes en España).
Cuándo SÍ necesitas un DevOps dedicado
Un pipeline de CI/CD resuelve el 80% de los problemas de despliegue de un equipo pequeño. Pero hay escenarios donde necesitas más:
- Múltiples entornos (dev, staging, producción, demo) con configuraciones diferentes
- Infraestructura como código porque tu aplicación necesita colas, bases de datos, caches, y servicios auxiliares
- Compliance que requiere auditoría de despliegues, segregación de entornos, y trazabilidad completa
- Escalado automático porque tu tráfico es muy variable
Si estás en alguno de estos casos, un perfil DevOps (interno o externo) tiene sentido. Pero incluso entonces, empieza con el pipeline básico y añade complejidad solo cuando la necesites.
Para equipos que necesitan CI/CD pero no tienen capacidad interna para montarlo, nuestro equipo de cloud y DevOps configura pipelines completos en 1-2 semanas. También ofrecemos servicios gestionados que incluyen la operación continua del pipeline.
Si tu proyecto está en WordPress sobre Railway o Hostinger, tenemos experiencia específica con ambas plataformas. Puedes revisar cómo abordamos la infraestructura en nuestra sección de desarrollo.