From GitHub to Azure App Service through Azure DevOps pipelines

En post anteriores vimos como compilar, ejecutar tests y lanzar la cobertura de código desde línea de comandos e incluso ejecutamos el análisis estático con Sonarqube:

Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator» y
«Code Analysis and Code Coverage using NetCore + VS Code & publishing to Sonarqube (sonarcloud.io)«),

pues bien, en éste veremos como hacer todo esto en Pipelines de Azure DevOps y además, concluiremos con una publicación en dos entornos (Development y Producción) basados en Azure App Service. En resumen, vamos a construir un sistema de CI y CD, para el que seguiremos los siguientes pasos, teniendo en cuenta como en ocasiones anteriores que nuestro código se encuentra en Github y concretamente aquí (MyBudget):

Configurar «Azure Pipelines» en GitHub buscándo esta carácterística en el Marketplace y eligiendo el plan gratuito.

Desde el Portal de Azure (aunque podemos elegir otra alternativa), crear dos Azure App Services (mybudgetdev y mybudgetpro) basados en Windows.
Nota: Podríamos optar por crear un sólo App Service con dos Slots, si bien, supondría un coste que con el plan básico de los App Services no exite.

Plan básico (Free) para la creación de Azure App Services

Creando Azure App Services (Windows) desde el Portal

Crear las Pipelines en Azure DevOps. Una para Build y otra para Release.
Nota: Si no disponemos de ningún proyecto Azure DevOps, lo creamos siguiendo los pasos detallados aquí.

Seleccionar como origen de código «GitHub»

Seleccionar la plantilla «Azure Web App fro ASP.NET»

Crear y deshabilitar las opciones de publicación a Azure App Service

Actualizar el paso «VsTest – testAssemblies«, como sigue, para la propiedad «Test Files»:

**\bin\$(BuildConfiguration)\**\*test*.dll
!**\obj\**
!**\xunit.runner.visualstudio.testadapter.dll !**\xunit.runner.visualstudio.dotnetcore.testadapter.dll

Guardar y ejecutar («Queue») la build. Nota: Podríamos haber optado por no deshabilitar esta publicación/deploy, si bien, queremos separar build (CI) de Deploy (CD) y conocer así, el funcionamiento de una Release.
Seleccionar la opción de menú: Pipelines – Release y crear una nueva release (+ new release pipeline) y pulsar «Apply» para la plantilla «Azure App Service deployment«.

Crear nueva release para la plantilla «Azure App Service deployment»

Establecer el nombre del Stage como «Development».
Marcar el artefacto origen que lanzará la release, que en este caso se corresponde con la build anteriormente creada.

Nombrar al Stage como «Development» y seleccionar la build a partir de la cual se generará la release

Configurar el State «Develpment», y seleccionar una subscripción de Azure.
Optar por el tipo de App Service basado en Windows.
Seleccionar el App Service «mybudgetdev«, dejando el resto de valores por defecto.

Configurar el stage «Delopment» y seleccionar el App Service «mybudgetdev»

Configurar el trigger para el Continuous Deployment a partir de la build.

Configurar el trigger para el Continuous Deployment (CD)

Crear un nuevo Stage «Production» seleccionado nuevamente la plantilla «Azure App Service deployment» y configurar el Stage al igual que el anterior, seleccionando en este caso el App Service «mybudgetpro«.

Clicar sobre el icono (persona) del Stage de Production y marcar como triger «Afer stage» seleccionando «Development» como Stage anterior.
Habilitar también «Pre-deployment approvals» e introducir el email del aprobador, que será quien de el OK para el despliegue al entorno de Producción. Nota: Utilizamos esta opción simplemente por simular un Continuous Delivery, es decir, el requerimiento de un paso/despligue a Producción previa aprobación.

Finalmente, tras hacer un commit en la rama «develop» de git y tras un PR a la rama «master», nuestrá build se ejecutará de manera automática y tras ella, el proceso de Continuous Deploy comenzará también su ejecución.