Estrategia de ramificación para entorno de prueba

Comenzaremos un nuevo proyecto este mes. El proyecto durará 1 año y el despliegue de producción solo ocurrirá hacia el final del proyecto.

Haremos un desarrollo iterativo (1 mes por iteración), por lo que esto significará que eliminaremos las características 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. Troncal: todo el desarrollo se realizará en la troncal.
2. Rama de características: las ramas fuera del tronco se crearán según las necesidades para el desarrollo de características grandes que podrían romperse si se realizan en el tronco
3. QA Release Branches: al final de cada iteración, se creará una rama de trunk. Esta rama (que incluye un número de versión) se lanzará al entorno de prueba. Todos los errores críticos y de bloqueo encontrados en esta versión se corregirán en esta rama y las correcciones tendrán que fusionarse con el tronco. Los errores no críticos / triviales no se abordarán en la rama de lanzamiento de QA y solo se corregirán en el tronco ya que la rama de lanzamiento de QA se desechará después del final de la siguiente iteración donde se creará una nueva rama de lanzamiento fuera del tronco.
4. Rama de producción: esta será la última rama de lanzamiento 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 con el tronco.

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

Estamos usando SVN.

Tu estrategia de ramificación me parece muy buena. He hecho la misma estrategia en el pasado y funciona bien. Dibuje en una pizarra y haga que todos sus desarrolladores lo entiendan para que las personas hagan el trabajo correcto en la rama correcta. Enseñe y explique a todos el comando switch y haga que todos verifiquen dos veces la rama en la que están trabajando. (O, alternativamente, solo mira el repositorio completo ... dependiendo del tamaño de tu código :) Recuerda ... ¡ svn revert es tu mejor amigo!

Personalmente, prefiero que una persona sea la persona de "fusión / sucursal" (con algunas personas de respaldo como reservas) para asegurar que todo se mantenga bajo control y sea consistente. Deja que esa persona se convierta en tu gurú SVN y estarás lejos.

Algunas otras sugerencias útiles:

• Fomentar actualizaciones frecuentes de SVN y confirmaciones de SVN. Todos los días son preferibles.
• Las fusiones cruzadas también se deben hacer todos los días o, alternativamente, siempre que se solucione un error. ¡Hazlos temprano y hazlos a menudo! (te volverás bueno en eso muy rápido).
• Obtenga una buena herramienta de diferencias: beyondcompare es as. El estándar tortoiseSVN uno ... no demasiado bueno.
• No registre cosas que cambian al compilar (como su directorio de salida)
• Intente limpiar su repositorio antes de comenzar a bifurcar (deshacerse de los archivos que no necesitan estar bajo control de versión, como bibliotecas externas, etc.). Cuanto más pequeño sea tu repositorio, mejor
• Los cambios en su rama de producción y ramas de control de calidad deben ser lo más pequeños y cortos posible: no comience a refactorizar el código allí, solo corrija el error.
• Asegúrese de ramificarse desde el nivel superior de su solución, y si tiene una base de datos, espero que haya programado todas sus cosas de base de datos (como procesos almacenados o disparadores)

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 la mitad de un gran cambio en el tronco que arruinó todas nuestras fusiones ... Fui bastante popular después de eso).

Parece una idea que podría no funcionar.

Quizás eche un vistazo a este enlace para obtener algo de inspiración: GitHub Flow Esta es la forma en que github está utilizando su sistema de versiones. A pesar de que usan git en lugar de svn, argumentaría que las ideas detrás de sus decisiones serán válidas.

Las (más importantes) partes de esta publicación de blog con respecto al control de versiones:

• master / trunk es desplegable o, aún mejor, desplegado
• el desarrollo ocurre solo en ramas
• la fusión ocurre solo después de la revisión (tal vez pueda colocar el control de calidad aquí)

De esta manera obtienes estabilidad. Déjame explicarte por qué. Necesitas alguna base para ramificarte. Ahora bien, si esta base no es lo mejor que podrías hacer y la instancia final de todo, entonces no tiene sentido hacerlo. Si se ramifica desde el tronco mientras otros trabajan en él, verá errores que introducen y que aún no se han encontrado o reparado. Por lo tanto, las probables pruebas de integración (y todo lo anterior) pueden fallar en usted aunque no sea la causa, aumentando drásticamente la cantidad de depuración y frustración.

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

Sugeriría seguir el camino de GitHub. Luego puede etiquetar qué versión envía a QA para tener una referencia al comunicarse. Aún mejor podría ser tener un control de calidad más estricto integrado en el ciclo de retroalimentación como se indicó anteriormente. Recomiendo encarecidamente usar un sistema de CI como Jenkins si aún no ha considerado usarlo. De esa forma, minimiza el tiempo de ida y vuelta entre el check-in y la retroalimentación, y puede aplicar reglas de codificación, ejecutar analizadores estáticos para la verificación de errores, etc.

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

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

