From GitHub to Azure App Service through Jenkins pipelines

Desde mi punto de vista Azure DevOps es quizas una de las mejores herramientas como orquestadora de Pipelines para DevOps, al menos con la que me siento más cómodo trabajando y para mi, la mas fácil. Si bien, hoy vamos a ver como trabajar con Jenkins para conseguir el mismo objetivo que ya vimos en el post anterior (con Azure DevOps) y para la aplicación MyBudget.

Configuración

Aunque podemos descargar e instalalar localmente Jenkins, vamos a optar por una instalación en Azure.

  • Crear un nuevo recurso (Create a resource)
  • Seleccionar Jenkins
  • Pulsar el boton de crear y completar los pasos indicados hasta finalmente pulsar “OK”.

Creación de un nuevo recurso “Jenkins” en Azure

  • Una vez creado el servidor Jenkins, tendremos acceso a la VM. Por defecto el protocolo de acceso es HTTP, por lo que no podremos acceder directamente a traves navegador a la url “xxx.cloudapp.azure.com“. Por tanto, tendremos que hacerlo via localhost mediante ssh de la forma: ssh -L 127.0.0.1:8080:localhost:8080 username@xxxwesteurope.cloudapp.azure.com, tal y como muestra la siguiente imagen:

  • En estos momentos ya podremos acceder al portal de jenkins vía http://localhost:8080, si bien para poder compilar la aplicación MyBudget, necesitaremos instalar el SDK de NetCore para Linux (Ubuntu) utilizando para ello las siguentes instrucciones.

Para conocer la distribución de linux para la que actualizar el SDK, podemos ejecutar el comando “cat /proc/version” desde la consola Cloud Shell.

wget -q https://packages.microsoft.com/config/ubuntu/16.04/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-2.2

  • Adicionalmente y para que Jenkins pueda acceder y desplegar en Azure App Service, necesitamos dos plugins que podemos instalar desde el menú: Manage Jenkin – Manage Plugins:
    • Azure Credentials
    • Azure App Service Plugin

Pipeline

Ahora que ya tenemos todo configurado, crearemos el Pipeline, cuyo objetivo es compilar y ejecutar los tests unitarios de forma automática (CI – Continuous Integration) tras cada push/merge en la rama “master”, para a continuación, disparar el proceso de CD (Continuous Deployment) para el despliegue a DEV de manera automática y a Producción, previa aprobación. Supondremos que nuestros dos Azure App Services (para DEV y PROD) han sido creados previamente.

En primer lugar creamos una nueva credencial para el acceso a Azure (gracias al plugin “Azure Credential”):

  • Desde el terminal Cloud Shell de Azure, ejecutar las siguientes dos instrucciones:
    • az account set –subscription “<AZURE SUBSCRIPTION NAME>”
    • az ad sp create-for-rbac –name “MyBadget” –password <PASSWORD

  • Con el resultado de dichos comandos completar la siguiente información para añadir así la nueva credencial de tipo “Microsoft Azure Service Principal“, donde:
    • Client ID, se corresponde con el appId.
    • Client Secret, con el password.
    • Tenat ID, con el tenant y,
    • Subscription ID, con la subscripción de Azure, que también podemos obtener con la instrucción “az account show“.
  • Pulsar en “Verify Service Principal” para asegurar que la credencial es correcta.
  • Pusar en “OK”.

Las dos intrucciones anteriores registran una nueva aplicación (“MyBadget”) en el Directorio Activo de Azure. Navegando a ella, podemos ver también los valores de los parámetros antes introducidos.

  • Crear un nuevo Pipiline con el nombre “MyBudget-CI-CD”.
  • Parametrizar el proyecto marcando el check “This project is parameterized” y crear los siguientes parámetros:
    • RESORCE_GROUP, con el valor correspondiente al nombre del Resource Group de azure donde se encontraran los Azure App Services destino del despliegue: mybudget.
    • APP_NAME_DEV con el valor “mybudgetdev” y, APP_NAME_PROD con el valor “mybudgetprod“. Donde ambos parámetros se corresponden con el nombre del Azure App Service y que a su vez forma parte de la url: https://<APP_NAME_DEV|APP_NAME_PROD>.azurewebsites.net.
    • AZURE_CREDENTIAL_ID, del tipo “Microsoft Azure Service Principal” y requediro y selecciónar la credencial previamente creada: “Azure-Enterprise-MyBudget“.
  • Marcar el check “Github hook trigger for GITScm polling”.
  • Crear el script para la Pipeline (Declarativo).

