El uso de feature branches en conjunto con pull-request es una práctica muy habitual en la actualidad, a pesar de que en general termina siendo un impedimento para implementar Continuous Delivery. Esto resulta en gran medida curioso porque mucha gente que utiliza feature branches y pull-request cree que hace Continuous Delivery.

Por definición Continuous Delivery implica Continuous Integración lo cual a su vez implica Trunk-Based Development, o sea: no hacer branches que duren más de un día. Siendo conceptualmente estrictos uno podría hacer feature-branches & pull-request y aún así hacer Continuous Delivery, pero entonces los branches y pull-request no deberían extenderse más de un 1 día, situación que no condice con lo que suele verse en la industria mayoritariamente en la actualidad.

Desde hace varios par de meses vengo trabajando con un equipo muy maduro en un sistema que ya está productivo hace años. Trabajan con una dinámica de feature-branches, pull-requests bloqueantes y puesta en producción al final de la iteración. Dado que la iteración dura 2 semanas, esta dinámica implica que todo ítem, por simple que sea, tardar 2 semanas en llegar a producción. A su vez esto provoca que cada release a producción sea bastante grande pues contiene todo el trabajo acumulado durante 2 semanas. Y obviamente, cuanto más grande, más riesgoso. En parte como consecuencia de esto cada release a producción implica un downtime del sistema lo que obliga notificar a los usuarios sobre el tiempo de downtime y al mismo tiempo obliga que el release se realice fuera del horario de oficina para así afectar lo menos posible a los usuarios.

Dado que a mi parecer el equipo está bien consolidado, cuenta con un interesante set de pruebas automatizadas, el producto está estable, hay un proceso formal de testing y release, considero que están en condiciones de transicionar a un esquema de Continuous Delivery y por ello la semana pasada le propuse hacer un experimento. La propuesta es identificar un par de items de backlog, de bajo riesgo, para liberarlos (ponerlos en producción) tan pronto estén listos. De esta forma se entrega valor al negocio más rápidamente y al mismo tiempo el release de fin de iteración es más pequeño y menos riesgoso.