version control - team - Estrategias de ramificación y fusión
version control team foundation server (4)
Se me ha encomendado crear una estrategia para ramificar, fusionar y liberar en los próximos 6 meses.
La complicación viene del hecho de que ejecutaremos múltiples proyectos, todos con diferentes cambios de código y diferentes fechas de lanzamiento, pero aproximadamente las mismas fechas de inicio de desarrollo.
Actualmente estamos utilizando VSS para la administración de código, pero estamos conscientes de que probablemente causará algunos problemas y migrará a TFS antes de que comience el nuevo desarrollo.
¿Qué estrategias debo emplear y qué cosas debo considerar antes de establecer un plan?
Lo siento si esto es vago, no dude en hacer preguntas y actualizaré con más información si es necesario.
El libro de subversión describe algunos patrones de ramificación comunes . Tal vez usted también puede aplicar estos a TFS.
Este es el mejor patrón de control de fuente que he encontrado. Enfatiza la importancia de dejar el tronco libre de cualquier basura (no basura en el tronco). El desarrollo se debe hacer en las ramas de desarrollo, y las fusiones regulares (después de que se haya probado el código) se deben volver a colocar en el tronco (Imagen 1), pero el modelo también permite parchar la fuente mientras aún está en desarrollo (Imagen 2). Definitivamente recomiendo leer el post en su totalidad, para entender completamente.
Pic 1
Pic 2
Edit: Las imágenes son definitivamente confusas 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 recomendaría leer el post, sin embargo:
La forma más sencilla 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 del "tronco inestable, rama estable".
Tronco es su principal fuente. Este contiene el código "más reciente y el más grande" y está orientado hacia el futuro. Generalmente no siempre es estable.
El lanzamiento es una asociación de uno a muchos con el tronco. Hay un tronco pero muchos lanzamientos que se derivan del tronco. Las versiones generalmente comienzan con una rama del troncal una vez que se ha alcanzado un hito de funcionalidad en particular, por lo que las "únicas" cosas que quedan para una implementación en particular deberían ser solo correcciones de errores. Luego bifurcas el tronco, le asignas una etiqueta (p. Ej., La versión 1.6 es nuestra última versión actual), creas y envías la versión a QA. También aumentamos el número de versión (generalmente el número menor) de la troncal en este punto para asegurarnos de que no tenemos dos lanzamientos con el mismo número.
Entonces comienzas el ciclo de prueba en tu rama de lanzamiento. Cuando se hayan realizado suficientes pruebas, se aplican correcciones de errores a la rama de lanzamiento, se combinan de nuevo en el tronco (¡para garantizar que las correcciones de errores se realicen!) Y luego se vuelve a lanzar una versión de la rama. Este ciclo con control de calidad continúa hasta que ambos estén contentos y el lanzamiento finalmente se entregue a los clientes. Cualquier informe de errores de los clientes que sea preciso (es decir, ¡es un error!) Inicia otro ciclo de control de calidad con la sucursal en cuestión.
A medida que crea versiones futuras, también es una buena idea tratar de mover a los clientes más antiguos a sucursales más nuevas para reducir la cantidad potencial de sucursales en las que podría tener que realizar una revisión de parches para corregir un error.
Usando esta técnica, puede implementar soluciones usando su tecnología a una variedad de clientes que requieren diferentes niveles de servicio (empezando por lo menos primero), puede aislar sus implementaciones existentes del nuevo código "peligroso" en el troncal y el peor escenario de combinación es uno rama.
Mi primera recomendación sería leer el CÓMO de control de fuente de Eric Sink, específicamente los capítulos de las branches y la combinación de branches .
Tenemos 3 contenedores: DEV, MAIN y RELEASE para nuestro trabajo. MAIN contiene todo nuestro código "listo para su lanzamiento" y tendemos a considerarlo como "básicamente estable". DEV / Iteration (o DEV / Feature, o DEV / RiskyFeatureThatMightBreakSomeoneElse) son ramas de MAIN y se combinan cuando Iteration / Feature está listo para ascender más allá del entorno DEV. También tenemos configuraciones TFS configuradas desde la rama DEV / Iteración y la rama MAIN.
Nuestro contenedor RELEASE contiene publicaciones 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 se haya completado 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, solo obtendría la última versión de VSS, la registraría en TFS y archivaría el repositorio de VSS.
Un último consejo: familiarice a los miembros de su equipo con el control de código fuente. Deben entender las ramificaciones y las combinaciones, o se quedará atascado haciendo mucho trabajo de limpieza :).
¡Buena suerte!