Estrategias de ramificación y fusión

Question

Me han encomendado la tarea de idear una estrategia para la bifurcación, la fusión y la liberación en los próximos 6 meses.

La complicación proviene del hecho de que vamos a ejecutar varios proyectos, todos con diferentes cambios de código y fechas de lanzamiento diferentes, pero aproximadamente las mismas fechas de inicio de desarrollo.

En este momento estamos usando VSS para la administración de código, pero somos conscientes de que probablemente causará algunos problemas y migrará a TFS antes de que comience un nuevo desarrollo.

¿Qué estrategias debería emplear y qué cosas debería considerar antes de establecer un plan?

Disculpe si esto es vago, siéntase libre de hacer preguntas y lo actualizaré con más información si es necesario.

Answer 1

Este es el mejor source control pattern que he encontrado. Hace hincapié en la importancia de dejar el tronco libre de cualquier basura (no hay basura en el maletero). El desarrollo debe hacerse de ramas de desarrollo, y se funde regulares (después de que el código ha sido probado) debe ser hecha en el tronco (foto 1), pero el modelo también permite la fuente que se puede conectar, mientras que todavía en desarrollo (Fig 2). Definitivamente recomiendo leer la publicación en su totalidad, para comprender completamente.

  Pic 1

  Pic 2

Editar: Las imágenes son definitivamente confuso y sin palabras. Podría explicarlo, pero básicamente estaría copiando al autor original. Habiendo dicho eso, probablemente debería haber seleccionado una mejor imagen para describir el proceso de fusión, así que espero que esto ayude. Todavía recomiendo leer la publicación, sin embargo:

Answer 2

El libro de subversión describe some common branching patterns. Quizás también pueda aplicar estos a TFS.

Answer 3

Mi primera recomendación sería leer el Source Control HOWTO de Eric Sink, específicamente los capítulos branches y branch merge.

Tenemos 3 contenedores: DEV, MAIN y RELEASE para nuestro trabajo. MAIN contiene todo nuestro código "listo para lanzar" y tendemos a pensar que es "básicamente estable". DEV/Iteration (o DEV/Feature, o DEV/RiskyFeatureThatMightBreakSomeoneElse) son ramas de MAIN y se fusionan cuando Iteration/Feature está lista para promocionarse más allá del entorno DEV. También tenemos versiones de TFS configuradas desde la rama DEV/Iteration y la rama MAIN.

Nuestro contenedor RELEASE contiene versiones numeradas (similar al contenedor de "etiquetas" utilizado en muchos repositorios de Subversion). Simplemente tomamos una rama de MAIN cada vez. Me gusta decir que estamos "cortando" una rama RELEASE para indicar que esto no debería tener mucha actividad una vez que termine la fusión.

En cuanto a VSS-> TFS - Microsoft admite una upgrade path el cual debe mantener su historial de versiones, pero si no lo necesita la historia, me acaba de obtener la última versión de VSS, comprobarlo en TFS y archivar el repositorio de VSS.

Un consejo final: familiarice a los miembros de su equipo con el control de código fuente. Deben entender la bifurcación y la fusión o te quedarás atrapado haciendo un montón de trabajo de limpieza :).

¡Buena suerte!

Answer 4

La forma más simple y habitual en la que he visto el trabajo de bifurcación es en dos premisas. Tronco y liberación. Creo que esto se conoce como la filosofía "Tronco inestable, rama estable".

Troncal es su fuente principal. Este contiene el código "último y más grande" y está mirando hacia el futuro. Por lo general, no siempre es estable.

La versión es una asociación uno a muchos con el tronco. Hay un tronco pero muchos lanzamientos que se derivan del tronco. Las versiones generalmente comienzan con una rama de la troncal una vez que se ha alcanzado un hito de funcionalidad particular, por lo que las "únicas" cosas que quedan para una implementación en particular deberían ser correcciones de errores. Luego ramifica el tronco, le da una etiqueta (por ejemplo, 1.6 Release es nuestra versión más reciente), crea y envía el lanzamiento a QA.También empujamos el número de versión (generalmente el número menor) del tronco hacia arriba en este punto para garantizar que no tengamos dos lanzamientos con el mismo número.

entonces comienza el ciclo de pruebas en su rama de lanzamiento. Cuando la prueba ha sido suficiente perfomed aplicar correcciones de errores a la rama de lanzamiento, combinar éstos hasta el tronco (para asegurar la corrección de errores se llevan adelante!) Y luego volver a lanzar una versión de la rama. Este ciclo con control de calidad continúa hasta que ambos estén contentos y la versión finalmente se entregue al cliente (s). Cualquier informe de error del cliente que sea preciso (es decir, ¡es un error!) Iniciará otro ciclo de control de calidad con la rama en cuestión.

A medida que crea futuros lanzamientos, es una buena idea también tratar de mover a los clientes más antiguos a sucursales más nuevas para reducir el número posible de ramas en las que podría tener que aplicar una corrección de errores.

Usando esta técnica puede implementar soluciones usando su tecnología para una variedad de clientes que requieren diferentes niveles de servicio (empezando por el primero), puede aislar sus implementaciones existentes del nuevo código "peligroso" en el maletero y el peor fusionar escenario es una rama.