¿YAML Pipelines? Si, ¡facil!

Posted on by ecardenas

Durante este tiempo, he estado explicando como construir Pipelines (antes Build definitions) en VST.. digo Azure DevOps, y para esto he mostrado como ir agregando diversas tareas a nuestro pipeline, para lo cual nos hemos apoyado en el diseñador gráfico que facilita la herramienta, algo que facilita la productividad y la curva de entrada para empezar a desplegar automáticamente, pero claro, pese a la facilidad había una objeción recurrente, el como poder versionar y/o editar en modo texto nuestros pipelines, claro, existe la posibilidad de exportar las definiciones como JSON, pero la verdad ese modo sufre de dos problemas: no esta integrado con el repositorio de código fuente y lo mas importante, no es leible fácilmente por humanos.

En base a este problema, desde el año Microsoft introdujo la opción de editar nuestros pipelines en formato YAML (usado también por Kubernetes y otras herramientas CI/CD) lo cual fue bien recibido por la comunidad de usuarios, pero este cambio involucraba el pasar a solo editar un archivo de texto en el repositorio, perdiendo los asistentes de las tareas y el tener que saber como escribir los diversos parámetros de las tareas a usar, bueno… eso esta cambiando desde ahora.

Primero, casi desde un primer momento se ofreció la opción de exportar nuestros Build Pipelines existentes como YAML y así tener un punto de partida para empezar el versionamiento, como se puede ver en las siguientes pantallas:

El gran paso viene dado ahora, pues al editor tradicional de puro texto, se le agrega un asistente que permite usar un formulario para configurar de manera visual los parametros de una tarea, que es lo que veremos a continuación.

En este caso lo que ya tenia es un YAML que compilaba una solución en .Net Core, siendo que me interesaba que una vez que la compilación se efectuara, tuviera disponible (para el posterior paso de release) una carpeta de la solución con el codigo ARM de la infraestructura que alojara la solución a desplegar, por lo que lo que tenemos que hacer es editar nuestro YAML y elegir la tarea respectiva:

Ya estamos en la tarea deseada “Publish and Build Artifacts”, asi que pasamos a editar los valores necesarios:

 

Damos clic en Add, y listo, ya tenemos la porción de código de la tarea en nuestro YAML!

Ahora toca seguir las novedades del Build donde seguramente veremos mas avances sobre como Azure Pipelines nos puede ayudar en nuestros ciclos de despliegue.

 

 

“Poquitecto” ¿realidad, broma o necesidad?

Posted on by ecardenas

Desde hace un tiempo, en un grupo de amigos desarrolladores, bromeamos acerca de como uno de nosotros tiene el rol de “Poquitecto“, la razón de esta broma deriva del hecho de que nuestro amigo tiene el rol de Product Owner, siendo que esta adscrito a un departamento de Arquitectura en su organización, y claro en esta época de “cargo cult agil” nunca esta de mas hacer una broma respecto a que nuevo rol puede inventarse dentro de las organizaciones…

La verdad es que esto no hubiera pasado de una broma o anécdota, si no fuera porque la conversación me hizo recordar que ¡Yo trabaje con un poquitecto!, ¿como así?, bueno, resulta que hace poco mas de un año el equipo en que me encontraba paso por un cambio radical de Product Owner, pasando de alguien con mucho enfoque en la funcionalidad de negocio a agregar y la facilidad de uso respectiva (vamos, un PO “clásico” *), a uno con fuerte base técnica (pero involucrado en la organización y el producto por varios años) que priorizaba y enfocaba las Historias de Usuario con un claro enfoque hacia la arquitectura de la integración tecnológica de nuestra aplicación con otra que estaba siendo desarrollada por otro equipo.

Y claro, las reuniones incluían conversaciones respecto a lo que implicaba el conectarse con la otra aplicación, el como estaba construida nuestra aplicación, diálogos en los que nuestro nuevo PO se implicaba directamente; cabe agregar que nuestro Scrum Master era uno de los que te acompañaba en la depuración de código cuando había que meter un cambio radical a lo que ya se tenia desarrollado y en producción.

¿Que cual de los dos perfiles de PO es el mejor? pues, a riesgo de hablar como consultor daré la respuesta clásica: “depende”, pues en una etapa del ciclo de desarrollo se requería un enfoque totalmente orientado al negocio y a la funcionalidad a agregar, pero en otro estadío dicha visión tecnológica era de gran utilidad (y hasta de necesidad) para lograr orientar adecuadamente los cambios esperados.

Desconozco los detalles del rol de nuestro amigo, pero esta experiencia me indica que a veces puede ser necesario que haya una “fusión” entre las actividades correspondiente a un Product Owner y las de un Arquitecto, tenga esta mezcla el nombre que tenga (llámalo poquitecto si quieres), que en un momento ese nombre se consolide… depende de como siga el cargo cult en nuestras organizaciones(**).

