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.
- 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í.
- 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“.
- 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.
- 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 trigger para el Continuous Deployment a partir de la build.
- 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.
Espero que sirva de utilidad y, principalmente para entender el proceso de CI y CD en un vistazo rápido.
Happy Azure DevOps
Juanlu