Estrategias de ramificación y fusión

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

La complicación proviene del hecho de que ejecutaremos múltiples proyectos, todos con diferentes cambios de código y diferentes dates de lanzamiento, pero aproximadamente las mismas dates 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.

Este es el mejor patrón de control de fuente 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 en twigs de desarrollo, y las fusiones regulares (después de que el código ha sido probado) deben volver al tronco (Imagen 1), pero el model también permite remendar la fuente mientras está en desarrollo (Imagen 2). Definitivamente recomiendo leer la publicación en su totalidad, para comprender completamente.

Cuadro grande

  Pic 1 

Parchado

  Pic 2 

Editar: Las imágenes son definitivamente confusas sin palabras. Podría explicarlo, pero básicamente estaría copyndo al autor original. Habiendo dicho eso, probablemente debería haber seleccionado una mejor image para describir el process de fusión, así que espero que esto ayude. Aun así, recomendaría leer la publicación: texto alternativo

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

El tronco es tu 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.

Release es una asociación uno a muchos con trunk. Hay un tronco pero muchos lanzamientos que se derivan del tronco. Las versiones generalmente comienzan con una twig del tronco 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. A continuación, bifurca el tronco, le da una label (por ejemplo, la versión 1.6 es nuestra versión más reciente), crea y envía la versión 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.

Luego comienzas el ciclo de testing en tu twig de lanzamiento. Cuando se han llevado a cabo suficientes testings, se aplican correcciones de errores a la twig de liberación, se fusionan de nuevo con el tronco (para garantizar que las correcciones de errores se lleven a cabo) y luego se vuelve a lanzar una compilation de la twig. 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 twig en cuestión.

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

Con esta técnica puede implementar soluciones usando su tecnología para una variedad de clientes que requieren diferentes niveles de service (empezando por la less primero), puede aislar sus implementaciones existentes del nuevo código "peligroso" en el enlace troncal y el peor escenario de fusión es uno twig.

Mi primera recomendación sería leer el CÓMO de control de fuente de Eric Sink, específicamente los capítulos de combinación de sucursales y sucursales .

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 twigs de MAIN y se fusionan cuando Iteration / Feature está list para promocionarse más allá del entorno DEV. También tenemos versiones de TFS configuradas desde la twig DEV / Iteration y la twig MAIN.

Nuestro contenedor RELEASE contiene versiones numeradas (similar al contenedor de "tags" utilizado en muchos repositorys de Subversion). Simplemente tomamos una twig de MAIN cada vez. Me gusta decir que estamos "cortando" una twig 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 ruta de actualización que debería mantener su historial de versiones, pero si no lo necesita, simplemente obtendría la última versión de VSS, la verificaría en TFS y archivaría el repository de VSS.

Un último consejo: familiariza a los miembros de tu equipo con el control de la fuente. Deben entender la bifurcación y la fusión o estarás atrapado haciendo un montón de trabajo de limpieza :).

¡Buena suerte!

El libro de subversión describe algunos patrones de ramificación comunes . Quizás también pueda aplicar estos a TFS.