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

Azure Ubuntu VM + SSH & RDP

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

En este post vamos a ver como crear desde Azure una máquina virtual Ubuntú y como conectarnos a ella vía SSH e incluso vía RDP para hacerlo también gráficamente. Para ello:

  • Desde el Portal de Azure (Portal.azure.com) pulsar “Create a resorce” en el menú lateral izquierdo.
  • Seleccionar la subscripción e introducir un nombre (ej.: goku).
  • Configurar la cuenta ssh donde:
  • Desde la consola (“terminal”) de comandos ejecutar los siguientes comandos. En windows podemos usar también la consola de bash (Windows WSL (“Windows Subsystem Linux”)):

ssh-keygen -t rsa -b 2048
cat .ssh/id_rsa.pub

  • Copiar el resultado del comando “cat” a exceptión del sufijo final, tal y como muestra la imagen anterior.
  • Completar y continuar los pasos del portal de Azure.

Activar puertos SSH, RDP y HTTP/S para descarga de paquetes (apt-get) desde la VM

  • Finalmente pulsar “Create” para crear la máquina virtual
  • Pulsar el botón “Connect” – “SSH” y a continuación copiar la instrucción “ssh” a ejecutar en el terminal.

Instrucción ssh para conectar con la VM (IP máquina azure)

Resultado de la ejecución ssh

  • A continuación, una vez establecida la conexión ssh, instalar XRDP y UBUNTU-DESKTOP.

sudo apt-get clean sudo apt-get update sudo apt-get install xrdp sudo apt-get install ubuntu-desktop

  • Una vez ejecutados y completados estos comandos, desde el portal de Azure y para la VM “Goku”, seleccionar la opción del menu lateral “Reset password” para introducir las credenciales necesarias para la conexión RDP.
  • A continuación seleccionar la opción “RDP” de conexión y pulsar en “Download RDP File“.

Información de conexión RDP

Completados todos los pasos, incluida la espera para la ejecución de los comandos “apt-get install …“, que son unos 15 min. aproximadamente, podremos realizar la conexión gráfica vía RDP con exíto.

Saludos and happy Ubuntu Cloud play
Juanlu

Code Analysis and Code Coverage using NetCore + VS Code & publishing to Sonarqube (sonarcloud.io)

En el post anterior (Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator), hablamos sobre la ejecución de Test Unitarios y de la cobertura de código e incluso de la generación de reports desde línea de comandos. En este Post y continuando con la línea de comandos (CLI) y con el foco/roadmap en DevOps (Jenkins, Azure DevOps, Travis, etc.), veremos como realizar un análisis estático de código y publicarlo en Sonarqube junto a la cobertura de código.

Para este caso usaremos https://SonarCloud.io como servidor gratuito y publico de SonarQube donde crearemos una organización, por ejemplo “juanluelguerre-github” y generaremos un token, que usaremos para la publicación

Partiremos del siguiente Script (Shell y Cmd) similar al del post anterior, al que hemos añadadio algunas sentencias adicionales. En concreto, y las que merecen especial atención para la publicación en Sonarqube, son las que hacen referencia a “dotnet sonarScanner”, es decir, las líneas: 15, 18 y 25.

En el parámetro “/d:sonar.exclusions”, podremos incluir todas aquellas exclusiones

Recuerda que en este post, puedes encontrar mas detalle sobre el resto de líneas de estos scrips

En post sucesivos, continuaremos trasladando todo esto a Jenkins, Azure DevOps, Travis, etc. ¡Espero una vez más que sea de ayuda!

Happy testing and good Coverage
Juanlu

New Monitor 2k for Windows & Mac with HiDPI.

Mi nuevo monitor BenQ BL2420PT de 2k

Llegó Navidad, y con ella, un nuevo monitor con el que extender mi zona ya obsoleta de trabajo como developer.

Tras conectar el monitor Full HD (1920×1080), lo primero que noté fué cambio bastante importante en la resolución y, principalmente, frente a las pantallas de los portatiles, tanto de mi Dell con Windows 10 como de mi Macbook Pro 15″, que claro cuenta con la pantalla retina de 2560×1600. Aunque parece ser que una mayoría de desarrolladores usan este tipo de pantallas, a mi, sinceramente no me convenció, por lo que inmediatamente lo cambié por uno nuevo Ultrawide 1080p, conocido como 2k ( de 2560×1440), que además, presenta la regulación de altura como otra mejora importante, entre otras. Cualquier otra monitor supuerior hubiera sido también una buena opción, si bien, el precio comenzaba a dispararse y no iba a sacarle partido, como desarrollador. ¡Eso sí, ahora que ya lo tengo, aprovecharé para alguna que otra edición de foto, vídeo e incluso diseño 🙂 !

