Estrategia de ramificación para el entorno de prueba

8

Comenzaremos un nuevo proyecto este mes. El proyecto será de 1 año y la implementación de la producción solo se realizará hacia el final del proyecto.

Haremos un desarrollo iterativo (1 mes por iteración), por lo que esto significa que dejaremos las funciones en el entorno de prueba al final de cada iteración para las pruebas de control de calidad.

Nuestra estrategia de ramificación es:

  1. Tronco: todo el desarrollo sucederá en el tronco.
  2. Rama de funciones: las ramas fuera del troncal se crearán según la necesidad del desarrollo de funciones de gran tamaño que podrían romperse si se hacen en el troncal
  3. QA Release Branches: al final de cada iteración, se creará una rama del tronco. Esta rama (que incluye un número de versión) se lanzará al entorno de prueba. Todos los errores críticos y de bloqueo que se encuentran en esta versión se solucionarán en esta rama y las correcciones deberán fusionarse con el tronco. Los errores no críticos / triviales no se tratarán en la rama de liberación de control de calidad y solo se solucionarán en el enlace troncal, ya que la rama de liberación de control de calidad se tirará después del final de la próxima iteración donde se creará una nueva rama de lanzamiento fuera del enlace. / li>
  4. Rama de producción: esta será la última rama de liberación de control de calidad al final del proyecto. Esto se etiquetará y todas las correcciones de errores de producción estarán en esta rama y se fusionarán en el tronco.

¿Es esta una estrategia de bifurcación correcta? ¿Hay algo más que no hayamos considerado?

Estamos usando SVN.

    
pregunta rro 09.10.2013 - 03:49

6 respuestas

2

Tu estrategia de ramificación se ve muy bien para mí. He hecho la misma estrategia en el pasado y funciona bien. Dibújalo en una pizarra y haz que todos tus desarrolladores lo entiendan para que la gente haga el trabajo correcto en la rama correcta. Enseñe y explique a todos el comando de cambio y haga que todos vuelvan a comprobar la rama en la que están trabajando. (O, alternativamente, simplemente revisa todo el repositorio ... dependiendo del tamaño de tu código :) ¡Recuerda ... svn revert es tu mejor amigo!

Personalmente, prefiero que una persona sea la persona "fusionada / ramificada" (con algunas personas de reserva como reserva) para garantizar que todo se mantenga bajo control y sea coherente. Deja que esa persona se convierta en tu gurú de SVN y estarás lejos.

Algunos otros consejos útiles:

  • Fomente actualizaciones frecuentes de SVN y confirmaciones de SVN. Todos los días es preferible.
  • Las combinaciones de ramas cruzadas también deben hacerse todos los días, o alternativamente, cuando se solucione un error. ¡Hazlas temprano y hazlas a menudo! (lo harás bien rápido).
  • Obtenga una buena herramienta de diferencias: beyondcompare is as. El estándar tortoiseSVN uno ... no es demasiado bueno.
  • No compruebe las cosas que cambian en la compilación (como su directorio de salida)
  • Intente limpiar su repositorio antes de comenzar a bifurcar (elimine los archivos que no necesitan estar bajo el control de versiones, como bibliotecas externas, etc.). Cuanto menor sea tu repo, mejor
  • Los cambios en su rama de producción y en las de control de calidad deben ser lo más cortos y cortos posible. No comience a refactorizar el código allí, solo corrija el error.
  • Asegúrese de que se bifurca desde el nivel superior de su solución, y si tiene una base de datos, espero que haya hecho una secuencia de comandos de todas sus bases de datos (como procesos almacenados o activadores)

También diga a las personas que no muevan las carpetas a menos que sea estrictamente necesario. Esto hará que su fusión sea mucho más fácil :) (No haga lo que hice, inicie una reestructuración masiva de directorios a mitad de camino a través de un enorme cambio en el troncal que arruinó todas nuestras fusiones ... después de eso fui bastante popular). / p>     

respondido por el Rocklan 15.10.2013 - 03:21
2

Parece una idea en la que podría no funcionar

Tal vez vea este enlace para inspirarse: GitHub Flow Este es el camino github está utilizando su versión del sistema. A pesar de que usan git en lugar de svn, diría que las ideas detrás de sus decisiones se mantendrán de todos modos.

