Promoción de código con Subversion

Question

Estoy trabajando para migrar nuestro equipo de desarrollo a Subversion y mejorar nuestra estructura y procesos de repositorio. Básicamente vamos con la configuración estándar trunk/branches/tags. Originalmente estaba planeando utilizar una estrategia de distribución de sucursales (branches/1.0, branches/2.0, etc.), pero ahora me inclino por un modelo de promoción de código (pruebas y ramas de producción). Es un poco mejor y más intuitivo el funcionamiento de nuestro equipo, pero las versiones serán un poco menos directas: efectivamente necesitamos que la rama de prueba se convierta en la rama de producción. (La rama de producción siempre está disponible para las versiones de mantenimiento, pero la rama de prueba no necesita existir entre la implementación de una versión y la lista de prueba de la próxima.)

¿Alguien que esté usando la promoción de códigos recomiende la mejor manera? implementar implementar la promoción de una rama de prueba a producción? Me imagino que estas son mis opciones, pero no sé si tienen pros/contras importantes:

a. Combinar completamente la rama de prueba en la rama de producción, eliminar la rama de prueba
b. Eliminar la rama de producción, copiar la prueba a la producción, eliminar la rama de prueba
c. Eliminar la rama de producción, cambiar el nombre de la rama de prueba a producción

¡Gracias por cualquier consejo!

Answer 1

primero: las opciones b) yc) son las mismas en subversión que en los cambios de subversión, de hecho, se copian y eliminan.

Eso le dijo que sólo tiene dos opciones:

1. fusionar completamente rama de prueba en la rama de producción, eliminar la rama de prueba

   Ésta es la limpia camino en términos de la subversión. Puede ver en usted svn log qué revisiones se fusionaron en producción y la copia de trabajo de todos permanece intacta.

   Pero viene con un precio: Tiene que hacer manualmente las fusiones y resolver posibles conflictos (si se producen cambios en productionbranch).

   Sin embargo por lo general puede hacer esto con una pequeña cantidad de sobrecarga

2. Eliminar rama de producción, cambiar el nombre de la rama de prueba para la producción

   Ésta es la manera fácil, ya que acaba de hacer un muy pequeña operación que es programable.

   Desventajas:

   Va a invalidar todas workingcopys la que apuntaban a testbranch

   seguimiento de la fusión es mucho más difícil, ya que no puede revisar la antigua rama de producción con facilidad (que se ha convertido la producción!). ¡Se pierden los cambios directos en la rama de producción (sin notificación)!

También hay que tener en cuenta que es posible que no desea que todos los envíos en testbranch en la producción (¿por qué probar, si todo va bien?). Por lo tanto, le sugiero encarecidamente opción A

Answer 2

Siempre pensé en ramas de corta vida, y todos mis lanzamientos están realmente en la carpeta de etiquetas. Cuando se necesitan soluciones para una determinada versión, la etiqueta se copia a una rama, se realiza el trabajo y se crea una nueva etiqueta. Tengo curiosidad por ver si alguien tiene un enfoque diferente/mejor.

Answer 3

Sus ramas de producción deben mantenerse intactas. Nómbrelos por su número de versión. ProductName_Production_ {major}. {Minor}. {Minor}. A medida que migra de la prueba a la producción, crea una nueva rama de producción con el último número de versión. Borre la rama de prueba si lo desea, pero puede tratarse de la misma manera.

Como parte de mi proceso de compilación, normalmente compruebo la producción actual antes de implementar la siguiente producción para poder volver a la última versión estable si fuera necesario. Solo un fyi.

No suelo usar ramas de esta manera. Guardo cada iteración etiquetada para que las tenga todas. Uso mis entornos para promocionar el código de prueba, qa, prueba de rendimiento, producción. Ziping cada paquete en el camino para capacidades de retroceso.

Answer 4

Actualmente no distinguimos entre la rama de trabajo principal y la rama de prueba en el nivel de control de versiones del código, pero tiene sentido para mí.

hecho me vaya para un enfoque como

• principal
• rama prueba
  • prueba
• rama de producción (utilizaría la carpeta de etiqueta para estos)
  • production1 .0

Cuando la prueba se terminó lo copia a una nueva carpeta production1.1/rama.

Answer 5

Creo una etiqueta desde cualquier rama o tronco para cada lanzamiento.

• tag/1.0_tc1
• tag/1.0_tc2
• tag/1.0_rc1
• tag/1.0_ga

Si RC1 es aceptable que simplemente hay que etiquetar de nuevo como 1.0_ga

Answer 6

¿Por qué migrar el código? ¡Construye la migración en su lugar!

Por más de 4 años, acabamos de utilizar ramas. Tomamos el enlace troncal e hicimos nuestra primera sucursal, llamada RB-2013.07.0.x. Esta sucursal es la Sucursal de Liberación de julio de 2013. Cerramos el camión para que nadie pudiera hacerle cambios. Todos los cambios se realizaron en RB-2013.07.0.x. Una vez que se completó el lanzamiento de julio, bloqueamos RB-2013.07.0.x, por lo que no se podrían hacer más cambios.

Mientras tanto, también creamos la rama RB-2013.09.0.x, para la versión de septiembre, desde el Troncal.Los desarrolladores trabajaron en el lanzamiento de septiembre, mientras trabajaban en el lanzamiento de julio.

Después de que el lanzamiento de julio entrara en PROD, luego fusionamos RB-2013.07.0.x en RB-2013.09.0.x. Nunca volvimos al Troncal. Nunca migramos nada. Y en más de 4 años, nunca perdimos ningún código, y cuando mirabas el proyecto, sabías exactamente para qué era la rama.

Si tiene un problema de prod (corrección), tomaría la versión de producto actual - digamos RB-2013.07.0.x y crearía una rama RB-2013.07.1.x, le haría cambios, implementaría en prod , bloquee la rama y fusione la rama en las ramas superiores: RB-2013.09.0.x. De esta manera, tendrás todo actualizado.

Tenga en cuenta que, en cada construcción que hicimos, creamos un TAG y lo guardamos en el directorio TAGS.

Las compilaciones que hicimos, agregamos el número de revisión de SVN a la última parte del número de compilación.
Las construcciones pasarían de dev, a prueba, a UAT/pre-prod y luego a prod. Si quería saber qué código estaba en cada compilación o sucursal, vaya a SVN y extraiga la lista de registro.