Una ligera diferencia es que hacemos correcciones de QA previas al lanzamiento en el tronco porque nos impide tener que volver a fusionarnos y realmente no hemos tenido 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 su viabilidad depende de cuán estrechamente integrado esté QA con el equipo de desarrollo. Funciona bien para nosotros porque tenemos un equipo bastante integrado y porque tenemos un cronograma de iteración rápido. Tenemos una rama separada para cada versión para que podamos parchear el entorno de producción sin dejar de construir nuevas características en el tronco, pero eso no parece ser necesario para usted hasta más tarde, cuando comience a lanzar más allá del control de calidad.

Hay un par de recomendaciones adicionales que haría:

1. Fomentar visitas frecuentes. Esto es especialmente útil si tiene muchas personas desarrollándose en el tronco. Evitará que los desarrolladores se desincronicen 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 los desarrolladores deberían estar obteniendo de la troncal. Las confirmaciones frecuentes no deberían ser un problema dado que está tratando de aislar cambios importantes en las ramas de entidades.
2. Instituir un proceso de integración continua. Esto asegura además que no terminará con grandes dolores de cabeza de integración al final de una iteración, notifica si algo se ha roto y le permite automatizar más su control de calidad tanto a través de pruebas automatizadas de unidad / aceptación como potencialmente a través de análisis / código estático herramientas de inspección He encontrado que CI ofrece una gran "inversión por dinero" como una inversión en el proceso de gestión de la configuración. Nota, existe una tensión entre CI y el uso de ramas de características en gran medida porque las ramas esencialmente le permiten mantener el tronco limpio, pasar sus pruebas en CI, pero aún crear conflictos / problemas en las ramas. Las fusiones frecuentes en el tronco pueden ayudar con esto, al igual que ejecutar CI en la rama y tirar del tronco con frecuencia, pero una proliferación de ramas comenzará a derrotar el proceso de CI ya sea al complicar su administración o simplemente ignorarlo en las ramas.

Según su estado:
su código reside en la troncal
Para cada característica / mejora importante - corta una rama de la troncal - desarrolle y luego proporcione a QA para probar
Todos los errores importantes e importantes se corrigen en esta
'troncal QA' 'el código de esta rama de regreso al tronco

Esto suena bastante bien para mí.
Hemos estado ramificándonos, fusionándonos y trunkingando regularmente en SVN usando eclipse svn plugin o tortuga.
Me parece bien

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 una vez en lugar de arreglarlos en el tronco como se encuentran .

Si corrige 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 QA. (Hablo por experiencia donde el más pequeño de los pequeños errores puede tener un efecto secundario que causa un gran dolor en otros lugares)

Una mejora potencial que podría mencionar es hacer el desarrollo de características en una rama, es decir, mover el trabajo que generalmente hace en el tronco a una rama dedicada. Entonces, el tronco solo tendrá fusiones comprometidas, lo que puede ayudar a rastrear los cambios que se hayan completado.

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

El proyecto durará 1 año y el despliegue de producción solo ocurrirá hacia el final del proyecto.

Realmente, realmente recomiendo que se implemente en un entorno similar a la producción con la mayor frecuencia posible, idealmente todos los días. Dejar la llamada 'productización' al final del proyecto generalmente genera problemas imprevistos. Los antipatrones aquí son 'integración tardía' y 'despliegue de producción tardía'.

1 mes por iteración

Un mes es un latido de iteración muy largo, y pocos desarrolladores podrán recordar claramente en qué estaban trabajando al comienzo de la iteración. Recomiendo ir para 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 . Idealmente, use las funciones de alternancia y ramificación por abstracción en su lugar. La ramificación de funciones tiende a generar 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 usa las funciones de seguimiento de fusión de v1.5 y versiones posteriores. Te recomiendo que cambies a Git, nunca mirarás hacia 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 de Git, pero ahora estoy 'vendido'. Las únicas cosas que usaría Svn para más de Git son para almacenar archivos binarios (¡si es realmente necesario!) Y para cosas como RANCID que tienen el control completo del repositorio. Para el control del código fuente, Git supera a Subversion cada vez.

Recientemente escribí sobre el trabajo que he realizado para liberar desde troncal / línea principal / maestro y evitar ramas de características, lo que podría brindarle algo más de 'reflexión': Saliendo de la plataforma: ramificación y liberación para subsistemas independientes

Además, lea algunas publicaciones en el sitio de Martin Fowler, como ContinuousIntegration , FeatureBranch y BranchByAbstraction .

Finalmente, compre una copia de Continuous Delivery de Jez Humble y David Farley y siga las recomendaciones: es un libro enormemente valioso, y cada desarrollador debe tener una copia. He encontrado útil imprimir las páginas de Contenido y ponerlas en la pared para seguir el progreso :) Incluso si no tiene la intención de entregar continuamente, muchas de las prácticas en este libro son realmente saludables y vitales para la entrega exitosa de software hoy.

Espero que esto ayude.

METRO