Actualizando la Gestión de la Configuración de ASPNET CORE con Azure

Hace medio año conversábamos acerca de la potencialidad que Microsoft nos empezaba a ofrecer para desarrollar aplicaciones para plataformas Linux y Mac, en el caso Web la iniciativa se llamo ASP NET 5, y en ese sentido se presento una manera para acceder de manera transparente a los valores de configuración (antiguamente manejados por los Web.config) para no tener que preocuparnos si se guardaban dichos valores en un archivo JSON o si por el contrario estábamos guardando dichos valores mediante la consola que Azure nos da para gestionar las Web Apps.

Pues bien, en este lapso varias cosas han transcurrido, y una de ellas es que ASP.NET 5 ahora se llama ASP.NET Core, decisión de Microsoft que ayuda a tener claridad para entender que “este” .Net que corre de manera multiplataforma no es la “siguiente versión” luego de .NET 4.X, así que correspondía regresar al desarrollo puro y duro para verificar si nuestra clase Helper seguía funcionando,  como es lógico habiendo pasado de una versión beta a una release candidate, las API se han actualizado por lo cual algunos de los metodos que se utilizaban ya no funcionan o funcionan de manera diferente, asi que correspondió hacer el ejercicio de revisar el código y dejarlo operativo.

De igual manera aproveche la ocasión para incorporar algo que se me quedo pendiente: soporte para cadenas de conexión, de esta manera seguiremos teniendo (como en ASP.NET 4x) la opción de trabajar en desarrollo con una BD local, y en entornos de despliegue (QA, PROD, etc) con una conexión gestionada por el entorno de Azure, evitando de esta manera trabajar con las ya conocidas Transformaciones, de esta manera si antes teníamos un fragmento de codigo asi:

 services.AddEntityFramework()
                .AddSqlServer()
                .AddDbContext<ApplicationDbContext>(options =>
                    options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]));

Con el uso de nuestro HelperConfig quedaria asi:

            services.AddEntityFramework()
                .AddSqlServer()
                .AddDbContext<ApplicationDbContext>(options =>
                    options.UseSqlServer(HelperConfig.GetConnectionString(Configuration, "DefaultConnection")));

Y de esta manera seria posible acceder de manera transparente al valor de la cadena de conexión que podria estar en nuestro JSON, asi:

  "Data": {
    "DefaultConnection": {
      "ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=aspnet5-WebTestConfig2-b1ec5227-eb73-448b-86ee-63e3746185e7;Trusted_Connection=True;MultipleActiveResultSets=true"
    }
  },

O, como mencionamos antes, en la consola de Azure:

ConnectionsStrings

Todo esto lo he subido a GitHub junto a un proyecto Web sencillo (vamos, la aplicación por defecto de Visual Studio 2015) para que uds lo descarguen y revisen su funcionamiento, particular atención merecen los siguientes archivos:

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Helper.cs (la clase HelperConfig en si y todo lo necesario para que funcione)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/appsettings.json (Los AppSettings y Connection Strings involucrados)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Startup.cs (Clase de arranque que prepara la Inyección de Dependencias e invoca a HelperConfig.GetConnectionString)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Controllers/HomeController.cs (Controlador que hace uso de HelperConfig.GetAppSettings)

En los próximos días explicare un poco mas de este pequeño proyecto, espero que les sea de utilidad y no se olviden de enviarme sus comentarios.

 

¿Estamos mirando todo el panorama al ir a Cloud o implementar DevOps?

Siendo que poco a poco las tendencias de cloud y DevOps tienden a alcanzar la madurez, he percibido una tendencia que va tomando forma en cuanto al “gusto” de los involucrados mas allá de lo existente en cuanto a herramientas y proveedores.

Por un lado lo que he percibido en estos meses, es que la mayoría de ofertas de trabajo que involucran el termino “cloud” se orientan a perfiles provenientes del ámbito sysadmin/IT pro, siendo que se piden skills vinculados a la gestión de infraestructura física (cableado, almacenamiento, etc) y relativamente poco con respecto a la gestión de las plataformas ya existentes en el mercado, y si algo en cuanto a lo que corresponde a la gestión de maquinas virtuales.

