¿Cómo puedo ramificar mi código de una manera que haga posible las pruebas sin contaminar la línea de base?

Question

Usando TFS, tenemos lo siguiente:

• Una línea de base principal
• Una rama de desarrollo para cada esfuerzo de desarrollo. Estos se fusionan de regreso a la línea de base.
• Una rama de lanzamiento que se crea con cada lanzamiento. Las correcciones de errores se hacen aquí, se liberan y se fusionan de nuevo a la línea de base.
• Usando estantes, podemos compartir el código en todas las ramas de desarrollo si es necesario sin contaminar la línea de base. Útil para revisiones de código.
• Cuando entregamos nuestros cambios de desarrollo a la línea de base, tenemos una compilación automatizada que comienza y coloca automáticamente nuestros cambios en el servidor de prueba.

El problema es que los analistas de negocios no pueden ver nuestros cambios hasta que estén en el servidor de prueba, y actualmente la única forma de obtener nuestros cambios en el servidor de prueba es verificarlos en la línea de base. Entonces, si los BA encuentran algo mal, el código, desafortunadamente, ya está en la línea de base y tendríamos que pasar por la molestia de retirarlo.

¿Hay alguna manera de cambiar nuestra estrategia o proceso de ramificación para obtener los ba lo que quieren ver sin contaminar nuestra línea de base?

Answer 1

Su estrategia de ramificación suena exactamente lo que decidimos en mi empresa. No creo que el problema sea con su estrategia de ramificación, creo que el problema es que debe verificar los cambios en la línea de base para aplicarlos al servidor de prueba.

En mi empresa, los cambios no se registran en la línea de base hasta que se promocionan y se ejecutan en producción. Las ramas de lanzamiento son las que se implementan en los servidores de prueba ... si se encuentran errores o el BAS quiere cambiar algo, no tenemos que pasar por el dolor de eliminar los cambios de la línea de base.

Sin embargo, si tiene muchas versiones concurrentes, esto puede convertirse en un dolor para fusionar todas las versiones juntas antes de trasladarlas a la producción, ya que no se fusiona en la línea de base hasta más tarde en el proceso. En mi empresa, tenemos un calendario de lanzamiento muy estricto e intentamos que solo sea un lanzamiento para la producción a la vez. Debido a esto, esperar para fusionar el lanzamiento en la línea de base hasta que el lanzamiento se haya promovido en producción no ha creado ningún problema para nosotros, ni trabajo extra hasta ahora ...

¿Con qué frecuencia realiza lanzamientos? ¿Podría implementar ramas de lanzamiento en sus servidores de prueba y hacer que la línea de base represente lo que se implementa actualmente en producción?

(Haría de esto un comentario, pero todavía estoy trabajando para ganar ese privilegio ...)

Answer 2

No preferiría este enfoque, sugeriría:

Una línea de base principal que contiene código estabilizado. El código se fusionará en esta rama a partir de la rama de la versión respectiva solo después de la versión exitosa.

Una rama de lanzamiento que se crea a partir de cada lanzamiento. Esta rama se utilizará para generar compilaciones de lanzamiento y se implementará para probar el entorno.

Una rama de desarrollo creada a partir de la rama de lanzamiento, se utilizará para los esfuerzos de desarrollo y se fusionará para lanzar cuando esté listo para dar mi compilación para probar.