TFS 2008: preguntas sobre autocomstackciones, tags y versiones generales

Un poco de historia primero…

Estoy configurando un sistema de numeración de versiones para nuestro proyecto que actualmente solo tiene una twig de desarrollo, pero ahora estamos avanzando hacia nuestra primera implementación. Estamos usando TFS y usamos comstackciones nocturnas en nuestra twig de desarrollo.

La forma en que probablemente vamos a ir con esto es que cuando nos preparemos para un lanzamiento tomamos una twig de dev y la llamamos 1.x. Esta será una twig de testing: la probaremos, la corregiremos (luego nos fusionaremos con dev), la probaremos un poco más y cuando esté bien eliminaremos otra twig de la twig 1.x y la llamaremos 1.0. Es esta twig la que se implementa en la producción. Cualquier corrección en la producción se realizará en el 1.x, probado y luego se realizará una nueva twig 1.1.

Mi problema es con la testing de la twig 1.x. Antes de la testing, la sucursal se bloqueará por razones obvias. Mi problema es que la garantía de calidad requiere que se lleve a cabo una ronda de testings contra un "número de versión" y si la testing falla, la próxima ronda de testings será contra un nuevo "número de versión". Los desarrolladores de nosotros quieren vincular el "número de versión" al lanzamiento y las testings pueden iterar sobre esa versión … por lo que hay un conflicto aquí.

Mi primer pensamiento es utilizar el número de compilation como el momento en el que se testing el código. Cuando es hora de enviar una nueva versión para probar, la twig 1.x se bloquea nuevamente y se inicia una compilation y el número de VSTS que se genera se convierte en una "versión de liberación 1 para v1.0". Mapeando el RC a una construcción que podemos hacer manualmente en una spreadsheet …

… luego alguien menciona las tags, y que el código debe ser bloqueado labeldo y construido antes de la testing. Nunca antes he usado labeldo y acabo de leer que la construcción misma crea una label en TFS.

Ahora estoy confundido acerca de cuál es la mejor manera de ir aquí. ¿Está usando un número de versión suficiente para un lanzamiento? ¿El labeldo manual sirve para algún propósito aquí (el único beneficio que puedo ver es que podemos dar su propio nombre y descripción)? ¿Puedo decirle a TFS que NO cree una label cada vez que ejecuta una compilation y acaba de hacer todas nuestras propias tags en puntos significativos en el time (no todas las construcciones van a ser candidatas a lanzamientos, por ejemplo)? Si es así, NO crear una label después de cada compilation es una mala idea, ¿qué me da el labeldo?

Creo que estoy confundido acerca de dónde se ajustan los changsets, los numbers de compilation / nombres y las tags entre sí …

Esta es una pregunta amplia, pero es una de esas en las que no estoy 100% seguro de qué preguntar. Cualquier ayuda apreciada.

… luego alguien menciona las tags, y que el código debe ser bloqueado labeldo y construido antes de la testing. Nunca antes he usado labeldo y acabo de leer que la construcción misma crea una label en TFS.

Lo que has leído es correcto. Con TFS (a diferencia de, digamos, SourceSafe), cada acción del server constituye un "punto conocido en el time" que más adelante se puede consultar. Puede ver lo que quiero decir al hacer una Get Specific Version... y search en el menu desplegable Version : en TFS 2005 los relevantes que veo son Changeset , Date , Label . Ahora, como dices correctamente, cada creación crea automáticamente una label. Esto significa que en cualquier momento futuro será posible recuperar el código exactamente como estaba después de cualquier set de cambios dado; en cualquier date dada; y cuando se aplicaba una label específica, por lo tanto, incluso cuando se realizaba una compilation.

El resultado es que puede usar sus propias tags o no, enteramente a su propio criterio: la capacidad de recuperar una instantánea determinada del código estará allí de todos modos. No recomendaría tratar de impedir que TFS produzca una label para cada compilation (no sé si esto es posible), las tags no le cuestan nada.

Su twig 1.x es una twig de consolidación que contendrá muchas pequeñas evoluciones incrementales.
Bloquear la twig no es la respuesta.

Establecer una label (específicamente llamado "para la testing de control de calidad" y bloqueado para no poder mover esa label) es la manera habitual de indicar al equipo de control de calidad que pueden build su propio espacio de trabajo y recuperar esa label exacta.
Entonces pueden comenzar sus testings contra el código.
Crear una label después de cada compilation no siempre es práctico, ya que no todas las comstackciones deben ser probadas por QA.