pipeline {
    agent any
    stages {
        stage('Checkout git repo (DEV)') {
            steps {
                git branch: 'master', url: params.GIT_REPO
            }
        }
        
        stage('Build and Publish') {
            steps {
                sh(script: "dotnet publish MyBudget.sln -c Release", returnStdout: true)
            }
        }
        
        stage('Deploy to Azure (DEV)') {
            steps {
                azureWebAppPublish azureCredentialsId: params.AZURE_CREDENTIAL_ID, 
                resourceGroup: params.RESOURCE_GROUP, 
                appName: params.APP_NAME_DEV, 
                sourceDirectory: "MyBudget/bin/Release/netcoreapp2.2/publish/"
            }
        }
        
        stage('Deploy to Azure (PROD)') {  
            steps {
                input 'Do you approve deployment to PRO?'
                
                azureWebAppPublish azureCredentialsId: params.AZURE_CREDENTIAL_ID, 
                resourceGroup: params.RESOURCE_GROUP, 
                appName: params.APP_NAME_PROD, 
                sourceDirectory: "MyBudget/bin/Release/netcoreapp2.2/publish/"
            }
        }        
    }
}

Aunque hemos optado para este post la opción “inline” para la creación de la Pipeline, la recomendación es usar un fichero “jenkinsfile” dado que el repositorio de código fuente jugará un papel importante en el mismo al igual que para el resto de código de nuestra aplicación.

Continuous Integration/Delivery

Para configurar la Integración continua (CI) en Jenkins, y así poder disparar el Pipeline automáticamente, es necesario incluir un Webhook en el repositorio de github, a traves de la opción: “Settings – Webhooks” y añadiendo el sufijo “/github-webhook” a la url de Jenkins:

Finalmente si hacemos un cambio en el código y un push a “master”, el Pipeline se activará debido al Webhook en Github y el proceso de CI/CD dará comienzo.

En el ejemplo, para el despliegue a “PROD” se ha incluido la aprobación, al igual que en el post anterior con Azure DevOps.

Happy DevOps
Juanlu

Nota: No olvidemos apagar la VM cuando no la usemos para ahorra créditos de Azure.

Referencias:

From GitHub to Azure App Service through Azure DevOps pipelines

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-21.png

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:

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.

Build en ejecución tras un PR a “master”

Tras la finalización de la Build, Release en ejecución y aprobación pendiente para Producció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

[Video Tip]Análisis estático con Sonar Lint y servidor privado Sonar en Azure App Service (Linux)

Muy buenas,

En esta ocasión veremos como realizar el análisis estático de nuestro código y como sacar mayor partido haciendo uso de Sonar como servidor, aunque también veremos que no es realmente necesario.

¿Quieres ver un vídeo explicativo a modo de DEMO? Si es así, puedes acceder directamente a partir de este enlace. En caso contrario, sigue leyendo para leer brevemente un resumen.

Sin usar un servidor sonar.

Para llevar a cabo el análisis estático de código en nuestra solución seguiremos los siguientes pasos:

1.- Añadir el paquete NuGet: SonarAnalyzer.CSharp.

image

2.- Incluir en nuestra solución un fichero Demo.RuleSet.

3.- Configurar las reglas, tanto las específicas de Microsoft, como hasta ahora hacemos en nuestros proyectos, así como las nuevas añadidas por sonar, que distinguiremos fácilmente dado que tienen la nomenclatura “Snnnn”.

image

4.- Finalmente, recompilar para analizar y posteriormente revisar el código.

image

Usando un servidor Sonar.

1.- Instalar la extensión “SonarLint for Visual Studio 2017”.

image

2.- Abrir la solución y realizar la conexión con el servidor Sonar.

image

3.- Tras la conexión, vincularemos la solución a proyecto Sonar previamente creado desde el propio servidor.

4.- Finalmente, el fichero de reglas “.ruleset”, se creará automáticamente.

image

5.- Al igual que para el caso anterior (sin servidor), configurar las reglas y compilar para comenzar a analizar y revisar el código.

Happy testing!

Un saludo
Juanlu, ElGuerre