Trunk-Based Development: Entregando con Seguridad Todos los Dias

Antes de trunk-based development, nuestro proceso de release incluia un dia de merge que todos temiamos: ramas de funcionalidad que habian divergido de main por dos o tres semanas, conflictos de merge que tomaban horas en resolverse, y una probabilidad nada trivial de que el 'arreglo' de un conflicto rompiera silenciosamente otra cosa. Despues de movernos a trunk-based development en una plataforma de microservicios de produccion, ese modo de falla completo simplemente dejo de existir, porque nunca se permitio que nada divergiera de main el tiempo suficiente para crearlo.

La practica en si es simple de enunciar y exigente de sostener: cada ingeniero mergea cambios pequenos y completos directamente a main al menos una vez al dia, y nada vive en una rama de larga vida. Lo que la hace exigente es que requiere infraestructura de soporte en la que la mayoria de los equipos no invierten lo suficiente. Los feature flags son el mecanismo que desacopla mergear codigo de lanzar una funcionalidad: el trabajo sin terminar se mergea a main detras de un flag apagado, asi que 'mergeado' deja de significar 'en vivo para los usuarios', y una funcionalidad a medio construir nunca bloquea que se desplieguen los cambios de nadie mas.

Un pipeline de CI rapido y confiable es la otra pieza no negociable, y es la que los equipos mas seguido se saltan. Si el build toma cuarenta minutos, o falla intermitentemente por razones que no tienen que ver con el cambio real, los desarrolladores racionalmente empiezan a agrupar cambios para evitar correr el proceso mas veces de las necesarias, y agrupar cambios es exactamente el modo de falla que trunk-based development esta disenado para eliminar. Invertimos especificamente en confiabilidad de pruebas y cache de builds antes de pedirle al equipo que adoptara merges mas pequenos y frecuentes, porque pedir la practica sin la infraestructura solo produce frustracion.

Branch-by-abstraction es la tecnica que hace que trunk-based development funcione incluso para cambios estructurales grandes: en lugar de una rama de larga vida que reemplaza una implementacion vieja por una nueva, introduces una capa de abstraccion detras de la cual ambas implementaciones pueden coexistir, migras a los que la llaman de forma incremental detras de esa abstraccion, y eliminas la implementacion vieja solo una vez que nada depende de ella. Esto significa que incluso refactorizaciones sustanciales ocurren como una secuencia de cambios pequenos, mergeables y reversibles en lugar de una rama grande.

La recompensa se ve especificamente en la respuesta a incidentes: cuando cada cambio es pequeno, encontrar el commit que introdujo una regresion toma minutos en lugar de horas, revertirlo es una operacion limpia y unica en lugar de un rompecabezas de reversion parcial, y el modelo mental compartido del equipo sobre la base de codigo se mantiene actualizado porque nadie trabaja desde una foto de main de hace tres semanas.

Puntos Clave

• Los feature flags desacoplan mergear codigo de lanzar una funcionalidad, asi el trabajo sin terminar se entrega apagado.
• Un pipeline de CI rapido y confiable no es negociable: sin el, los equipos racionalmente agrupan cambios.
• Branch-by-abstraction hace que incluso refactorizaciones estructurales grandes ocurran en pasos pequenos y reversibles.
• Los merges pequenos y frecuentes hacen que revertir sea trivial y encontrar incidentes sea rapido.
• Todo el equipo mantiene un modelo mental compartido y actualizado de la base de codigo.