(*) Ya lo he mencionado antes, personalmente creo que es imprescindible que un Scrum Master tenga un conocimiento del ámbito técnico en el que se va a mover con su equipo (sin llegar a ser experto), requerimiento que no considero mandatario para un Product Owner.

(**) Las cuales hablan de la importancia del Agile Technical Coach (si, otro cargo) y de la excelencia técnica, pero a la hora de la verdad no efectúan las acciones reales.

Agilidad al borde del nuevo año

Posted on by ecardenas

El 2019 se cumplirán 10 años que estoy metido en estos temas de la agilidad, escena/movimiento que ha ido cambiando y readapatandose con una velocidad asombrosa, cayéndose, aprendiendo sobre la marcha, generando cuestionamientos, así que este fin de año es una buena ocasión para repasar algunas de las cosas que se han visto en este año en este entorno y comunidad.

Una de las cosas que afecto la escena agil mundial en los primeros meses del año fue el asesinato de Mike Beedle, firmante del Manifiesto, el cual poco antes había publicado esto

 

Reflexión totalmente valida (sumada a otra en la que proclamaba “arreglar” Scrum para seguir avanzando *) en un contexto en el que se hizo énfasis el ver la agilidad como algo solo organizacional y/o cultural, olvidándose de que el pilar técnico es importante el proceso de desarrollo de software, lo cual de la mano con el omnipresente “cargo cult” derivo que el rol mas demandado el año pasado y principio de este fuera el de Agile Coach y derivados, es que claro, si se quiere seguir escalando ser Scrum Master ya no es suficiente.

La consecuencia de ese boom fue que se empezó a dar una imagen de que para lograr hacer cambios hacia la agilidad lo importante era tener buenos coaches (externos, claro esta) y Scrum Masters, que no tenían porque entender (que no es lo mismo que ser expertos, ojo) las complejidades del desarrollo de software en un problema en concreto, sino en procurar la búsqueda de la felicidad de los equipos, y si al final del PI se tenia un bonito tablero frente al que sacarse fotos, mejor que mejor… y claro, este fenómeno se replico en las comunidades y eventos, generando una saturación del tema coach y relacionados, olvidándonos de como hacer bien software (en un momento en que todos p. ej. quieren hacer microservicios porque esta de moda, y no hay quien les pare la mano).

Este problema, porque hay que reconocer que es un problema, derivo en otros dos fenómenos relacionados, por un lado los mas hardcore empezaron a sentir que ya no tenían su lugar en la agilidad por lo que procuraron consolidar espacios para hablar en profundidad de los temas de software, y por otro lado el empezar a apuntar que algo esta mal, lo cual se hizo mas evidente con el ya famoso discurso de Martin Fowler en Australia, donde básicamente instaba a afrontar los siguientes retos:

  • Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
  • Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
  • organize around products.

Ah si! porque me olvide de algo, es que durante este tiempo (junto a los coaches) no falto quienes se subieron al carro para venderles a las empresas (ansiosas de comprar, hay que decir) el como volverse ágiles, pero para variar, aplicando estrategias top down que generalmente dejan intactos los esquemas, pero claro, queda muy bien decir que se esta muy involucrado con la agilidad por ir contratando varios SM y coaches.

El discurso de Fowler tuvo su impacto (por ejemplo la respuesta de Uncle Bob) a nivel global y debate a nivel de la comunidad, en la que si por un lado se paso a revalorar (**) la importancia técnica en el desarrollo de software, por otro lado se ha dado una vuelta de tuerca con el mensaje de que “Agilidad no es Agile”, que Agile solo es a nivel de software, que agilidad va mas allá, “esto no lo logras  en la agilidad de equipos”; todo este nuevo buzz me parece que puede salirse de control, pues empuja la idea de que esto de lo que hemos tratado de hablar en estos años solo corresponde al “nivel estratégico”, lo cual termina dando un carácter secundario a objetivos como los de empoderar a los equipos y sus miembros o valorar el trabajo real sobre la imagen … , suma esto al hecho de afirmar que los coaches requieren “espacios seguros” para perfeccionarse, y tenemos una receta perfecta para segmentar a una comunidad que debería empujar un proceso de construcción colectiva.

Hay esperanzas, por un lado algunas organizaciones ya no están cayendo en la búsqueda de coaches (o SM) al peso, sino valorando sus meritos per se, aunque claro… el cargo cult terminara buscando nuevas figuras para asegurar la relevancia cuando un termino ya dejo de ser cool; por otro lado esta nuestra responsabilidad y consciencia de asegurar que los tópicos vinculados a la excelencia en nuestros ámbitos de dominio sigan presentes, y eso es tarea de todos en la que seguiremos.