Por otro lado desde que le he tomado interés a lo que es el movimiento DevOps es evidente notar que la mayor atracción va hacia herramientas que tienden automatizar y facilitar la gestión de maquinas virtuales (Puppet, Chef, Vagrant, etc), esto por la necesidad de ser capaz de regenerar exactamente el entorno en que corre nuestra aplicación (de ahí el impacto que tiene el concepto de Infraestructura como código), pero como sabemos eso tiene cierto limite debido al peso que puede llegar a tener una MV así como el tiempo que se tarda en levantar una por mas automatizado que este su creación, de ahí el jale que tiene la propuesta de Docker, contenedores que solo contienen lo necesario para correr la aplicación (delegando buena parte de la carga al SO anfitrión) y así efectuar de manera sencilla un redespliegue de la aplicación…. con entorno y todo.

Si bien todo esto no deja de ser un avance, tengo la opinión de que no se esta teniendo una visión integral de las alternativas que se disponen en la actualidad, hace unas semanas estuve en una conversación con el responsable de una aplicación sectorial en una corporación, llegado el momento se nos indico que dentro de la organización se le ofrecía como opción (aparte del usual hardware “real” y maquinas virtuales) efectuar los desarrollos y/o despliegues correspondientes a su departamento.. en la nube! wow… pero en la conversación quedo claro que su responsable de infraestructura solo le había explicado las posibilidades existentes en IaaS y por ende.. solo el como era posible provisionar sus aplicaciones en MV alojadas en la nube,  mas no aclarando las posibilidades de que su BD se gestionara como servicio PaaS, y probablemente tampoco la posibilidad de hacer lo mismo con sus aplicaciones Web, con el consiguiente potencial ahorro que se podria conseguir para su organización.

Es que claro, somos criaturas de costumbres y probablemente nos sea mas natural trasladar el ya conocido modelo de Maquinas Virtuales de nuestros servidores a la nube, pero en el camino no debemos perder de vista si efectivamente es esa la mejor solución tanto en costos como facilidad de administración, siendo que PaaS nos provee de una abstracción que simplifica la administración y escalamiento y dándonos opciones para buen rango de nuestras necesidades de desarrollo, y si, claro que hay escenarios en que nuestro requerimiento (necesidad de ser “híbridos”, sistemas legados o stack tecnológico muy especifico) va mas allá de los esquemas que nos dan modelos PaaS como Azure App Service o Amazon Elastic Beanstalk pero valorar el modelo correcto es un ejercicio que debemos hacer necesariamente antes de la toma de decisiones.

Lo mismo con el caso de nuestras necesidades de Integración y Entrega Continua, el crecimiento de Docker abre nuevas posibilidades a la hora de regenerar entornos, pero no debemos dejar de tener en cuenta si de veras vamos a estar regenerando entornos periódicamente como parte del proceso, pues hacerlo no es trivial, hace poco desplegué una aplicación sencilla usando Docker a Azure y por el peso tardó bastante (ojo, estamos hablando de cientos de megas por contenedor) en hacerse el despliegue, en ese sentido no dejo de cuestionarme de si efectivamente para esa necesidad es o no mejor provisionar mi aplicación en una plataforma gestionada en vez de una MV o un contenedor, igual si que necesite hace IaaS pero antes debo decidirlo adecuadamente; claro esto no quita que siempre debemos procurar gestionar adecuadamente los archivos de creación de entornos (como hicimos con Resource Manager).

Así pues, nos corresponde tener una visión integral de las tecnologías que van surgiendo y usarlas de la manera mas optima posible, no basándonos unicamente en lo que es mas cercano a lo que ya conocemos de tiempo.

Monitoreando la calidad del código en nuestros procesos de desarrollo: Sonarqube

Bueno, en nuestras ultimas series de artículos prácticamente hemos completado el ciclo de despliegue de una aplicación desde el cambio de código hasta su publicación en los entornos, pero como es lógico esto no se acaba ahí, nuestro objetivo debe ser siempre la búsqueda de calidad en lo que estamos desarrollando, y esto necesariamente involucra al código: legibilidad, mantenibilidad, seguridad, buenas practicas según lenguaje, etc.

