Modelo de ramificación TFS para soportar un ciclo largo de control de calidad (pruebas del sistema)

Question

Digamos que tienes una aplicación. Esta aplicación debe ser probada y desplegada en la producción. Existen algunas restricciones en el ciclo de vida de la aplicación.

1. Solo existirá una versión de la aplicación en producción.
2. Una vez implementado en producción, si es necesario, se deben desarrollar los arreglos necesarios. Los arreglos en caliente están dirigidos específicamente para corregir un defecto específico de alta severidad y no introducir nuevas funciones. El cambio de código de revisión debe integrarse a la inversa en otras sucursales.
3. Antes de pasar a producción para el lanzamiento de una nueva característica, debe pasar por un ciclo de control de calidad.
4. Después de lanzar a QA, toma un tiempo considerable para probar la aplicación. En el primer ciclo de control de calidad, si el control de calidad abre 20 defectos, deben solucionarse en la próxima versión de control de calidad sin más funciones para probar. Si el equipo de control de calidad vuelve a abrir, digamos 10 defectos, en la próxima versión de control de calidad solo quieren que esos 10 defectos se solucionen. No hay otros defectos o nuevas características. La siguiente versión de la función solo puede ocurrir después de que el recuento de defectos sea 0 (o se decida que algunos defectos no sean fijos o mejorados, etc.).
5. Dado que el ciclo de control de calidad toma tiempo, durante ese tiempo el desarrollo no se puede detener. Se deben continuar desarrollando nuevas características para el próximo lanzamiento de características.

¿Cómo configurarías tu modelo de ramificación TFS?

Answer 1

Parece que eres un candidato perfecto para el " Estándar " estrategia de la rama TFS / guía de fusión: http://tfsbranchingguideii.codeplex.com /Release/ProjectReleases.aspx?ReleaseId=20785

En esencia, esto toma tu Dev básico < - > Principal < - > Suelte el modelo, luego agrega una capa más de direccionamiento indirecto. Las soluciones rápidas obtienen su propia rama en el lado de la versión de la jerarquía, por lo que su desarrollo + prueba no interrumpe el ciclo de control de calidad ordinario que ocurre en Main ni contamina la inviolabilidad de la versión. Puedes ver una ilustración visual en la página 7 del PDF.

¿Tiene un requisito rígido de que las sucursales de Release representan una instantánea exacta de la producción (es decir, hay una relación 1: 1 entre los registros en Release y las implementaciones, y / o una sucursal de Release independiente creada por implementación)? Si no es así, es posible que ni siquiera necesite la rama de hotfix - haga las revisiones directamente en la versión. Esto se trata en la sección " Básico " estrategia anterior en el documento.

En cualquier caso, asegúrese de leer todo el conjunto de documentos. No es largo, pero extrae muchos hallazgos de implementaciones del mundo real. (Los " VSTS Rangers " están formados principalmente por MVP y otros consultores en el sitio)

Para una visión más larga y teórica de las estrategias de desarrollo de equipos & amp; su implementación en TFS, consulte los documentos de Patterns & amp; Grupo de prácticas: http://msdn.microsoft.com/en-us/library/bb668991. aspx http://branchingguidance.codeplex.com/Wiki/View.aspx?title= html