(*) Lo cual hace inevitable recordar el como hay quienes saltan diciendo “eso no es Scrum” cuando ven que algunos equipos han evolucionado a practicas que les son mas eficientes en su contexto, pero que ya no siguen Scrum al pie de la letra.

(**) Por ejemplo en el HT #PorfaArgentina salto la importancia de asegurar espacio para el contenido técnico en el próximo Ágiles 2019.

 

Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Posted on by ecardenas

Por aquí ya hemos hablado una vez y otra sobre como gestionar los datos sensibles (como las cadenas de conexión) de nuestras aplicaciones, porque, claro, nadie debería de poner los datos de producción en el código fuente que grabamos en nuestro repo, ¿verdad?

Anteriormente las opciones pasaban por efectuar mezclas/transformaciones de tal manera que en tiempo de compilación se generara un archivo final con los datos sensibles correspondientes a cada entorno, lo cual si bien nos daba simplificación para colocar la clave correcta en el paquete y entorno correcto, nos obligaba a seguir versionando las cadenas de conexión en el código fuente (por no mencionar que había que compilar mas de una vez); la otra opción pasaba por gestionar dentro del entorno de destino (en nuestros ejemplos: WebApps) sobrescribiendo de esta manera los valores que vinieran desde el código fuente.

Dado que ni nuestro repositorio ni nuestra herramienta de integración/despliegue deberían contener datos sensibles, usaremos un servicio de nube que nos da la seguridad necesaria para gestionar nuestras credenciales, el Azure KeyVault, el cual nos permite almacenar de manera segura y granular ya sea certificados digitales como data sensible, pudiendo restringir quienes pueden acceder a que datos y a que no (aplicando Control de acceso basado en roles: RBAC). Un mecanismo usual de accesos a estos recursos sensibles es programar dentro de nuestra aplicación un código que lea los valores en tiempo de ejecución (procurando no releer el valor a cada uso, sino hacerlo una única vez), en este caso usaremos un enfoque distinto que consistirá en leer los valores almacenados en KeyVault durante nuestro pipeline de despliegue, alterando secciones del archivo appsettings.json (porque nuestro ejemplo se basara en .Net Core) que se alojara en nuestra Web App destino (aunque también funciona perfectamente en un despliegue sobre IIS).

Así que estos serán los pasos que seguiremos:

  • Crear un KeyVault
  • Crear un “Secret” dentro de nuestro KeyVault, ahí sera donde almacenaremos una cadena de conexión a la base de datos
  • Identificar el “Principal” mediante el cual nuestro Team Project se conecta a Azure
  • Dar los permisos sobre nuestro KeyVault a dicho principal
  • Identificar en nuestra aplicación las secciones a modificar en tiempo de ejecución
  • Enlazar nuestro TeamProject contra el KeyVault, fijando el scope respectivo
  • Configurar el reemplazo de valores en el appsettings.json
  • Validar que nuestros cambios han sido desplegados en el entorno destino

Para esta demo asumiremos que tendremos tanto un pipeline de Build como de Release, de una aplicación en ASP.Net Core, en nuestro ejemplo usare la aplicación de ejemplo del libro de EF Core in Action (excelente libro que tuve el honor de revisar) cuyo código fuente se puede descargar aquí, y claro, como es usual el despliegue lo haremos contra una Azure Web App.

Para el primer paso seguiremos las instrucciones dadas en la primera parte de este articulo, en mi caso he usado estos nombres: RG_DevmoVault01 para el Resource Group y ErnestoDemoKeyVault para el KeyVault, como en este caso la creación la hemos hecho vía linea de comandos verificaremos que podemos revisar este recurso en el Portal de Azure, así:

Finish Reading: Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

En el Microsoft Ignite 2018!!

Posted on by ecardenas

Estas semanas han sido muy intensas para mi pues tuve la ocasión de participar en el Microsof Ignite, que se realizo en Orlando el pasado Septiembre, y si, era la primera vez que iba a un evento de estas dimensiones, pero la emoción era mayor pues participaba como speaker al haber sido aprobada mi ponencia DevOps is about people, beyond automation, reto grande, ya que si bien es un tema que me es familiar significaba mi primera vez como orador en ingles, por lo que me pase un buen tiempo ensayando todos los días para estar a la altura del evento.

Domingo 23, MVP Preday donde nos dieron los ultimos tips para la presentación.

Ya en el evento en si, arrancamos con el Keynote de Satya Nadella, y tuve la suerte de poder ver de cerca la presentación.
Y antes de mi charla aproveche para visitar el stand de libros donde hojee dos de los libros que tuve la suerte de revisar para Manning

