Pongamos una Wiki en nuestros Team Projects

Bueno, esto podría sonar no tan novedoso si tenemos en cuenta que desde hace buen tiempo las plataformas de tipo Wiki se han popularizado como una forma practica de compartir información entre organizaciones y/o proyectos, pero curiosamente esto era una asignatura pendiente en VSTS, lo cual no deja de ser curioso puesto que hace rato TFS (la versión On Premise) cuenta con dicha herramienta “out of the box” (bueno, si instalas los módulos vinculados a Sharepoint), pero en todo caso esta es una buena noticia, desde hoy podemos agregar una Wiki a nuestros Team Projects.

Y empezar a trabajar con la Wiki, es sencillo, solo tenemos que loguearnos como administradores de nuestra instancia de VSTS y veremos la opción disponible en la barra de herramientas, hacemos clic ahí y solo habrá que seguir las instrucciones:

Y bueno, luego a editar, para lo cual habrá que seguir las guías de marcado correspondientes:

Es todo para empezar, ya se vienen nuevas características como buscador transversal dentro de los diversos proyectos, filtrado, mejoras en el marcado, etc.

Seguiremos informando 😉

El camino de la agilidad personal…

Hace unas semanas durante un “after” luego de una de las reuniones de Agile Perú, surgió la cuestión de que la agilidad cada uno la vive de manera personal … diferente y si, conforme dimos nuestras opiniones vimos que cada uno lo veía bajo un angulo distinto, pero igual de valido; así hubo quien dijo que lo que le gustaba de la agilidad era el poder experimentar, alguien mas comentaba que era el cambio lo mas importante, otro punto de vista era que la agilidad era el poder eliminar desperdicio, también se menciono que lo que atraía de la agilidad era el poder motivar a las personas y equipos, en mi caso personal comentaba que para mi el ser ágil era el poder entregar valor (*) …

Nótese el detalle… distintas aristas, distintos enfoques, todos complementarios, pero en ningún caso hicimos mención a temas de “gestión de proyectos” ni entregar el alcance antes, no… hablábamos de como la agilidad como filosofía (por decirlo de alguna forma) había influenciado nuestras vidas, y que esto era un camino constante… lo cual me hizo traer a colación algo que había comentado hace unas semanas “Si crees que lo de agilismo va esencialmente de gestión, es que tu camino recién ha empezado…”, la conversación de esa noche me lo reafirmó, así que … sigamos en el camino, o inicialo si es que recién estas viendo de que trata esto, no te arrepentirás.

(*) ¿Será por eso que me atrajo el enfoque DevOps?

Relanzamiento de www.agile-peru.net

Para nadie es un secreto que desde que regrese a Perú he estado involucrado en Agile Perú, primero como asistente y luego como parte de su organización, en este lapso hemos tenido nuestras altas y sus bajas, sacando adelante los Agile Open Lima que tanto impulso Lennon, y sobre todo, nuestro recordado y fatigado Ágiles 2013, y en los ultimos años nuestras clasicas reuniones mensuales.

Pero a todo esto, había algo que habiamos pasado por alto, y era nuestra pagina web, que si, que nuestra lista de correo y nuestro Facebook están muy activos, pero si que hace falta un medio propio para poder ir registrando nuestras actividades, facilitar contenido a la comunidad, etc… es asi que desde el 12 de mayo nuestra web esta online nuevamente, en nuevo host WordPress, donde de momento iremos publicando nuestras actividades (como nuestro reciente Agile Open Lima VIII) asi como la discusión de los planes futuros de nuestra comunidad.

Como buenos agilistas hemos empezado con una versión básica que de momento nos permite ir posteando, pero que esperamos vaya creciendo para incorporar secciones y diseño funcional para nuestro publico, en eso estamos, paso a paso….

“Nuestro sistema no es compatible con DevOps”

Esto del enfoque DevOps y el que sepan de que uno es promotor de ello trae escenarios bien peculiares que me motivan a reflexiones que quiero compartir con ustedes….

Hace unas semanas conversaba con unos amigos y hacíamos referencia a que en el proyecto de uno de ellos los pases a producción terminaban en la madrugada, y la respuesta fue “es que nuestro sistema no es compatible con DevOps”, bueno… directamente solo le pude decir que DevOps no es solo eso, pero me derivo a pensar en la malinterpretación de mi amigo, las implicancias que esto trae y claro… caminos de solución.

