Etiqueta: Azure

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

Posted on by ecardenas

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 (I)

Posted on by ecardenas

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)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Posted on by ecardenas

Pues si, como fue prometido, ya va tocando meternos con el modelo de Builds, pero antes de proseguir respondamos la pregunta que deje en el post anterior, ¿en que parte de la solución estoy grabando los parámetros de conexión a la BD? pues en el archivo PartsUnlimitedWebsite.pubxml ya que es ahí donde el wizard de deploy guardo los datos de la cadena de conexión a pesar de que al final no sobrescribió los valores del web.config, nos corresponde editar las secciones de dicho archivo a fin de que no persistan los valores dentro de nuestra solución.

Curiosamente, debemos agregar este archivo a nuestra solución, para lo cual hacemos clic derecho y ya formara parte de lo gestionado por VSO, ojo esto solo funciona si hemos editado adecuadamente nuestro archivo .gitignore como ya hemos explicado en el segundo post de esta serie.

Clipboard27
Bueno, ahora si, subamos el cambio y volvamos a nuestro Team Project en Visual Studio Online, dirigiéndonos a la zona de BUILD, de momento estará vacía.Clipboard28
Posicionados sobre la zona que dice “Build definitions” (nótese que aparte tenemos una zona correspondiente a las XAML definitions) y presionamos el “+”, nos saldrá la siguiente pantalla:Clipboard29
Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Posted on by ecardenas

Bueno, luego de una pausa, proseguimos con esta serie de artículos para establecer un escenario completo de despliegue usando el nuevo modelo de Builds que traen tanto Visual Studio Online como Team Foundation Server 2015, ¡así que manos a la obra!

Para proseguir con el demo de Parts Unlimited, debemos mencionar que en este ejemplo se hace uso intensivo de los Resource Groups que ya conversamos anteriormente, esto permite automatizar la creación del entorno donde se desplegara nuestra aplicación, vale decir que reduciremos nuestras visitas al Portal de Azure para la creación de nuestros recursos.

Para facilitar esto debemos preparar a nuestra maquina para que sea capaz de provisionar directamente en Azure, para lo cual abrimos una ventana de PowerShell (con permisos de Administrador, claro esta) y escribimos Set-ExecutionPolicy RemoteSigned.

5554.image_thumb_6CC60E94

Bien, terminaron los preparativos así que ya con la aplicación cargada en Visual Studio (y bien conectada a VSO) vamos al proyecto PartsUnlimitedEnv, hacemos clic derecho y elegimos New Deployment… Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

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

Posted on by ecardenas

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

Cita - Posted on by ecardenas

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!)

Posted on by ecardenas

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)

Posted on by ecardenas

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)

Gestión automática de entornos de despliegue con Azure (Introducción)

Posted on by ecardenas

510af5389e0b9b98decb66e3b5fd6577e3f73032a4e336aeb523b1c836901341   A estas alturas ya debería estar claro para que sirve la integración continua y sus ventajas: el tener un sitio donde se corran todas las compilaciones y tests, el evitar “en mi maquina funciona”, reducir el tiempo de despliegue, el tener una buena gestión de los diversos entornos ¿no?

Bueno, en esta ocasión quiero referirme a la gestión de los diversos entornos en que va a correr nuestra aplicación durante su ciclo de vida: Desarrollo, QA, Staging, PreProducción, Certificación, Producción, etc, como quieran llamarle, pero el caso es que mal que bien (aun cuando no se usen practicas Agiles, DevOps o Integración Continua) al menos hay un reconocimiento en las organizaciones de que no se puede pasar las aplicaciones directamente de la máquina del desarrollador a Producción, bueno, salvo el caso de un sitio donde trabaje en el que los entornos de PreProducción estaban tan desactualizados que no quedaba otra que hacer los pases “en caliente”.

