¿Cómo evitar el branchageddon con grandes organizaciones?

10

¿Cómo se evita una situación de ramificación cuando se trabaja con grandes organizaciones?

Trabajamos con varias organizaciones financieras grandes cuyo enfoque es no llevar actualizaciones al software, sino solo parches de seguridad altos / críticos y funcionalidad personalizada. Estas organizaciones solo tomarán parches y versiones personalizadas entre las principales actualizaciones. Las actualizaciones importantes pueden estar separadas por años y conllevar altos costos. Este enfoque hace que (la empresa de software) tenga una rama de nuestro código por cliente principal, lo que conlleva todos los costos e ineficiencias de la ramificación a largo plazo.

Mis preguntas a la comunidad son:

¿Ha experimentado enfoques similares de aceptación de actualizaciones por parte de sus clientes?
¿Qué sugerencias tiene para ayudar a trabajar con este enfoque?
¿Qué sugerencias tiene para ayudar a cambiar los enfoques de las organizaciones para tomar actualizaciones de software?

release process branch

— Mark Wheeler
fuente

Hola Mark, parece que tienes un dilema interesante. ¿Cómo gestiona el desarrollo de estas actualizaciones por cliente? ¿Los desarrolla de forma puntual para cada cliente o es algo que desarrolla y aplica a todos los clientes?

— PrestonM

Personalmente, podría buscar otro empleo en esta situación. Esto suena como un incidente de seguridad a la espera de que suceda ... Puedo decirte que para el proveedor de dispositivos para el que trabajé, tenían un error importante que se corrigió en una actualización a la que, según los informes, no podían acceder. Querían una solución personalizada. Nos negamos a construir uno y les dijimos que tenían que arreglar sus políticas comerciales; no íbamos a lanzar una revisión personalizada para un error que ya habíamos corregido solo para que pudieran evitar problemas políticos internos.

— James Shewey

Gestionamos las actualizaciones específicas del cliente personalizado a través de múltiples bifurcaciones de código y actualizaciones de seguridad de corrección cruzada para todas las bifurcaciones, y el código de bifurcación de reparación cruzada nuevamente en el tronco. A menudo, el cliente A no tomará las actualizaciones del cliente B en su sucursal, solo tomará sus propias actualizaciones y parches de seguridad. Esto se debe a un deseo de estabilidad en su rama y, por lo tanto, solo tienen que probar las actualizaciones relevantes para ellos. Toman actualizaciones troncales con menos frecuencia (es decir, meses a años) cuando están listas para ejecutar repeticiones de pruebas completas, lo que puede llevar meses completar. ¡Las pruebas automatizadas podrían ser la respuesta!

— Mark Wheeler

3

Como Michael mencionó, ofrezca una solución estándar basada en versiones / números de lanzamiento, con una vida útil razonablemente larga para su industria (tal vez entrelazada con una o más versiones intermedias de vida útil más corta, si tiene sentido para sus clientes típicos).

Ofrezca a sus clientes la opción de embarcarse en esta ruta de lanzamiento estándar, tal vez con un plazo de migración decente.

Si insisten en una estrategia de soporte de sucursal totalmente personalizada, simplemente cárgueles en consecuencia, para cubrir adecuadamente todos sus costos adicionales por ofrecer dicho soporte totalmente personalizado, solo tiene sentido comercial. Algunos clientes migrarán para reducir sus costos (lo que lo ayudará a reducir la cantidad de sucursales personalizadas), otros no.

La facturación de soporte variable, que crece progresivamente con la antigüedad de las versiones de lanzamiento desde las cuales se originan las sucursales personalizadas, también puede ser un incentivo para que los clientes migren a sucursales más nuevas más rápido, ayudando a cerrar más rápidamente las sucursales personalizadas más antiguas. Esto puede ayudar a reducir la cantidad de sucursales personalizadas por cliente, si tiene clientes que ejecutan simultáneamente varias versiones de su software.

Asegúrese de no caer en la trampa de realizar fusiones completas de ramales desde / hacia cualquiera de las ramas de lanzamiento (tanto estándar como personalizado), todos los cambios a ellos deben ser desarrollados individualmente o arreglos combinados seleccionados.

Debido a que cada una de estas ramas divergerá gradualmente entre sí, la cantidad de revisiones que requieren personalización / desarrollo individual crecerá exponencialmente (fallará la fusión simple de selección de cereza). Debe tener en cuenta el costo de desarrollo de estos.

Sin fusiones de sucursales (significativas) en la imagen, usted puede (y no puedo enfatizar su importancia lo suficiente) construir tuberías de CI / CD completamente automatizadas para estas sucursales, acompañado de un buen sistema de seguimiento / gestión de revisiones, lo que hace que la entrega de la revisión solo rutina (o casi).

— Dan Cornilescu
fuente

Dan: tan obvio y simple, pero tiene mucho sentido. El dinero hace girar el mundo y, a su vez, debería ayudarnos a compensarnos el costo de las sucursales de larga vida o alentar a los clientes a actualizarse y permanecer cerca del tronco. Gracias por tu buen consejo.

— Mark Wheeler

1

¿Tal vez si mantiene sucursales por versiones en lugar de por clientes, podría ayudar a reducir su número?

De lo contrario, la única forma de alejarse de él es poder alojar el software usted mismo y cambiar a un modelo SaaS en el que pueda mantener solo una versión del mismo.

— Michael Pereira
fuente

Desafortunadamente, nuestros clientes a menudo operan en entornos muy cerrados debido a los datos financieros con los que están trabajando, por lo que un modelo SaaS no sería aceptable.

— Mark Wheeler