Una sinfonía en C#

Un pequeño aporte a la comunidad de habla hispana.

Cómo ejecutar unit test con Azure usando Integración continua

En posts anteriores vimos cómo trabajar con entrega continua en Azure y cómo personalizar el build con Kudu. Vamos a utilizar esta combinación para ejecutar nuestras pruebas unitarias automáticamente cuando hacemos push en nuestro repositorio y si fallan evitar que se despliegue la aplicación.

Paso a paso

Primero necesitamos un repositorio, en este caso he utilizado github, y después creamos un sitio web en Azure y lo conectamos al repositorio (estos pasos están mejor detallados en este post)

image

Una vez conectado y con nuestro proyecto de test listo (en este caso utilicé MSTest, es decir el que viene incluído en Visual Studio) lo que tenemos que hacer es crear el archivo .deployment para personalizar el build.

El archivo .deployment

En este archivo no hacemos más que indicar que el comando a ejecutar va a estar en un .bat (podemos usar powebshell también), de este modo

[config] 
command = deploy.cmd 

Luego, en el archivo "deploy.cmd" indicamos lo siguiente

REM restauramos los paquetes nuget
cd webapp1
nuget restore
REM Compilamos el proyecto web
"%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\WebApp1\WebApp1\WebApp1.csproj"
REM Compilamos el proyecto de test
"%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\WebApp1\WebApp1.Tests\WebApp1.Tests.csproj"
REM ejecutamos los test
vstest.console.exe "%DEPLOYMENT_SOURCE%\WebApp1\WebApp1.Tests\bin\Debug\WebApp1.Tests.dll"

Esto es muy sencillo, Kudu nos permite acceder a variables propias para acceder, por ejemplo, al directorio de MSBuild (%MSBUILD_PATH%) y del proyecto (%DEPLOYMENT_SOURCE%), después sólo indicamos la ubicación de los .csproj y listo.

El truco está en la línea final vstest.console.exe es el ejecutable incluído desde Visual Studio 2012 que nos permite correr los test desde la consola, entonces simplemente lo ejecutamos.

Viendo los resultados en Azure

image

Y si hacemos click en “View Log” podemos ver el resultado de los tests

image

Y por supuesto, hacemos fallar un test y esto es lo que ocurre

image

Falla, y el log nos indica que fue el test que modificamos

image

Mágico, nos leemos

Desplegar aplicaciones Nodejs a Azure desde GIT automáticamente

En un post anterior vimos cómo desplegar aplicaciones .net en Azure. Bien, Azure Web sites también tiene la capacidad de ejecutar aplicaciones hechas con NodeJs y por supuesto soporta el mismo esquema de despliegue automático.

¿Cómo hacerlo paso a paso?

Para este post me basé en este ejemplo de MSDN, a diferencia de mi post anterior ahora estoy usando la versión más actual del portal de Azure.

Aplicación de Nodejs sencilla

var http = require('http')
var port = process.env.PORT || 1337;
http.createServer(function(req, res) {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello World\n');
}).listen(port);

Simplemente nos retorna un string "Hello World" como texto antes un request HTTP

Una vez que subimos a GIT nuestro código (en mi caso un repositorio en Bitcucket) no nos queda más que configurar Azure.

Creación del sitio en Azure

image

Una vez creada configuramos el despliegue continuo

image

Luego de ingresar las credenciales, seleccionar el repositorio y el branch estamos listos

image

Y listo

image

Vamos a la url de Azure y nuestro sitio está funcionado

image

Mágico, nos leemos.

Cómo especificar qué proyecto desplegar en Azure?

Existen casos en los que configuramos nuestra Webapp en Azure para que se conecte a Git y despliegue automáticamente pero tenemos un problema hay dos aplicaciones dentro del repositorio y Azure no sabe qué hacer.

Kudu al rescate

La magia detrás de los deploys automáticos en Azure está controlada por Kudu, un proyecto open source que se encarga de muchas cosas, por ejemplo decidir qué es lo que se despliega

Personalizando Kudu

