Fixed Buffer

Herramientas de desarrollo: Azure Pipelines

JorTurFer 19 febrero, 2019 No hay comentarios

Hace un par de semanas, empezamos esta serie sobre Integración Continua y Despliegue Continuo (CI/CD) con Travis CI y una pequeña explicación sobre que es la integración continua. Como comentábamos, a lo largo de estas entradas, vamos a hablar de los principales servicios de CI/CD, y hoy es el turno de Azure Pipelines, herramienta que forma parte de Azure DevOps. Para quien no lo conozca, es un conjunto de herramientas para trabajo colaborativo de Microsoft, que además es gratuito para fines Open-Source.

Creando el proyecto en Azure DevOps

Para poder utilizar esta herramienta, vamos a la web de Azure DevOps (si no nos hemos registrado, tendremos que hacerlo) y vamos a crear un proyecto:

Esto nos lanza una segunda ventana, donde tendremos que elegir el nombre del proyecto y si queremos que sea público o privado, en este caso, lo elegimos público y pulsamos en “Create”:

Con esto, hemos creado un repositorio en Azure DevOps, el cual nos permite gestionar nuestro código como lo podrían hacer unos servicios como GitHub o GitLab, pero la parte que nos interesa es la de crear un pipeline, así que seleccionamos sobre el:

Vamos a crear nuestro pipeline

Simplemente pulsamos en “New pipeline”

Esto nos va a mostrar un sencillo asistente, en el cual, primero seleccionamos desde donde va a coger el código, en nuestro caso, GitHub.

Esto nos mostrará los repositorios disponibles si ya nos hemos conectado, y si no, nos mostrará un botón para autorizar.

Una vez autorizado, simplemente elegimos nuestro proyecto, y esto nos muestra un control donde tenemos que escribir nuestro .yml (igual que hacíamos en los demás CI), en nuestro caso, hemos utilizado el mismo proyecto en el que hablamos sobre mocking, por lo tanto, al ser NetCore, podemos compilarlo y ejecutar sus pruebas en Windows, Linux y MacOS (si fuese .Net Framework, solo podríamos con Windows y los comandos serían ligeramente diferentes), así que nuestro .yml podría ser algo como esto:

# Matriz de máquinas que vamos a utilizar
strategy:
  matrix:
    linux:
      imageName: 'ubuntu-16.04'
    mac:
      imageName: 'macos-10.13'
    windows:
      imageName: 'vs2017-win2016'

# Configuramos el pool con la imagen
pool:
  vmImage: $(imageName)

# Variables que vamos a necesitar (podemos definir tantas como queramos)
variables:
    solution: '**/*.sln'
    testProject: '**/PruebasUnitarias.csproj'
    buildConfiguration: 'Release'
    netCoreVersion: '2.2.103'

# Pasos a ejecutar
steps:

# Instalar Nuget
- task: [email protected]

# Instalar la versión de NetCore que hemos definido en las variables
- task: [email protected]
  inputs:
    version: '$(netCoreVersion)'

# Ejecutar un 'nuget restore'
- task: [email protected]
  inputs:
    restoreSolution: '$(solution)'

# Lanzamos el comando de compilación
- task: [email protected]
  inputs:
    command: build
    projects: '$(solution)'
    arguments: '--configuration $(buildConfiguration)' 

# Lanzamos el comando de test
- task: [email protected]
  inputs:
    command: test
    projects: '$(testProject)'
    arguments: '--configuration $(buildConfiguration)'

En caso de que esto no sea suficiente, dejo también un enlace hacia la documentación oficial.

Con esto, si todo ha ido bien, deberíamos poder ir a la pestaña “Builds” y en ella ver nuestra integración en ejecución.

Si pulsamos sobre la compilación, nos mostrará el resultado en el que podemos ver la ejecución de nuestros 3 jobs (uno en cada sistema operativo), con los resultados de la ejecución de cada una de las instrucciones que le pusimos en el “.yml”.

Por último, solo nos queda ya poder añadir esa badge tan chula a nuestro proyecto, para que todo el mundo sepa que todo está bien, para eso (lo han puesto un poco escondido…), vamos a los 3 puntos que tenemos arriba a la derecha.

Pinchamos sobre Status Badge, y nos muestra una nueva ventana con el código listo para copiarlo y pegarlo en nuestro Markdown.

Con esto, hemos conseguido que nuestro repositorio ejecute la integración continua, de modo que, cada vez que hagamos un “push”, se lance automáticamente la integración en Azure Pipelines.

Igual que con Travis CI, cuando añadimos esto, se añade a nuestro repositorio de GitHub los checks en cada “push” que indican si la integración ha ido bien:

Además de lanzarse (al igual que con Travis CI) en cada Pull Request.

Como último dato, se puede utilizar más de un servicio de integración continua sin ningún tipo de problema al mismo repositorio (como se puede ver en la imagen de arriba en la que están Travis CI, AppVeyor y Azure Pipelines).