Pero como ya sabemos, cuando trabajamos en múltiples entornos, debemos asegurarnos que cada entorno tenga un conjunto de parámetros separado, de tal manera que no vaya a ser que al entorno de Producción se le dé por escribir en el entorno de QA, o a QA buscar la máquina del ultimo desarrollador que hizo el pase de entorno, de ahí que en buena parte de los despliegues (manuales) se dedique buen tiempo a verificar que estamos copiando los archivos de configuración en el entorno adecuado, y claro esta tarea es pequeña pero estresante.

Entornos

Soluciones hay muchas y una de las que nos brinda desde hace buen tiempo Visual Studio son las “transformaciones” que básicamente consiste que en adición a nuestro Web.config y app.config incluyamos en nuestro proyClipboard01ecto archivos de nombre web.EntornoObjetivo.config como se ve en el gráfico, siendo que cada uno de estos archivos contiene fragmentos XML donde se indican que atributos de configuración serán alterados en el entorno destino y que valores se colocaran en reemplazo de los que habían en Web.config. Finish Reading: Gestión automática de entornos de despliegue con Azure (Introducción)

Los retos para hacer cloud en el Perú

Posted on by ecardenas

Cloud es una interesante y validad promesa para las empresas peruanas, la promesa de reducir sus costos fijos, haciendo que buena parte de la infraestructura pase a ser costo variable pagando solo lo que se consume, es algo muy atractivo, y mas cuando un caso de éxito como el de Cineplanet llama la atención por la escalabilidad que esta logrando.

Para lograr esto hay que mirar con otros ojos a nuestras conexiones de internet, si antes se orientaba a facilitar acceso a la web y al correo, ahora… las cosas cambian, si antes el servidor de correo estaba en la red local ahora lo esta fuera, así que cada request sale fuera de la red de la organización por mencionar el detalle que podría ser mas común.

Otro escenario en que nuestra velocidad de conexión puede asomar un lado poco amable es el de la carga de datos desde nuestra organización hacia la nube, y claro como usualmente la infraestructura de la nube esta fuera de nuestro país la latencia si que es un factor a considerar, para lo cual habrá que recurrir a herramientas como Azure Speed y así determinar en que zona geográfica nos conviene mas provisionar nuestros servicios en la nube; pues como vengo insistiendo, el hecho de que haya datacenters cloud en Brasil no implica que vayamos a conseguir mejores velocidades de conexión que las que tenemos con USA.

Pero por mas de que elijamos bien la zona geográfica y aumentemos razonablemente el ancho de banda, hay otro factor que toca considerar y es que la mayoría de conexiones a Internet que se contratan son de tipo ADSL (Asymmetric Digital Subscriber Line) siendo que la A, que antes usualmente no nos importaba pues solo consumíamos contenido, nos puede jugar una mala pasada pues la Asimetría nos recuerda que la velocidad con la que nos podemos bajar contenido siempre sera mucho mayor que la velocidad de subida… upss y eso se refleja en los problemas mencionados anteriormente, de ahí que dentro del planeamiento de uso de soluciones cloud debe hacerse la evaluación de pasar de conexiones ADSL a conexiones DSL que no restrinjan la capacidad de subir contenido.

Ya en el lado que no esta mucho en nuestras manos esta el reclamar por los precios y las velocidades que se ofertan en el Perú (penosas realmente) y esperar que a se haga una NAP a nivel de la Comunidad Andina, lo cual justificaria a los proveedores de cloud el montar un datacenter en la región, o que se mejore la conexión vía fibra óptica con Brasil y así reducir la latencia con los datacenter de dicho país.

Por otro lado, corresponde hacer una mayor difusión respecto a lo que implica cloud en cuanto a generar nuevas aplicaciones (PaaS) o gestión de Infraestructura (IaaS), pues percibo que aun en los departamentos de IT se habla de cloud solo en términos de compartir información en repositorios de facil acceso o usar herramientas de ofimática basadas en Web, y como bien sabemos es mucho mas que eso, todo un reto para los informáticos en estos tiempos ¿no?