Releases Management

Cada vez que se publica en QAS, se debe publicar un release correctamente versionado. Un release correctamente versionado cumple dos requisitos: las librerías manifiestan una versión específica, y existe en el TFS una copia del código fuente correspondiente a tales librerías.

Para lograr estos objetivos, todos los proyectos TFS están divididos en tres branchs:

• • Development: Branch donde los programadores desarrollan la aplicación

  • Main: Ultimo release publicado

  • Releases: Contenedor de tantos branchs como releases se hayan publicado en QAS.

A su vez, cada uno de éstos branchs tiene un branch por cada solución perteneciente al proyecto TFS. Todo lo relacionado a control de versiones se hace a nivel de solución (nunca se hace merge o branch a nivel de un nodo superior al de una solución entera)

Típicamente, una operación de publicación consiste en un Merge de una solución en Development hacia Main, modificación del CommonAssemblyInfo en el Main (para versionar el futuro release), y luego un Branch desde Main hacia un nuevo nodo en Release específico para la versión.

Actualización del Branch Main

Para hacer el merge desde Development hacia Main, hay que elegir en el Source Control Explorer el nodo de la solución a publicar dentro del branch Development (elegir el hijo inmediato a Development correspondiente a la solución y nunca un nodo distinto). Se hace click derecho sobre tal nodo y en el menú contextual se escoge Branch and Mergin y luego en el submenú se hace click en Merge:

El cuadro de diálogo de la operación se abrirá con los valores necesarios por defecto: el nodo de la solución en Development como origen del merge; el nodo de la solución en Main como destino; y la opción de pasar todos los cambios pendientes desde el origen hacia el destino.

Haciendo click en Next dos veces y luego en Finish el TFS replicará en el branch de destino todos los checkins que se hicieron en el branch de origen que no hayan sido mergeados hacia el branch de destino. No se modificarán en el branch de destino aquellos archivos que se hayan modificado en tal branch de destino y luego de ello no hayan sido checkineados en el branch de origen (es lo que sucede con los archivos CommonAssemblyInfo que se actualizan solo en el branch Main y por lo tanto cuando se hace merge desde Development éstos archivos no sufren modificaciones)

Una vez realizado el merge, solo resta modificar en Main la información de versión de la publicación en el archivo CommonAssemblyInfo (el mismo archivo se utiliza para todas las librerías a publicar). El mismo puede ser encontrado en las propiedades de cualquier proyecto dentro de la solución:

Se indica la nueva versión de los ensamblados a generar (compuesta de cuatro partes: major, minor, build y revision) y se compila toda la solución para garantizar que el merge no quedó incompatible. Luego se hace checkin sobre todo el nodo de la solución en el branch Main (el nodo sobre el que se hace checkin debe ser hijo inmediato de Main, nunca hacer checkin sobre otro nodo distinto).

Algunas pautas para actualizar la versión de los ensamblados:

• • Si el nuevo release no tiene funcionalidades nuevas (solo se corrigieron bugs o se hicieron mejoras de funcionalidades existentes), se modifica únicamente revision. Cuando hay funcionalidades nuevas, revision vuelve sí o sí a cero.

  • Cuando las nuevas funcionalides son parte de la misma iteración de desarrollo que el release anterior, se incrementa el build (y por ende vuelve a cero revision)

  • Al avanzar de iteración de desarrollo, se incrementa minor. También se puede considerar incrementar el minor cuando hay un cambio importante en el modelo de dominio o en la estructura arquitectónica del proyecto.

  • Un cambio en major significa prácticamente la reingeniería del proyecto, un proceso de desarrollo nuevo, o un cambio arquitectónico radical.

Generación de un Nuevo Branch en Release

Una vez checkineado el nodo de la solución en Main, se hace un nuevo branch para el release en particular dentro del nodo correspondiente a la solución en el branch Release. Una vez más, la unidad de trabajo es el nodo completo correspondiente a la solución que se publica.

En el SourceControlExplorer, se elige el nodo de la solución completa en el branch Main (elegir siempre el nodo que es hijo inmediato de Main para generar una copia completa de la solución), se abre el menú contextual con el click derecho y se elige el menú Branch and Mergin y luego el submenú Branch:

Al abrirse el cuadro de diálogo para el branch, lo único que se debe modificar es el Target en donde se especifica qué nodo se creará dentro del TFS conteniendo una copia exacta y completa de lo que hay en el origen del branch. El destino del branch debe ser siempre un nodo con el número del release generado dentro del nodo correspondiente a la solución en el nodo Release:

Se hace click en OK y cuando la operación termina, se abre la solución en el nuevo branch generado dentro de Release y se verifica que compile la solución completa. En este caso, la compilación debe hacerse siempre en configuración Release y para cualquier CPU:

Una vez verificada la compilación en el nuevo branch generado, se hace el checkin del mismo y así se termina la administración del código en TFS.

Consideraciones Generales

Al generarse un nuevo release que se deberá actualizar sobre una publicación preexistente (es decir, el release generado no será la primera publicación del producto), se debe tener en cuenta los siguientes cambios que eventualmente habrá que hacer en forma manual al publicar en el nuevo ambiente:

• • Estructuras de Datos: Probablemente, la nueva versión a publicar utilice tablas o campos que no existen en el entorno donde se publicará. Para detectar cambios de este tipo, verificar al hacer checkin de Main qué clases entidades se agregaron o modificaron en el proyecto Domain (Core para los proyectos MVC3).

  • Datos Paramétricos: También puede suceder que la nueva versión necesite contar con datos paramétricos preestablecidos. Verificar antes de hacer checkin en Main si hubo cambios en el archivo MasterData.sql dentro de la carpeta Databases (carpeta db para los proyectos MVC3).

  • Configuraciones a Nivel Aplicación: Validar los cambios que se pueden haber producido en archivos web.config o app.config antes de hacer checkin en el branch de la solución en Main. Tener en cuenta que en el destino de la publicación los archivos de configuración se modifican manualmente (nunca debiera pisarse completamente un archivo web.config o app.config en QAS o producción)