La empresa para la que trabajo está empezando a tener problemas con su modelo de ramificación actual y me preguntaba a qué diferentes tipos de estrategias de ramificación ha estado expuesta la comunidad.Estrategias de ramificación
¿Hay alguna buena para diferentes situaciones? ¿Qué usa tu empresa? ¿Cuáles son las ventajas y desventajas de ellos?
que había animo a leer la opinión de Eric Sink sobre el asunto:
Yo, como Eric, prefieren el estilo "carpeta" de ramificación que habla.
Eric dijo: "Cambios simples. Como mencioné anteriormente en mi escenario de" Eddie ", no ramifique para cada corrección o función de error". Pero con los nuevos SCM por ahí, esto ya no es cierto. Los chicos de SVN solían decir lo mismo hasta que implementaron una bifurcación adecuada ... Y la gente de GIT nunca dirá eso ... Pero normalmente las personas detrás de un cierto control de versiones dirán que lo que no pueden hacer no vale la pena hacerlo ...: - ( – pablo
Eric está revisando el CÓMO, y creo que incluso lo está convirtiendo en un libro. La popularidad de los sistemas como git y hg también es un tema en algunas de sus publicaciones de blog más recientes. –
Esto dependerá del sistema de control de versiones que esté utilizando. Cada VCS tiene diferentes enfoques para la bifurcación.
¿Qué VSC usas?
Mientras que el sistema de control de versiones podría determinar cómo vas sobre la ramificación, no necesariamente determina tu estrategia de ramificación. Para responder a tu pregunta, usamos subversión. –
No estoy seguro de que sea completamente cierto en la práctica. Git prácticamente fomenta la ramificación porque es una operación fácil y rápida y la fusión es relativamente sencillo. Es mucho más difícil en CVS. No hacer una sucursal porque es un trabajo difícil formaría parte de una estrategia de bifurcación. –
Actualmente contamos con una sucursal para mantenimiento continuo, una rama para "nuevas iniciativas" que solo significa "cosas que saldrán en algún momento en el futuro, no estamos seguros de cuándo". También ocasionalmente hemos tenido dos ramas de mantenimiento en marcha: una para proporcionar soluciones para lo que está actualmente en producción y otra que aún está en control de calidad.
La principal ventaja que hemos visto es la capacidad de reaccionar ante las solicitudes de los usuarios y las emergencias con mayor rapidez. Podemos hacer la corrección en la rama que está en producción y liberarla sin liberar nada extra que ya haya sido registrado.
La principal desventaja es que terminamos haciendo mucha fusión entre ramas, lo que aumenta la posibilidad de que algo se pierda o se fusione incorrectamente. Hasta ahora, eso no ha sido un problema, pero definitivamente es algo a tener en cuenta.
Antes de instituir esta política, generalmente hicimos todo el desarrollo en el tronco y solo ramificamos cuando lanzamos el código. Luego hicimos arreglos contra esa rama según sea necesario. Era más simple, pero no tan flexible.
La filosofía que seguimos en el trabajo es mantener el tronco en un estado donde pueda empujar en cualquier momento sin causar daños drásticos al sitio. Esto no quiere decir que el tronco siempre estará en perfecto estado. Por supuesto, habrá errores en él. Pero el punto es nunca, nunca dejarlo roto drásticamente.
Si tiene una función para agregar, bifurque. Un cambio de diseño, rama. Ha habido tantas veces que pensé: "oh, puedo hacer esto en el maletero, no me tomará tanto tiempo", y luego, 5 horas más tarde, cuando no puedo descifrar el error que está rompiendo las cosas. realmente deseé haberme ramificado.
Cuando mantiene la cajuela limpia, permite la oportunidad de aplicar rápidamente y eliminar las correcciones de errores. No tiene que preocuparse por el código roto que tiene que se ramificó convenientemente.
Para Subversion, estoy de acuerdo con el comentario de Ryan Duffield. El capítulo al que se refiere proporciona buenos análisis sobre qué sistema usar.
La razón por la que pregunté es que Perforce proporciona una forma completamente diferente de crear ramas desde SVN o CVS. Además, están todos los DVCS que le dan su propia filosofía a la bifurcación. Su estrategia de ramificación estaría dictada por qué herramienta (s) está (n) utilizando.
FYI, Svnmerge.py es una herramienta para ayudar a fusionar sucursales en SVN.Funciona muy bien siempre que lo use con frecuencia (cada 10-30) se compromete, de lo contrario, la herramienta puede confundirse.
Nos ramificamos cuando un lanzamiento está listo para el control de calidad final. Si se descubren problemas durante el proceso de control de calidad, los errores se corrigen en la sucursal, se validan y luego se fusionan en el enlace troncal. Una vez que la rama aprueba el control de calidad, lo etiquetamos como un lanzamiento. Las revisiones para esa versión también se realizan en la sucursal, se validan, se fusionan en la troncal y luego se etiquetan como una versión separada.
La estructura de carpetas se vería así (línea 1 de control de calidad, 2 lanzamientos de revisión, y el tronco):
/ramas
/REL-1.0
/etiquetas
/REL-1.0
/REL-1.0.1
/REL-1.0.2
/tronco
Aquí es el método que he utilizado en el pasado con buenos resultados:
/tronco - borde sangrante. Siguiente gran lanzamiento del código. Puede o no funcionar en un momento dado.
/branches/1.0, 1.1, etc. Ramas de mantenimiento estables del código. Se usa para corregir errores, estabilizar nuevos lanzamientos. Si es una sucursal de mantenimiento, debe compilar (si corresponde) y estar listo para QA/envío en cualquier momento. Si es una rama de estabilización, debería compilarse y ser una característica completa. No se deben agregar nuevas características, ni refactorizar, ni limpiar el código. Puede agregar un prefijo previo para indicar ramas de estabilización frente a ramas de mantenimiento.
/branches/cool_feature. Se usa para trabajos altamente experimentales o destructivos que pueden o no convertirse en tronco (o en una rama de mantenimiento). No hay garantías sobre cómo compilar código, trabajar o comportarse de forma sensata. Debe durar el mínimo tiempo posible antes de fusionarse en la rama principal.
/tags/1.0.1, 1.0.2, 1.1.3a, etc. Se utiliza para etiquetar un paquete & enviado. Nunca cambia NUNCA. Haz tantas etiquetas como quieras, pero son inmutables.
En sus carpetas branches/cool_feature, ¿bifurcan todo el enlace troncal o solo ciertas subcarpetas? – swilliams
normalmente es todo el baúl. rara vez una característica solo toca un directorio. También recomiendo svnmerge.py si no está ejecutando svn 1.5. hace que todo el proceso de ramificación/fusión sea mucho más agradable. – jcoby
Presenta un muy buen modelo. Una política que mi empresa aplica, y creo que esto es bastante común, es que el tronco siempre debe construir y pasar todas las pruebas. Entonces dices bajo tu modelo que 'puede o no funcionar'. Hay diversos grados de estabilización, y creo que hacer cumplir la regla de que el tronco siempre debe construir y las pruebas automáticas siempre deben pasar es una buena regla en general. – RjOllos
Utilizamos el estilo salvaje, salvaje y al oeste de git-branches. Tenemos algunas sucursales que tienen nombres bien conocidos definidos por la convención, pero en nuestro caso, las etiquetas son en realidad más importantes para nosotros para cumplir con los requisitos de nuestra política de procesos corporativos.
A continuación, observé que usa Subversion, por lo que creo que debería consultar la sección sobre ramificación en el Subversion Book. Específicamente, consulte la sección "diseño de repositorio" en Branch Maintenance y Common Branch Patterns.
nuestro repositorio se parece a:
/trunk
/branches
/sandbox
/vendor
/ccnet
/tronco es su norma, sangrado desarrollo borde.Usamos CI así que esto siempre debe construir y aprobar pruebas.
/branches aquí es donde ponemos grandes cambios 'sancionados', es decir, algo que SABEMOS lo convertirá en el tronco, pero puede necesitar algún trabajo y romper CI. También donde trabajamos en lanzamientos de mantenimiento, que tienen sus propios proyectos de CI.
/sandbox cada desarrollador tiene su propia caja de arena, más una zona de pruebas compartida. Esto es para cosas como "vamos a agregar un proveedor de LINQ a nuestro producto" tipo de tareas que haces cuando no estás haciendo tu trabajo real. Eventualmente puede entrar en el tronco, puede que no, pero está allí y bajo el control de la versión. Sin IC aquí.
/vendor rama de proveedor estándar para proyectos donde compilamos pero no es código que mantenemos.
/ccnet esto es nuestras etiquetas de CI, solo el servidor de CI puede escribir aquí. Hindsight nos hubiera dicho que cambiemos el nombre a algo más genérico como CI, BUILDS, etc.
La alternativa que no veo aquí es la filosofía de "Branch on Change".
En lugar de tener su baúl en el "Salvaje Oeste", ¿qué pasa si el baúl es la "Versión actual"? Esto funciona bien cuando solo hay una versión de la aplicación lanzada a la vez, como un sitio web. Cuando se necesita una nueva característica o corrección de errores, se crea una rama para mantener ese cambio. A menudo, esto permite que las correcciones se migren para liberarlas individualmente y evita que los codificadores vaqueros agreguen accidentalmente una función para lanzar que no pretendías. (A menudo es una puerta trasera - "Solo para desarrollo/prueba")
Los indicadores de Ben Collins son bastante útiles para determinar qué estilo funcionaría bien para su situación.
Solíamos tener este modelo, pero la fusión constante de los cambios de las ramas resultaba prohibitivamente compleja. Ahora usamos el tronco para el borde sangrante y las ramas para la estabilización y el mantenimiento. De esta forma, no se necesita fusionar árboles. –
Henrik Kniberg's Version Control for Multiple Agile Teams también tiene algunos buenos puntos a tener en cuenta.
Para ver la guía madre sobre patrones de ramificación, ver el Streamed Lines: Branching Patterns for Parallel Software Development de Brad Appleton. Es un trabajo pesado, pero no he visto nada que lo supere en términos de amplitud y profundidad de conocimiento sobre la ramificación.
Jeff Atwood wrote acerca de esto en una buena publicación de blog; esa publicación tiene algunos enlaces importantes en ella.
Tome un vistazo a este http://codicesoftware.blogspot.com/2010/03/branching-strategies.html para una mejor explicación
No importa el patrón de ramificación elegido, usted debe tratar de mantener sus ramas en forma de árbol binario de la siguiente manera:
trunk - tags
|
next
/\ \
bugfix f1 f2
/ \ \
f11 f21 f22
Lo primero: BESO (! Que sea sencillo estúpida)
/branches
/RB-1.0 (*1)
/RB-1.1 (*1)
/RB-2.0 (*1)
/tags
/REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2)
/REL-1.1
/REL-2.0
/trunk
current development with cool new features ;-)
* 1) Mantener la versión mantenible - por ejemplo, Service Packs, revisiones, correcciones de errores que puede estar fusionado al tronco si es necesario y/o necesarios) * 2) major.minor.build.revision
Reglas del pulgar:
--hfrmobile
Gnat ha escrito this excellent break down en los diversos bits de consejos que puedes encontrar en branc estrategias de hing.
No hay una estrategia de ramificación, que es lo que funciona para:
Jeff Atwood's post se desglosan muchas posibilidades.Otro para agregar es el concepto de promoción (del enlace de Ryan Duffield). En esta configuración, tiene una rama dev, prueba bracnh y rama de publicación. Promociona su código hasta que llega a la rama de lanzamiento y se implementa.
Leer este clásico: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf – zvolkov
@casperOne eso es probablemente la forma más divertida de manejar un vínculo de sólo responder a la bandera que he visto – gnat
@gnat Comes parte de la parcela con manejar la bandera en la respuesta. =) – casperOne