Lo primero, como ya hemos conversado anteriormente, DevOps es un enfoque que procura la sinergia y colaboración entre las (usualmente divididas) áreas de Desarrollo e Infraestructura de cara a mejorar los flujos de entrega de valor a los usuarios finales, empero las ideas que se suelen asociar al concepto son las de Integración y Entrega Continua, Automatización, Infraestructura como Código, y ya en casos extremos con los ejemplos ultra difundidos (pero interesantes) de las empresas tecnológicas que sacan varias versiones de sus aplicaciones a producción… diariamente, y claro si al final uno termina pensando en DevOps=Despliegues superautomatizados, el corolario es creer (como mi amigo) que aplicar DevOps es imposible por culpa de las aplicaciones con las que se esta trabajando, olvidándonos de lo mas importante en DevOps: sinergia y colaboración, que como veremos es el punto de partida en la búsqueda de mejoras.

Regresando al caso que nos ocupa, pensemos en lo que involucra un despliegue de una aplicación corporativa de mediana a grande: compilación, parada del sistema actual, actualización de base de datos, ejecución de scripts en sistemas asociados, despliegue de compilados, validación progresiva de que los cambios están funcionando, etc… si, pasos complejos que deben realizarse con cuidado y que son la razón por la cual la fiesta dura hasta el amanecer con desayuno incluido; en ese contexto se puede pensar que para acelerar los despliegues se requieren cambios muy grandes, instalación (y adquisición) del software adecuado, capacitación de los equipos, consultores, y zas! pasamos al escenario de pensar en los recursos (financieros) para la implementación de una iniciativa DevOps que ponga en marcha lo necesario (*), siendo que aun con restricciones se pueden dar los pasos de Mejora Continua en los procesos de despliegue.

Reitero: colaboración y a lo cual debemos sumarle el compartir información, así que para el despliegue mencionado correspondería reunir a los involucrados en el proceso de las diversas áreas y basarnos en la técnica de Los cinco ¿Por qué? a fin de entender plenamente el flujo de despliegue, así que especulando mucho la cosa quedaría así:

  • “¿Por qué el pase a producción de XYZ tarda de 3 a 5 horas?”
  • “Es que necesitamos antes actualizar el subsistema conceptual VW y las bases de datos golosinarias OP” “El sistema de actualización estratosferico GH tarda media hora”
  • “¿Por qué el sistema GH tarda media hora?”
  • ….
  • “¿Por que los módulos florales DE no se actualizan como los módulos hidráulicos JK?”

Bueno, cada sistema es un mundo propio, pero el punto de este análisis es procurar que las áreas involucradas tengan un conocimiento cabal de lo que involucra cada etapa del despliegue, incluyendo las que no están bajo su directa visibilidad o responsabilidad, pues es lo que nos pasa como tecnologos nos enfocamos mucho en nuestra área y solemos pensar en el resto de los sistemas e infraestructura con los que interactuamos como si fueran una caja negra (**) lo cual limita nuestra capacidad de sugerir mejoras en el proceso de forma integral.

Como consecuencia de este análisis se pueden identificar de manera colaborativa los puntos de mejora que se pueden acelerar (ya sea mediante scripts o automatizaciones parciales), coordinaciones a simplificar, reducción de redundancias en el proceso, y establecer una prioridad de acciones de mejora a realizar de cara a los sucesivos pases a fin de reducir los tiempos, que si, no hemos logrado aun establecer los hermosos pipelines en los que con un clic logramos desplegar todo el repositorio de código fuente en los entornos, pero por lo menos ya se han dado los pasos para que cuando llegue el momento sea mas simple el orquestar todos los pasos apoyándonos en una herramienta de automatización de despliegues como VSTS/TFS o similares, pero en el camino habremos iniciado el proceso de reducir los tiempos de despliegue, mejorar su calidad y logrando incrementar la autoconfianza del equipo en su labor, pues quienes hemos tenido que hacer pases a mano sabemos la tensión extrema que hay hasta que no se esta seguro de que los cambios “ya están corriendo en producción”. Y.. ¿saben? aun cuando no se llegue a la super automatización, este proceso de colaboración también es DevOps.

Ahora que si me dicen que va a ser muy difícil (y no hablo de temas de disponibilidad de horarios) poner a los diversos involucrados frente a una misma pizarra y mas difícil aun que compartan su información, pues…. el problema es muchísimo mas serio que unos despliegues lentos, y toca trabajar bastante desde el punto de vista cultural, por lo que cualquier estrategia llamada “Iniciativa DevOps” o similar basada unicamente en la automatización y gestión del ciclo de releases/entregas solo estará automatizando ineficiencias de una raíz muy profunda.

