Subversion: Branch per Environment?

Question

Actualmente estoy trabajando en un proyecto en .NET que consta de varias capas lógicas y varios frontales. Aquí es una representación aproximada de nuestra estructura SVN:

trunk 
---doc 
---lib 
---src 
------console 
---------console.vbproj 
------domain 
---------domain.vbproj 
------... 
------web 
---------web.vbproj 
---.sln 

Todo nuestro desarrollo del día a día que ocurre en el tronco - aquí es donde todos los desarrolladores Checkout desde/a cometer.

Estoy buscando una manera de implementar de forma limpia y fácil entre entornos (prueba y producción).

Mi idea es crear dos ramas, prueba y producción, desde trunk - solution y todo. Yo estoy justificando esto a mí mismo por las siguientes razones:

1. tengo un control completo sobre la que fluyen las modificaciones a las que los entornos sólo por la fusión del tronco a la rama de prueba y de la rama de prueba a la rama de producción
2. que pueda ver fácilmente qué código se está ejecutando en cada entorno simplemente mirando el registro de la rama correspondiente en Subversion

¿Alguien ha tenido alguna experiencia con una solución similar a esta? ¿Hay algún peligro potencial o descuido que me falta?

Answer 1

¿Alguien ha tenido alguna experiencia con una solución similar a esta?

Sí :-)

¿Existen peligros potenciales u omisiones que me falta?

Se encontrará con el problema de que con el tiempo las ramas de prueba y liberación se alejarán del entorno de desarrollo, ya que es muy probable que no se fusionen todos los cambios del tronco. Los desarrolladores trabajarán en un entorno ligeramente diferente y perderán mucho tiempo manteniendo las ramas sincronizadas. Esto se conoce como merge-mania anti-pattern.

Prefiero asesorarme para crear una rama de versión desde el tronco para cada versión planificada una vez que haya implementado todas las funciones. En el momento en que sucursal, ambos son iguales. Luego, tenga un equipo para estabilizar y probar en la rama de lanzamiento. El desarrollo va en paralelo en el tronco. Una vez que se haya pulido su versión, combine las correcciones con el tronco.

Repita el procedimiento para cada lanzamiento. De esta manera, limitará el número de fusiones y hará que la gente trabaje en algo que siempre es la vanguardia.

Espero que estos aspectos lo ayuden en su decisión. El enlace también muestra muchos otros antipatrones. Haga una lectura para todos ellos, tal vez reconozca algunas lecciones aprendidas y obtendrá algunos consejos para resolverlo mejor.

Answer 2

Estamos utilizando el mismo diseño sin ningún problema. Asegúrese de usar la última versión de svn. La versión anterior a 1.5 no se debe utilizar debido a que falta el seguimiento de fusión.

Junto con una herramienta de seguimiento de errores como jira de atlassian (no estoy patrocinado) su configuración se vuelve aún más transparente.