Herramientas de desarrollo: AppVeyor

La imagen muestra el logo de Nuget y AppVeyor

Hoy vengo con otra entrada de esas que me hacen ilusión, y es que volvemos a colaborar con José de VariableNotFound, esta vez para hablar de cómo crear paquetes Nuget (con SourceLink, por supuesto), sobre el repositorio Nuget.org, y sobre como publicar nuestros paquetes automáticamente con un sistema de CI/CD como AppVeyor.

En la primera parte de la entrada, que se ha publicado en VariableNotFound hablábamos de cómo crear un paquete Nuget con SourceLink y publicarlo en Nuget.org (si no sabes lo que es, deberías echarle un vistazo a la entrada hablando del tema). Como comentábamos al final, hacerlo a mano se hace tedioso, por eso es una buena idea utilizar una herramienta de Despliegue Continuo (CD por sus siglas en ingles).

En su momento publique en el blog de compañero de trabajo unas entradas sobre AppVeyor en las que explicaba como añadir AppVeyor a nuestro repositorio. Hoy, vamos a continuar aquella entrada añadiendo el CD hacia Nuget.org (aunque repasemos la parte que es común).

En primer lugar, nos tendremos que crear una cuenta en AppVeyor, algo que es muy fácil si tenemos cuenta de GitHub. Simplemente vamos a «Sign in» y seleccionamos iniciar con GitHub (u otros servicios).

Añadiendo AppVeyor a nuestro repositorio

Login AppVeyor

Con nuestra cuenta creada, añadimos el proyecto con el botón «NEW PROJECT»

Señala el botón de crear proyecto en AppVeyor

Y después, seleccionamos el proyecto que queremos, y pulsamos sobre el botón «Add»

Con esto, nuestro proyecto se compilará automáticamente cada vez que hagamos un «push» al repositorio y ejecutará las pruebas unitarias, aunque obviamente fallará porque aún no hemos configurado que tiene que hacer.

Para configurarlo, vamos a la pestaña «settings»

En primer lugar, en el menú «General» vamos a tener que bajar hasta casi el final, y seleccionar «On» en la opción «.NET Core .csproj patching «, con esto, vamos a conseguir cambiar la versión del paquete a la que queramos. Recordemos, qué si intentamos resubir un paquete con la misma versión que uno que ya existe, fallará. Como lo que nos interesa es que la versión se actualice y no se repita, vamos a utilizar la variable de AppVeyor «version«, la cual depende de los campos «Next build number» y «Build version format«, siendo el primero el número de compilación (es autoincremental) y el segundo la versión «Major» que queremos que tenga nuestro paquete, una vez hecho, pulsamos sobre el botón «Save» para guardar los cambios.

La imagen muestra como activar el parcheo de versión del paquete Nuget en AppVeyor

Pasamos al menú «Environment», en este solo vamos a necesitar seleccionar la imagen de Visual Studio 2017 y pulsar en el botón «Save».

La imagen muestra como seleccionar Visual Studio 2017 en AppVeyor

Ahora vamos con el menú «Build», aquí le vamos a indicar como tiene que hacer la compilación, además de ejecutar scripts para preparar los prerrequisitos que tengamos, por ejemplo, hacer un «nuget restore». Esta es quizás la parte más compleja del trabajo.

Lo primero, seleccionamos la configuración «Release» escribiéndolo en el apartado «Configuraton» al inicio, y después hay que bajar casi hasta el final para seleccionar que queremos hacer un paquete («Package NuGet projects»), que queremos incluir los símbolos para SourceLink («Include NuGet symbol packages»), y por último y muy importante (si no, no compilará), añadir un comando previo a la compilación que ejecutará un «nuget restore».

La imagen muestra la configuración del menú "Build" de AppVeyor

Con esto, tras pulsar en «Save», si hacemos cambios sobre el repositorio, podemos ver que ejecuta toda la integración continua.

La imagen muestra la salida de la consola de AppVeyor

Configurando el despliegue en Nuget.org desde AppVeyor

Por último, vamos al menú «Deployment», y añadimos un nuevo despliegue pulsando sobre «Add deployment» y seleccionando Nuget en la lista desplegable. Ahora, simplemente introducimos nuestra API Key, le decimos que no queremos publicar un paquete de símbolos, y por ultimo y MUY IMPORTANTE, como no queremos que se haga deploy de cada push, añadimos la condición de que para hacer un deploy, tiene que ser un push con un «tag», esto lo conseguimos poniendo como condición que la variable de AppVeyor «APPVEYOR_REPO_TAG» sea true.

La imagen muestra la configuración de el despliegue en AppVeyor

Si con esto pulsamos sobre salvar, y mandamos un nuevo tag al repositorio, veremos cómo al igual que si lo enviábamos manualmente, aparece disponible en Nuget.org. Como siempre, dejo el código fuente en GitHub.

En próximas entradas, hablaremos sobre como utilizar Azure Pipelines como CD además de CI y las ventajas que tiene cerrar el ciclo CI/CD.

Herramientas de desarrollo: Azure Pipelines (CI)

azure pipelines

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:

Create

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»:

Nombre Azure DevOps

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

Crear Azure Pipelines

Simplemente pulsamos en «New pipeline»

Boton New

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.

Azure Pipelines GitHub

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

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: NuGetToolI[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.

Azure Pipelines Build

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».

Resultados de Azure Pipelines

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.

Boton para Badge

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

Código Badge

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:

Historial Commits

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

Prueba PR

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

      No hay comentarios en Herramientas de desarrollo: Travis CI
netCoreTravis

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:

Historial Commits

Prueba 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:

Readme.md

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:

Add Project

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

Add Repo

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:

CI End

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.

badge url

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…