En ese sentido la idea seria mantener unos niveles de calidad y “parar la Build” en caso que la calidad del código no cumpla unos mínimos, tradicionalmente en .Net hemos contado con la opción de definir unas reglas mediante Code Analysis, permitiendo que no se haga checkin de código si no se cumplen las reglas (si usamos TFVC) o que ciertas reglas se cataloguen como error (forzando a corregirlas si o si), alternativa muy interesante sobre la que tratare de regresar en un post futuro.

En todo caso, en paralelo a lo que veíamos en el mundo .Net iba evolucionando una herramienta muy potente que permitía explotar el análisis de código estático al máximo: Sonarqube, herramienta a la que pude conocer cuando me correspondió configurar un proyecto de Integración Continua donde me gustaron mucho sus dashboard que permitía ir analizando con detalle los diversos tipos de deuda técnica existente en nuestras aplicaciones (para verlo en acción revisa aquí) y como esta ha ido evolucionando históricamente; en ese momento si querías integrarlo en .Net tenias dos opciones: invocar manualmente el análisis, o enlazarlo a un ciclo de Integración Continua usando Jenkins, pero ahora Microsoft ha colaborado para que sea posible integrarlo con TFS y VSTS y de esto se trata este post.

Para mas razones por las cuales usar Sonarqube en nuestros desarrollos, revisar este post de Adrian.

Finish Reading: Monitoreando la calidad del código en nuestros procesos de desarrollo: Sonarqube

Completando el ciclo de ALM: Release Management (II)

Prosiguiendo con la entrega anterior, pasamos a los pasos 4 y 5 de este proceso que consiste en configurar cada uno de los entornos de despliegue en los que se va a desplegar la aplicación, la idea que implementaremos en esta ocasión sera la siguiente:

  • Cada vez que se efectué un cambio en el código fuente se disparara una Build (Integración Continua, esto ya lo tenemos bien sabido)
  • Si la Build es exitosa se disparara una Release
  • El primer paso de la Release sera desplegar automáticamente al entorno QA
  • Efectuado el despliegue a QA, un aprobador humano dará su conformidad, o no, al contenido desplegado
  • Si el despliegue en QA ha sido aprobado, recién entonces se efectuara el despliegue al entorno PRO

Obvio que este esquema puede extenderse para incorporar mas entornos, para añadir pruebas de carga en la nube, distintas categorías entre aprobadores, etc, pero para demostrar el concepto esta prueba sera suficiente.

De momento vamos a identificar correctamente nuestros entornos, así que nos vamos al entorno llamado por defecto “Default Environment” y le cambiamos el nombre…

Clipboard01

A QA:

Clipboard02

Finish Reading: Completando el ciclo de ALM: Release Management (II)

Completando el ciclo de ALM: Release Management (I)

Repasemos un poco lo que hemos aprendido hasta ahora: sabemos como configurar nuestro Visual Studio On… digo Visual Studio Team Services para crear un Team Project, desarrollar una aplicación en ASP.NET para finalmente compilar y desplegar dicha aplicación cada vez que efectuemos un cambio en el código fuente (Integración Continua).

Todo perfecto, pero recordemos que si queremos definir un conjunto de entornos (QA, DEV, STA, PRO…) entre los que sucesivamente vayamos escalando nuestra aplicación, hacíamos uso de la funcionalidad de Azure llamada “slots”, la cual de una manera sencilla nos permitía intercambiar contenidos entre los diversos entornos, esta técnica es muy practica y nos permite cierto grado de protección a fin de poder revisar nuestros cambios antes de que hagamos el despliegue en el entorno definitivo.

Devops-release

