Como ya había comentado anteriormente la creación de Build Types de la versión 2005 difiere bastante con la versión 2008. Para empezar, ya ni si quiera se llaman Build Types, sino Build Definitions. Además se introduce un nuevo elemento que es esencial a la hora de definir nuestras Builds, los Build Agent. En Team Build 2005 solo existía un motor de compilación que era la máquina donde estaba instalado Team Build. Ahora en la nueva versión podemos definir distintas máquinas como Build Agents, por lo que se al haber más de una máquina destinada para este uso se puede realizar más de una compilación distinta en el mismo momento. Además una cosa que no se nos permitía hacer en la versión anterior era lanzar dos Builds seguidas, si lo hacíamos la segunda de ellas nos respondía que el servidor de compilación estaba ocupado y quedaba automáticamente anulada no llegando a ejecutarse nunca. Sin embargo ahora existe una cola donde se van apilando peticiones de compilaciones y es Team Build quién se va encargando de ejecutar las Builds según su orden de llegada.
Volviendo al proceso de la creación de Build Definitions, además de estos nuevos de Build Agents y encolado, tenemos algunas características más que definiré cuando lleguemos al punto en que sea necesario. Para empezar, al igual que la versión antigua, debemos dar un nombre a la Build Definition y si queremos podemos introducir también una descripción de la misma.
En el segundo paso, llega una de las novedades/diferencias, la selección del Workspace. Ahora en Team Build 2008 podemos seleccionar un Workspace y una serie de carpetas (Working folders) donde se buscarán los ficheros de solución que queramos compilar en la Build que estamos definiendo.
Una vez más llega otro cambio respecto a la versión anterior. En Team Build 2005 el fichero TFSBuild.proj se almacenaba en un sitio fijo dentro del control de código fuente y no se podía cambiar. Ahora por el contrario existe un nuevo paso en el asistente en el que podemos especificar la ruta del control de código fuente donde se guardará el fichero TFSBuild.proj, con lo que podremos definir el árbol de carpetas dentro del control de código fuente que deseemos. Cuando estamos creando una nueva Build Definition por lo general no existe un fichero TFSBuild.proj, y nos aparece un botón en el propio asistente que nos permite crearlo. Hay que tener en cuenta que podríamos usar un mismo fichero TFSBuil.proj para diferentes Build Definitions, por lo que quizás no necesitemos crear este fichero cada vez.
Si pulsamos este botón para crear un nuevo fichero de compilación nos aparece otro asistente (si, si, asistentes anidados :P) que es muy similar al que teníamos en Team Build 2005. En primer lugar debemos seleccionar las soluciones que queremos que se compilen. En el caso de que hayamos elegido más de un WorkSpace en el segundo paso se nos mostrarán todas las soluciones contenidas en los WorkSpaces seleccionados. Para continuar, definimos las configuraciones de compilación, que consistía en seleccionar el modo de compilación (Debug o Release) y la plataforma de destino (Any CPU, x86, x64, Itanium, etc...). Para finalizar este asistente de creación del fichero TFSBuild.proj, tenemos un paso opcional en el que podemos elegir las listas de que se ejecutarán tras realizar la compilación, indicar una serie de assemblies que contienen tests y que queremos que sean ejecutados y elegir si habilitar o no el que se realice la ejecución de las reglas de análisis estático de código.
Volviendo al asistente principal después de haber creado el fichero TFSBuild.proj, llega de nuevo una opción que no existía en Team Build 2005, la Retention Policy. En este paso lo que se nos permite es definir que numero de reportes de Builds queremos almacenar para cada unos de los estados finales posibles. Me explico, cuando ejecutamos una Build existen cuatro estados en los que esta Build puede acabar:
- Failed: La compilación ha fallado
- Stopped: La compilación ha sido detenida y no se ha finalizado
- Partially Succeeded: Solo una parte de la compilación fue satisfactoria, es decir, el código compilaba pero las pruebas o el análisis de código no cumplió el resultado esperado
- Succeeded: La compilación fue un éxito por completo
Y en esta parte del asistente podemos definir que numero de número de reportes de Build queremos que sean guardados. Se nos da la opción de guardar todos, ninguno, el último, o los n últimos (pudiendo nosotros especificar el numero).
En el siguiente paso, Build Defaults, especificamos quién será el encargado de realizar la compilación (Build Agent) y la ruta de red donde se depositará el resultado de la Build. Para no hacer este post demasiado largo, el proceso de creación de un nuevo Build Agent (que no es algo complejo) lo describiré en el siguiente post. Para el propósito de este post que describir el proceso de creación de una Build Definition, asumiremos que ya nos aparece un Build Agent en la lista y los seleccionaremos.
Finalmente en el ultimo paso podemos definir la frecuencia de una de las características más esperadas en Team Build, la integración continua. En este ultimo paso tenemos cuatro opciones. Las dos primeras nos permiten desactivar la integración continua (Check-ins do not trigger a new build) y activarla para cada Check-in (Build each check-in) respectivamente. Una de las cosas que pueden causar que el rendimiento del servidor disminuya es activar la segunda opción, hacer una build para cada check-in. En equipos de trabajo muy grandes se pueden producir check-ins cada muy poco tiempo y muchas veces las compilaciones tardan varios minutos en obtener la ultima versión del código fuente, compilarlo y pasar las pruebas, por lo que en muchos casos no es recomendado activar la compilación para cada check-in. Debido a este problema surge la tercera opción que nos permite acumular check-ins y lanzar la build cada "X" minutos pero la build siempre será lanzada por un check-in. Como ultima opción dentro de este paso del asistente podemos definir una agenda de compilación, olvidándonos ya de tener que crear ficheros .bat o .cmd y programarlos con el administrador de tareas. Se nos permiten opciones bastante normales como qué días de la semana queremos que se ejecute la build y a qué hora. Además tenemos una opción que nos permite marcar si queremos que se ejecute la compilación incluso si no han ocurrido cambios desde la ultima build.
Con este paso que acabamos de ver concluye el proceso de creación de Build Definitions en Team Build 2008, en el siguiente post explicaré con algo más de detalle el proceso de creación de un Build Agent.