Configuración de SVN para el mejor juego del Dev -> QA -> Prod

Question

Lo siento si esto ya se ha pedido, pero no he podido encontrar una respuesta específica a esta situación:

Para nuestra web aplicación, tenemos 3 sistemas: dev, QA y producción. En este momento, un tercero está manteniendo el código, pero pronto estará en nuestras manos. Tendremos entornos de construcción separados para cada etapa. Además, usamos RAD para el desarrollo de código, por lo que en realidad habrá un paso primario, test/sandbox.

Idealmente, quisiéramos aislar repositorios de alguna manera para cada etapa, por ejemplo, verificamos desde DEV, hacemos algunos cambios, los probamos localmente y los volvemos a registrar en DEV. Si todo está bien en Dev, revisaremos QA, y así sucesivamente.

¿Deberíamos tener repositorios separados para cada uno, o esto estaría bajo 'ramificación', donde tendríamos una rama separada para dev, QA y prod. ¿Podría también proporcionar los mejores medios para implementar la ruta ideal?

Avíseme si hay alguna otra pregunta, también.

Gracias Chris

Answer 1

utilización ramas y la mezcla

hacemos lo siguiente:

Cuando liberamos creamos una rama de lanzamiento actual. Hacemos correcciones de errores aquí entre lanzamientos, luego los fusionamos de nuevo a nuestro trunk.

Desarrollamos en trunk y cuando estamos listos para lanzar hacemos una rama QA. Probamos y solucionamos y luego lo sacamos y se convierte en nuestra rama de lanzamiento actual.

Answer 2

Usted debe tener un repositorio único que se puede comprobar a cabo o exportado durante el proceso de despliegue.

Nosotros, también, tenemos una configuración similar. Los desarrolladores verifican una copia local de trabajo y desarrollan en su entorno de desarrollo. Cuando estamos listos para lanzarnos al escenario, o QA como lo llamas, hacemos una exportación svn a ese entorno (a menudo de head, pero siempre hacemos un seguimiento de la revisión específica).

Durante el proceso de control de calidad, seguimos desarrollando en desarrollo y despliegue en control de calidad.

Finalmente, cuando estamos listos para la producción, exportamos la revisión correcta desde el repositorio al entorno de producción.

Funciona muy bien!

[Editar: en cuanto a 'es esta ramificación' - lo que está describiendo es probablemente más como un seguimiento de las revisiones. la ramificación es, sin embargo, una técnica muy importante para gestionar diferentes líneas de desarrollo. esto no debe confundirse con tener una rama diferente para cada etapa (dev, el escenario, en vivo), necesariamente]

Answer 3

Esto funciona bien si está trabajando en un solo flujo de desarrollo con tareas fácilmente confirmadas. Pero será más desafiante con múltiples flujos de desarrollo y la posibilidad de que las tareas se retiren o retrasen. Entonces necesitaría algún tipo de dependencia de tiempo dentro de su aplicación. También podría usar algo como ramas de características que se fusionan de nuevo en el tronco una vez que se construye la característica.

Answer 4

Salida entrada en el blog de Scott Cowan:

http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/

Él tiene un gran artículo sobre la promoción de su código para diferentes entornos. Incluirá la escritura de algunos scripts de construcción, pero mejorará el proceso. Le permitirá también ser algo automatizado.

Answer 5

Tenemos un esquema similar. En SVN tenemos 3 sucursales, trunk, PREPROD y PROD. Cada vez que una nueva función está lista para probar, se fusiona en la rama PREPROD (utilizando solo números de revisión específicos y solo para archivos específicos), si pasa el control de calidad, se compromete y se fusiona en la rama PROD. Cuando los cambios se confirman en la rama PROD, se implementan automáticamente en todos los servidores de producción. Excepto cuando se prueban nuevas características, PREPROD y PROD son iguales.

Answer 6

Tenemos una rama de desarrollo para cada corrección de error, función o tarea, y los proyectos involucrados tienden a tener múltiples ramas secundarias.

Inicialmente es un tanto extraño crear una nueva rama para una sola corrección de código de una línea, pero permite fusionar la troncal en la rama, luego realizar pruebas de regresión y finalmente volver a fusionarse en la troncal.

Idealmente, esto significa que cualquier cosa fusionada en el tronco no romperá la construcción, y significa que no tiene miedo de comprometer su código para hacer una construcción frágil.

A menudo utilizo varias ramas para el único problema, probando diferentes soluciones sin dejar de obtener los beneficios de SCM.

También etiquetamos versiones o lanzamientos específicos, lo que permite una implementación rápida basada en un buen código conocido.

Muchos de nuestros sistemas basados ​​en la web utilizan svn: externals que apuntan a versiones específicas de dependencias tales como bibliotecas y código de proveedor. Una implementación se toma de lo externo, en lugar de una salida o exportación directa.