Subversión: twig por ambiente?

Actualmente estoy trabajando en un proyecto en .NET que consta de varias capas lógicas y varios front-ends. Aquí hay 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 diario ocurre en el tronco: aquí es donde todos los desarrolladores realizan el checkout desde / commit to.

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

Mi idea es crear dos twigs, testing y producción, desde la solución troncal y todo. Me justifico esto por las siguientes razones:

  1. Tengo un control completo sobre qué modificaciones fluyen en qué entornos fusionándose solo desde el tronco a la twig de testing y desde la twig de testing a la twig de producción
  2. Puedo ver fácilmente qué código se está ejecutando en cada entorno simplemente mirando el logging de la twig 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?

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

Sí 🙂

¿Hay algún peligro potencial o descuido que me falta?

Te enfrentarás al problema de que con el time las twigs de testing y liberación se alejarán del entorno de desarrollo, ya que es muy probable que no fusiones todos los cambios del tronco. Los desarrolladores trabajarán en un entorno ligeramente diferente y perderán mucho time manteniendo las twigs sincronizadas. Esto se conoce como el anti-patrón merge-mania .

Prefiero asesorarme para crear una twig de publicación desde el enlace troncal para cada publicación planificada una vez que haya implementado todas las características. En el momento en que sucursal, ambos son iguales. Luego, tenga un equipo para estabilizar y probar en la twig 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 te ayuden en tu 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.

Estamos usando el mismo layout 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 configuration se vuelve aún más transparente.