Lo que verdaderamente me preocupaba, era el poder aprovechar esta resolución adecuando Windows a unos tamaños de ventanas, textos, menus, etc, idóneos y no excesivamente pequeños (2560×1440). Es aquí donde Windows 10 hace la magia. Basta con establecer el % de escalado y seleccionar la resolución. ¡Mantengo la resolución más optima y recomendada y Windows 10 hace un escalado para adecuar los tamaños. !

Ahora que en Windows estaba todo bien, ¿Que pasaría en Mac?. Pues bien, aquí no todo es mágia. O aprovechamos la máxima resolución del monitor viendolo todo más pequeño, o bajamos la resolución perdiendo calidad. ¡La sospecha inicial era una realiada en Mac! Sin embargo, y como no podía creermelo, finalmente encontré SwitchResX , que nos permite lo mismo que de manera nativa nos aporta Windows 10, pero, siguiendo previamente algunos pasos manuales:

  • Descargar e Instalar SwitchResX.
  • Iniciar el Mac en modo recovery, pulsando Cmd + R al reiniciar.
  • Abrir el terminal desde el menu Utilities y escribir “csrutil disable“.

  • Reiniciar nuevamente el Mac.
  • Abrir las preferencias del sistema y pulsar sobre el nuevo icono “SwitchResx”.
  • Acceder a la pestaña “Custom Resolutions” y añadir (pulsando “+”, hasta un máximo de dos nuevas resoluciones (en la versión gratuita). En concreto, estas resoluciones se corresponderán con el doble de las resoluciones buscadas. Ej: Para la resolución deseada de 1920×1080, crear una de 3840×2160.

Creando resolución tipo “Escalado” de 3849×2160

Nueva resoluciones

  • Una vez creadas la resoluciones desadas, seleccionar la pestaña “Current Resolutions”.
  • Finalmente, marcar la nueva resolución 1920×1080 (HiDPI), que se corresponde con la creada en el punto anterior.

Seleccionando nuevas resolución (HiDPI)

Esto es debido a que Mac solo permite un conjunto de resoluciones HiDPI para nuestro segundo monitor y entre ellas no se encuentra la que realmente queremos. ¡Es decir, la mágia de Windows 10!

Referencias:

Happy New Year 2019 coding with high resolution
Juanlu

Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator.

imageMuy buenas,

Llevo ya un tiempo con ganas de escribir sobre este tema y, principalmente por el impacto que causa en DevOps, en donde últimamente estoy un poco más inmerso de lo habitual.

En primer lugar, me gustaría hacer mención a este post del compañero @snavarropino, donde nos habla de la Cobertura de Código y Azure DevOps (anteriormente conocido como VSTS).

Y, en segundo lugar quiero hacer mención también a esta reseña de Wikipedia:

La cobertura de código es una medida (porcentual) en las pruebas de software que mide el grado en que el código fuente de un programa ha sido comprobado. Sirve para determinar la calidad del test que se lleve a cabo y para determinar las partes críticas del código que no han sido comprobadas y las partes que ya lo fueron.

Cuando desarrollamos con Visual Studio, y ejecutamos tests, en la mayoría de las ocasiones hacemos uso del tooling integrado en Visual Studio, si bien, tenemos que reconocer que para poder lanzar la cobertura de código entre otras acciones que brinda, necesitamos disponer de la edición Enterprise, lo que supone un coste adicional, que en muchas ocasiones es tal que da lugar a evaluar y analizar el mismo frente al beneficio que aporta.

A continuación veremos como ejecutar los Tests y la Cobertura de código desde Visual Studio, tal y como estamos acostumbrados y también, desde la línea de comandos, con .Net Core.

Desde Visual Studio (Enterprise Edition)

Lanzamos la cobertura de código bien desde la opción de menú “Test – Analyze Code Coverage” o bien, desde el Test Explorer, “Analyze Code Coverage for Selected Tests”:

image

El resultado es el siguiente:

image

Donde, por ejemplo, para la clase ProjectService.cs, podemos ver que parte del código está cubierto (en azul) por los tests y que partes no.

image

Teniendo en cuenta esto, podemos ir afinando nuestros tests para cubrir más y más código. Existen indicadores referentes a este dato que sirven de orientación para medir la calidad de nuestros desarrollos, si bien, no olvidemos que la cobertura determina la calidad del test, (no la del código). Eso si, podremos conocer el porcentaje de código que es cubierto y en consecuencia asegurar que tal %, al menos está “testeado”, lo que supone una garantía de calidad.

Conseguir un 100% de cobertura, evidentemente supone un esfuerzo y un coste, y es aquí donde debemos poner especial atención. Tenemos que valorar el porcentaje a cubrir en base a este coste y tiempo. Un valor de este porcentaje orientativo puede estar entre el 60% y el 70%, pero va a depender de cada caso en particular.  Dejo aquí una referencia de Wikipedia, a: El Triangulo de Hierro (o Iron Triangle), para profundizar en este tema, al que quizás, otro día le dedique un post.

Desde Línea de Comandos (Sin Visual Studio)

Antes de continuar, es importante recordar que los tests han de ser excluidos de la cobertura indicándolo mediante el atributo [ExcludeFromCodeCoverage] a nivel de clase en los tests.  De igual forma, podemos también excluirlos haciendo uso del fichero “.runsettings”. Visitar este enlace, para más detalle.

Adicionalmente, añadir el paquete Nuget: “coverlet.msbuild”.

image

A continuación, en el siguiente fragmento de código, (“coverage.cmd”) contamos con todas las instrucciones para ejecutar los tests y visualizar la cobertura de código de forma similar a como lo hace Visual Studio.

Las líneas [19-24, se corresponden con el comando “dotnet test” que ejecuta los tests unitarios. Habilitan la cobertura de código, especifican el formato en el que generar la cobertura (“Open Cover”) y la ruta en la que se generará el fichero “.xml” con el resultado de la cobertura.

Si ejecutamos este comando, obtendremos la siguiente salida en relación a la cobertura de código:

image

Donde, podemos ver la cobertura para cada módulo y diferenciada por:

  • Línea. Número de líneas de código que son cubiertas.
  • Branch. Número de caminos diferentes que toma el código (para instrucciones, if, switch, etc.), que son cubiertos.
  • Método. Número de métodos que son invocados desde los tests.

Adicionalmente, podríamos utilizar el parámetro /p:Exclude=\”[].Models.*\”, para excluir del análisis, cualquier clase cuyo namespace coincida con el filtro indicado. Mas detalle aquí: coverlet.msbuild.

La línea 27. Instala la herramienta Report Generator, que va a permitirnos generar un informe similar al utilizado por Visual Studio.

La línea 28.  Ejecuta la herramienta, tomando como entrada uno o más ficheros (en formato .xml) generado tras la ejecución de los tests, indicado por el parámetro “p:/CoverletOutput” y como salida, –targetdir, la ruta en la que se generan los ficheros de informes en el formato especificado por el parámetro –reporttypes (Html y HtmlSummary).

Finalmente, la línea 30, lanza el navegador y muestra el fichero “index.htm” tal y como podemos ver en la siguiente imagen, con el resumen y el detalle de la cobertura.

image

¡Ahora ya no hay argumentos para no “cubrir” bien el código!

En siguientes posts, veremos como aplica todo esto a la Integración Continua dentro del mundo de DevOps, tanto en Jenkins, como en Travis, como en Azure DevOps.

Happy testing and good Coverage
Juanlu

Logging/Traces in NetCore projects with Serilog

imageBuenas,

Como en cualquier desarrollo, un buen sistema de Logging o Trazas para diagnósticos y detección de problemas, es una buena práctica que va a salvarnos de un aprieto más de una vez. En La mayoría de los casos, creamos un ApplicationBlock, un Helper, o similar para trabajar con un sistema de estas características, cuyo objetivo es escribir trazas en un repositorio: Consola, fichero y/o base de datos entre otros, con la intención de poder consultarlo a posteriori, ante cualquier problema, que como sabemos, siempre recurrimos a el en entornos Productivos.

Con NetCore, podemos hacer lo mismo como no podía ser de otra manera, si bien, una peculiaridad y gran ventaja, es la posibilidad de usar el Interfaz ILogger (Microsoft.Extensions.Logging), tanto en nuestro controladores como en nuestros servicios o cualquier clase, mediante Injección de dependencias, lo que nos permitirá codificar sin pensar el framework o factoría encargada de escribir trazas en un repositorio: consola, fichero, base de datos, etc.

Existen muchos frameworks, que nos permiten llevar a cabo esta tarea de manera muy facil: Serilog, NLog y Log4Net, entre otros. ¡Atrás quedo Enterprise Libray  ! Cada uno tiene sus particularidades, si bien, Serilog, es considerado como uno de los mejores, además, cuenta con un elevado número de extensiones para el guardo de trazas en diferentes repositorios: consola, fichero, RollingFile, base de datos, Azure ApplicationInsight, Azure App Service, etc., lo que lo hacen aun más potente.

Por tanto, veamos como trabajar con Serilog:

Por ejemplo, podríamos tener el siguiente código en nuestro Controller:

Donde “_logger”, dejará dos trazas en nuestro/s repositorio/s.  Podríamos codificar de esta misma forma todas aquellas de nuestras clases: Servicios, Repositories, etc., sin preocupación adicional, por el momento.

A continuación, en el fichero Program.cs, incluiremos la siguiente configuración:

Como buena práctica, dejaremos en manos del fichero “appSettings.json”, la configuración de el/los repositorio/s.

Otra ventaja de Serilog, como puede verse en el código anterior, es la capacidad de ejecución en modo “asíncrono”. Es decir, la escritura de trazas en un hilo adicional para no afectar a la ejecución normal del programa.

ver-github

Y ahora, veamos todo esto en ejecución:

Referencias:

Un saludo & Happy Logging
Juanlu

 

SQL Server and SQL Cliente Application on Mac

imageContinuo aprendiendo y “cacharraenado” con el MAC para trabajar de la misma forma que lo hago con Windows. Así que, como SQL Server está en mi día a día, ¿Por que no en el MAC? Pues bien, veamos a continuación que necesitamos para poder disponer de un SQL Server en MAC y como consumirlo, también desde MAC, con una herramienta cliente, SQL Operation Studio.

Instalar y Configurar SQL Server

En primer lugar y gracias a que contamos con SQL Server On Linx configuraremos un servidor SQL como sigue:

docker pull microsoft/mssql-server-linux

  • A continuación iniciar el contenedor basado en la imagen anterior con el siguiente comando:

sudo docker run -e ‘ACCEPT_EULA=Y’ -e ‘SA_PASSWORD=P@ssw0rd1’ \
-p 1433:1433 –name sql1 \
-d microsoft/mssql-server-linux:2017-latest

Donde:

  • P@ssword1, ser corresponde con el password asignada al usuario administrador “sa”.
  • 1433, es el puerto donde estableceremos la comunicación con nuestro SQL Server. Este puerto es el utilizado de manera predeterminada.

Para más detalles sobre estos pasos, leer este Quickstart.

Instalar y ejecutar SQL Operation Studio

Como no disponemos de SQL Management Studio para Mac, vamos a hacer uso de una reciente herramienta Cliente “SQL Operation Studio”. Una herramienta muy sencilla y con una interfaz muy similar a Visual Studio Code, que también es Cross Platform y, que por tanto, también podemos instalar in Windows. ¡Creo que es buen momento para probarla!

  • Crear una nueva conexión, indicando el servidor “localhost” (en este caso), usuario (“sa”) y el password antes especificada, es decir: “P@ssw0rd1”.
  • Tras establecer la conexión, podremos comenzar a realizar consultas, incluso sus planes de ejecución para analizarlas.

image

  • Así mismo y al igual que Visual Studio Code, SQL Operation Studio, permite la instalación de extensiones, dando una mayor funcionalidad a la aplicación. En la imagen anterior, podemos ver SQL Server Profiler”. Extensión que nos permitirá conocer todas las consultas realizadas al servidor SQL desde cualquiera de las aplicaciones durante su ejecución.

Y, para conocer todo esto en funcionamiento (en MAC), como viene siendo habitual, podemos verlo en este vídeo:

https://youtu.be/N_iYM6RmhiI 

Un saludo y a seguir jugando con el MAC y Microsoft 😉
Juanlu

[Material] Evento Blazor (C# en el Browser)

image

Buenas,

Ayer 28 de Junio he vuelto a poder compartir conocimiento y muy buenos momentos con los compañeros de SVQDotNet, hablando de #Blazor en el evento: BLAZOR: Browser + Razor (C# en el Navegador) ¿Adios a JavaScript?

Dejo aquí el material empleado en la misma:

ver-github

En esta otra entrada puedes continuar profundizando.

Un saludo
Juanlu