Diseñando una Transición Segura Entre Dos Equipos de Desarrollo

Un producto con dependencia fuerte de un CMS para administrar contenido y estructura (onboarding, formularios, workflows), desarrollado en un monorepo por un equipo interno pequeño, con parte del backend en manos de un equipo externo dentro del ecosistema del cliente. Hacia 2024, el cliente empezó a armar su propio departamento de IT y quiso asumir progresivamente el mantenimiento del producto.

No alcanzaba con documentar el sistema y hacer un handoff. Un equipo nuevo, con poco contexto sobre el producto, tenía que empezar a contribuir directamente sobre el repositorio mientras nuestro equipo seguía desarrollando funcionalidades al mismo ritmo. Ambos equipos necesitaban trabajar en paralelo sin convertir cada cambio en un problema de coordinación.

Trabajé con el director de ingeniería en un sistema de clasificación por riesgo, con un modelo de semáforo, sobre el mismo tablero y el mismo repositorio. Los issues verdes eran cambios chicos y de bajo riesgo: el equipo nuevo los implementaba y mergeaba sin necesitar un review formal de nuestro lado. Los amarillos requerían más contexto o tenían un impacto más significativo: el equipo nuevo los implementaba, pero uno de nuestros desarrolladores participaba como reviewer y el PR tenía que incluir una explicación breve del cambio y su impacto esperado. Los rojos podían comprometer la integridad de la plataforma o requerían conocimiento profundo de la arquitectura: esos se derivaban directo a nuestro equipo. La idea no era impedir que el equipo nuevo tocara el código. Era que pudieran tocarlo de forma segura.

Creamos una rama de maintenance que convivía con el flujo principal de desarrollo. Los cambios de mantenimiento seguían su propio flujo de integración y validación mientras el desarrollo de nuevas funcionalidades continuaba por su camino, con sincronizaciones automáticas entre ramas para reducir la coordinación manual. Esto importaba especialmente por la dependencia fuerte del producto de datos estructurados y configuración administrados desde el CMS: agregar o eliminar un campo, modificar un formulario, cambiar un workflow o actualizar un modelo de contenido podía tener consecuencias que iban mucho más allá del cambio puntual en el código. Con varios equipos tocando el mismo producto, necesitábamos reducir al máximo las situaciones donde alguien tuviera que preguntarse qué había cambiado, dónde, y qué más podía afectar.

Armé infraestructura de desarrollo alrededor de Docker y GitLab CI/CD: cada vez que se creaba una rama, el pipeline levantaba un entorno aislado con una instancia de frontend, una de backend y una base de datos basada en una copia del entorno de desarrollo. En vez de pedirle a QA que reprodujera un escenario localmente, le entregábamos directamente un entorno de preview: un desarrollador trabajaba en su rama, la desplegaba en su propio entorno, y QA validaba el flujo completo con una base de datos representativa, sin tocar el entorno compartido. Cuando el trabajo dejaba de ser necesario, el entorno se descartaba sin afectar al resto del equipo. Conceptualmente es el mismo enfoque que después popularizaron los preview deployments de plataformas como Vercel, aplicado a una arquitectura con frontend, backend y base de datos.

El handoff se volvió una transición progresiva en vez de un salto abrupto: el equipo nuevo empezó a contribuir directo al monorepo y a asumir mantenimiento, mientras nuestro equipo seguía shippeando features y solo intervenía en los cambios de mayor riesgo arquitectónico. No lo resolvimos agregando reuniones ni haciendo que cada cambio pasara por nuestro equipo. La clasificación de cambios, el ownership progresivo, la sincronización de ramas, el CI/CD automatizado y los entornos de preview aislados permitieron que dos equipos contribuyeran sobre el mismo producto sin interferirse todo el tiempo, mientras el ownership estaba cambiando de manos.