Las (imho) partes más importantes de esta publicación de blog con respecto a las versiones:

  • master / trunk es desplegable o, incluso mejor, implementado
  • el desarrollo ocurre solo en las sucursales
  • la fusión se produce solo después de la revisión (quizás pueda colocar el control de calidad aquí)

De esta manera obtienes estabilidad. Déjame explicarte por qué. Necesitas un poco de base para ramificar. Ahora bien, si esta base no es lo mejor que puedes hacer y la última instancia de todo, entonces realmente no tiene sentido hacerlo. Si se bifurca del tronco mientras otros trabajan en él, verá errores que introducen y que aún no han sido encontrados o solucionados. Por lo tanto, es probable que las pruebas de integración (y cualquier otra cosa anterior) te fallen, aunque no seas la causa, lo que aumenta drásticamente la cantidad de depuración y frustración.

Además, tendrá mucho trabajo manteniendo sincronizados sus 3 ramas (troncal, control de calidad, producción). Esto probablemente llevará a la confusión. Casi puedo garantizarle que perderá la pista en algún momento si no hace cumplir esto con la automatización.

Yo sugeriría ir por el mismo camino que GitHub. Luego puede etiquetar la versión que envía a QA para tener una referencia cuando se comunique. Incluso mejor podría tener QA integrado más estrechamente en el ciclo de retroalimentación como se indicó anteriormente. Le sugiero encarecidamente que utilice un sistema de CI como Jenkins si aún no ha considerado usarlo. De esa manera, minimiza el tiempo de ida y vuelta entre el registro y la retroalimentación y puede hacer cumplir las reglas de codificación, ejecutar analizadores estáticos para la comprobación de errores, etc.

Descargo de responsabilidad: El flujo de git funciona solo si no desea corregir errores sin introducir nuevas funciones. Si desea hacer esto, su enfoque podría ser más adecuado.

    
respondido por el TheMorph 15.10.2013 - 03:50
2

Tu estrategia de ramificación me parece bastante razonable. Hemos seguido una estrategia similar en mi empresa y ha funcionado bien con nosotros.

Una pequeña diferencia es que realizamos correcciones de QA previas al lanzamiento en el troncal porque evita que tengamos que volver a unirnos y no hemos tenido realmente ningún problema con el desarrollo de nuevas funciones al corregir defectos. Esto le da a QA un poco más de un objetivo móvil en términos de lo que están probando, por lo que la forma de hacerlo depende de qué tan integrado está el QA con el equipo de desarrollo. Funciona bien para nosotros porque tenemos un equipo bastante integrado y porque estamos en un programa de iteración rápido. Tenemos una rama independiente para cada versión, por lo que podemos parchear el entorno de producción mientras seguimos creando nuevas funciones en el troncal, pero parece que no será necesario para usted hasta más adelante, cuando comience a liberar más allá del control de calidad.

Hay un par de recomendaciones adicionales que haría:

  1. Fomente los controles frecuentes. Esto es especialmente útil si tiene muchas personas desarrollando en el maletero. Evitará que los desarrolladores pierdan la sincronización con lo que otros están haciendo y reducirá la posibilidad de conflictos. Asegúrese de que haya una guía explícita sobre cuándo está bien comprometerse y con qué frecuencia deben obtener los desarrolladores desde el tronco. Las confirmaciones frecuentes no deberían ser un problema, ya que está tratando de aislar los cambios de última hora en las ramas de características.
  2. Instale un proceso de integración continuo. Esto asegura que no terminará con grandes dolores de cabeza de integración al final de una iteración, notificará si algo se ha roto y automatizará más su QA a través de pruebas automatizadas de unidad / aceptación y potencialmente a través de herramientas de análisis estático / inspección de códigos. He descubierto que CI proporciona una gran inversión para el proceso de gestión de la configuración. Nota , existe una tensión entre los elementos de configuración y el uso intensivo de las ramas de características porque las ramas esencialmente le permiten mantener limpio el tronco, pasar sus pruebas en el centro de datos, pero aún crear conflictos / problemas en las ramas. La combinación frecuente de nuevo en el tronco puede ayudar con esto, al igual que la ejecución de CI en la rama y la extracción del tronco con frecuencia, pero una proliferación de ramas comenzará a anular el proceso de CI ya sea complicando su administración o simplemente ignorándolo en las ramas.
respondido por el DemetriKots 14.10.2013 - 16:10
0

