Buenas,
hace unos días Enrique propuso un par de escenarios comunes de trabajo donde se planteaba la posibilidad de realizar una validación previa al CheckIn de un desarrollador utilizando un Build, para validar de esta manera la calidad y el trabajo del código a subir al control de código fuente. En el post, se nombraron varias herramientas y yo dejé caer como posibilidad comenzar a estudiar una nueva característica incluida en Visual Studio Team System 2010 denominada Gated CheckIn (he realizado una pequeña búsqueda y me parece que no hay referencias a este término fuera del mundo MS).
La principal base de esta funcionalidad se basa en que los desarrolladores no pueden subir código directamente en el control de código fuente. En cambio, se sube un ShelveSet con los cambios pendientes y se realiza una Build con el mismo para comprobar la compilación y si se pasan las pruebas unitarias. Si toda la acción ha ido correctamente, se procede al CheckIn.
Descripción Paso a Paso
1. Una parte importante de este proceso es configurar un Build dentro de un Team Project en Team Foundation Server 2010, donde el trigger que dispare el mismo, sea un Gated CheckIn. La siguiente imagen muestra la nueva ventana de propiedades para los triggers de un Build
2. Luego de configurar este Build en un Team Project, al momento de realizar una tarea de CheckIn, podremos ver que además de los pasos usuales del proceso, aparece una nueva ventana alertando que los cambios deben ser validados previos al CheckIn. Esta opción creará un nuevo ShelveSet, y he optado como opción preservar los cambios localmente
3. Un nuevo Build se agrega en el servidor de compilación y el resultado del mismo, definirá si los cambios en el código se suben al control de código fuente.
4. En este caso en particular he incluido errores en el código para que el Build sea erróneo, con lo que los cambios no se aplicarán.
5. Una vez solucionados los problemas en el código fuente, y verificadas las pruebas correspondientes; un nuevo proceso de CheckIn es disparado. Sin embargo en este caso, el resultado del mismo es correcto lo que nos habilitará a subir los cambios al control de código fuente.
6. Para subir estos cambios, debemos seleccionar el Build correcto, y desplegando el menú contextual sobre el mismo seleccionar la opción "Update Workspace".
7. Esto nos permitirá "reconciliar" los archivos del Build, basados en un ShelveSet, con los archivos del Source Control para de esta forma, poseer una versión definitiva y correcta de los mismos.
8. CheckIn listo y con las pruebas completas !!!
Los Gated CheckIn son una de las grandes novedades en la nueva versión de Visual Studio Team System 2010, sin embargo creo que todavía se puede mejorar mucho la integración y experiencia de usuario con los mismos, por ejemplo añadiendo un par de opción para un Build por defecto en un Team Project, o mejorando la ventana de CheckIn.
Como todavía falta para la versión final de VSTS 2010, seguro que nos encontraremos con un par de novedades por el camino.
Saludos @ Home (finally)
El Bruno