Desarrollo de un proyecto con Visual Studio Online - Parte 2 de 3
Hagamos memoria
Vamos a seguir con el proyecto de Cubitos que empezamos en el post anterior. Si recordáis estábamos haciendo un proyecto Web con MVC utilizando al máximo los servicios que nos ofrece Visual Studio Online.
Las tareas que nos asignamos a nuestro primer Sprint eran las siguientes:
Desarrollo del proyecto
Vamos a empezar a desarrollar el proyecto. Lo primero que vamos a hacer es instalar Entity Framework, desde el gestor de paquetes NuGet. Una vez descargado los ensamblados tenemos que crear los modelos y los controladores para poder insertar, ver, editar y borrar los datos.
Hemos creado un modelo que contiene los siguientes campos:
public class Item
{
public int ItemID { get; set; }
public string Name { get; set; }
}
Y tenemos nuestro contexto de Entity Framework que es capaz de crear, ver, editar y borrar.
public class CubitosContext : DbContext
{
// You can add custom code to this file. Changes will not be overwritten.
//
// If you want Entity Framework to drop and regenerate your database
// automatically whenever you change your model schema, please use data migrations.
// For more information refer to the documentation:
// https://msdn.microsoft.com/en-us/data/jj591621.aspx
public CubitosContext() : base("name=CubitosContext")
{
}
public System.Data.Entity.DbSet<Cubitos.Models.Item> Items { get; set; }
}
Ahora que ya tenemos una primera versión de nuestra aplicación web preparada vamos a preparar toda la parte de test, builds, etc.
Test
Para asegurarnos de que cada checkin es funcionalidad incremental de calidad y para asegurarnos de que ese conjunto de cambios no afecta a otras partes de nuestra aplicación, vamos a crear un proyecto de Testing, donde vamos a generar unos test que comprueben la integridad del código. De esta manera tenemos un mecanismo para pasar a nuestro proyecto para asegurarnos de que todo va bien. Como veremos más adelantes podemos configurar la Build para que solamente se permitan hacer checkin solamente si la Build es correcta y todos los test están en verde, esta opción se llama Gated Checkin
Para hacer esto nos vamos a la solución y agregamos un proyecto de Unit Test.
Este proyecto es un tipo de proyecto especial que nos permite crear diferentes test unitarios sobre el código que se está trabajando. Nosotros vamos a empezar por crear un test que pruebe nuestro controlador de Item, ItemController. Agregamos al proyecto de test una referencia de nuestro proyecto web para poder trabajar con los controladores. Al querer pasar test a un proyecto de MVC tenemos que añadir una referencia a su ensamblado.
Para crear un test unitario para el ItemController agregamos un nuevo elemento al proyecto de test.
En nuestra nueva clase añadimos un método para probar el Create de nuestro controlador. Una vez lo hemos creado es hora de pasar los test. En la barra superior de Visual Studio encontramos la pestaña Test. Desde ahí podemos ejecutar todos los test de nuestro proyecto.
En nuestro caso todo ha ido bien, el test se ha pasado correctamente. Ahora vamos a modificar el controlador para que no inserte el Item en la base de datos y volvemos a pasar el test.
Como podemos ver nuestro test ha fallado. Nos muestra que tests han fallado, y el mensaje que le hemos puesto, de esa manera se puede identificar el tipo de error más claramente.
Hacer tests nos ayuda a mantener un código de calidad y poder generar realeases incrementales de funcionalidad. Nos permite poder ir generando código de manera incremental y asegurarnos de que los cambios que hemos hecho no afecta al correcto funcionamiento de otras partes de nuestra aplicación.
Builds
Visual Studio Online nos ofrece la posibilidad de poder hacer construcciones automatizadas. Vamos a ver las distintas configuraciones que podemos hacer. Para empezar, debemos ir al menú del Team Explorer, seleccionar Builds y hacer click en New BuildDefinition.
Se nos abrirá una pestaña para poder configurar nuestra Build. En la primera sección, General, podemos indicar el nombre de la Build y una descripción. Además podemos decir si esta activa o no. El nombre es importante porque será parte de la carpeta de salida de la Build, es importante mantener el nombre de la Build lo más pequeño posible.
En la segunda sección, Trigger, podemos configurar cuando se va a lanzar la Build.
Nos ofrecen varias opciones de configuración.
- Manual: Con esta opción los Check In no lanzan la Build, sino que es el desarrollador el que ha de lanzarla manualmente.
- Continous Integration: Cada vez que se hace un Check In se desencadena la Build.
- Rolling builds: Está haciendo Builds constantemente.
- Gated Check In: Con esta opción solo se aceptará los Check In si la Build da un resultado correcto. En esta opción ya entran en juego nuestro Test. Si no se pasan todos, no se hará el Check In.
- Schedule: Podemos programar las Builds para que se ejecuten a una hora del día los días que queramos. Por ejemplo todos los días a las 00:00. Son perfectas para hacer daily builds.
Nosotros vamos a seleccionar Gated Check In. Y luego veremos a la hora de hacer el Check In que pasa cuando todos los test son correctos y cuando falla alguno.
Por otro lado tenemos la ventana de proceso que nos permite configurar el proceso que va a seguirse en la Build. La solución que se va a ejecutar, los test que se le van a pasar, dónde se va a guardar la salida de la Build, etc.
Vamos a ver un poco más en detalle las opciones más importantes.
En primer lugar podemos configurar las soluciones o proyectos que se van compilar en la Build en el apartado Item to Build. Además en Configurations to Build podemos indicar para que plataforma queremos hacer la Build y si es Release o Debug.
En el apartado de Basic podemos indicarle que test se van a pasar durante la Build, si queremos que la Build falle si fallan los tests, la plataforma de ejecución de los test, etc. Otro de los aspectos importantes de este apartado es poder limpiar el workspace de la máquina dónde se ejecuta la Build. En muchos casos los proyectos tienen mucho contenido multimedia que hace que ocupe mucho espacio y hace la transferencia del proyecto más lenta. Por tanto si no limpiamos el Workspace únicamente se descargará los archivos modificados para hacer la Build, haciendo el proceso más rápido.
Por otro lado podemos indicar que cuando se ejecute la Build se genere un archivo con los símbolos del proyecto.
En el apartado de Advanced podemos indicar que asocie la Build a los Work Items e incluso que nos cree un Work Item en caso de que falle la Build. Además nos permite etiquetar la Build.
En el resto de secciones podemos configurar otros aspectos como cuantas Builds se van a guardar, donde se van a realizar…
Check In
Ya hemos terminado parte de nuestro proyecto, es hora de subir nuestros cambios y asociar esos cambios con las tareas a las que afectan. Para hacer esto seleccionamos Work Items en el menú de Team Explorer.
En este menú seleccionamos de Interation Backlog en la carpeta Current Iteration. Nos aparecerá una pestaña con todas las tareas de esta iteración.
Ahora nos vamos a Pending Changes en el menú de Team Explorer. En el apartado de Comment escribimos una breve descripción de que cambios incluye este Check In. Y en el apartado de Related Work Item arrastramos las tareas o historias de usuario a los que afectan este Check In. Podemos elegir si con este Check In las tareas se cierran (Resolve) o simplemente se han hecho cambios pero no se ha terminado (Associate).
Cuando hacemos Check In nos aparece un mensaje que nos avisa que necesitamos hacer una Build de nuestros cambios para validan el Check In.
Ahora se ejecutará la Build y nos indicará si ha fallado. En nuestro caso como no hemos arreglado el controlador debe dar error. Podemos ir viendo el estado de la Build desde Visual Studio y desde visual Studio Online. Cundo acabe la Build nos indicará que ha fallado.
Y nos lleva a Visual Studio Online donde podemos ver más detalles sobre por qué ha fallado la Build.
Como podemos ver nos dice que test han fallado. No se ha pasado ningún test con éxito. Además nos dice que ha compilado sin problemas.
Ahora vamos a arreglar el controlador y a volver a hacer un Check In, exactamente igual que antes. En este caso nos dice que han pasado todos los test y que debemos reconciliar nuestro código, es decir, al hacer el Check In dependiente de la build nuestro código no se aloja en la nuestra rama de trabajo, cuando se han pasado todos los test debemos consolidar nuestro código en nuestra rama de trabajo actual.
¿Qué nos falta por hacer?
En el siguiente post vamos a subir nuestro proyecto a Azure, enlazando nuestro repositorio y vamos a modificarlo directamente con el editor Monaco de Visual Studio Online.
Os dejo el enlace al primer y al tercer post.
Un saludo,
Sergio Gallardo Sales (@maktub82)
PD: Mantente informado de todas las novedades de Microsoft para los desarrolladores españoles a través del Twitter de MSDN, el Facebook de MSDN, el Blog de MSDN y la Newsletter MSDN Flash.