ci/cd

Poco a poco el serverless se está extendiendo a más y más casos de uso: procesamiento, bases de datos, sistemas de mensajería o de CI/CD son solo algunos de los ejemplos. El procesamiento de grandes volúmenes de datos era uno de los campos que aún no había sido colonizado por el serverless pero parece que esto está a punto de cambiar. Hoy vamos a hablar de Dataproc serverless, que nos permite ejecutar trabajos de Spark sin necesidad de tener un cluster. Empecemos definiendo un poco qué es Spark y qué es Dataproc: Spark es un framework de procesamiento escalable sucesor de Hadoop MapReduce aunque la idea es la misma. Tiene gran aceptación en la comunidad BigData al ser uno de los frameworks más utilizados y queridos. Cloud Dataproc es la manera de tener clusters gestionados por Google Cloud para ejecución de trabajos Hadoop MapReduce, Hive, Spark, Flink…. Gracias a Dataproc podemos levantar clusters de manera sencilla y económica. El uso del serverless para la ejecución de nuestras cargas Spark nos ofrece ciertas ventajas como el poder abstraernos de la infraestructura, tener capacidad de cómputo inmediata o una gran flexibilidad de costes. El nuevo Dataproc Serverless nos permite la ejecución de cargas Spark sin tener que preocuparnos por otra cosa distinta al código y los datos, lo que como desarrolladores, es algo que agradecer. Si quieres saber más sobre este producto, cual es su experiencia a usarlo y sus puntos menos fuertes no te pierdas este programa de Cómo conocí a nuestro Cloud. Intervienen Andrés Navidad, Óscar Ferrer y Tomás Calleja, miembros del equipo de Goodly. ¿Quieres escuchar nuestros podcasts? https://www.ivoox.com/podcast-apasionados-tecnologia_sq_f11031082_1.html ¿Quieres saber cuáles son los próximos eventos que organizamos?: https://www.paradigmadigital.com/eventos/

De como un pequeño squad, montado para el desarrollo de una simple herramienta, que permite quitar dependencias con servicios externos y poder mockearlos, acabó siendo toda una estrategia de despliegue automático, con contendores, que asegura SLAs y que permite, a los equipos, tener más control sobre las herramientas que construye. Quiero explicar como evolucionamos una simple idea, que podia ser usada en cualquier situacion y entorno por que nos ayudaba a desprendernos de la limitación que nos imponía un servicio de un 3o hasta desarrollar CI/CD con Azure + AWS que ayuda a cumplir con unos SLOs Querría explicar las lecciones aprendidas como entender que mantener esos datos, como los SLOs, métricas de los entornos, resultados de los tests, y que poder mostrarlos, y poder mostrarlas de una manera amigable, para poder estudiarlas, compararlas es necesario, ya que culturalmente habíamos pasado de necesitar escribir soluciones que se despliegan en un sito X con un pipeline Z que realiza unos pasos a escribir esas soluciones y que tienen que rendir de manera optima en los distintos entornos que necesitemos llegar a desplegarlas, que un día pueden ser una maquina real y otro día un entorno virtual entregado por un vendor u otro. También como aprendimos, o nos enfrentamos a los problemas de comunicación habituales a los que, si les añades sistemas más complejos con múltiples componentes y con un mindset de los desarrolladores anticuado, te enfrentaba a un desarrollo más lento y difícil de visualizar. Que cada uno de los componentes del squad teníamos una visión y la solución del problema son muchas pequeñas partes, entonces tener una visión global y conjunta se hacia difícil. Yo fui el primero que no tuve una visión real hasta casi finalizar el squad. Quiero dar ejemplos de como fuimos desarrollando todo este concepto paso a paso y día a día y quizás de los fallos más relevantes qué tuvimos, como por ejemplo lo que cambiar las soluciones que dábamos que no se ajustaban a la nueva realidad o pensar que al acabar el squad ya no había nada más que hacer, cuando en realidad nos tocaba hacer de evangelizadores. ------------- ¡Conoce Autentia! -Twitter: https://goo.gl/MU5pUQ -Instagram: https://lk.autentia.com/instagram -LinkedIn: https://goo.gl/2On7Fj/ -Facebook: https://goo.gl/o8HrWX

Agile visto desde una plataforma de gestión de Apis. El ciclo de vida de las ApIs contado bajo los 4 valores del Manifiesto Agile. Las personas y roles del API Team. Working software. El contrato YAML y el uso del API first como aproximación al cambio del usuario. La estrategia Domain Driven Design y la inversión de la Ley de Conway. Incorporando ingeniería ágil en el ciclo de vida como API first, DDD, TDD, BDD... CI/CD. Explicando la parte de estrategia y delivery utilizando Kanban por ejemplo y la mejora continua utilizando Scrum. El API Team no gestiona endpoints, acompaña el ciclo de vida de las APIs y apoya el cambio cultural desde un punto de vista pedagógico. Utilizando por ejemplo técnicas de gamificación. Aplicar Agile en el Open Banking a través del API Team, mejora la capacidad de una organización para cambiar. Se juntan la transformación Agile con la transformación digital Open, autentica punta de lanza de la revolución actual. ------------- ¡Conoce Autentia! -Twitter: https://goo.gl/MU5pUQ -Instagram: https://lk.autentia.com/instagram -LinkedIn: https://goo.gl/2On7Fj/ -Facebook: https://goo.gl/o8HrWX

