Autor: ecardenas

Y ahora verificando la performance (II)

Posted on by ecardenas

Ok, esta vez si me he demorado en la segunda parte de esta serie sobre como agregar pruebas de performance a nuestros procesos de despliegue, en nuestro articulo anterior vimos como agregar configurar una prueba de carga sencilla, básicamente registrábamos una URL, el volumen de la prueba y listo… ya podíamos hacer una prueba preliminar que nos podría ser muy útil en algunos casos (como cuando todos los parámetros de una búsqueda están en el QueryString, por ejemplo), pero si queremos mayor granularidad en los parámetros de la prueba la alternativa es usar los Web Performance and Load Test Project que han ido evolucionando y que mediante el uso de Azure nos permiten desde Visual Studio tener unos resultados de prueba muy configurables, así:

Clipboard26

Y eso esta genial, pues nos permite (mediante nuestra cuenta de VSTS) provisionar recursos Azure que hagan la respectiva prueba mientras sea necesario, y que podamos ver dichos resultados desde nuestro Visual Studio, pero… ¿que tal si queremos que esta validación de carga decida si un despliegue ha ido bien o no? Pues eso es lo que trataremos de conseguir en este post.

En concreto lo que haremos sera agregar un proyecto de carga a nuestra solución, incluirla en el repositorio y de esta manera valernos de sus archivos para incluir un nuevo tipo de tarea durante nuestro proceso de despliegue, asumiremos que estamos trabajando con una solución Web que ya tiene configurado su repositorio asi como sus procesos de Build y Despliegue como hemos visto en anteriores artículos, ¿ok? Finish Reading: Y ahora verificando la performance (II)

Los dilemas de la Gestión de la Configuración en Entornos de despliegue

Posted on by ecardenas

Si, se que les debo el como configurar la prueba de performance avanzada, pero en el interin quiero compartir unas reflexiones a propósito de la gestión de la configuración que vino a mi mente durante el DevDays.

Quienes han ido a mis diversas sesiones sobre VSTS o DevOps, sabrán que siempre hago referencia al lio que nos significa el gestionar los parámetros de configuración conforme una aplicación pasa de un entorno, el como manualmente uno tenia que tener mucho cuidado para asegurarse que la aplicación en Producción no apunte a la BD incorrecta, por mencionar el ejemplo mas claro.

Al empezar usar técnicas de Integración y Entrega Continua el primer enfoque que utilice para aliviar estos problemas fue el basarme en las Transformaciones, de esta manera se gestionaba un Web.Config «maestro» (en el caso de Java y Maven el escenario es muy similar solo que en este caso se trata de «pom»s»), que podía ser usado sin problemas en los equipos de desarrollo, pero al momento de efectuar la construcción de una nueva versión el compilador modificaba el Web.Config reemplazando porciones de este con contenidos especialmente definidos en archivos «delta» que contenían las variantes de cada destino al cual se iba a destinar la versión respectiva, en consecuencia ocurrían los siguientes hechos:

  • Se requiere hacer una Build Definition por cada potencial entorno al cual se iba destinar la aplicación, para de esta manera indicar que la construcción cogiera el «delta» correcto.
  • Si una versión puesta en un entorno es aprobada para ser «promovida» a un entorno superior, es necesario que dicha versión haya sido etiquetada o identificada adecuadamente a fin de poder recuperar el código fuente vigente entonces a fin de generar un paquete para el destino indicado.
  • Todos los «deltas» tienen que estar versionados en el código fuente, lo cual puede ser un problema si se desea mantener reserva sobre las cadenas de conexión a los entornos de Producción.

Aun así esto significa un gran avance con respecto a la gestión usual de editar y copiar a mano los archivos de configuración, donde revisas varias veces para ver que todo esta Ok. Otra opción, que no me gusta, es el de gestionar un repositorio (a veces separado del de código fuente) con todos los archivos de configuración de las diversas aplicaciones y que el proceso de despliegue simplemente copie el archivo respectivo en destino, y en algunos casos efectuar las mezclas necesarias de archivos.

La nube viene a significar una mejora en estos problemas, como vimos anteriormente  es muy sencillo configurar para que sea el Entorno (en este caso un Azure Web App, aunque AWS ofrece algo similar en su Elastic Beanstalk) sea quien almacene los mencionados parametros, y mas aun… gestionar ranuras de despliegue que permitan mover de manera sencilla el paquete de un lado a otro (en realidad mediante un cambio de DNS), conservando cada entorno su propio conjunto de parametros, sin que estos tengan que almacenarse en el código fuente.

