CI/CD para equipos que no tienen equipo de DevOps

El problema real: desplegar da miedo

Conocemos el patron. 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 arreglandolo a mano mientras el equipo espera.

Los despliegues se hacen los viernes a las 6 de la tarde (porque “asi 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 epico 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 articulo explica como montarlo con herramientas que cuestan entre 0 y 50 euros al mes.

Que es CI/CD (sin la jerga)

Integracion Continua (CI): cada vez que alguien hace push a una rama, se ejecutan automaticamente los tests y las comprobaciones de calidad. Si fallan, la rama no se puede fusionar. Esto evita que codigo roto llegue a la rama principal.

Despliegue Continuo (CD): cada vez que la rama principal recibe un merge, se despliega automaticamente a produccion (o a un entorno de staging, dependiendo de tu configuracion). Esto evita la acumulacion de cambios y reduce el riesgo de cada despliegue individual.

Junto, CI/CD convierte “desplegar” de un evento traumatico a algo que pasa 5 veces al dia sin que nadie lo piense dos veces.

El stack minimo 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 publicos e incluye 2.000 minutos/mes en el plan gratuito para repositorios privados. Para la mayoria de equipos pequenos, eso es suficiente. Si lo superas, el plan Team a 4 USD/usuario/mes incluye 3.000 minutos.

Un pipeline minimo viable tiene tres etapas:

Lint y formato. Verifica que el codigo 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 integracion. Si tu proyecto no tiene tests, empieza por aqui: escribe tests para las 5 funciones mas criticas. No necesitas 90% de cobertura el primer dia. Necesitas que las rutas criticas esten 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 esta lista para review. Si cualquiera falla, el PR se marca como fallido y no se puede fusionar.

2. Un servicio de hosting con deploy automatico

El deploy deberia activarse cuando un merge llega a la rama principal. Sin SSH, sin scripts manuales, sin rezos.

Railway. Nuestro favorito para equipos pequenos. Conectas tu repositorio, configuras el branch de produccion, y cada push despliega automaticamente. Soporta Node.js, Python, PHP, Go, y practicamente 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 opcion obvia. Deploy automatico, preview deployments para cada PR, y un CDN global. Plan gratuito generoso para proyectos pequenos.

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 produccion.

El pipeline que usamos en nuestros proyectos

Este es el pipeline real que ejecutamos para un proyecto tipico (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 + notificacion

Para proyectos de bajo riesgo (blogs, webs corporativas), eliminamos el paso de staging y desplegamos directamente a produccion. Para proyectos con datos de usuario (ERPs, plataformas transaccionales), el staging es obligatorio.

El tiempo total desde merge hasta produccion es: 3-8 minutos para proyectos sin staging, 3-8 minutos mas aprobacion manual para proyectos con staging. Comparalo 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 asi que CI no nos sirve.” Falso. El lint y la verificacion de build ya son CI. Atrapan problemas reales. Anade 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 mas de 10 minutos, los desarrolladores dejaran de prestarle atencion. Optimiza: ejecuta lint y tests en paralelo, cachea dependencias (node_modules, pip cache), usa imagenes de Docker ligeras. Nuestro pipeline mas lento tarda 6 minutos. La mayoria estan en 2-4.

Error 3: Deploy a produccion sin rollback automatico. 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, configuralo tu: manten las ultimas 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 hara push directo a main a las 11 de la noche “porque es un cambio pequeno.” Configura branch protection en GitHub: require PR, require CI passing, require at least 1 approval. Son 5 minutos de configuracion que previenen dias 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
Monitorizacion	UptimeRobot free	0 EUR
Total		5-20 EUR

Si necesitas mas minutos de CI o ejecutar tests mas 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
Monitorizacion	Better Uptime	20 EUR
Total		96-127 EUR

Ambos escenarios son ordenes de magnitud mas baratos que un ingeniero DevOps dedicado (3.500-5.000 EUR/mes en Espana).

Cuando SI necesitas un DevOps dedicado

Un pipeline de CI/CD resuelve el 80% de los problemas de despliegue de un equipo pequeno. Pero hay escenarios donde necesitas mas:

• Multiples entornos (dev, staging, produccion, demo) con configuraciones diferentes
• Infraestructura como codigo porque tu aplicacion necesita colas, bases de datos, caches, y servicios auxiliares
• Compliance que requiere auditoria de despliegues, segregacion de entornos, y trazabilidad completa
• Escalado automatico porque tu trafico es muy variable

Si estas en alguno de estos casos, un perfil DevOps (interno o externo) tiene sentido. Pero incluso entonces, empieza con el pipeline basico y anade 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. Tambien ofrecemos servicios gestionados que incluyen la operacion continua del pipeline.

Si tu proyecto esta en WordPress sobre Railway o Hostinger, tenemos experiencia especifica con ambas plataformas. Puedes revisar como abordamos la infraestructura en nuestra seccion de desarrollo.