Herramientas de desarrollo: Azure Pipelines (CI)

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: NuGetToolInstaller@0

# Instalar la versión de NetCore que hemos definido en las variables
- task: DotNetCoreInstaller@0
  inputs:
    version: '$(netCoreVersion)'

# Ejecutar un 'nuget restore'
- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

# Lanzamos el comando de compilación
- task: DotNetCoreCLI@2
  inputs:
    command: build
    projects: '$(solution)'
    arguments: '--configuration $(buildConfiguration)' 

# Lanzamos el comando de test
- task: DotNetCoreCLI@2
  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.