Agile visto desde una plataforma de gestión de Apis. El ciclo de vida de las ApIs contado bajo los 4 valores del Manifiesto Agile. Las personas y roles del API Team. Working software. El contrato YAML y el uso del API first como aproximación al cambio del usuario. La estrategia Domain Driven Design y la inversión de la Ley de Conway. Incorporando ingeniería ágil en el ciclo de vida como API first, DDD, TDD, BDD... CI/CD. Explicando la parte de estrategia y delivery utilizando Kanban por ejemplo y la mejora continua utilizando Scrum. El API Team no gestiona endpoints, acompaña el ciclo de vida de las APIs y apoya el cambio cultural desde un punto de vista pedagógico. Utilizando por ejemplo técnicas de gamificación. Aplicar Agile en el Open Banking a través del API Team, mejora la capacidad de una organización para cambiar. Se juntan la transformación Agile con la transformación digital Open, autentica punta de lanza de la revolución actual.

De como un pequeño squad, montado para el desarrollo de una simple herramienta, que permite quitar dependencias con servicios externos y poder mockearlos, acabó siendo toda una estrategia de despliegue automático, con contendores, que asegura SLAs y que permite, a los equipos, tener más control sobre las herramientas que construye. Quiero explicar como evolucionamos una simple idea, que podia ser usada en cualquier situacion y entorno por que nos ayudaba a desprendernos de la limitación que nos imponía un servicio de un 3o hasta desarrollar CI/CD con Azure + AWS que ayuda a cumplir con unos SLOs Querría explicar las lecciones aprendidas como entender que mantener esos datos, como los SLOs, métricas de los entornos, resultados de los tests, y que poder mostrarlos, y poder mostrarlas de una manera amigable, para poder estudiarlas, compararlas es necesario, ya que culturalmente habíamos pasado de necesitar escribir soluciones que se despliegan en un sito X con un pipeline Z que realiza unos pasos a escribir esas soluciones y que tienen que rendir de manera optima en los distintos entornos que necesitemos llegar a desplegarlas, que un día pueden ser una maquina real y otro día un entorno virtual entregado por un vendor u otro. También como aprendimos, o nos enfrentamos a los problemas de comunicación habituales a los que, si les añades sistemas más complejos con múltiples componentes y con un mindset de los desarrolladores anticuado, te enfrentaba a un desarrollo más lento y difícil de visualizar. Que cada uno de los componentes del squad teníamos una visión y la solución del problema son muchas pequeñas partes, entonces tener una visión global y conjunta se hacia difícil. Yo fui el primero que no tuve una visión real hasta casi finalizar el squad. Quiero dar ejemplos de como fuimos desarrollando todo este concepto paso a paso y día a día y quizás de los fallos más relevantes qué tuvimos, como por ejemplo lo que cambiar las soluciones que dábamos que no se ajustaban a la nueva realidad o pensar que al acabar el squad ya no había nada más que hacer, cuando en realidad nos tocaba hacer de evangelizadores.

¿Consideras que vuestro equipo tiene puntos de mejora que has visto en charlas y libros? ¿Conoces prácticas de XP y de Lean software development que os pueden ayudar pero no acabas de saber explicar bien el por qué funcionan? ¿Quieres introducir alguna mejora, pero no tienes claro cómo “venderla” al equipo? Una de los ejercicios que más me ha ayudado en los últimos años, ha sido basarme en los 7 tipos de “waste” (muda) de Lean software development. Me ha ayudado a combatir algunos mitos como que "la especificación temprana reduce el tiempo de desarrollo", que "estimar mejora las predicciones" o que "el testing es para encontrar bugs". Y me ha guiado para saber que prácticas implementar en cada momento y para qué las necesitábamos (pairing/mob, TDD, Vertical slicing, CI/CD… ). Basándome en mi experiencia explicaré que prácticas ayudan para cada tipo de “waste”, por qué y que impacto tienen en nuestro proceso. ------------- ¡Conoce Autentia! -Twitter: https://goo.gl/MU5pUQ -Instagram: https://lk.autentia.com/instagram -LinkedIn: https://goo.gl/2On7Fj/ -Facebook: https://goo.gl/o8HrWX

Durante este KIT exploraremos las capacidades de KarateDSL para el testing y mocking de APIs REST. Para ello implementaremos: - Suite de Tests E2E para el servicio productor de la API y - Mocks de Alta Fidelidad con Estado (Consumer Contracts) para los proyectos cliente. Todo el código fuente estará disponible en github https://github.com/ZenWave360/karate-openapi-petstore - Introducción a Contract Testing - Niveles de Madurez en el testing de APIs - Implementando Tests End-to-End con KarateDSL: atomic, data-driven y business flows - Creando Mocks de Alta Fidelidad y con Estado como Consumer-Contracts para Tests Unitarios/Integración - Automatización: CI/CD, calculo de cobertura de los tests y de los mocks con respecto al API

Engineer at Dataworkz A passionate engineer at Dataworkz, Pieter gets a buzz from anything that's related to Engineering. It doesn't matter if it's a piece of code, a nicely setup K8s environment or a CI/CD pipeline - as long it is related to data or data streaming he's happy. When he's not working on Engineering, you're most likely to find him out on the water somewhere :-)

Developer Advocate at Apache APISIX A Developer Advocate with 15+ years experience consulting for many different customers in a wide range of contexts, such as telecoms, banking, insurance, large retail and in the public sector. Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps, Nicolas also doubles as a trainer and triples as a book author.

QA Manager at Plytix Fran Guerrero is an Agile ISTQB-certified specialist with more than 10 years of experience in the Quality Assurance field. He implements testing processes, QA strategies, innovative tools, and builds strong relationships across all teams. At Plytix, his team has become an essential part of the software quality process. From time to time, he enjoys speaking at QA-related forums on topics that include Agile Testing, Test Automation, and DevOps CI/CD methodologies.