GeneXus Continuous Delivery
•Download as PPTX, PDF•
0 likes•571 views
Encuentro GeneXus 2017 Queremos llevar la potencia que GeneXus tiene en el desarrollo a un nuevo nivel, dándole herramientas y automatismos también a los equipos de operaciones y negocios, logrando un salto de calidad y productividad y mejor colaboración entre las 3 áreas. Para esto, estamos construyendo un set de herramientas y automatismos integrados a GeneXus para alcanzar Continuous Delivery, que no sólo permite construir productos robustos en producción rápidamente, sino reducir la fricción entre desarrollo y operaciones (propiciando una cultura de DEVOPS) y una mejora sustancial para el negocio y/o nuestros usuarios. https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/Tooling-para-DevOps
Recommended
Recommended
More Related Content
More from Federico Toledo
More from Federico Toledo (20)
GeneXus Continuous Delivery
- 1. GENEXUS CONTINUOUS DELIVERY #GX2 7 Federico Toledo @fltoledo Fabián Baptista @fbaptista “Automate everything that can be automated”
- 3. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- 4. • Poner cambios en producción de forma rápida y segura. • Hacer deploys predecibles y rutinarios. • Asegurando que el código (branch principal) siempre este deployable
- 5. OPERACIONESDESARROLLO NEGOCIO Idea / Requerimiento Producto Cadena de valor / Delivery Pipeline
- 6. PRINCIPIOS DE DISEÑO “Automate everything that can be automated” Enfoque Lean Para DEV GX Permitir DevOps Sin fricción / alto valor agregado No reinventar la rueda
- 10. ¿Y ESTO CÓMO SIGUE?
- 12. GXUNIT
- 13. GXUNIT Y GXTEST
- 14. ¿QUÉ MÁS HACE FALTA?
- 16. GENEXUS CONTINUOUS DELIVERY #GX2 7 Federico Toledo @fltoledo federico@abstracta.us Fabián Baptista @fabianbaptista fabian@abstracta.us “Automate everything that can be automated”
Editor's Notes
- Gente, {presentación}. Hemos cambiado fuertemente la estrategia, y la visión, de como podemos hacer un aporte fuerte a la comunidad GX para tener mejor calidad y productividad, y estamos convencidos de quienes lo adopten van a tener un salto inmediato. Por eso vamos a hablar de CD, por que esta tan “de moda” y de el toolchain de productos que vamos a integrar. Como uds. sabrán, CD es la practica de la industria de SW moderna, fundamentalmente por ser la “ganadora” en términos de: beneficios para el negocio calidad productividad. => Entonces vamos a contar que es, cómo lograrlo en proyectos GX mediante una demo. ¿Qué esperamos que se lleven de esta charla? (Punto B) Para aquellos que no la conocen, que entiendan los beneficios tanto para desarrolladores GX como para los negocios y los clientes finales”.(independientemente de si su negocio requiere o no llevar esta practica adelante) Para los que la conocen y ya estan ansiosos de poder tener esto cuanto antes, esperamos que puedan ser early-adopters, y empiecen a descrubrir los resultados en GX. Antes que nada, agradecer a Genexus por confiar en Abstracta y en varios jugadores con muchísimos años de experiencia en GeneXus y construir este “ecosistema de automatismos” y resolver problemas cada vez mas complejos. Como uds. saben, GeneXus ya hace un gran trabajo en DEV, pero para lograr CD necesitamos llevar esa potencia a otras areas, Necesitamos un set de herramientas y mejoras para cubrir todas estas etapas => por eso estamos muy contentos de comenzar a trabajar en esto, y estar cada vez mas alineados con uno de los lemas de GX: Es decir “<AUTOMATE>” ============> Entonces, ¿de donde viene todo esto?
- POC - voy a mencionar 3 personajes… Este señor que nació hace algo mas de 100 anios, ingeniero industrial, hombre de negocios, es considerado el Padre del sistema de produccion de toyota. Esa Cultura de gestión japonesa se popularizo luego de la 2da guerra mundial cuando Japon necesitaba mejorar su produccion automotriz. Tal fue el éxito, que su trabajo tuvo infuencia en casi todos los sistemas de produccion del mundo (y para nosotros la base de la metodologia ingenieria de SW moderna)… adoptada luego en EEUU y llamada Lean Manufacturing. Ese modelo de produccion tenia entonces reglas basicas para mejorar la calidad, reducir los desperdicios y aumentar la produccion.
- Fijens que 100 años despues de su nacimiento, se hace popular el libro “Lean Startup” de Eric Ries. Con la misma filosofia “lean”: es decir, un metodo para contruir negocios y productos en forma iterativa midiendo el progreso en la cancha mediante la experimentacion continua. (contar la historia de la plataforma de messenger). > Como moraleja: Tendemos a diseñar e implementar las cosas asumiendo como funciona el negocio, y nos equivocamos (lo mismo pasa con los requerimientos.) Luego de que se popularizan las metodolgias agiles (Scrumm, XP, etc) emergio este concepto: “Continuous Delivery”, es una palabra que se encuentra en el primer “principio” del manifiesto Agil. “” - sAsi que podemos decir que Mr. Taiichi. Ohno es el padre de las raices del “agilismo” y metodologias “lean”.
- (What?) es la habilidad… —including new features, configuration changes, bug fixes and experiments— (Why?) El objetivo es (How?) Esto es posible .. Esto elimina por completo: las integraciones las largas etapas de testing y las fases mas duras luego de que el developer dice “termine”. Con la ventaja de que es una practica que nos hace ser mucho mejores en tareas que hacemos poco (poner cosas en produccion). “Cuanto mas lo hagamos mejores seremos en ello” aunque no lo necesite tu negocio!
- Asi como en LEAN, existe una cadena de valor para producir, en SW tenemos lo que llamamos Delivery pipeline. Lo que hemos visto durante todos estos anios en forma sistematica es: Dependiendo de la fricción que exista entre esas 3 areas, es qué tan exitosa es la organización generando productos de valor en las manos del usuario. %%% De hecho Abstracta hoy tiene mas de 60 profesionales trabajando para ayudar a empresas a mejorar esas falencias para mejorar la calidad y la productividad. Vivimos de eso Entonces, vamos a mostrar las herramientas disponibles para trabajar “END to END” y los beneficios para estas 3 areas.
- REFORZAR QUE VAMOS A CONSTRUIR Y LLEVAR ESTO ADEALNTE, Para construir el pipe, nos basaremos en 5“principios de diseño”, Unos son productos de la discusión con Genexus y varias empresas de la comunidad, y otros producto de haber aprendido de errores q cometimos.
- Les vamos a mostra entonces como seria un pipeline “end to end”. O sea, la serie de tareas automatizadas, enganchadas en cadena para poder tener entrega continua, continuous delivery.
- Lo primero que se necesita es una herramienta de integración continua para orquestar todo el proceso. Por ejemplo, podríamos usar Jenkins que es el señor mayordomo de la figura, que es la herramienta opensource más popular para este tipo de automatismo, para poder automatizar el pipeline. Lo que lograremos con esto es que cuando alguien introduce un nuevo cambio, esto activará un trigger en Jenkins que hará que ejecute el pipeline de continuous delivery. Esto implica descargar el repositorio de Código para poder traer los útlimos cambios a un ambiente completamente fresco, y de ahí orquestar una secuencia de herramientas para realizer varios chequeos sobre este Código. Pasa por etapas de build, de testing de distintos tipos y niveles, y luego del armado del release y del deploy. Esto hace que cada línea de Código que un desarrollador manda al repositorio, es tomada por Jenkins, procesada y analizada con un montón de pruebas automáticas, instalada en distintos ambientes, y finalmente si todo fue bien, se manda a un ambiente de pruebas o pre-producción. Continuous delivery es algo que todos Podemos pensar alcanzar con las herramientas que temenos y con las que estamos construyendo nosotros y les vamos a presenter en breve. Fíjense que hay cientos de herramientas para integrar. Cada una de estas herramientas aumentan la productividad de nuestra entrega, y mejoran la calidad (o al menos disminuyen el riesgo de problemas)
- Nosotros les preparamos una demo, donde les vamos a mostrar un pipeline pronto en GX, y las herramientas asociadas. En esta demo lo que tenemos es un Jenkins con una serie de tareas automatizadas, tal como se muestra acá en el diagrama. Cuando un desarrollador suba un código al genexus server, se disparará esta secuencia, donde lo primero será traer los cambios desde el genexus server, hacer el build, ejecutar pruebas unitarias, hacer deploy en un ambiente de pruebas, ejecutar pruebas automatizadas funcionales y luego de performance. Todo esto nos va a dar feedback de cada etapa. Si falla alguno de estos puntos, vamos a recibir una notificación como para poder comenzar a corregir, intentando reducir el tiempo que pasa desde que se introduce el problema hasta que se detecta y se resuelve.
- Hemos estamos trabajando para que esto que les acabamos de mostrar ustedes lo puedan armar en dos horas. Ahora les voy a contar un poco cómo vamos a seguir de ahora en más nosotros en Abstracta, de cuál es nuestro plan para disponibilizar herramientas que permitan seguir continuous delivery en genexus, lo cual es el objetivo que nos propusimos
- Primero que nada contarles que nosotros hace casi 10 años comenzamos a trabajar para la comunidad Genexus ofreciendo Gxtest, que es una herramienta para automatizar pruebas, pero pensada en el tester. El problema que queríamos resolver era el de la automatización a nivel de interfaz gráfica, pero no tuvimos en cuenta que a la comunidad le estaba faltando algo más primordial, que era una herramienta sólida para hacer pruebas unitarias. Entonces, para poder seguir las buenas practices ahora vamos a apuntar a darle esa herramienta al DEV GX, que es la base de la pirámide, es más necesario contar con automatización de pruebas para el desarrollador, ya que es donde más beneficio se obtiene de la automatizacion, ejecutando pruebas más rápidas, más fáciles de mantener, más temprano, porque las ejecuta el propio desarrollador en local, incluso antes de que las ejecute Jenkins.
- Estuvimos trabajando para mejorar Gxunit, logrando algunos avances importantes como por ejemplo Una Mejor integracion en gx Resultados compatibles con herramientas de integracion continua Seguiremos trabajando de acuerdo a los principios que contó Fabián al inicio, para que la herramienta sea muy fácil de usar, esté bien integrada a genexus, no haga falta instalar nada, y ver qué más se puede automatizar. Por ejemplo, Hace falta la posibilidad de tener mocks, especialmente de datos, ya que las aplicaciones genexus son fuertemente orientadas a datos… entonces debemos trabajar en mecanismos para reducer la dependencia de las pruebas con el estado de la base de datos, o de procesos externos.
- También estuvimos trabajando en una version de Gxtest integrada al IDE, y que se pueda programar en Código genexus. Entonces, desde una prueba gxunit se podrá manejar un external object con las funcionalidades de gxtest, pudiendo hacer pruebas que simulen acciones de usuario sobre el navegador. Alguans Ventajas que tiene esto es que ‘ va a ser una herramienta para dev (intellisense, automaticamente integardo) ‘ no necesita instalar nada ‘ Tambien es CI compatible, ya que funciona sobre gxunit ‘ webdriver standard, lo cual significa que se puede ejecutar sobre cualquier provider de selenium, como Browserstack, saucelabs, o si nosotros ejecutamos un selenium grid localmente, pudiendo así incluso ejecutar pruebas en paralelo.
- Qué más hace falta? Como dijimos, no es la idea reinventar la rueda, sino ver qué hay por ahí que se pueda aprovechar así como está, qué es lo que es necesario adaptar, o armar algun conector para poder utilizarlo, y qué herramientas realmente es necesario implementar específicas para Genexus, como fue el caso de Gxunit, ya que tiene que estar integrado al IDE y tiene que ser en el mismo lenguaje de programación. Vale destacar que Existen ya bastantes extensions que pueden ser agregadas a lo que mostramos, como herramientas de chequeos de seguridad, de code review, docker para genexus, etc. En el caso del design thinking, gestión de proyectos, etc., creo que hay muchas herramientas que ya cubren la mayoría de las necesidades. Por le lado de la derecho de este pipeline, luego que ponemos en producción es donde quizá hagan falta más cosas. Podríamos entonces pensar en herramientas específicas para analítica de los usuarios, de qué hacen nuestros usuarios en nuestros sistemas, aplicar testing A/B, y ese tipo de cosas. Trabajo hace años hacienda pruebas de performance a sistemas genexus y les puedo afirmar que acá temenos bastante para aportar, en integración de herramientas que permitan entender major y de manera más fácil, el comportamiento de nuestras aplicaciones. Hoy genexus ya tiene mecanismos en los cuales expone información específica del runtime, como por ejemplo por JMX, eso sería genial integrarlo a herramientas como newrelic o dyantrace, y así tener una trazabilidad mayor entre el rendimiento de los servidores, las plataformas de base y el comportamiento interno de nuestra aplicación Y por ultimo mencionar que hay muchas herramientas que permiten analizar los logs del Sistema, e incluso establecer alarmas a partir de determinadas cosas que se identifiquen. Sería genial poder trabajar todo esto a un mismo nivel de abstracción que genexus, como para facilitar la integración de este tipo de tools también. Lali dejó funcionando ELK con relativamente poco esfuerzo, procesando los logs de su aplicación ejecutando en Tomcat y disparando alertas ante cualquier problema o demora en los tiempos de respuesta. Son herramientas que temenos a la mano, tal vez sea cuestión de generar y compartir más experiencias sobre las ventajas que tiene usarlas en sistemas genexus también.
- Cierre de Fede: Para cerrar, esperamos que hayan entendido el beneficio de esto, y puedan subirse lo antes posible a adaptar CD. Podemos empezar rapido con herramientas abiertas y gratuitas e ir descubriendo los desafios de poder ir "mas alla "en el pipeline. Cierre de Fabian: Para eso abrimos un meetup GXCD, en el cual compartiremos todo el material, tutoriales, herramientas y discusiones acerca de las practicas de CD. (El meetup no tiene un fin comercial, sino un fin abierto para apuntar a ser productor y constructivo. Deberiamossumar a todos los GUG del mundo) Sumense! “Shape our tools to shape our future”
- https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/Tooling-para-DevOps Gente, hemos cambiado fuertemente la estrategia, y la visión, de como podemos ayudar a los usuarios GX a tener mejor calidad, productividad y mejores negocios. MaMoK Estamos convencidos de que tenemos la motivación y las capacidades de entregar nuevos productos integrados a GX para lograrlo. Por eso vamos a hablar de CD y por que esta tan “de moda” y de el toolchain de productos a integrar, CD es hoy la practica que la industria de SW utiliza como la “la ganadora” en términos de: beneficios para el negocio calidad productividad. => Entonces vamos a contar que es, cómo lograrlo en proyectos GX y una demo. ¿Qué esperamos que se lleven de esta charla? (Punto B) Para aquellos que no la conocen, que entiendan los beneficios tanto para desarrolladores GX como para los negocios y los clientes finales”.(independientemente de que si el usuario GX tienen o no la necesidad de llevar esta practica adelante) Para los que la conocen y ya estan ansiosos de poder tener esto cuanto antes, esperamos que puedan ser early-adopters, ya que estamos seguros de que les va a cambiar la vida. Antes que nada, agradecer a Genexus por confiar en Abstracta y en varios jugadores claves con muchísimos años de experiencia en GeneXus y construir este “ecosistema de automatismos” y resolver problemas cada vez mas complejos. Como uds. saben, GeneXus ya hace un gran trabajo en DEV, pero para lograr CD necesitamos llevar esa potencia a otras areas, un set de herramientas y mejoras para cubrir todas estas etapas => por eso estamos tan contentos de comenzar a trabajar en esto, y estar cada vez mas alineados con uno de los lemas de GX: Es decir “<AUTOMATE>” ============> Entonces, ¿de donde viene todo esto?