Ahora tenemos una opción adicional, y es que desde la gestión que hace VSTS/TFS manejemos de manera separada la forma en que nuestro “paquete” va siendo desplegado y escalado en los entornos de aprobación hasta su destino “final”: producción, y al hacerlo logramos introducir un factor que sera de gran utilidad de cara al aseguramiento de la calidad de lo entregado: la aprobación de versiones, vale decir que a una persona (o grupo de personas) se le notifica que hay una nueva versión de la aplicación en determinado entorno y que le corresponde dar su conformidad a dicha versión, lo cual derivara en que la versión en cuestión sea propagada al siguiente entorno, y así sucesivamente. Adicionalmente este cambio nos va a permitir manejar ya no solo el historial de nuestras Builds sino tambien el historial de nuestros despliegues, pudiendo ver si todos los despliegues propuestos han pasado los tests de carga y/o fueron aprobados satisfactoriamente por QA o el cliente.

Finish Reading: Completando el ciclo de ALM: Release Management (I)

Buenos cambios para el entorno DevOps en Microsoft

Guau.. vaya con las novedades de Connect 2015, bastantes cosas en desarrollo multiplataforma, cloud, Windows… pero centrémonos en lo que corresponde a nuestro interés como DevOps y entusiastas del ALM, asi que vamos con calma….

Adiós Visual Studio Online…. hola Visual Studio Team Services, si, un nombre puede ayudar mucho, y desde que Microsoft le dio el nombre oficial a lo que originalmente conociamos con Team Foundation Service me ha sido complicado explicar que VSO no es un IDE como Visual Studio pero en el browser, sino por el contrario una herramienta ALM (Scrum, repositorio, build…), ahora este cambio de nombre puede ayudar un poco mas a entender las cosas, así que repitamoslo una vez mas: Visual Studio Team Services (VSTS).

Preview de Release Management para VSTS, una gran noticia, quienes han seguido mis artículos sobre despliegue, se habrán percatado que el proceso de paso a entornos lo había configurado como un paso final del proceso de Build, pues bien… una etapa tan importante requiere una gestión por separado que facilite no solo colocar la aplicación en el primer entorno, sino también mover las versiones de la aplicación entre diversos entornos, y ese es el objetivo de RM que ha evolucionado de ser un producto separado a ser una parte integral del entorno de VSTS, permitiéndonos entre otras cosas establecer aprobadores manuales que decidan si una versión de nuestra aplicación ya esta lista para pasar al siguiente nivel, como detalle adicional es importante indicar que no es necesario que tu ciclo de Build lo hayas gestionado con VSTS sino que tu paquete también puede provenir de Jenkins, y claro… como era de esperar nuestro entorno destino no es solo Windows. En las próximas semanas iremos desgranando un poco estas facilidades.



 

Preview de Code Search en VSTS, una ayuda que nos permitirá ubicar el código deseado de manera potente a través de nuestros repositorios via web.

Soporte para Subversion en TFS y pronto en VSTS, hay que reconocerlo a pesar del crecimiento de Git, hay muchos desarrolladores en el mundo Java que se sienten muy cómodos con Subversión, así que en breve se tendrá como opción el que nuestros Team Projects se creen con Subversión como tipo de repositorio, la cosa es tener opciones ¿no?

A seguir poniéndonos al día!

 

Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Quienes han leído mis anteriores artículos sobre el despliegue en Azure pensaran que uff, ya tenemos todo listo para buscarnos la vida hasta que Release Management de un soporte total a PaaS, pero la verdad es que la cosa tiende a evolucionar y hay que hacer pequeños ajustes de cara a los cambios que se anunciaron en el Build y que vienen con el Visual Studio 2015.

Esto a propósito de la posibilidad que nos ofrece Microsoft de desarrollar aplicaciones .Net que corran tanto en Mac como en Linux, una posibilidad totalmente disruptiva que es todo un ejemplo de los cambios que llegaron de la mano de Satya, pero claro, esto no implica que lo que hemos desarrollado hasta ahora en ASP.NET lo recompilamos y lo subimos a Linux y ya esta… no, claro que no, para lograr el objetivo Microsoft ha sacado una nueva edición del .NET Framework llamada Core, sobre la cual se ha desarrollado una nueva versión de ASP.NET (concretamente la 5) mas modular y ligera, sin las dependencias monolíticas usuales, aprovechando tendencias ya existentes en el mercado: Bower, Grunt, npm…

