DevOps culture in GeneXus
•Download as PPTX, PDF•
1 like•621 views
Encuentro GeneXus 2017 - DevOps y Continuos Integration/Continuos Delivery plantean muchos desafíos y muchas cosas para aprender, pero a su vez un montón de oportunidades que ya podemos comenzar a aprovechar con GeneXus. Veremos en esta charla métodos y herramientas que aumentan la productividad en todo el ciclo de vida de un producto, pudiendo así acercarse a una cultura de DevOps donde se entrega valor al usuario de manera frecuente y con calidad. https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/DevOps-y-GeneXus
Recommended
More Related Content
Similar to DevOps culture in GeneXus
Similar to DevOps culture in GeneXus (19)
More from Federico Toledo
More from Federico Toledo (20)
DevOps culture in GeneXus
- 1. DEVOPS CULTURE IN GENEXUS #GX2 7 Federico Toledo @fltoledo federico@abstracta.us Laura Aguiar @laguiarz laguiar@imasdev.com
- 3. AGIL E
- 4. DEVOP S
- 8. EL CAMBIO GRANDE, ES EMPEZAR A PENSAR EN TODO EL PROCESO DE VIDA DE UNA APLICACIÓN, EN VEZ DE OPTIMIZAR POR PARTES. SE MEJORA EN PRODUCTIVIDAD Y CALIDAD. ENRIQUE ALMEIDA NO SE TRATA DE IR MÁS RÁPIDO, SINO QUE SE TRATA DE HACER OTRAS PREGUNTAS. KAREN JOHNSON
- 21. CONSTRUCCIÓN COLECTIVA Manager Business Designer Tester Support Monitoring Infrastructure Developer
- 22. Title Text
- 24. #GX2 7 DEVOPS CULTURE IN GENEXUS ¡GRACIAS! Federico Toledo @fltoledo federico@abstracta.us Laura Aguiar @laguiarz laguiar@imasdev.com
- 25. LINKS INTERESANTES • Engines de Integración Continua: • Jenkins https://jenkins.io/ • Cruise Control .Net http://www.cruisecontrolnet.org/ • GeneXus Server • http://gxserver.com/ • MSbuild tasks para GeneXus • https://wiki.genexus.com/commwiki/servlet/wiki?3908,MSBuild+Tasks, • GXunit • https://www.federico-toledo.com/gxunit-renace-nuevamente/ • http://ealmeida.blogspot.com.uy/2017/09/renovado-interes-en-gxunit.html • Metodología: • https://www.federico-toledo.com/continuous-delivery-en-genexus/ • Grupo BuildAndDeploy https://wiki.genexus.com/commwiki/servlet/wiki?24343,Category%3ABuildAndDeploy,
Editor's Notes
- https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/DevOps-y-GeneXus Abstract: DevOps y Continuos Integration/Continuos Delivery plantean muchos desafíos y muchas cosas para aprender, pero a su vez un montón de oportunidades que ya podemos comenzar a aprovechar con GeneXus. Veremos en esta charla métodos y herramientas que aumentan la productividad en todo el ciclo de vida de un producto, pudiendo así acercarse a una cultura de DevOps donde se entrega valor al usuario de manera frecuente y con calidad. Descripción: La productividad no solo se trata de cuán rápido “codificamos”. Cada vez hay más herramientas y metodologías que nos hacen más productivos (produciendo con calidad y velocidad). Tenemos contenedores, pipelines, herramientas para realizar chequeos de calidad a distintos niveles, monitorización de punta a punta, etc. Por eso, para seguir manteniendo la ventaja competitiva que tenemos gracias a usar GeneXus, es necesario ver y entender qué se puede tomar del resto de herramientas y metodologías, ya sean ágiles, DevOps, para Continuous Delivery, etc. En esta charla haremos un resumen de las prácticas actuales de CI/CD y DevOps de la industria, y que cosas se pueden ir haciendo en GeneXus desde ya para empezar a transicionar hacia este nuevo enfoque y obtener lo mejor de ambos mundos.
- DevOps es la nueva moda. Seguro que escucharon hablar de esto y por eso están acá. Si uno se pone a leer de qué se trata, a primera vista parece otro sabor de todo esto de las metodologias agiles, lean y afines? Yo creo que es una metodología alineada con todo esto, con agile, etc., pero en algunos aspectos es poco más amplio, DevOps mira al software como un todo… y en particular trata de unir dos cosas que estan historicamente separadas … la construccion del software (el desarrollo) y la operacion del mismo (y de ahí viene el nombre, ya que DEVOPS se forma con la conjunción de dos palabras, devs y ops, developers and operations, dos mundos entre los cuales se sabe que agregan valor, que los necesitamos, pero que entre ellos se dice que hay mucha rivalidad, mucha fricción. Esto es porque hay un “conflicto de intereses”. Los desarrolladores por un lado quieren poner en producción todas las semanas, con todo esto de Scrum, iterativo incremental, quiero poner las features en producción y validar con el cliente. Y por el otro lado los de operaciones están con la filosofía que si funciona no lo toques. Mientras más veces ponés en producción más laburo me das, y más riesgo, porque si hay problemas los usuarios se van a quejar primero que nada conmigo, por más que el problema sea del software. Y en realidad en toda esta historia de la construcción del software la fricción se da en más puntos….
- Y en este sentido me gusta lo que plantea Katrina Clokie en su libro. Ella dice que fue genial que en las metodologías ágiles se comienza a hablar de formar un único equipo, más horizontal, todos compartiendo responsabilidad, sin necesidad de distinguir roles. Desarrolladores, managers, diseñadores, testers, todos somos parte del equipo, compartimos resonsabilidad, estamos al mismo nivel. El tema es que acá el desarrollo termina cuando se pasa el paquete a la gente de operaciones, pasamos la tarjeta a DONE, y vamos con la que sigue, el problema es de otro.
- Katrina plantea que DevOps es una evolución de Agile, en el sentido que se plantea involucrar a otros equipos. Lo más importante es generar conversaciones, repartir responsabilidades, involucrar a la gente, que se reparta el conocimiento, que se generen preguntas, retroalimentación. Loops de feedback por todas partes. Mucha comunicación.
- Punto b: La cultura DevOps implica tener las conversaciones adecuadas en los momentos oportunos. Para esto tenemos aspectos metodológicos y de herramientas que nos pueden ayudar en este sentido. En esta charla queremos hablar de herramientas y metodologías para propiciar una cultura DevOps, y analizar qué tan bien o mal estamos los que trabajamos con GeneXus. O sea, es algo inalcanzable? O es algo que tenemos relativamente a la mano? Claves en DevOps Ciclos Cortos para aprender rapido… que son soportados por: Metodologia Herramientas Conversaciones / Interaccion. En este ciclo hay que automatizar todo lo automatizable porque temenos que liberar tiempo para estas interacciones.. Para analizar la informacion que recibimos de feedback e implementar los cambios necearios…
- Y es por eso que me gusta esta imagen, es la que se usa para representar el concepto de devops típicamente. Se ve como lo más importante es obtener feedback continuo. Todo rodeado de comunicación en tiempo real. También aparece el concepto de CONTINUOUS INTEGRATION, que seguramente habrán escuchado hablar. Continuous integration, continuous delivery, continuous deployment. Si bien en un par de horas, acá mismo, con Fabián daremos una charla de continuous delivery en GeneXus, en esta charla para hablar de DevOps es necesario hablar un poco de continuous delivery, ya que es muy complicado de tener una cultura DevOps sin tener una base sólida en metodologías y herramientas que apoyen el enfoque. En el mismo artículo de donde saqué esta imagen cuentan que los equipos que aplican DevOps despliegan más frecuente, pero además, con mayor calidad. Y quizá más importante, cuando hay un error se recuperan mucho más rápido. Esto es gracias a tener todo aceitado y a tener ciclos de feedback, levanter información de todo el proceso de desarrollo. Y un concepto importante en todo esto es el de PIPELINE
- Pipeline en inglés es tubería. Es una metáfora que ya se usa en Linux para refierse a una cadena de tareas organizadas de forma tal que la salida de uno sea la entrada del siguiente. En Continuous Delivery usamos esta metáfora para visualizar la creacion y entrega de software como un flujo constante. Una vez que algo entra en el pipeline va ‘hacia adelante’ y si hay algún problema en el camino, este es reportado hacia el origen y Vuelve a comenzar. Pero de todos modos el flujo es siempre en un sentido… si entra algo que rompe un build, se corta el flujo y luego entra otra cosa que lo arregla. Lo que se intenta es proteger la salida del pipeline. Puede haber problemas a lo largo del recorrido pero la idea es atajarlos antes d eque lleguen a la salida :) Toda esta idea del pipeline es para generar conversaciones adecuadas en momentos oportunos, ciclos de feedback, etc., pero solo tiene sentido, solo es implementable y sostenible si la armamos sobre una base de herramientas y automatismos que permitan aceitar el proceso, sistematizarlo, mecanizarlo. VEO MUY DIFÍCIL HACER DEVOPS SIN CONTINUOUS DELIVERY
- Relacionado a esto quiero hacer dos citas. Una es esta frase de Enrique, que hace unos días me comentó algo así en un mail que intercambiamos y para mí dice mucho sobre lo que es la cultura Devops. Hay que pensar en optimizer todo el proceso, y no solo las pequeñas partes. Por otro lado, hace poco escuché a Karen Johnson decir en un podcast que no se trata de ir más rápido, o de entregar más seguido… se trata de hacer otras preguntas. Y es impresionante las preguntas que se generan alrededor del pipeline. Porque el pipeline es algo que pertenece a todos, y todos somos responsables por optimizarlo.
- En este sentido algo que me ha pasado mucho en el útlimo tiempo trabajando para equipos en Estados Unidos, pero también con muchos acá en Uruguay, es que yo, en mi rol de tester, participo en decisiones relacionadas al proceso de desarrollo, a la forma en la que se hacen los branches, al armado de ambientes, en un montón de cosas que no son puramente de pruebas. Esto es lo que a uno lo hace sentir parte de un mismo equipo. No somos el enemigo, no estamos en un equipo aparte que tiene una mission completamente opuesta o incluso contradictoria. No!! Entonces, entre todos temenos que pensar cuál es la major forma de trabajar, optimizer el proceso como una misma cosa, y no solo optimizer el desarrollo, optimizer el testing.
- Esta imagen la tomé de un artículo. El mayordomo que está en el medio es clave. Pero ojo, es el logo de Jenkins, pero no es la única opción. Generalmente se necesita una herramienta que permita definer los pipelines de los que hablábamos. Estas se las conoce como herramientas de integración continua, o continuous integration engines. Jenkins es un ejemplo, temenos Bamboo, TeamCity, Travis, GoCD, etc. Miren el millón de herramientas que hay por ahí`, todas nos dan beneficios de productividad Las están aprovechando? No? eso no les hace pesnar algo? Acá se puede observar uno de los Fuertes de la cultura devops, integrar herramientas, integrar chequeos, buscar feedback con herramientas que hay por ahí. Jenkins y este tipo de herramientas permiten integrar esto y orquestarlo.
- Pero esto no termina acá. NOOO. Porque hasta acá fue el pipeline de continuous integration y continuous delivery. Si queremos pensar en devops, no Podemos terminar cuando pusimos el product en producción, sino que temenos que integrar en nuestro proceso a la operación del product. Entonces temenos que pensar en otras herramientas como las que nos permiten hacer un seguimiento de la aplicación cuando está en producción, como las herramientas para analytics, para monitorización, para analizar logs. Y lo mismo antes del proceso, temenos que pensar en todas las herramientas que hay para la parte del diseño, para gestionar y compartir el análisis de los requerimientos, para gestionar el Proyecto y así ir seleccionando qué funcionalidades le vamos a dar en qué orden al usuario. Es parte de todo lo que entra en ese proceso que temenos que optimizer. No solo optimizer el desarrollo, optimizer el todo. Y esto es muy importante, porque tal vez desde desarrollo temenos que hacer algo extra para que en producción sea todo mucho más fácil de controlar y monitorizar, entonces tal vez a costo de desarrollo aumentamos la productividad de todo el ciclo de vida. O con ciertos ajustes Podemos hacer que las pruebas sean más fáciles, o con ciertos ambientes facilitamos la ejecución de otras cosas… Optimizar las partes, pero también optimizer el todo. Claramente esto se logra si el diseño del pipeline lo hacemos involucrando a todas las áreas.
- Yo aca decidi arrancar con una slide en blanco porque en la anterior habia mucha cosa Lo que me quedo claro es que hay un mundo de herramientas y de gente trabajando en mejorar la forma en que hacemos software y nosotros Tambien Podemos hacerlo. Ya sea poque nos parece que esta bueno Ya sea que uno se acerque a esto de devops por mantener una ventaja competitive – desarrollamos mas rapido, temenos que lograr al menos en el resto ser igual – o ya sea que uno se acerque porque le parece que es una Buena forma de trabajar
- Si queremos armar un pipeline de ese estilo hoy por hoy, podemos. De hecho esto es un ejemplo de uno que armo la gente de Abstracta – y si les interesa concer de esa experiencia los invitamos a la charla que van a dar al respect. Y dado que se puede trabajar de este modo, nos parecio interesante conversar de que nos exige y que nos aporta a nosotros desarrolladores trabajar en un marco de devops
- Para trabajar en un mundo de devops, lo primero que necesitamos es tener integracion continua. Eso implica el GXServer y un motor de integracion continua – el de la foto es Jenkins pero puede ser Cruise Control o cualquier otro. Esto es automatizar el proceso desde un commit hasta la actualizacion de la KB del Consolidado. Que nos cambia esto a nosotros? Mas alla de que automatizarlo igual libera el tiempo de alguno? Bueno, que tener visualizacion del estado del build nos ahorra muchos dolores de Cabeza. Cuantas veces les Habra pasado que se actualizan el del server y resulta que ahora no especifica o no compila por un cambio que subio algun otro? Y despues quiza cada uno lo intent arreglar y subio su cambio y se genera mucho ma conflict. Con un motor de CI Podemos ver antes de actualizar si el build esta ok o si esta roto, y evitar actualizarnos si esta mal. Y tambien en vez de hacer un commit y me voy a casa, ahora igual espero un poquito mas para ver como quedo el build y quiza dejar el problema arreglado antes de irme.
- En un mundo devops al desarrollar una funcionalidad tambien desarrollamos la forma e validarla.. Es uno de los elementos criticos de feedback del pipeline. Necesitamos saber a medida que integramos nuestro codigo si el miso funciona como esperamos y Tambien si no rompe ninguno de las pruebas que habia.. Y si lo hace necesitamos saberlo temprano… es decir, para poder tener esos caminos de feedback las pruebas tienen que poder corer cada vez que integramos y para eso tiene que haber pruebas automaticas.
- Eso no quiere decir que salgamos a automatizar todo, de hecho de tener al tester mas cerca es que nos puede ayudar a pensar que automatizar y que no, e incluso a disenhar estas pruebas, siempre teniendo en cuenta esto de la piramide de retorno que nos dice que la mayoria de la automatizacion deberia ser a nivel unitario.
- Una personal es que cuando hacemos tests unitarios, programamos mejor. Si queremos hacer test unitario vamos a tener que identificar y aislar mas esa unidades… por poner un ejemplo burdo si yo tengo que programar algo como un login, yo podría tener un webapanel donde leo las variables de pantalla y en el evento ‘enter’ tengo un for each a la tabla de usuarios … eso seguro funciona pero es caro de testear, solo puedo hacerlo en la pantalla. Si quiero hacer una prueba unitaria necesito separar esta funcionalidad en 2 objetos, una pantalla donde solo se leen las variables y luego se llama a un procedimiento que hace la validacion. Esto es mejor porque separo la lógica de la interfaz y tengo algo que potencialmente puedo reusar manhana si necesito hacer un login como webservice o que se yo. En definitiva al hacer el código mas testeable termine con una solución técnicamente mejor.
- Que tenemos para poder automatizar nuestas pruebas unitarias? GxUnit… Ahora mismo es un proyecto opensource y este anho se trabajo en hacerlo mas fácil de adoptar, Se mejoro la visualización de los resultados de las pruebas en el IDE de GeneXus, Y también se genero salida que puede ser integraa en Jenkins o Cruise-Control para poder ejecutar las pruebas en el pipeline. Un tema no menor a la hora de armar pruebas unitarias es el tema de los datos – no solo por el tema de preparar los datos , sino porque las pruebas que van a la base de datos son a veces lentas, y entonces no es posible ejecutar toda la batería de pruebas que tenemos en cada integración… La buena noticia al respecto de eto es que la gente de Abstracta va a estar trabajando con GeneXus para definir una forma de poder realizar ‘mockeo’ de datos lo cual va a hacer más corto el ciclo de tests De todas formas no hay porque esperar a esto, ya se puede usar y sacarle jugo a GxUnit
- Pero no alcanza con solo pruebas unitarias y por eso esta GxTest. Otra buena notica es que va a existir un GxTest para el desarrollador, y que podamos programar las pruebas desde GeneXus. Esto no esta disponible aun… y pueden saber mas hablando con algún Abstractero. Esto y el tema de la simulación de los datos nos va a dar una gran potencia para armar nuestros tests a la hora de desarrollar, incluso programar tests de interfaz es igual de sencillo que programar pruebas unitarias… la pirámide se mantiene poque son mas caras de ejecutar pero van a ser igual de barato de programar.
- Lo primero es trabajar en nuestrs soft-skills porque ahora hay que tener capacidad de integrar diferentes visions a la hora de de construir la solucion. No solo pensar en resolver un requerimiento de un usuario sino hacerlo de forma mas usable, mas testeable, mas facil de monitorear, etc. Pero no solo en las soft skills sino Tambien las practicas tecnicas
- Hay mucho mas para hablar, muchas herramientas que existen y se pueden adaptar para conectadas al pipeline y muchas herramientas que Podemos incoporar asi como estan – validadores tipo el kbdoctor o el security scanner, genexus esta trabajando por integrar docker… en fin hay mucha cosa que existe y mucha cosa sucediendo…. Lo Bueno de esto es que se puede construer de forma incremental. Capaz que otras tecnologias si quieren manhana armar un pipeline lo tienen un poco mas facil, mas documentado y con mas herramientas integradas en su proceso de desarrollo… pero nosotros temenos suficientes para arrancar y nos gustaría invitarlos a experimentar con las herramientas que hay, quizá incoporar alguna nueva, compartir esas experiencias y en definitiva a a que colaboremos mejorar juntos nuestros procesos y herramientas.
- O siguiendo el slogan del evento: Involucrate, Dale Forma a nuestro Futuro
- https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/DevOps-y-GeneXus Abstract: DevOps y Continuos Integration/Continuos Delivery plantean muchos desafíos y muchas cosas para aprender, pero a su vez un montón de oportunidades que ya podemos comenzar a aprovechar con GeneXus. Veremos en esta charla métodos y herramientas que aumentan la productividad en todo el ciclo de vida de un producto, pudiendo así acercarse a una cultura de DevOps donde se entrega valor al usuario de manera frecuente y con calidad. Descripción: La productividad no solo se trata de cuán rápido “codificamos”. Cada vez hay más herramientas y metodologías que nos hacen más productivos (produciendo con calidad y velocidad). Tenemos contenedores, pipelines, herramientas para realizar chequeos de calidad a distintos niveles, monitorización de punta a punta, etc. Por eso, para seguir manteniendo la ventaja competitiva que tenemos gracias a usar GeneXus, es necesario ver y entender qué se puede tomar del resto de herramientas y metodologías, ya sean ágiles, DevOps, para Continuous Delivery, etc. En esta charla haremos un resumen de las prácticas actuales de CI/CD y DevOps de la industria, y que cosas se pueden ir haciendo en GeneXus desde ya para empezar a transicionar hacia este nuevo enfoque y obtener lo mejor de ambos mundos.