De lo que afirmas:
Tu código reside en el maletero
Para cada característica principal / mejora, usted corta una rama de un tronco, desarrolla y luego proporciona un control de calidad para probar
Todos los errores importantes e importantes se solucionan en esta 'rama de control de calidad'
Publique el QA que 'trunce' el código de esta rama nuevamente al troncal

Esto me parece una buena estrategia.
hemos estado bifurcándonos, fusionándonos y trunking en SVN con el complemento eclipse svn o tortuga
Me parece bien

    
respondido por el akila 14.10.2013 - 04:15
0

Suena bien, me preocuparía que la rama de control de calidad tenga una vida relativamente corta, y haría todas las correcciones relacionadas con esa versión en esa rama para que se fusionen con el tronco de 1 vez en lugar de fijarlas en el tronco como se encuentran.

Si arreglas los errores triviales en la rama de control de calidad, los evaluadores pueden verlos y marcarlos rápidamente. Supongo que obtienen compilaciones diarias / semanales de la rama de control de calidad, por lo que los errores triviales no deberían consumir mucho tiempo si se realizan en control de calidad. (Hablo por experiencia donde el más pequeño de los pequeños bichos puede tener un efecto en cadena que causa un gran dolor en otros lugares)

Una mejora potencial que podría mencionar es realizar el desarrollo de características en una sucursal, es decir, mover el trabajo que normalmente hace en el troncal a una sucursal dedicada. Entonces, el enlace troncal solo tendrá combinaciones comprometidas, lo que puede ayudar a rastrear los cambios que se completaron.

    
respondido por el gbjbaanb 14.10.2013 - 15:00
0

Menciona varias cosas que pueden aumentar la incomodidad y reducir las posibilidades de éxito para su proyecto:

  

El proyecto será de 1 año y la implementación de la producción solo ocurrirá   hacia el final del proyecto.

Realmente, realmente recomiendo que se implemente en un entorno de producción tan a menudo como sea posible, idealmente todos los días. Dejar la llamada 'producción' al final del proyecto generalmente resulta en problemas imprevistos. Los antipatrones aquí son 'integración tardía' y 'implementación tardía de la producción'.

  

1 mes por iteración

Un mes es un latido muy largo de iteración, y pocos desarrolladores podrán recordar claramente en qué estaban trabajando al inicio de la iteración. Recomiendo ir a las iteraciones de 2 semanas, entregando en lotes más pequeños. Anti-patrones: 'tamaños de lotes grandes', 'tiempo de ciclo largo'.

  

Rama de funciones

Probablemente debería evitar las ramas de características, a menos que también use ramas de integración . Lo ideal es utilizar alternancia de características y ramificación por abstracción en su lugar. La ramificación de características tiende a conducir a problemas inesperados de integración tardía. Anti-patrón: 'integración tardía'.

  

Estamos usando SVN.

La fusión es bastante dolorosa en Subversion, incluso si usas las funciones de seguimiento de combinación de v1.5 y posteriores. Te recomiendo que cambies a Git, nunca mirarás atrás. La fusión con Git es indolora en comparación con Svn. Usé Subversion durante muchos años, y al principio era escéptico con respecto a Git, pero ahora estoy "vendido". Las únicas cosas que usaría Svn para sobre Git son para almacenar archivos binarios (¡si es realmente necesario!) Y para cosas como RANCID Los cuales están en completo control del repositorio. Para el control del código fuente, Git vence a Subversion cada vez.

Hace poco escribí sobre el trabajo que he hecho al liberar desde trunk / mainline / master y evitar las ramas principales, lo que podría darte algo más de "alimento para el pensamiento": Abandonando la plataforma - Bifurcando y liberando para Independiente Subsistemas

También, lea algunas publicaciones en el sitio de Martin Fowler, como ContinuousIntegration , FeatureBranch , y BranchByAbstraction .

Finalmente, compre una copia de Entrega continua por Jez Humble y David Farley y siga las recomendaciones: es un libro sumamente valioso y cada desarrollador debe tener una copia. Me ha resultado útil imprimir las páginas de Contenidos y colocarlas en la pared para hacer un seguimiento del progreso :) Incluso si no tiene la intención de realizar la entrega de manera continua, muchas de las prácticas de este libro son realmente saludables y vitales para la entrega exitosa del software. hoy.

Espero que esto ayude.

M

    
respondido por el Matthew Skelton 17.10.2013 - 00:56

Lea otras preguntas en las etiquetas