Genial, pero todo esto viene con un precio, el primero y para mi el mas doloroso es que esta nueva versión de ASPNET no incluye proyectos en WebForms (sniff :'( ), ha habido un reacomodo en algunas librerías (sobre todo de cara a lograr la integración entre MVC y WebAPI), desaparición de global.asax, en fin no doy mas detalle porque para eso mejor leer los artículos de José M. Aguilar que va cubriendo con detalle las cosas que van saliendo.

Pero dentro de todos los cambios habidos hay uno que nos afecta especialmente a quienes trabajamos en la gestión de entornos de trabajo y de despliegue, y es que por defecto al crear un proyecto nuevo ya no hay un archivo web.config, esto debido a que la gestión de configuración ya no esta centralizada en un archivo monolítico sino que puede estar dispersa a lo largo de un conjunto de archivos (de preferencia JSON) o de las variables de entorno del sistema, correspondiendonos a nosotros el elegir que archivos usaremos y en que orden de secuencia y prioridad se van sacando, y claro la forma de acceder a estas propiedades, que vimos anteriormente, han cambiado.

slots29

Si pues, ya no mas ConfigurationManager y similares…

Y por lado de la estructura de los archivos JSON seria de esta forma, mucho ojo a este config.json, lo usaremos mas abajo:

configjson

Ok, entonces ¿como hago para acceder a dichos valores desde mi código? Finish Reading: Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Quienes han dedicado un rato a ver mi serie sobre automatización en el despliegue de aplicaciones con Azure habrán notado que había varios pasos manuales a la hora de preparar los entornos en los que íbamos a desarrollar y luego desplegar nuestras aplicaciones.

Pero, ¿nos hemos preguntado que pasa cuando hemos llegado a cierta madurez y nos encontramos con un escenario en que?: siempre creamos nuestros Websites en la misma zona geográfica de Azure, el mismo plan de precios, y… que la organización ya definió cuantos slots (ranuras) de despliegue son requeridos para el ciclo de desarrollo antes de que algo pase a producción.

En ese sentido Azure nos ofrece los Azure Resource Manager templates, que nos permiten definir y usar plantillas para automatizar la creación de recursos y entornos completos dentro de Azure, y ojo esto no esta limitado unicamente a Web Apps, sino también a entornos que involucren VM, Docker, Logic App, etc, en suma algo muy potente si queremos simplificar tareas repetitivas.

Este mecanismo llamo mi atención luego de que la genial GiS (a quien pude conocer de pasada en mi época en España) publicara este interesante articulo sobre como crear las citadas plantillas desde Visual Studio y es a ese articulo a donde deben remitirse para entender con detalle las partes de un proyecto de este tipo, luego de lo cual podemos regresar aquí.

¿Ok? En nuestro caso vamos a definir un proyecto de plantilla de tipo Web App (a diferencia de GiS que eligió la Blank Template para explicar con mas detalle la estructura base), así:

RM1En este caso notaremos que a diferencia del ejemplo genérico, lo que obtendremos serán archivos de nombre WebSite.json y WebSite.param.dev.json, los cuales se corresponden con los DeploymentTemplate.json y DeploymentTemplate.param.dev.json que con tanto detalle se describieron en el articulo de GiS.

RM2Ahora lo que haremos sera configurar los diversos archivos a fin de lograr una plantila que automáticamente nos permita:

  • Crear un Web App que incluya dos slots por defecto: “QA” y “Staging
  • Localizar esta Web App (y sus slots) en una zona geografica determinada, en mi caso: “East US
  • Usar siempre un mismo Grupo de Recursos (ya previamente creado en nuestro Portal de Azure, o creado la primera vez que invoquemos la plantilla), en mi caso: “Default-Web-EastUS

Finish Reading: Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Gestión automática de entornos de despliegue con Azure (tercera parte ¡desplegando!)

Luego de que el camino de usar las Azure API Apps no fuera el mas adecuado para la prueba de concepto (lo cual no quita que sea una tecnología muy prometedora para desarrollar con REST) de nuestro entorno de despliegue, toca proceder a usar los ya conocidos Azure Websites para el ejemplo, en ese sentido repasemos lo que tenemos hasta el momento:

  • Un Team Project en Visual Studio Online, bajo modelo Git (por cierto ¿sabían que está en camino la posibilidad de renombrar los proyectos?)
  • Ya sabemos cómo subir nuestros cambios de nuestro repositorio local de Git a VSO
  • Ya sabemos cómo crear un entorno de despligue en Azure desde Visual Studio, lo hemos visto con API Apps, pero el proceso es básicamente similar para Azure Websites, y claro también hemos aprendido a desplegar desde Visual Studio.
  • Hemos entrado al Portal de Azure y revisado lo que hemos instalado desde Visual Studio.

Con estas bases regresemos a nuestro problema inicial, gestionar los despliegues en entornos separados de QA, Staging, Preproducción, Integración, etc.., en ese sentido debo mencionar que las practicas usuales y conocidas respecto a Integración Continua se basan en el versionamiento de : Código fuente, scripts, datos de prueba, archivos de configuración, siendo lo de Infraestructura como Código un paso más allá en ello (algo en lo que tengo que ponerme cuanto antes); dicho esto el enfoque asumido por Microsoft en los web slots consiste en dejar que el entorno (Azure en este caso) se haga cargo de la gestión de ciertos atributos críticos (definidos por los usuarios, claro está) como las cadenas de conexión a BD de producción, lo cual permite copiar todo el contenido versionado con la seguridad de que no habrá forma de que se hagan públicos esos datos sensitivos, probablemente este enfoque (que personalmente me reduce la cantidad de Perfiles de Publicación que debo de crear en mi proyecto) sea chocante para algunos, pero yo lo veo como una apuesta muy seria y con bastante lógica especialmente cuando ya se trabaja con entornos muy sensitivos, recordemos que los archivos de transformación, que vimos en la primera parte de esta serie, obligan a tener una copia de los atributos variables de cada entorno a fin de luego poder regenerar un .config mezclado.

(Muchas gracias a Scott Hunter quien en el último DevDays me conto estos detalles y permitió que le diera un nuevo vistazo a los slots que es el que comparto con ustedes)

Ya sabemos a que vamos a enfrentarnos, así que manos a la obra.

Como primer paso agregamos a nuestra solución un nuevo proyecto ASP.NET Web que llamaremos WebSlots02SimpleWeb, en este caso lo estamos agregando dentro de la estructura de solución WebSlots01 que ya teníamos.

slots25 Finish Reading: Gestión automática de entornos de despliegue con Azure (tercera parte ¡desplegando!)

Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Visto el contexto del problema y la solución potencial, decidí verificar si era posible aplicar esta solución dentro de los nuevos Azure API Apps, nueva tecnología agregada a la oferta de Azure que permite generar APIs REST a nuestra aplicación de manera sencilla, evolucionando lo que ya conocíamos de las Web API.

De primera entrada fijemos los objetivos y características de lo que trataremos de demostrar:

  1. Gestionar nuestro respositorio en Visual Studio Online, usando Git como modelo de repositorio.
  2. Efectuar despliegues automatizados a cada vez que hagamos un commit y sincronización hacia VSO.
  3. Que cada entorno desplegado utilice distintos valores de configuración, que la aplicación sea capaz de “leer” dichos valores y actuar acorde a ello.
  4. Efectuar Intercambios (swaps) entre nuestro entorno de QA, hacia Producción, verificando que si bien la aplicación se actualiza, los valores de configuración se mantienen.

Nuestro primer paso es crear un proyecto en Visual Studio Online, asi que vamos a ello:

Slots01Creado nuestro proyecto vamos a Visual Studio 2013 y nos conectamos a nuestro servidor eligiendo al Team Project que acabamos de crear:

Slots02Hecho esto, nos corresponde “clonar” (esto es terminología Git) el repositorio para empezar a trabajar

Slots03

Finish Reading: Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)