Se puede indicar qué hacer a Kudu de dos formas, la primera es creando un archivo de nombre “.deployment” en el directorio raíz de nuestro repositorio (o dropbox, claro) e indicamos el archivo del proyecto, por ejemplo

[config]
project=api\DataApi\DataApi\DataApi.csproj

Es suficiente, indicamos a Kudu la ubicación del archivo que tiene que utilizar para generar el proyecto (es mejor indicar el csproj en lugar del sln)

Con eso sería suficiente, pero también podemos indicar a Kudu un archivo .cmd o incluso powershell con comandos más avanzados.

Opción dos, utilizar los settings

Si no vamos a hacer más que indicar el proyecto tal vez ser más simple utilizar un setting de Azure, para esto vamos a la pestaña configure de nuestra webapp e indicamos lo mismo

image

Y listo.

Nos leemos.

Delivery continuo en Azure

Una de las grande características de Azure son las Web Apps, básicamente es la posibilidad de tener un sitio web sin más, desplegar una app ASP.NET (de cualquier tipo) e incluso de otras plataformas como PHP, Tomcat, Node, etc.  y listo, sin configurar IIS, ni nada.

Primero, la forma tradicional

image

Presionamos el signo + abajo a la izquierda, seleccionamos algunas cosas y listo

image

La aplicación ya está creada y corriendo pero no tiene código

image

Subiendo nuestra aplicación como sitio web

La forma más simple es utilizar Visual Studio, una vez creada la aplicación web, en este caso MVC

image

Entre las opciones aparece Azure.

image

Ingresamos nuestras credenciales de Azure

image

Y elegimos la app creada (podríamos haberlo hecho desde Visual Studio también)

Y publicamos.

image

Delivery continuo

Vamos al tema que nos interesa existe otra forma de publicar aplicaciones en Azure sin intervención directa de nuestra parte y es vinculando un origen de código con Azure.

Primero tenemos que indicar el origen del código , por el momento estos son los posibles orígenes del código que vamos a publicar:

  • Github
  • Bitbucket
  • Codeplex
  • Dropbox
  • Visual Studio online
  • Repositorio externo

En nuestro caso vamos a usar Github

Inidicando el origen del código

Buscamos la opción “setup deployment from source control” en el Dashboard de nuestra Web app

 

image

Y elegimos Github

image

Ponemos las credenciales y autorizamos a Azure a leer nuestro repositorio. Vemos que podemos seleccionar el branch con lo cual podemos tener el repositorio organizado para tener un branch de desarrollo otro de demo, otro de RC y controlar qué se despliega automáticamente.

image

Listo, en la solapa “DEPLOYMENTS” vamos a ver cada vez que se publica el sitio, por ahora no hay nada.

image

Haciendo el primer delivery automático

Simplemente tenemos que hacer “push” en el repositorio, Azure va a buscar si existe un archivo .sln o cualquiera que conozca, vamos a clonar el repositorio localmente y a colocar nuestro código ahí, después hacemos un cambio

image

hacemos “commit” y luego “push” y vemos que Azure nos indica que se está ejecutando un deploy

image

Y si todo va bien vemos el resultado

image

Vamos a nuestro sitio y tenemos el cambio desplegado

image

Mágico, a partir de ahora cada vez que hagamos “push” se va a deplegar y ahí tenemos nuestro delivery continuo funcionando en 5 minutos gracias a Azure.

Nos leemos.

Novedades de C# 6: Inicializadores de diccionarios

Esta es simple pero muy práctica, en el pasado para inicializar los valores de un diccionario teníemos que hacer esto:

var capitales = new Dictionary()
{
    { "Argentina", "Buenos Aires" },
    { "Francia", "París" },
    { "España", "Madrid" }
};

Ahora podemos hacer así:

var capitales = new Dictionary()
{
    ["Argentina"] = "Buenos Aires",
    ["Francia"] = "París",
    ["España"] = "Madrid"
};

Podemos señalar como ventaha que es más claro cuál es el nombre y cuál el valor.

Nos leemos.