Muy bien, parte de los problemas simplificados, uno solo creaba una Build Definition con paso de despliegue a un entorno y luego mediante la consola del entorno se encargaba de hacer los respectivos swaps o intercambios de contenidos, pero eso nos dejaba con los siguientes hechos:

  • Se salia fuera del ciclo automatizado de Integración y Entrega Continua para hacer el movimiento entre entornos.
  • Solo funciona en un entorno PaaS, si se trabaja con IaaS u On Premise, esta ventaja esta totalmente fuera de nuestro alcance.
  • Si se trabaja con AWS, hay que tener cuidado con no publicar valores en los archivos de configuración, pues (a diferencia de Azure) las variables definidas en el entorno solo funcionan si NO están definidas en los archivos de configuración, siendo que lo que este en los archivos tiene prioridad sobre el entorno.

El escenario ha mejorado bastante con la introducción de Release Management, que permite manejar el proceso de Build de una manera separada del de Despliegue, para que de esta manera uno genere un paquete, lo despliegue (cogiéndolo de un punto de contacto común), y si luego se aprueba su paso a otro entorno (mediante el flujo de aprobadores que ya hemos visto) el sistema efectuara la copia respectiva del paquete, y claro si seguimos trabajando aprovechando las ventajas de la gestión de parametros en el entorno… pues ya tenemos casi todo solucionado, solo que entre otras cosas… esto sigue siendo valido solo para PaaS.

En el ultimo DevDays tuve la ocasión de conversar con el gran Donovan Brown, el cual me ayudo con unos detalles de Release Management que no había configurado del todo bien, y en adición a ello le resumí brevemente sobre el enfoque de uso de Azure Web Apps para guardar parametros, y me dijo que es una buena opción para soluciones no complejas, pues solo podemos guardar AppSettings y Cadenas de Conexión, siendo que si requerimos grabar una entrada compleja (como la configuración de Redis) esto solo podríamos hacerlo mediante archivos de configuración, y como de nuevo esto nos regresa al tema de las transformaciones y las build independientes, me sugirió revisar el concepto de tokenización.

Investigando, pude entender (gracias a este interesante articulo) que mediante la tokenización lo que se pretende es que se despliegue un archivo de configuración con marcas (tokens) que luego en el proceso de despliegue (no en la compilación, ojo) sean sobreescritas por parámetros definidas en la Release Definition, resultando en que el web.config (por ejemplo) que llega al entorno destino ya tiene todos los valores correctos para dicho entorno, siendo que estos valores ya no son gestionados por el repositorio de código fuente, sino por el motor de Entrega Continua (en nuestro caso VSTS, pero el concepto es aplicable a otros motores), esta tendencia recién esta avanzando pero se simplifica mucho ahora que es posible definir tareas personalizadas a nuestro VSTS (y me imagino que ya habrá algún plugin Jenkins que logre el mismo efecto), ya que de momento no vienen de serie… pero eso no quita que en un futuro el proceso de tokenización venga de serie, de momento… tocara toquetear un poco… en el caso de ser necesario (cuando no se este usando PaaS y/o necesitemos gestionar valores complejos).

Asi pues, siempre hay formas de mejorar y afinar la solución para casos no cubiertos plenamente ¿qué otras opciones se les ocurren para estos dilemas?

 

Y ahora verificando la performance (I)

Posted on by ecardenas

Varias cosas han pasado desde que empezamos a probar en nuevo modelo de Builds en VSTS, primero creamos una build sencilla que desplegaba a una Azure Web App, luego probamos como usar los Resource Groups para desplegar entornos, luego retiramos el paso de despliegue de la Build para trasladarlo a Release Management luego de su integración con VSTS, y hace poco agregamos Sonar como parte del proceso de análisis de nuestro código dentro de la compilación.

Y como el ciclo de evolución del proceso DevOps nunca para, en esta ocasión veremos como hacer algo a lo que le he tenido bastante respeto desde la época de las builds con el modelo XAML, en este caso la evaluación de la performance y estabilidad de nuestras aplicaciones web desplegadas.

