El proceso de despliegue que funcionaba con 5 ingenieros se rompe con 15
Todo equipo de ingeniería hace despliegues manuales en algún momento, y durante un tiempo funciona bien. Una o dos personas conocen los pasos, la checklist vive en un documento de Notion, y los releases ocurren cuando alguien tiene una tarde libre. Luego el equipo crece más allá de los 15 ingenieros, la frecuencia de release pasa de semanal a diaria, y ese mismo proceso, exactamente igual, empieza a producir incidentes.
Vemos este patrón todo el tiempo: un equipo que llevaba dos años lanzando releases sin problemas, de pronto tiene un mes malo. No porque nadie haya empeorado en su trabajo, sino porque el proceso nunca escaló más allá del tamaño de equipo para el que fue diseñado. Los despliegues manuales son un sistema de punto único de fallo disfrazado de "así es como siempre lo hemos hecho".
La pregunta que nos hacen no es "¿deberíamos automatizar?". En eso ya todos están de acuerdo. La pregunta es qué automatizar primero, porque los equipos que intentan arreglarlo todo en un solo sprint suelen estancarse y no entregar nada. Aquí está el orden que realmente funciona, basado en el patrón que vemos en equipos en etapa de crecimiento.
Arregla el camino de despliegue antes de tocar la infraestructura
El instinto, cuando todo se siente frágil, es recurrir primero a infrastructure-as-code: llevar todo a Terraform, poner los servidores bajo control. Ese es el primer movimiento equivocado. Si tu proceso de despliegue todavía es "entrar por SSH y correr un script", pasar a Terraform la máquina donde corre ese script no arregla el verdadero modo de fallo: una persona haciendo a mano una tarea repetible, bajo presión de tiempo, sin plan de rollback.
El primer dólar de automatización debe ir a CI/CD: un pipeline que corre en cada push, ejecuta las mismas pruebas cada vez, y despliega de la misma manera cada vez. En concreto, eso significa:
- Cada merge a main dispara un build y una suite de pruebas — sin excepciones, sin pushes manuales de "solo por esta vez".
- El paso de despliegue es un job del pipeline, no la terminal de una persona. GitHub Actions, GitLab CI o CircleCI manejan esto perfectamente; la herramienta importa menos que la disciplina de usarla siempre.
- El rollback es un botón, no una persona tratando de recordar a las 11pm cuál fue el último commit hash que funcionó bien.
Los equipos que hacen esto primero suelen ver una caída notable en los incidentes relacionados con despliegues durante el primer mes, sin tocar un solo archivo de Terraform. La razón: la mayoría de los incidentes de "infraestructura" en esta etapa no son problemas de infraestructura. Son problemas de proceso disfrazados de infraestructura — un valor de configuración que solo existe en la cabeza de un ingeniero, un paso de migración que alguien olvidó correr, un despliegue que ocurrió fuera de orden respecto a otro.
Luego haz que los entornos sean reproducibles
Una vez que los despliegues están automatizados, surge el siguiente modo de fallo: "funciona en staging pero no en producción", o peor, "no recordamos cómo se configuró staging". Aquí es donde infrastructure-as-code se gana su lugar — no como la primera solución, sino como la segunda.
Los módulos de Terraform u OpenTofu que describen tu entorno de AWS, GCP o Azure como código versionado resuelven un problema específico: el drift de entorno. Sin IaC, cada entorno acumula pequeñas diferencias no documentadas — un tamaño de instancia cambiado a mano aquí, una regla de security group agregada durante un incidente allá — hasta que staging deja de ser un predictor confiable del comportamiento en producción.
El objetivo práctico no es "automatizar el 100% de la infraestructura" desde el día uno. Es: ¿puedes destruir y reconstruir tu entorno de staging desde código en menos de una hora, sin necesitar conocimiento tribal? Si la respuesta es no, eso es lo siguiente que hay que arreglar — antes de Kubernetes, antes de multi-región, antes de cualquier cosa más ambiciosa.
Los entornos de vista previa cierran el ciclo que abre CI/CD
Con los despliegues automatizados y la infraestructura reproducible, la siguiente palanca es darle a cada pull request su propio entorno desechable. Este es el paso que los equipos se saltan porque parece un lujo, pero suele ser la automatización de mayor impacto después de las dos primeras.
Sin entornos de vista previa, la pregunta "¿esto realmente funciona?" se responde en staging, que es compartido, lo que significa que los cambios de cada ingeniero chocan con los de todos los demás. El QA se convierte en una cola. Los bugs se descubren tarde, después de que varios cambios se han apilado unos sobre otros, lo que los hace costosos de aislar. Los entornos de vista previa — creados por cada PR y eliminados al hacer merge — convierten esa cola de nuevo en pruebas paralelas e independientes. Los equipos que agregan esto después de arreglar el pipeline de despliegue generalmente ven que el tiempo entre revisión y merge mejora, porque los revisores pueden hacer clic en un enlace y ver el cambio real funcionando, en lugar de leer un diff y confiar en que funcionará.
Qué automatizar al final, no al principio
La entrega progresiva — canary releases, feature flags, rollback automático ante picos en la tasa de errores — es real y valiosa, pero es una inversión de etapa posterior. Resuelve el problema de "cómo lanzamos de forma segura al tráfico de producción", algo que solo importa una vez que lanzar a producción ya es confiable y aburrido. Los equipos que construyen infraestructura de canary antes de tener un CI/CD funcionando están automatizando el riesgo equivocado; la lógica de reparto de tráfico no ayuda si el despliegue subyacente todavía depende de que alguien ejecute los comandos correctos en el orden correcto.
Kubernetes cae en la misma categoría tardía para la mayoría de los equipos en crecimiento. Resuelve problemas reales — autoescalado, aislamiento de recursos, servicios autorreparables — pero añade una superficie operativa real: manifiestos, Helm charts, actualizaciones de clúster, RBAC. Los equipos de menos de unos 20 ingenieros que corren un puñado de servicios normalmente están mejor servidos con una plataforma más simple (ECS, Cloud Run, un PaaS gestionado) con un CI/CD sólido por delante. Muévete a Kubernetes cuando tengas suficientes servicios como para que el problema de orquestación sea real, no porque sea el siguiente paso esperado.
Una secuencia realista, y lo que cuesta
Para un equipo de 15-25 ingenieros que viene de despliegues manuales o semimanuales, una secuencia como esta suele funcionar: primero, un pipeline de CI/CD con pruebas automatizadas y rollback de un clic (típicamente 2–4 semanas); segundo, infrastructure-as-code para los entornos principales (otras 3–5 semanas, dependiendo de cuánto drift se haya acumulado ya); luego entornos de vista previa y monitoreo/alertas por encima. Una configuración de CI/CD por sí sola típicamente arranca desde $8,000; la secuencia completa — CI/CD más infrastructure-as-code más entornos de vista previa — típicamente arranca desde $25,000+ dependiendo de cuántos servicios y entornos entren en el alcance — y es un despliegue por etapas que nuestro equipo de cloud y DevOps dimensiona etapa por etapa, en lugar de tratarlo como una reconstrucción de plataforma abierta e indefinida.
El error que hay que evitar es tratar esto como un solo proyecto grande de infraestructura con una única fecha de lanzamiento. Cada etapa debe entregarse de forma independiente y empezar a dar resultados de inmediato — un pipeline de CI/CD funcionando ya tiene valor por sí solo, incluso antes de que exista Terraform para respaldarlo.
La conclusión
Cuando los despliegues manuales empiezan a fallar, la solución no es "conseguir más herramientas de DevOps". Es secuenciación: primero el pipeline, segundo la infraestructura reproducible, tercero los entornos de vista previa, y la entrega progresiva y la orquestación solo una vez que lo básico ya es aburrido. Los equipos que automatizan en este orden arreglan sus peores incidentes en el primer mes. Los equipos que empiezan con la herramienta más sofisticada de la lista suelen pasar un trimestre entero construyendo infraestructura para un proceso de despliegue que, en el fondo, sigue siendo fundamentalmente manual.