Entonces podemos ver que si bien mejorar nuestros flujos de entrega de valor implican un esfuerzo y cursos de acción priorizados, es posible lograr mejoras importantes aun sin llegar (de momento) a la total automatización, la cosa es partir desde el principio, en mejorar la colaboración y el flujo de información entre las áreas involucradas.

(*) Lo cual no esta mal si dicha iniciativa no se queda solo en la automatización pura y dura sino que también (y sobre todo) es capaz de lograr los cambios culturales asociados al enfoque DevOps.

(**) Siempre comento lo productivas que fueron unas reuniones que el equipo de desarrollo tuvo con el jefe de infraestructura en un proyecto en el que participe, gracias a dicha reunión pudimos entender cabalmente cual era el trafico de paquetes entre las sedes de la organización, eso nos ayudo a hacer cambios en la configuración de la aplicación así como a sugerir ajustes en el sistema DNS y de ruteo de la red.

Las perspectivas PaaS Linux sobre Azure

Si hace unos años me hubieran dicho que estaría comentando sobre lo que menciona el titulo, me hubiera puesto a reír, pero el contexto tecnológico cambia de manera constante y este es el escenario en que los desarrolladores debemos tener claras nuestras opciones a la hora de considerar Linux como plataforma.

De mas esta comentar sobre las oportunidades que nos ofrece .Net Core para poder llegar a escenarios en los que tradicionalmente Windows estaba vedado, pero también debemos tener en cuenta las perspectivas de poder integrarnos y trabajar con otros stacks, así que si… Linux nos va a rodear bastante a los que trabajamos con .Net.

Ahora bien,  trabajar con Máquinas Virtuales Linux siempre ha sido posible desde que los proveedores de cloud empezaron a ofrecer IaaS, pero si uno basa su estrategia cloud en depender de máquinas virtuales que básicamente replican la arquitectura que se tenía on premise, no se está sacando partido de las potencialidades de la nube (optimización de costos y escalamiento) ni  tampoco se esta asumiendo un enfoque pragmático frente a los retos (o limitaciones) inherentes a la nube, como pueden ser los niveles de servicio asegurados por el proveedor (SAL), lidiar con las latencias, etc, esto y la necesidad de brindar a nuestros equipos de desarrollo con plataformas que aceleren su productividad nos deben obligar a mirar la nube más allá del IaaS.

Es con esta mirada que debemos analizar la propuesta PaaS que nos da Azure en el entorno Linux; recordemos que tradicionalmente si queríamos implementar una Web App lo que estábamos provisionando “por detrás” era una MV Windows con un IIS especialmente configurado para permitir las ventajas como slots, escalamiento, kudu, etc… lo cual nos va bien para aplicaciones .Net pero por ejemplo no nos permite correr aplicaciones Ruby, aparte de que existen escenarios en que se requiere cierta librería PHP que ¡oh sorpresa! tiene una fuerte dependencia con el sistema operativo Linux, así que era natural que Microsoft Azure venga a ofrecer una solución de Web Apps basada en Linux como una opción para los desarrolladores, misma que en este momento esta en versión de prueba.
top-level-create
Finish Reading: Las perspectivas PaaS Linux sobre Azure

Las expectativas sobre DevOps

El pasado 7 de Abril tuve la oportunidad de exponer en el Scrum Day Perú mi presentación  “En búsqueda del DevOps perdido”, esta presentación es una evolución dos años después de mi charla “El reto del DevOps ágil”, pues trato de explicar como el concepto se ha ido distorsionando desde lo que originalmente era, un enfoque de búsqueda de sinergias entre los equipos en el proceso de generación de valor para la organización, en un afán por automatizar y que una persona se haga cargo de ello (de ahí la aparición de ofertas de empleo para el “rol” de DevOps).

