Cuando se habla de DevOps, la imagen mental suele ser un equipo desplegando microservicios veinte veces al día. La realidad de la mayoría de las empresas es otra: una aplicación monolítica con años de historia, un servidor que nadie se atreve a reiniciar y despliegues que se hacen a mano un viernes con los dedos cruzados. Llevo años aplicando DevOps precisamente ahí, en el mundo brownfield, y os aseguro una cosa: es donde más se nota la diferencia.
Las ventajas: por qué merece la pena
- Despliegues repetibles: pasar de la copia manual de ficheros a un pipeline, aunque sea sencillo, elimina de golpe una categoría entera de errores, la de «se me olvidó un paso». El primer despliegue aburrido es una victoria enorme.
- Visibilidad real: añadir monitorización y logs centralizados a un sistema veterano suele destapar problemas que llevaban años ahí. Es como encender la luz en una habitación que solo conocías a tientas.
- Conocimiento documentado: automatizar obliga a escribir lo que antes vivía en la cabeza de una persona. Cada script es documentación ejecutable y un poco menos de dependencia del héroe de turno.
- Confianza para cambiar: con un camino de vuelta claro (rollback definido, backups probados), el equipo pierde el miedo a tocar el sistema. Esa confianza vale más que cualquier herramienta.
Los retos que nadie pone en la diapositiva
- No hay tests: automatizar el despliegue de algo que no puedes verificar da vértigo. A veces el primer paso de DevOps no es montar un pipeline, es escribir cuatro pruebas de humo.
- Entornos irreproducibles: el servidor de producción es un copo de nieve moldeado a mano durante años. Reconstruirlo desde cero es un ejercicio de arqueología que exige paciencia y muchas notas.
- Dependencias ocultas: ese cron que nadie recordaba, la integración por FTP con un proveedor, la base de datos compartida con otra aplicación… Aparecen siempre, y siempre en el peor momento.
- Resistencia cultural: quien lleva quince años operando el sistema a mano puede vivir la automatización como una amenaza. Sin llevar a esas personas contigo, el proyecto técnico fracasa aunque el pipeline sea perfecto.
Por dónde empezar sin romper nada
Mi receta, refinada a base de tropiezos: primero, todo al control de versiones, incluidos esos scripts sueltos y la configuración que vive en el servidor. Segundo, monitorización antes que automatización, porque necesitas saber qué es normal antes de cambiar nada. Tercero, un pipeline que al principio haga exactamente lo mismo que se hacía a mano, solo que de forma repetible:
stages:
- package
- deploy
package:
script:
- tar -czf release.tar.gz app/
deploy:
script:
- scp release.tar.gz servidor:/opt/miapp/releases/No es glamuroso, pero es honesto: replica el proceso actual, gana confianza y a partir de ahí introduce mejoras pequeñas y reversibles. Para la evolución del propio sistema, el patrón strangler fig (ir rodeando lo antiguo con piezas nuevas en lugar de reescribirlo de golpe) es tu mejor aliado. La gran reescritura casi siempre es una trampa: paraliza al equipo durante meses y entrega el valor al final, si es que llega. DevOps sobre legacy funciona justo al revés: valor pequeño, continuo y desde la primera semana.
Trabajar con sistemas heredados no da charlas virales ni queda espectacular en el CV, pero es donde el impacto se mide en algo muy valioso: noches tranquilas y viernes sin sudores fríos. Si estás en esa trinchera, no estás solo. ¿Cuál ha sido tu mayor batalla (o tu mayor victoria) llevando DevOps a un sistema legacy? Cuéntamelo en los comentarios 😊