> 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-1-antes-de-comenzar.-la-puesta-a-punto/las-herramientas.md).

# Las herramientas

La principal de todas las herramientas es Visual Studio 2015 *Update 3*, Visual Studio 2017 o superior. Utilizando siempre la versión más reciente, sacaremos el máximo partido a nuestro desarrollo aprovechando, además, sus nuevas características y funcionalidades. La usaremos en los distintos capítulos en la medida en que la vayamos necesitando.

Existen varias ediciones de Visual Studio: *Professional*, *Enterprise*, además de las ediciones *Express* con funcionalidad limitada. En función de nuestras posibilidades optaremos por una u otra, y en caso de ser estudiante, educador o formar parte de una institución académica, entonces, estamos de suerte, existe a nuestra disposición *Visual Studio* *Community* que es la edición gratuita. Además, podremos contar con el programa de Microsoft, *Dream Spark*[¹](/de0an/capitulo-1-antes-de-comenzar.-la-puesta-a-punto/que-hemos-aprendido.md#notas) para optar a otros productos gratuitos.

Sea cual sea nuestra elección, tengamos un poco de paciencia a la hora de instalar el software principal, hay que dejarlo todo listo antes de comenzar con el desarrollo.

## Visual Studio

En la página de Microsoft (<http://www.visualstudio.com/en-us/downloads>) encontramos todas las versiones del producto, donde, una vez descargada, iniciamos la instalación y seguimos los siguientes pasos:

1. Aceptamos los términos de licencia en la ventana inicial.
2. Seleccionamos los componentes a instalar. Para nuestro desarrollo a lo largo del libro, bastará con los marcados en la siguiente imagen.

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

**Figura 03.- Selección de componentes al instalar Visual Studio**

3. Pulsamos "Next" y a continuación “Install” y esperamos a que se complete el proceso de instalación.
4. Cuando el proceso haya finalizado, encontraremos los iconos de acceso directo en la pantalla de inicio, que podemos agrupar, por ejemplo, como “Development”:

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

**Figura 04.- Accesos directos a herramientas de Visual Studio 2015**

Podemos comprobar que, además de Visual Studio, se ha instalado *Blend for Visual Studio*. Se trata de la versión más reciente del antiguo *Microsoft Expression Blend 4*. Ésta, nos permitirá diseñar nuestras páginas aportándole un aspecto más amigable y acorde a nuestros gustos. ¡Eso sí, cuidado, si eres como yo, revisa algunos tutoriales para que tu diseño no resulte desastroso, excesivamente llamativo o incluso aburrido! Aun así, no te preocupes por el momento, tenemos todavía mucho camino por delante hasta llegar a ese punto.

{% hint style="info" %}
**Nota**: Es posible que necesitemos actualizar el SDK de Windows y Windows Mobile. Si es así, lo haremos desde aquí <https://developer.microsoft.com/es-es/windows/downloads>.
{% endhint %}

## Team Services

Team Services (hoy Azure DevOps Services; conocido, anteriormente como Visual Studio Team Services, o Visual Studio Online), es la versión en la nube de TFS (Team Foundation Server) que proporciona de manera **gratuita** funcionalidades para la gestión de código fuente y versionado, servidor de compilación y la gestión de Elementos de Trabajo o *Work items* (Tareas, Bugs, Test cases, etc.). Estos elementos están relacionados con la metodología de desarrollo la cual tendremos que elegir en el momento de la creación del nuevo Proyecto de Equipo (o ***Team Project***).

Es muy común denominar a Visual Studio Team Services como **TS** o **VSTS** para abreviar, así que también lo veremos a lo largo del libro de esta otra forma.

### Trabajando y conectando con Team Services

Para comenzar a trabajar con TS necesitaremos completar algunos pasos previos:

1. Acceder a Visual Studio Dev Essential mediante el enlace, <https://www.visualstudio.com/products/visual-studio-dev-essentials-vs>
2. Unirse o acceder
3. Registrarse y crear de manera gratuita una cuenta de TS utilizando para ello un nombre identificativo y fácil de recordar. Por ejemplo, “juanluisguerrero”. Dicho nombre se corresponderá con el prefijo de la URL a través de la cual accederemos posteriormente al nuevo servicio TS, en la nube.

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

**Figura 05.- Creación de una cuenta TS y Proyecto de Equipo**

4. Indicar el nombre de nuestro primer Proyecto de Equipo (*o Team Project*): **Task\[in]**. Adecuar el resto de valores, al igual que se muestra en la imagen anterior.
5. Una vez creado, se mostrará una ventana de confirmación desde la cual se accederá bien a la gestión del trabajo, bien al código, o bien cerrando la ventana a la pantalla de bienvenida (o Home):

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

**Figura 06.- Primer acceso al Equipo de Proyecto “Task\[in]”**

6. El siguiente paso es acceder a Visual Studio e introducir las credenciales de la cuenta de TS usando para ello la opción de menú “Team – Manage Connections…” e introducir como servidor, el valor introducido en el paso 2 seguido del sufijo “.visualstudio.com”. Finalmente pulsar OK.

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

**Figura 07.- Conexión a TS desde Visual Studio**

7. También tenemos la posibilidad de crear un nuevo Proyecto de Equipo desde el Explorador de Equipos (o ***Team Explorer*****)**, concretamente desde la opción: “HOME – Projects and My Teams – New Team Project…”.

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

**Figura 08.- Creando un Team Project desde Team Explorer**

8. A continuación, accederemos al formulario web para la creación del mismo, donde introduciremos el nombre y descripción de nuestro proyecto.

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

**Figura 09.- Creando un Team Project en TS desde Visual Studio**

De cualquiera de las maneras anteriores, dispondremos ya de nuestro Proyecto de Equipo. Podremos comenzar a trabajar con él y hacer uso del repositorio de código fuente. Accederemos al mismo a través del Explorador de Código Fuente (o ***Source Control Explorer***), donde configuraremos el espacio de trabajo creando un mapeo con una ruta física del PC.

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

**Figura 10.- Configuración del espacio de trabajo**

*Source Control Explorer*, es una estructura de proyectos y carpetas con opciones y acciones específicas que poco a poco iremos viendo. En la siguiente figura puede verse la forma que va a tener nuestro proyecto Task\[in]. Inicialmente tan sólo aparecerá la carpeta BuildProcessTemplates\*,\* pues se crea por defecto. La carpeta **main** será creada en la siguiente sección o epígrafe.

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

**Figura 11.- Source Control Explorer en Visual Studio**

En este momento, ya tenemos todo listo para que el código pueda ser gestionado, versionado, etiquetado o comparado con otro más antiguo, que probablemente funcionaba mejor ¡Si éste es tu caso, pon atención para ver si tiene sentido lo que estás haciendo…!

TS también tiene la posibilidad de trabajar con un repositorio ***Git*** (como hemos podido observar en las figuras anteriores) en lugar de *Team Foundation Version Control* (**TFVC**). Para llevar a cabo el desarrollo de nuestra aplicación se ha optado por TFVC. En futuras aplicaciones, elegiremos aquél con el que nos sintamos más cómodos. No importa cuál sea, lo importante es que el código esté siempre “a buen recaudo”.

{% hint style="info" %}
**Nota**: Se recomienda no comenzar nunca un desarrollo sin una herramienta de gestión de control de código fuente. TFVC y Git están integrados en TS, pero siempre podremos optar por otros como, el antiguo Visual Source Safe, Subversión, CVSNT, Open CVS, ClearCase, PVCS, BitKeeper, etc.
{% endhint %}

Veremos a continuación los conceptos de *Branching* y *Merging*. Se trata de conceptos importantes para que la aplicación o el producto que estamos desarrollando puedan ir evolucionando de manera organizada y controlada.

### Branching y Merging

Cuando se emplean estos conceptos, se habla de ramas (directorios o carpetas de TFS o TS) e implícitamente de *Continuous Delivery*, es decir, la evolución continua del producto.

El objetivo de estas ramas es preparar el código fuente para cada una de las versiones de su proceso de evolución. Aunque esto parece fácil, también puede ocurrir que mientras se desarrolla una nueva versión, en otra liberada previamente, se detecte algún *bug* que deba solucionarse. ¿Qué hacer en ese caso? ¿Basta con un simple copiar y pegar en ambas versiones? Todo buen programador está de acuerdo en que duplicar código no es una buena práctica, sino más bien todo lo contrario.

Esto nos lleva al proceso de *Branching* y *Merging,* con los cuales, es posible evolucionar y mantener código sin necesidad de tener que repetirlo y, siempre, desde el punto de vista de la organización, control y versionado adecuado.

Aunque existen diferentes estrategias, éstas dependen de las necesidades de evolución, es decir, es posible optar por: una única versión por producto (**plan básico**), varias versiones por producto, versionado por características, versiones por *Hotfixes*, etc.

A la hora de desarrollar código, hay que tener en cuenta que éste pasará por una serie de fases; desarrollo, producto y versiones, estando cada una de ellas asociada a una rama: **dev**, **main** y **release** respectivamente. Estos son sólo nombres, y aunque es posible cambiarlos, se recomienda no hacerlo y mantener así los convenios y buenas prácticas establecidas por grandes expertos en el tema.

{% hint style="info" %}
**Nota**: Al comenzar a escribir el código, partir siempre de la carpeta **main** (principal), que es la rama más importante. Será ésta, a partir de la cual se realizarán los *Branching* y por la que se volverá a pasar al hacer los *Merging*.
{% endhint %}

Siguiendo los pasos indicados, a continuación, aprenderemos cómo conseguirlo:

1. Crear una nueva carpeta cuyo nombre sea **main**.

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

   **Figura 12- Nueva carpeta desde el Source Control**
2. Aplicar la acción “Check In Pending Changes” sobre la nueva carpeta **main**. El significado de esta acción lo veremos en la siguiente sección.
3. A partir de **main**, crear una nueva rama **dev**. Lo que permite establecer un vínculo entre ambas ramas además de copiar el contenido entre ellas. Como por el momento no hay ningún fichero de código, la nueva rama **dev** tampoco lo tendrá.

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

**Figura 13- Nuevo Branch desde el Control de Código Fuente**

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

**Figura 14.- Branch “dev” desde el Control de Código Fuente**

4. A partir de este mismo instante, será la rama **dev** sobre la que comenzaremos a trabajar. En capítulos posteriores veremos el proceso de *Merging*, por el momento basta considerarlo como el proceso por el cual el contenido de la rama **dev** vuelve a pasar a la rama **main**, realizando una “mezcla” entre ellas y dejando siempre como resultado en esta última el código más reciente.
5. Partiendo nuevamente de la rama **main**, crearemos la rama **release** de la misma forma que para la rama **dev**.

El siguiente plan de *Branching*, es el plan básico y es la base para llevar a cabo nuestra aplicación de ejemplo. Dicho plan lo encontraremos detallado al igual que muestra la siguiente figura, en la guía: “*ALM Rangers - Visual Studio Branching and Merging Guide*[²](/de0an/capitulo-1-antes-de-comenzar.-la-puesta-a-punto/que-hemos-aprendido.md#notas)*”*.

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

**Figura 15.- Plan básico de Branching y Merging**

{% hint style="info" %}
**Nota**: El proceso de *Merging* puede resultar complejo, y aunque el control de código fuente facilita este proceso, se recomienda efectuarlo constantemente, por ejemplo, siempre que se completen ciertas funcionalidades o requisitos. Así, esta tarea resultará mucho más fácil.
{% endhint %}

### Check In y Check Out

Tras haber mejorado el código de acuerdo a una serie de buenas prácticas, ya sólo queda el último paso para tenerlo en lugar seguro. En estos momentos el código está en nuestro PC (en local), sin embargo, es necesario trasladarlo al servidor para lo cual usaremos la acción de *Check In*. De esta manera, el código al que apliquemos esta acción se almacenará en el servidor manteniendo un histórico del mismo. Es importante, por tanto, hacer *Check In* cada vez que se completen funcionalidades en el código y **siempre**, una vez que el código haya sido compilado con éxito. Lo ideal sería que, además, haya pasado con éxito un mínimo número de pruebas unitarias.

Recordemos que no siempre trabajaremos solos y, por tanto, el código que añadamos al repositorio tiene que estar libre de errores. Evitaremos esfuerzos innecesarios a nuestros compañeros y comenzaremos así a asentar las bases para un buen trabajo en equipo.

De la misma manera que para proteger el código se emplea el proceso de *Check In,* para desprotegerlo y volver a trabajar sobre él, usaremos *Check Out*. La configuración por defecto de esta acción, obtendrá automáticamente la última versión del fichero, es decir, incluirá todos los cambios realizados por los miembros del equipo.

Tampoco debemos pasar por alto, la buena práctica de aplicar un **etiquetado** a nuestros ficheros. Obtendremos una instantánea de un conjunto de ficheros en un momento dado y con el fin de poder consultarlos o recuperarlos posteriormente.

{% hint style="info" %}
**Nota**: TS y TFS tiene la opción, *Shelve Pending Changes*, que permite subir código al servidor sin tener que hacer *Check In*. La diferencia es que *Shelve* no integra los cambios en el desarrollo en curso, simplemente, almacena los cambios pendientes en una zona del servidor habilitada para cada desarrollador. Podremos volver a retomar estos mediante la acción *Unshelve* cuando estemos en disposición de hacer el *Check In* adecuado.
{% endhint %}