En corto, la posibilidad de probar nuestras aplicaciones Web precede aun a .Net, recuerdo cuando probé Web Application Stress Tool (Homer) para hacer unas pruebas sencillas sobre ASP Clásico, de ahí le perdí el rastro pero la cosa se puso interesante desde Visual Studio 2013 se permite que los tests de carga se basen en las capacidades de la nube, lo cual significa que durante nuestras pruebas se provisionaran las maquinas virtuales que hagan falta para cubrir la cantidad usuarios y peticiones deseadas, esto ya lo había probado desde Visual Studio (revisar aquí y aquí), con buen resultado, pero… ¿como hacer que estas pruebas se ejecuten cuando se produzca cierto tipo de despliegue?

Antes de proseguir hay algunas consideraciones a tener en cuenta:

Los recursos que Azure provisiona para efectuar estas pruebas tienen un costo (si se va por encima de los minutos de carga incluidos con nuestra suscripción de VSTS) por lo que hay que tener cuidado de no lanzar estas pruebas por cada commit que los desarrolladores efectúen, así que la sugerencia general seria tener un sitio de DEV donde se despliegue continuamente pero sin efectuar las pruebas de cargar, luego definiríamos un sitio QA (por ejemplo) al cual se desplegara ya sea de manera manual o de manera programada el contenido existente en DEV (con Release Management lo que se despliega son paquetes que no necesariamente son recién compilados) y al efectuar ese despliegue se lanzaran las pruebas de carga, las cuales si son exitosas indicar que en el proceso de despliegue esta listo para ser sometido a aprobación (si lo hemos definido así) para decidir su pase a otro entorno.

Con estas consideraciones en mente procederemos con nuestra primera prueba para lo cual no sera necesario usar Visual Studio simplemente agregar un paso adicional a nuestro proceso de despliegue, esto es porque a veces lo que nos interesa es simplemente ver que tan bien resiste una URL en concreto a cierta petición.

Para esto vamos a la pestaña de Release de nuestra instalación de VSTS, elegimos nuestro plan actual, seleccionamos el «entorno lógico» sobre el cual agregaremos nuestra prueba de carga y agregamos el Step de Cloud-based Web Performance Test, así:

Clipboard01

Clipboard02

Ok, ahora toca parametrizar el paso para lo cual dejaremos los parámetros mas o menos así, en breve explicare el significado de cada parámetro:

Clipboard06

Antes de proseguir prestemos atención al parámetro Registered connection, lo que ocurre es que cada prueba de carga se hace con cargo a los recursos y facturación de una cuenta de VSTS y podría darse el caso de que la organización tenga mas de una instancia de VSTS, así que corresponde indicar explícitamente dicha cuenta, así que hagamos clic sobre el enlace que dice Manage, que nos abrirá una nueva pestaña en el navegador para agregar un Endpoint (como ya hicimos anteriormente para enlazar Sonar y la cuenta de Azure), y en este caso elegiremos Generic, así:

Clipboard04Y llenamos los parametros de configuración de nuestra instancia de VSTS, pero ojo, al hacerlo deberemos utilizar los datos de nuestra conexión alterna a VSTS, algo de lo que hablamos hace tiempo cuando empezamos a trastear con Git.

Clipboard05

Listo, ya hemos enlazado nuestra prueba de carga a nuestra cuenta de VSTS,  personalmente yo agregaria un checkbox que permita usar la instancia actual y no hacer nada mas, pero siempre es bueno tener una conexión alterna a VSTS especialmente de cara a la integración con herramientas de terceros en Git.

Ok, antes de grabar repasemos los parámetros que estamos configurando:

  • Registered connection: como lo vimos, la instancia de VSTS sobre la cual se hara la facturación de esta prueba de carga.
  • Website Url: La dirección que vamos a probar, en este caso estoy probando la raiz del site (o mejor dicho del slot) en que acabo de hacer el despliegue, cabe indicar que tranquilamente podria haber colocado cualquier URL interna de nuestro site, o peor aun, una URL totalmente externa no manejada por nosotros, pero eso no queremos ¿verdad?
  • Test Name: El nombre con el que identificaremos a esta prueba.
  • User Load: La cantidad de usuarios supuestos que se estarán conectando a nuestra URL.
  • Run Duration (sec): El tiempo de duración de la prueba.
  • Load Location: La zona geográfica de Azure desde donde se hará la prueba, es muy interesante y conveniente hacer la prueba desde una zona que no sea la que aloja a nuestro site, en mi caso la URL esta alojada en East-2, así que la prueba la estoy lanzando desde West.