Y llego el momento, lunes 24 en el Expo Theater 6, tocaba presentar el material, felizmente todo salio bien ante mas de 100 asistentes.

Aquí con la gran Jessica Deen, de la League!!

Ya en los siguientes días, trate de aprovechar el evento con calma, pero primero atendí a una entrevista con el equipo de Microsoft Latam!!.

Ultimo día, mis pasos se dirigían con cierta pena al OCCC, pero contento por todo lo aprendido.

Con la promesa de regresar!!
Gracias OCCC y hasta la próxima!!!

Comparto mi sesión, esperando sus comentarios sobre estas visión de DevOps.

Presentando Azure DevOps

Posted on by ecardenas

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

¿Qué es lo que esperamos de nuestros Scrum Masters?

Posted on by ecardenas

Normalmente en los artículos y conferencias vinculados a la agilidad se nota mucho el enfoque de como los Scrum Master (y Agile Coaches) pueden ir mejorando, evolucionando y lograr lo mejor de los equipos para conseguir los objetivos esperados de la organización, pero… ¿cuantas veces hemos reflexionado sobre que es lo que esperamos los miembros “de base” de los equipos ágiles de nuestros respectivos SM? (*)

Es así que en la pasada reunión de Agile Perú, propuse el tema así que comparto las reflexiones de dicha reunión sumado a los comentarios de entonces y los que luego tuve en conversaciones posteriores.

Como punto de partida previo, hay que tener claro que no se esperaba que el Scrum Master fuera un “cargo” institucionalizado, si no mas bien un “rol” dentro de los integrantes del equipo; lamentablemente, por la deriva que ha tenido la “escena ágil”, la figura se ha consolidado, tanto por el movimiento de ex PMs que se acercaron a la agilidad, como por los profesionales que buscan ir a la rama de “gestión” esquivando lo técnico, esa es la realidad y si bien hay que recordar cual era la intención original del rol, también es bueno procurar canalizar de manera adecuada la situación en aras de lograr lo mejor para los equipos.

Con esto como base, soy de los que considera que el objetivo del Scrum Master es volverse prescindible para el equipo ya que ha procurado que este haya llegado a un grado de madurez que permite se pueda confiar en su auto-organización, esto implica muchos retos, pues el perfil de cada equipo es diferente, puede tratarse de profesionales con poca experiencia en las practicas ágiles (o en el dominio tecnológico respectivo) por lo que corresponderá un acompañamiento adecuado para que esto se vaya impregnando en el hacer de los miembros del equipo, o también tratarse de un equipo de rockstars con mucha experiencia tanto tecnológica como en agilidad y que por lo mismo tocara hacer los esfuerzos para que las diversas personalidades logren la sinergia y colaboración esperada. Como se ve, retos diferentes pero con el (se supone) mismo objetivo, convertir un grupo de personas en un equipo auto-organizado, así que creo que el éxito de la carrera de un SM (**) debe apreciarse por como (y a cuantos) ha contribuido a lograr que los equipos hayan llegado a ese estadio, que (por cierto esta en el Manifiesto Ágil) : “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados“. Finish Reading: ¿Qué es lo que esperamos de nuestros Scrum Masters?

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Posted on by ecardenas

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Agilidad ¿responsabilidad de todos?

Posted on by ecardenas

Si, por aquí de nuevo, luego de unas semanas muy ajetreadas, donde pudimos organizar el Global DevOps Bootcamp, renové mi participación en el programa Microsoft MVP (gracias por la confianza!) y se organizo el Ágiles Perú 2018 con motivo del décimo aniversario de nuestra comunidad.

El evento se realizo en la UTEC, y pese a todo lo acelerado que pasamos como comité organizador fue todo un éxito, mucho interés del publico por las charlas de los asistentes y varias propuestas interesantes en el Open Space.

 

En todo caso la jornada me dejo algunas anécdotas que están derivando en reflexiones, que comparto con uds. Finish Reading: Agilidad ¿responsabilidad de todos?

¿Una Imagen vale más?

Posted on by ecardenas

En esta ocasión cedemos el espacio a una amistad de la comunidad que prefiere permanecer en el anonimato, pero tiene algo valioso y crudo que contar.

La famosa frase que dice “Una imagen vale más que 1000 palabras” ¿Realmente calza en todos los entornos? Porque lo que percibo en mi mundo laboral, mi entorno el desarrollo de Software, Aplicación de Negocios, y Mejora de Procesos, etc. Realmente esta frase solo engaña.  L

Mi comentario, es que ahora lo que se ve más por los pasillos son lindos posits  de colores e imágenes bonitas de equipos que aparentan la mejor calidez y que nada malo pasa por ahí.

Hasta que se tienen resultados. Finish Reading: ¿Una Imagen vale más?