Plataforma DevOps interna

Cómo empezó

Me incorporé a WITH Madrid como desarrollador full-stack a mediados de 2020, construyendo plataformas de datos para clientes con Django y Vue. Junto a ese trabajo, heredé la responsabilidad del sistema de despliegue basado en Ansible: el mecanismo que llevaba el código de las ramas de los desarrolladores a producción en todos los proyectos de la empresa.

El script en sí no era lento. El problema era todo lo que le rodeaba: cualquier desarrollador podía ejecutarlo desde su propia máquina, usando credenciales compartidas a todos los entornos. No había ningún registro central de quién había desplegado qué, cuándo ni por qué. Depurar un despliegue fallido implicaba preguntar a compañeros. Los rollbacks eran manuales y estresantes.

Funcionaba… hasta que no funcionaba, y cuando eso pasaba, era difícil saber por dónde empezar.

Hice la propuesta de reemplazarlo por completo.

La plataforma

El encargo de la empresa era directo: construir una plataforma interna de despliegue. Ese nombre, y el problema que implicaba, era en esencia la especificación completa. El alcance, el diseño, las prioridades: míos para definir.

Diseñé y construí desde cero, como única persona responsable de la plataforma, una solución que sacó los despliegues de los portátiles de los desarrolladores y los metió en un pipeline controlado y observable.

El núcleo del sistema:

• Una capa de orquestación en Python que coordinaba todos los pasos del ciclo de vida de un despliegue: build, test, publicación de imagen, despliegue y verificación de salud.
• GitHub Actions como punto de entrada — un push a la rama correcta disparaba el proceso automáticamente, con un rastro de auditoría completo en cada ejecución.
• Workflows containerizados con Docker para garantizar reproducibilidad total entre entornos de desarrollo, staging y producción.
• Configuración por proyecto y entorno que eliminaba lógica duplicada y permitía incorporar nuevos proyectos en minutos.
• Sin credenciales compartidas: cada entorno tenía sus propios controles de acceso, y ningún desarrollador necesitaba secretos de producción en su máquina. La configuración de cada proyecto se gestionaba de forma centralizada a través de una instancia de Hashicorp Vault: los ajustes se almacenaban de forma jerárquica, de modo que un feature branch sin configuración propia heredaba automáticamente la del entorno de develop. Producción tenía siempre su propio conjunto aislado.

Esto incluía los despliegues de la propia plataforma: cualquier actualización pasaba por el mismo pipeline que operaba para el resto de proyectos.

Paralelamente, mantuve y seguí mejorando el sistema Ansible legacy durante la transición, hasta que la nueva plataforma lo sustituyó completamente.

El resultado

• Más de 3.000 despliegues en los primeros seis meses de uso. Cada rama de funcionalidad tenía su propio entorno completamente aislado: una copia de la base de datos de desarrollo, independiente de cualquier otra rama y del sitio en producción. La rama de producción solo se tocaba cuando se creaba un tag de forma deliberada.
• Trazabilidad completa en cada despliegue: quién lo disparó, qué cambió, cuál fue el resultado.
• Los desarrolladores mantuvieron la autonomía de despliegue sin cargar con el riesgo operativo.
• Los rollbacks pasaron de ser un proceso manual y estresante a una sola acción.
• El conocimiento operativo dejó de estar en cabezas de personas y en portátiles individuales, y pasó a estar en la plataforma.

Además de construir el sistema, actué como mentor técnico y puente entre los equipos de desarrollo y operaciones, facilitando la adopción y resolviendo la fricción que siempre acompaña a cambiar cómo trabaja la gente.