En las siguientes entradas de esta serie, veremos cómo podemos utilizar estos mismos sistemas de integración continua, para hacer el despliegue de nuestro proyecto, por ejemplo a Nuget.org o Azure WebApp, consiguiendo así automatizar todo el proceso de manera cómoda.

Herramientas de desarrollo: Travis CI

JorTurFer 5 febrero, 2019 No hay comentarios

Hace ya unos meses, hice mis primeras publicaciones sobre tecnología en el blog de un compañero de trabajo, y en ellas hablaba de una práctica que por desgracia, sigue siendo una gran desconocida cuando hablo con gente que se dedica al software. Me estoy refiriendo a la integración continua (CI).

Si bien es cierto, que las pruebas unitarias tienen una funcionalidad clara, no valen de nada si no las ejecutas. Esto puede pasar por muchas razones, pero una de ellas (al menos la que más me suele afectar a mi), es que trabajas sobre una funcionalidad que hay que pasar a la rama principal urgentemente y no hay tiempo de lanzar todas las pruebas unitarias. Durante el desarrollo de esa característica, compruebas que todo funciona bien, y subes tus cambios tranquilo, hasta que de repente… ¡¡Algo se ha roto en otro sitio!!

Gracias a herramientas como AppVeyor , Travis CI o Azure Pipelines, (los 3 son gratis si nuestro repositorio es público) podemos conseguir automatizar este trabajo, de modo que no tengamos que preocuparnos de compilar y ejecutar las pruebas. Ademas, estos sistemas nos aportan otra ventaja adicional, podemos compilar y ejecutar pruebas en diferentes entornos, como veremos a lo largo de esta entrada sobre Travis, y la siguiente que será sobre Azure Pipelines (y como se puede ver en mi colaboración en MascandoBits sobre AppVeyor).

Antes de continuar, es un buen recordar la entrada sobre Mocking (¡o leerla sin aun no lo has hecho!), ya ahora vamos a ver las ventajas de no depender de recursos externos para ejecutar las pruebas unitarias. De hecho, vamos a utilizar ese mismo repositorio para incluir la integración continua con Travis y Azure Pipelines al ser un proyecto NetCore (podemos ejecutarlo en Windows, Linux y MacOS) y tener pruebas unitarias.

Funcionamiento de los servicios CI

En primer lugar, podemos preguntarnos como funcionan estos sistemas de CI. Si utilizas GitHub es muy simple, están totalmente integrados, y con unos pocos clicks podemos hacer que cada vez que hagamos un push al repositorio (o nos manden un Pull Request), automáticamente se lance la compilación y ejecución de las pruebas del código, sin tener que preocuparnos de nada más. Ademas, estos servicios suelen trabajar usando un fichero de configuración “.yml”, en el cual definimos todos los pasos que queremos ejecutar, de modo que es fácil reutilizar las configuraciones en nuestros diferentes proyectos con unos cambios mínimos. Una vez terminen, veremos en el historial de commits un indicador de si la integración ha ido bien o no, al igual que en los PR:

Ademas, estos servicios suelen permitirnos utilizar badges que podemos añadir a nuestro readme.md para saber siempre a simple vista el estado del proyecto:

Añadiendo Travis CI a nuestro repositorio

Para añadir nuestro repositorio a los trabajo de integración de Travis, en primer lugar, vamos a ir a su web y vamos a pulsar en el botón de registrarnos con GitHub. Nos lanzará una ventana para confirmar que autorizamos la consulta de datos desde GitHub, y una vez aceptemos, nos mostrará una ventana (¿vacía?) con nuestros proyectos. Lo que vamos a hacer, es pulsar sobre el botón “+” para añadir un nuevo repositorio:

Sincronizamos nuestra cuenta para que se nos muestren los repositorios, y simplemente, activamos el repositorio que nos interesa:

Con esto, ya hemos indicado a Travis que queremos que lance el CI cada vez que detecte cambios en el repositorio, y Travis se encarga de configurarlo todo en GitHub para que le notifique esos cambios. A partir de este momento, cada vez que hagamos un push al remoto, se iniciara una compilación. En este momento, fallará al no tener el “.yml”, asi que vamos a añadirlo.

Fichero .travis.yml

Vamos a crear un fichero en el repositorio que se llamará .travis.yml (el primer “.” delante de travis hay que ponerlo también). En el vamos a poner lo siguiente:

 
# Lenguaje que vamos a usar
language: csharp
dist: trusty
mono: none
# Version del SDK de NetCore que queremos utilizar
dotnet: 2.1.301
# Matriz de sistemas operativos sobre los que queremos lanzar el CI
os:
  - linux
  - osx
# Comando que queremos ejecutar ANTES de compilar  
install:
- dotnet restore
# Script de compilacion
script:
  # Compilamos el proyecto
- dotnet build
  # Ejecutamos las pruebas unitarias
- dotnet test PruebasUnitarias/PruebasUnitarias.csproj
# No queremos que nos notifique por email los resultados
-notifications:
-  email: false

