> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-04-la-construccion.-los-cimientos/integracion-con-vsts.md).

# Integración con Source Control (VSTS)

Como ya comentamos en el capítulo 1, el código fuente ha de estar siempre a buen recaudo para no perderlo, poder trabajar con versiones del mismo, etc. Otro punto importante es que el código tiene que compilar y ha de estar libre de errores. Aseguraremos esto creando nuestras primeras compilaciones automáticas (o *builds*).

## Source Control

La estructura base de nuestro proyecto está lista, la ruta física es la idónea (“D:\dev\ePomo3\main\src”), así pues, veamos a continuación cómo añadir el código a VSTS y crear las ramas “main” y “dev” tal y como ya sabemos.

La publicación del código en VSTS requiere de algunos sencillos pasos:

1. Desde el menú contextual de la solución, seleccionar “Add Solution to Source Control…” y y seguidamente seleccionar como repositorio “Team Foundation Version Control”.

![C:\Users\juanlu\AppData\Local\Microsoft\Windows\INetCache\Content.Word\Añadiendo solucion a VSTS.PNG](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-a01a19a85d812e2838c2d1d2340c76c2d57fad3c%2Fimage48.png?alt=media)

**Figura 38.- Añadiendo la solución al source control de VSTS**

2. Realizar el mapeo entre VSTS y la ruta física.

   ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-3042284a1a33494743b442bdacf90997dfa7cc1d%2Fimage49.png?alt=media)

**Figura 39.- Mapeo del workspace en VSTS: carpeta del servidor vinculada a la carpeta local**

3. Asegurar que el código compila y se ejecuta correctamente.
4. Realizar *Check In* para la carpeta y rama principal ***main***. Con ello, tendremos finalmente, nuestro código en lugar seguro. Es recomendable no olvidar escribir un comentario con cada *Check In*.
5. Realizar el ***branching*** generando la nueva rama **dev** a partir de la *main*.

   ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-1821b5211422004db658cc170af8a609c95d8283%2Fimage50.png?alt=media)

**Figura 40.- Nueva rama dev generada a partir de la main**

6. Hacer *Check In* en la rama *dev* y continuar el desarrollo en esta rama dado que será nuestra rama habitual de trabajo. Completaremos *Merges* con la rama *main*, cada vez que completemos una funcionalidad, release, etc.

{% hint style="info" %}
**Nota**: Recordemos que la rama **main** es la rama principal a partir de la cual se generarán las *dev* y *release*. Además, actuará como punto central para los ***merges***. En definitiva, la rama **main** es la línea base para el control de código fuente.
{% endhint %}

## Builds

Las *builds* o procesos automáticos de compilación generan ejecutables, a partir del código fuente ubicado en el Control de código fuente (o *Source Control*), asegurando, por tanto, que no tiene errores de compilación. Persigue corregirlos lo antes posible incluso cuando la consolidación de código fuente se realiza por más de un desarrollador. Se recomienda que este proceso incluya análisis de código y pruebas unitarias e incluso publicación y despliegue de los ejecutables resultantes.

Pueden ejecutarse de varias maneras: automática, bajo demanda, programada para una fecha y hora o bien, con cada *Check In*. A esta última se le conoce como integración continua y trata de detectar posibles fallos tras cada *Check In*.

La creación de una nueva definición de *build* (o *build definition*) para VSTS requiere de los siguientes pasos:

1. Desde la opción *Builds* del Team Explorer, seguir los pasos indicados en la siguiente figura.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-7da13584c10fd05242cbd5abd849f70da1a4c6c0%2Fimage51.png?alt=media)

**Figura 41.- Nueva definición de build**

2. Guardar la *build* indicando un nombre “Task\[in] NB” y una descripción, “Build nocturna”, e indicar los siguientes parámetros:
   1. En el paso “Get resources”, el repositorio (o *Repository*), y el mapeo de las áreas/espacios de trabajo (*Workspace mapping*s).

      ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-eceda6284d3a6fa470cc37cbf3a005926e05fcb1%2Fimage52.png?alt=media)

**Figura 42.- Paso “Get resources” de la definición de la build**

2. En el paso “NuGet restore”, concretamente en el campo “Path to NuGet.config", indicar el valor *$(System.DefaultWorkingDirectory)* y marcar la versión 3.5.0 en opciones avanzadas.

   ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-22c4c885ba699b5aee208ca202cc4dca0788f4c7%2Fimage53.png?alt=media)

**Figura 43.- Paso “NuGet restore” de la definición de la build**

3. En el paso “Build Solution”, indicar el valor: *$/Taskin/dev/src/ElGuerre.Taskin.sln*, en el campo “Solución”.
4. Establecer el desencadenante (o *Trigger*) que lanzará la *build*. Por defecto no se establece ningún valor, lo que indicará que únicamente se lanza de manera manual. Estableceremos un horario nocturno.

   ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-3a63083166b9c400c6f38f843db53d976c5c3d73%2Fimage54.png?alt=media)

**Figura 44.- Pestaña “Trigger” de la definición de una Build**

4. Guardar nuevamente y ejecutar el proceso de compilación poniéndolo en la cola (“Queue New Build…”).
5. Esperar a que la *build* sea ejecutada por un agente libre. Al tratarse de VSTS, estamos trabajando con recursos en la nube (o *Cloud*), y además de manera gratuita. Esto puede implicar algunas demoras en el comienzo de ejecución de las *builds*.

   ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-fd30ec30c1917c01c9b397506cc2922180546b65%2Fimage55.png?alt=media)

**Figura 45.- Build completada con éxito en el portal de VSTS Build & Release**

Nuestro proyecto Task\[in] está listo para comenzar a implementar los requerimientos y para dar forma a la interfaz de usuario que estuvimos definiendo a lo largo del capítulo tres. En el siguiente capítulo, comenzaremos por los requisitos y páginas más fáciles a la misma vez que seguiremos conociendo buenas prácticas.