Arquitectura de repository de Subversion para entornos separados Dev / Test / Prod

Me han encomendado crear un sistema de subversión para entornos dev / test / prod, y me preguntaba si alguien tiene alguna experiencia con un entorno o sugerencias similares.

Construimos y configuramos una serie de sistemas que son una combinación de scripts y files de configuration complejos para productos de terceros. Debido a esto, es imposible reestructurar el layout de las routes y los files de configuration porque no controlamos el código del sistema de terceros (es decir, si el sistema quiere un file de configuration en un lugar determinado, ahí debe estar).

Trabajamos con una metodología dev / test / prod, pero es un poco más complejo que eso. Hay un ambiente físico completo para cada etapa. Debido a esto, cada etapa necesita algunas modificaciones que deben ocurrir para que funcione en ese entorno. Todo el desarrollo debe ocurrir en el server de desarrollo, probando en el server de testing, luego tenemos los serveres de producción.

Con esta configuration, es imposible verificar una copy de un proyecto en su propia estación de trabajo, hacer algunos cambios, probarlos y volver a cometerlos. Esto solo funcionará en un server dev / test / prod (es decir, las cosas están ligadas a nombres de host y ranges de IP específicos).

Entonces, como lo veo, hay 2 opciones:

Opción 1

Haz la estructura normal de tronco / twigs / tags. Luego, tenga un script como parte de la compilation que haga todos los cambios específicos para los entornos dev / test / prod.

Por ejemplo, deberías ingresar todo el código en el maletero como de costumbre, y luego, cuando estés satisfecho con él, lo copyrás en una label de lanzamiento. Luego, en el entorno de testing, verifica la última label. Esto incluye un script 'setup'.

Luego, la secuencia de commands se ejecuta manualmente (o mediante el enlace SVN) y detectará que está en el server de testing y realizará los cambios en consecuencia.

El problema con esta forma es que svn diffs, etc. van a mostrar modificaciones a los files que obtienen las alteraciones. La ventaja es que es (bastante) simple.

opcion 2

Haga que las twigs de testing / prod y el tronco sean el desarrollo:

project trunk branches test prod tags v1.0 v1.1 

La idea es que el server dev señale a trunk . Cuando estamos contentos con los cambios, hacemos una nueva label. Luego lo fusionamos en branches/test . Esto ya tendrá los cambios necesarios para que funcione en el server de testing. Luego hacemos lo mismo para prod cuando se completa la testing.

Por lo que puedo ver, la ventaja de este enfoque es que no hay necesidad de scripts de gancho elegante, y podemos tener diferencias más complejas entre dev / test y dev / prod que SVN debería ser capaz de manejar mejor mediante la fusión.

Solo buscamos información, sugerencias, experiencia, etc. Estamos ligados a Subversion y las herramientas adicionales son, desafortunadamente, un no-go.

Gracias (lo siento por la duración)!

Honestamente, creo que cualquier opción es perfectamente viable.

Sin embargo, prefiero ligeramente tu primera elección, porque una vez que comienzas a get 'diferencias conocidas' entre ciertas twigs tienes que empezar a usar la potencia del cerebro para ejercitarte "¿es esta una diferencia entre la testing y el golpe que se supone que debe haber allí?"

Con la opción 1, siempre, definitivamente, estás trabajando y construyendo desde la misma twig, el mismo código, por lo que simplemente no obtendrás nada de esto. Cada vez que alguien hace un cambio, puede ver de inmediato (si lo desea), si esto afectará a entornos específicos antes de que se fusionen con él.

Entonces, básicamente, es un argumento para mantener las cosas simples. Es el mismo argumento si marca su software de acuerdo con su cliente. Cualquiera de los methods es viable, pero me inclino por la opción 1.

La opción 2 parece una buena architecture. También he estado buscando uno y hablando con otros desarrolladores también