Si nos fijamos, simplemente le estamos indicando al servicio que es lo que queremos que haga. Le indicamos el lenguaje, le indicamos la versión del SDK, y los sistemas operativos sobre los que trabajar.
En el script de instalación (previo a compilar), ejecutamos un restore, para descargar los paquetes Nuget necesarios (sino, vamos a tener un fallo de compilación), y después indicamos que queremos lanzar dotnet build para compilar, y dotnet test “proyecto de pruebas” para ejecutar los test. Os dejo el enlace a la documentación para que podáis consultarla si queréis hacer cosas más concretas.

Una vez que hemos añadido el fichero, commit y para el repositorio, con lo cual, se iniciará automáticamente el trabajo. Si todo va bien, una vez que termine, si vamos a travis, veremos algo como esto:

Como comentaba antes, Travis nos permite generar badges para saber el estado del repo, esto se hace tan fácilmente como pulsando sobre el badge, y nos mostrara una ventana para seleccionar donde lo queremos poner. Simplemente, tenemos que seleccionar donde lo vamos a colocar, y nos dará el código copy-paste.

Con esto, ya tenemos una primera aproximación a la Integración Continua con Travis CI. En las siguientes entradas de esta serie sobre CI/CD, veremos Azure Pipelines, y hablaremos sobre el despliegue continuo (CD), que es tan facil como el CI, y nos permite por ejemplo, automatizar la publicación de paquetes nuget, webs, subir los binarios a un FTP, etc…

SourceLink: Depuración de código bajo demanda

JorTurFer 1 febrero, 2019 No hay comentarios

Después de la última entrada en colaboración con VariableNotFound, volvemos a la normalidad, y hoy vengo a hablaros de una herramienta relativamente nueva, que me parece muy interesante conocer para nuestros proyectos, esta herramienta es SourceLink.

¿Y que es esta herramienta?, te puedes estar preguntando, pues fácil, es una herramienta de descarga de código bajo demanda, la cual nos permite que si quien desarrolla el paquete hace los deberes (hay que dar tiempo de adaptación también eh, ¡no nos pongamos nerviosos!), nosotros podamos entrar a depurar el código fuente, porque este se nos descargue automáticamente desde el repositorio. Ojo, esto lo que nos permite es entrar y seguir la ejecución, no modificar el paquete en sí mismo, pero esto al menos, nos permite saber si el fallo es nuestro o del autor. (Y creedme, ¡esto es mucho mejor que tener que descargarse el proyecto entero y depurarlo de verdad!)

Dicho esto, vamos a meternos en faena… ¿Como puedo habilitar SourceLink en mi Visual Studio?

Habilitar SourceLink en Visual Studio

Esto en realidad es muy fácil, simplemente tenemos que ir al menú “Herramientas→Opciones”, y dentro de la ventana que nos abre, bajar hasta “Depuración→General” y buscar “Habilitar compatibilidad con vínculos de origen”, una vez lo encontremos, tenemos que activarlo:

Con esto tan simple, ya lo hemos activado, pero ahora, vamos a ver cómo funciona. Por ejemplo, yo he utilizado un paquete Nuget que hice en su día para WoL, y que hace unas semanas actualicé para dar soporte a SourceLink. Para ello, creamos un proyecto, e instalamos el paquete con el comando:

PM-> Install-Package EasyWakeOnLan

Y por ejemplo, podemos utilizar este código:


string Mac = null;
//Instance the class
EasyWakeOnLanClient WOLClient = new EasyWakeOnLanClient();
//Wake the remote PC
WOLClient.Wake(Mac);

Este código, a priori debería lanzar una excepción, ya que no le indicamos una Mac válida. A modo de comparación, vamos a ejecutarlo primero sin SourceLink:

Como podíamos prever, la librería lanza una excepción, y para nosotros, toda la información se limita a la llamada de la librería, pero si volvemos a ejecutar con SourceLink habilitado, vemos que, al llegar a la línea, nos muestra el mensaje:

Y cuando pulsamos en “Descarga el origen y continuar depurando”, vemos que el error se lanzaba en la primera línea, al intentar operar con la variable “Mac” siendo su valor null:

Hay que decir además, que no es necesario que se produzca una excepción para poder entrar a depurar el paquete, si entramos dentro del método como lo haríamos con uno nuestro, también nos permite descargar el código y depurar el paquete.

Como se puede ver, si eres consumidor de paquetería Nuget, esta herramienta es muy interesante, y yo recomiendo tenerla activada, ya que muchos paquetes hoy en día ya lo soportan, y puede ser de ayuda para encontrar el problema. Si eres el desarrollador de un paquete Nuget, esta opción también es interesante, ya que te pueden dar información más detallada sobre la issue que hay en tu código.

Más adelante hablaremos sobre cómo crear y publicar un paquete Nuget en Nuget.org o en un repositorio privado, y veremos más en profundidad que hacer para dar soporte a esta maravillosa herramienta que es SourceLink.