Patrones / políticas de ramificación

Question

Actualmente estoy renovando la forma en que nuestra tienda hace el control de versiones. Utilizaremos una solución de control de versiones centrada en el servidor.

Me gustaría ver cómo otras personas se ramifican y lo hacen con éxito, sin todos los dolores de cabeza que leí.

¿Cuáles son algunos patrones de ramificación probados en el campo que ha visto en un entorno de producción que funcionaron bien, es decir, ramificación por lanzamiento? Qué políticas se han implementado para garantizar que la ramificación se realice sin problemas.

Gracias

Answer 1

Depende del tipo de software que esté desarrollando.

Para nosotros, somos una tienda web, por lo que no tenemos ningún 'lanzamiento' numerado. Mantenemos el tronco como lo que es digno de 'producción' y solo cometemos directamente pequeños cambios.

Cuando tenemos un proyecto grande, creamos una rama y la preparamos para la producción, todo mientras sincronizamos los cambios troncales.

Si el proyecto implica una gran reestructuración de la base del código, generalmente crearemos una etiqueta en la última revisión antes de fusionar los cambios de rama.

Nuevamente, si está creando software empaquetado donde necesita mantener versiones diferentes, esto no funcionará tan bien.

Para el registro, utilizamos Subversion .

Answer 2

El libro de subversión describe algunos de uso común patrones de ramificación (por ejemplo, ramas de liberación, ramas de características, etc.).

Answer 3

3 cosas al considerar la ramificación.

Primero: la ramificación está bien, siempre y cuando intentes fusionar las cosas más adelante. Claro que siempre puede tener una sucursal con un parche específico para uno de sus clientes con un problema específico. Pero eventualmente desea fusionar la mayoría de los parches de regreso al tronco principal

Segundo: Afirma tus necesidades. He visto árboles de todos los tamaños dependiendo del tamaño del departamento, el número de clientes, etc.

Tercero: verifique qué tan bueno es su control de fuente para bifurcar Y fusionar. Por ejemplo, CVS es notoriamente muy pobre para este tipo de operación. SVN, "CVS hecho bien" como afirman, es algo mejor. Pero Linus Torvalds, quien creó Git (que es especialmente bueno para este tipo de operación) le diría que CVS no se puede hacer bien (lo dijo en una presentación muy interesante sobre Git). Entonces, si tiene una necesidad real de ramificación y fusión, al menos obtenga SVN, no CVS.

Answer 4

Eche un vistazo a los patrones de ramificación:

http://www.cmcrossroads.com/bradapp/acme/branching/

Describe una serie de patrones para trabajar con patrones. Generalmente he trabajado de dos maneras:

• Línea de recepción estable: todo el desarrollo se realiza en ramas y se fusiona en el tronco solo cuando es necesario. Esto significa que siempre tiene un único punto de liberación estable.

• Línea de desarrollo principal: todo el trabajo se realiza en el tronco. Cuando se trata de lanzar, tomas una etiqueta de lanzamiento y la usas. Si se requiere un gran trabajo experimental, se lleva a cabo en una rama y se fusiona nuevamente en el tronco cuando es estable.

Answer 5

Así es como lo hacemos y nos funciona bien ...

Project
   |
   +--01-Development
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--02-Integration
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--03-Staging
   |
   +--04-Production

bueno, ya tienes la idea ...

NOTA: esta es la estructura de directorios en Team Foundation Server. Las ramas solo existen entre 01-Development / Release1.0 y 02-Integration / Release1.0, 02-Integration / Release1.0 y 03-Staging / Release1.0, 03-Staging / Release1.0 y 04-Production / Release1.0

En otras palabras, no podría fusionar 03-Staging / Release1.0 a 04-Production / Release2.0, etc ...

Lo que esto hace por nosotros es que tenemos 4 entornos separados Desarrollo, Integración (servidor alfa), Puesta en escena (servidor beta), Producción.

El código comienza en el desarrollo comienza en el desarrollo y luego es promovido a medida que lo prueba QA (integración / alfa) y usuarios (Staging / beta) y finalmente a producción.

Las características / cambios se recopilan y agrupan en versiones que se producen cada pocos meses.

Pero digamos que está en desarrollo para la Versión 2.0 y obtiene un problema de producción en la Versión 1.0 ... Puedo obtener fácilmente la última versión de la Versión 1.0 y solucionar el problema y promocionarlo sin afectar nada de lo que yo he estado trabajando para Release2.0

No digo que esto funcionará para todos en cada situación, pero esto funciona muy bien para nosotros.