Continuous Delivery va de la mano de una cultura DevOps (este año en el Encuentro GeneXus participaré de dos charlas, una sobre Continuous Delivery en GeneXus, junto a Fabián Baptista, y otra sobre DevOps y GeneXus, junto a Laura Aguiar; lo bueno es que están bien alineadas). No se trata “solo” de Integración Continua (lo cual es una tarea que podría hacerse en el equipo de desarrollo, sin participación ni incidencia en nadie más), sino que se trata de aceitar todo el proceso de construcción y entrega del software, para que le estemos entregando nuevo valor a los usuarios y clientes de manera frecuente. Las optimizaciones al proceso incluyen e impactan al negocio, al desarrollo y a operaciones, y de ahí la relación con DevOps.
En Abstracta estamos trabajando cada vez más con clientes que ya tienen esta metodología funcionando, y los beneficios en la productividad y en la calidad con la que se entrega al usuario son notables, y quizá más que nada en la tranquilidad con la que se hacen los cambios. Una buena forma de resumirlo sería que se busca reducir el riesgo y aumentar la confianza. Por esto es que queremos aportar de alguna forma en que estas prácticas se puedan llevar a cabo en la comunidad GeneXus.
Continuous Integration, Delivery y Deployment
Ya había hablado de las diferencias en este post, pero traigo también este post que creo que explica muy bien las diferencias, y por eso voy a aprovechar incluso las imágenes que utilizan para esquematizar las diferencias. El siguiente esquema muestra lo que implica Continuous Integration, donde básicamente se puede ver que los desarrolladores trabajan versionando su código en un repositorio, y luego existe un servidor de integración continua que toma esos cambios, construye la aplicación, ejecuta pruebas y determina si el build está “roto” o “estable”, notificando a todos los desarrolladores al respecto.
Cuando pasamos a hablar de Continuous Delivery y Continuous Deployment, hay más automatismos en el proceso, en el pipeline, tal como se representa en la siguiente imagen.
La diferencia entre ellos es el hecho de que en Continuous Delivery alguien tiene que hacer el deploy en producción de forma “manual”. Seguramente esté automatizado y sea solo un clic o la ejecución de un comando, pero lo importante es que alguien tiene que tomar la decisión. En Continuous Deployment esto es automático, entonces, cada línea nueva que pasa todos los chequeos automáticos llega a los usuarios (es lo que todos comentan que hacen empresas como Facebook o Google).
Pipeline desde la idea hasta la felicidad del usuario
Existe así un pipeline desde la idea o requerimiento, hasta que el usuario es feliz con la funcionalidad en el sistema, y en distintos puntos de ese pipeline deberemos ir tomando feedback para corregir cualquier desviación lo antes posible. Vale aclarar que (según como yo lo veo) no alcanza con mirar ese pipeline hasta el momento en que el usuario recibe el software por primera vez; creo que hay que mirar también las idas y vueltas que se puedan generar. Por esto es que en ese proceso es igual de importante ir tomando medidas de cómo se desempeña nuestro sistema en manos de los usuarios, para continuar el ciclo de mejora continua a partir del feedback que se obtenga cuando estos lo usan.
Para aumentar la productividad, para reducir el time to market, o sea, el tiempo desde que llega la idea hasta que está en las manos felices del cliente, quiero citar dos cosas que he escuchado y conversado en estos días que me parecen muy acertadas y relevantes:
- Conversando con Enrique Almeida sobre CI/CD me comentó: El cambio grande, es empezar a pensar en TODO el proceso de vida de una aplicación en vez de optimizar por partes. Trae grandes cambios en la forma de trabajar, pero aparecen muchísimas oportunidades de mejora en productividad y calidad.
- Karen Johnson comentó en un podcast: CI/CD no se trata de ir más rápido, sino que se trata de hacer otras preguntas.
Entonces, tenemos que que hacer otras preguntas, mirando el todo, optimizar no solo las partes, sino el proceso general. CI/CD plantea tener un proceso optimizado para obtener feedback lo antes posible, detectar el error temprano y corregir, antes que se propague en el camino hacia las manos del cliente.
En este sentido, quiero ir haciendo un pienso también de las distintas partes en que se puede optimizar y alimentar el proceso para obtener feedback de cada paso, analizando qué hay hoy disponible en el mundo GeneXus, y qué más sería necesario hacer o ajustar.
¿Qué herramientas y qué ajustes son necesarios entorno a GeneXus para implementar Continuous Delivery?
Acá va mi lista inicial de categorías, que espero ir completando con el tiempo, pero me encantaría escuchar tus ideas.
- IDE de desarrollo GeneXus
- El IDE de desarrollo y la forma de describir el conocimiento es lo que creo que está más evolucionado en el mundo GeneXus.
- Sería bueno considerar la integración con distintas herramientas, quizá analizar qué extensiones existentes son útiles en el proceso de CI/CD.
- GXunit y GXtest
- Fortalecer las herramientas para test unitario y de interfaz gráfica.
- Facilitar el uso de mocks para acelerar la ejecución de pruebas y evitar dependencias con servicios y datos.
- Hoy se han hecho ajustes a GXunit para que vuelque los resultados en un formato consumible por herramientas de integración continua con CCnet o Jenkins.
- MSbuild tasks
- Existe un conjunto de tareas automatizadas que resultan útiles para la implementación del pipeline.
- Se podrían crear más facilidades y automatismos para el proceso de CI con este mecanismo.
- GeneXus Server
- Hace falta un mecanismo de webhooks para disparar el pipeline ante cada cambio en el repositorio.
- Facilidades para manejar distintos branches, hoy es muy “caro” andar cambiando de un branch a otro, y hacer un build a partir del mismo.
- Revisión de código integrada al Server, tal como se puede hacer con Github a través del mecanismo de pull requests.
- Jenkins GeneXus Friendly
- Se podrían hacer una serie de automatismos pre-armados en Jenkins (o cualquier servidor de integración continua) para tener disponibles las tareas típicas de un pipeline de una aplicación desarrollada con GeneXus. Por ejemplo, la conectividad con GeneXus Server, la ejecución de MSbuild tasks para GeneXus, la ejecución y reportes de las herramientas de test de GeneXus (GXunit, GXtest, KBdoctor), etc.
- Tests unitarios de performance
- Se podrían generar automáticamente tests unitarios de performance para ejecutar concurrencia sobre objetos accesibles por HTTP (webpanels, procedimientos expuestos como servicios, etc.). Al menos armar un template con alguna herramienta como Taurus que sea fácil de integrar a Jenkins.
- Otros chequeos automáticos
- Se podrían integrar otras herramientas como las disponibles como GeneXus Security Scanner.
- Se podrían realizar otras verificaciones automáticas, como cambios en los WSDL o en las navegaciones de los accesos a la base (estos fueron aportes de Enrique).
- Quality Gates en KBdoctor
- Se podría extender KBdoctor para seguir el concepto de Quality Gates de SonarQube, y así poder integrar verificaciones estáticas automáticas en el pipeline.
- Deploy con contenedores
- GeneXus está trabajando en generar aplicaciones en Docker, lo cual van a mostrar durante el evento en esta charla.
- APM – Application Performance Management
- Para obtener feedback del sistema en producción, es necesario monitorear los accesos de los usuarios, las respuestas de la aplicación y el desempeño de los servidores. Se podría facilitar la integración de estas herramientas (como NewRelic y Dynatrace) así como brindar acceso desde las mismas a información específica de la aplicación GeneXus (como la expuesta por JMX).
- Análisis de logs
- Facilitar la integración de herramientas como Sumo Logic, LogEntries, Splunk, o el stack ELK. De esta forma, poder analizar los logs, generar alertas, etc., lo más cercano posible al lenguaje de un desarrollador GeneXus.
Quiero ir profundizando en cada uno de estos puntos. ¿Qué otras cosas te parecen interesantes/útiles/necesarias?
Excelente el post Fede!
me encanto!