Y parte de este problema lo pude notar en el auditorio, pues por lo que pude conversar, parte del publico esperaba una charla mas técnica, orientada a solucionar problemas de implementación y/o de elección de herramienta, lo cual me hizo reafirmarme en cuanto a la importancia de esta reflexión, en lo fácil que estamos cayendo en algunos de estos antipatrones sobre el enfoque DevOps:

  • DevOps es un rol, pues no… es un enfoque sinergico que busca la entrega continua de valor
  • DevOps es un rol que debería ser ocupado preferentemente por IT Pros/sysadmin, siendo que los roles de apoyo a este enfoque pueden provenir de cualquiera de ambos equipos, en tanto se cuenten con las habilidades blandas que faciliten la comunicación y sinergia
  • DevOps es básicamente automatizar, en realidad automatizar es el resultado de las decisiones sucesivas que se toman para optimizar el ciclo de construcción y entrega de aplicaciones
  • Tratar de asociar ciertas herramientas o plataformas a lo que es DevOps

Y claro, si se parte de esas premisas, el riesgo de terminar decepcionado es muy alto, así pues, nos toca seguir revisitando los orígenes del enfoque y seguir en la búsqueda de la mejora continua de nuestros procesos, y de eso nos cuenta un poco Jersson.

Espero sus opiniones, y de momento los dejo con la presentación mencionada.

Reflexiones a proposito del #CentenarioPUCP (2): La Ingeniería Informática en perspectiva

Habiendo ya comentado respecto a lo que significa mi alma mater en el contexto actual, toca reflexionar sobre la situación actual de nuestra especialidad, la Ingeniería Informática, su perfil, su evolución y sobre todo sus retos a futuro.

17499173_1885665281678573_8201655322192449166_n Finish Reading: Reflexiones a proposito del #CentenarioPUCP (2): La Ingeniería Informática en perspectiva

Microservicios: claro y simple

Desde hace tiempo hemos escuchado mucho sobre la conveniencia de usar Microservicios para el desarrollo de aplicaciones frente al esquema “monolitico” tradicional, de hecho la primera exposición seria que tuve sobre el tema fue durante el Agiles 2015, donde Maria Gomez dio un excelente charla planteando el esquema, de la cual comparto y recuerdo la facilitación gráfica respectiva:

_DSC3014

Desde entonces muchas dudas afloran ¿entonces ya no tendremos transacciones ACID? ¿como validamos la consistencia? ¿como deberemos modelar los datos? lo cual sumado a las ventajas ofrecidas por Docker hace necesario tener las bases teóricas claras para acometer este tipo de desarrollos.

En ese sentido, junto al lanzamiento de Visual Studio 2017, Microsoft presento una aplicación de referencia, basada en Contenedores y Microservicios, llamada eShopContainers que esta disponible en GitHub para ir siguiendolo (pues es un trabajo en construcción aún), miren nomas lo ambiciosa que es:
eShopOnContainers_Architecture_Diagram

Si, ambiciosa en cuanto a la diversidad de tecnologías a usar: Docker, Linux, .Net Core, Xamarin, etc pero lo mas importante a mi modo de ver es el libro que se esta construyendo, y que se puede descargar aquí.

He empezado a leerlo y me ha gustado mucho, se cubre con claridad que son los Microservicios, como se relacionan con Docker, los nuevos paradigmas a seguir, un concepto interesante llamado Data Sovereignty, como estructurar las entidades, lo cual hace caer en cuenta de la necesidad de ir entendiendo los conceptos de DDD, y lo mejor de todo, con un lenguaje claro y bien estructurado, lo dicho… ya estas tardando en descargar el libro!

Muchas gracias a Cesar de la Torre de Microsoft por este trabajo emprendido que nos ayudara mucho a los desarrolladores.

(Vídeo) Conociendo a los Build Agents

De vuelta a los contenidos y en esta ocasión (aprovechando la licencia de Camtasia) decidí probar con un video para explicar un concepto indispensable a la hora de decidir cual sera nuestra arquitectura de desarrollo y despliegue con TFS/VSTS: los Build Agents, que son, como han evolucionado, con que tipos contamos y cuales son las implicancias de elegir Agentes privados o Agentes hosteados, espero que sea de utilidad para entender este pilar de la arquitectura de TFS/VSTS

Enlaces de referencia:

Empezando bien el año: MVP

Pues si, este año empieza bien pues hoy recibí el correo que me informa que se me ha otorgado el reconocimiento Microsoft Most Valuable Professional (MVP) en la categoría Visual Studio and Development Technologies, esta designación me motiva mas para seguir este proceso de compartir conocimiento en lo que son las practicas ALM y DevOps, así que nos espera un año con un reto bastante exigente. Muchas gracias a todos los que me apoyaron en este proceso, tanto de Microsoft Perú como de las diversas Comunidades Microsoft.

mvp