Marcamos Enabled y grabamos, ya estamos listos para empezar, asi que lo mas sencillo sera hacer un cambio en nuestro codigo fuente, lanzar una nueva Build manualmente, o si queremos divertirnos relanzar un paquete antiguo al ciclo de Release, en todo caso esperamos un poco y veamos cuando nuestra Release se empieza a ejecutar y llega al paso que hemos agregado:

Clipboard08

Para después terminar:

Clipboard09Normalmente pasaríamos a aprobar o rechazar esta Release, pero ahora me interesa conocer los resultados de nuestra prueba, así que vamos a la pestaña Tests, y elegimos la opción LoadTest, para luego seleccionar la prueba mas reciente (en mi caso tengo algunas pruebas anteriores, pero si es la primera vez deberías tener una sola prueba en tu lista).

Clipboard10

Y así entramos a un detalle de los resultados de la prueba:

Clipboard11

Notemos algo interesante, aparentemente nuestra prueba salio ok (o sea, no hubo errores 500 o timeouts) pero el panel nos indica 2 errores, así que veamos el detalle:

Clipboard12

En mi caso el mensaje de error dice «The value 85.10138 exceeds the warning threshold value of 75«, lo cual nos viene a indicar no un error en el sitio que estamos probando sino un exceso en la capacidad de la instancia provisionada para hacer la prueba, esto apunta a que forzamos la maquina dandole 250 usuarios concurrentes, lo cual se relaciona a las pocas opciones de configuración que ofrece este tipo de prueba.

Listo, sencillo y ya podemos empezar a sacar conclusiones, pero como verán esta prueba es muy sencilla y en adición al ya mencionado problema del threshold no permite saber si por ejemplo el comportamiento es diferente desde un browser u otro, desde un tipo de red, etc, para lograr este tipo de análisis lo que se nos ofrece es la posibilidad de crear un test muy detallado desde dentro de Visual Studio y que cuando se efectúe el despliegue Visual Studio Team Services pueda «leer» todos estos parámetros archivados y ejecutar tras bastidores las pruebas programadas, esto sera tema de nuestro próximo post, de momento sugiero familiarizarse con este tipo de prueba, pues los conceptos siguen siendo validos cuando los escalemos, aparte de que estas pruebas tienen su lugar si  hacemos peticiones Get que luego repercuten a nuestra BD, o queremos probar la mejora si usamos un servicio de cache, etc.

Espero sus comentarios 😉

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

Posted on by ecardenas

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?

Posted on by ecardenas

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

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

Posted on by ecardenas

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)

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)

Buenos cambios para el entorno DevOps en Microsoft

Posted on by ecardenas

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!

 

Otro gran reencuentro: Ágiles 2015 en Montevideo

Posted on by ecardenas

Con algo de retraso y con la emoción y entusiasmo aun en mi, repaso estos tres días en que los agilistas latinoamericanos nos reunimos en Montevideo, Uruguay para celebrar el Ágiles 2015, esta fue mi tercera participación en el evento y fue bueno reencontrarse con los amigos, conocer nueva gente y sobre todo… compartir experiencias y conocimiento.
_DSC2810

Excelente el keynote de Mary Poppendieck «Fricción» que nos hizo plantearnos en que debemos enfocarnos en resolver problemas que a agregar «caracteristicas», procurar ir evolucionando y no temer a la experimentación constante, aparte claro esta de reducir la «fricción».
_DSC2862

Ese mismo día me tocaba mi sesión «Gestión Ágil de Entornos de Despliegue en la Nube», tema en el cual he tratado de volcar mis reflexiones producto de la practica este año, así como de la elaboración de los posts que hemos visto sobre el tema, todo salio bien (¡la sala se lleno!) salvo por el tema de Internet, ya que debido a la propia naturaleza de la charla era necesario explicar en vivo los entornos de despliegue sobre los que estábamos hablando, felizmente tenia un vídeo hecho anteriormente que ayudo a mitigar un poco el problema, aquí las diaspositivas de mi sesión:

Como nota curiosa debo decir que la keynote me dio la inspiración para indicar el como los procesos que recomiendo para despliegue tienen como objetivo reducir la «fricción», eso lo capto bien el gran Martin Salias que hizo la facilitación gráfica de mi sesión.

IMG_0978-2

Finish Reading: Otro gran reencuentro: Ágiles 2015 en Montevideo