Nerdearla 2023: Integración Continua 3.0

La semana pasada me notificaron que mi propuesta de sesión «Integración Continua 3.0» había sido aceptada en Nerdearla. Asimismo me dijeron que la idea es que la presente, valga la redundancia, presencialmente. Hay algunas sesiones que serán grabadas en forma previa a la conferencia y luego serán transmitidas por streaming durante los días del evento, pero al parecer mi sesión la daré en vivo en un de los escenarios de la conferencia en CC Konex con transición en simultáneo. Aún no tengo los detalles de agenda pero si puedo compartir algunos detalles de lo que hablaré en la sesión.

Comencemos por el título. Lo de 3.0 responde a tres épocas distintas en la evolución de esta práctica.

1.0: el origen

El inicio de esta práctica se remonta a fines de los ’90 con el surgimiento del enfoque de desarrollo propuesto por Extreme Programming. La figura a continuación muestra la relación de la práctica de Integración Continua (continuous integracion) con el resto de las prácticas de Extreme Programming. Dicha figura pertenece al libro Extreme Programming Explained de Kent Bent, publicado en 1999.

Yo conocí está práctica allá por 2003 precisamente leyendo ese libro y luego la profundicé leyendo el ya clásico artículo de Integración Continua de Martin Fowler publicado en el año 2000. La primera vez que implementé esta práctica fue con la herramienta Cruise Control. Poco tiempo después me fui inclinando al uso de Hudson (que luego daría origen en Jenkins). Por aquellos años también tuve la oportunidad de utilizar las primeras versiones de Microsoft Team Foundation Server. Hacia 2010 recuerdo que me mi herramienta favorita para hacer integración continua era Team City.

2.0: Continuous Delivery

Para mi la segunda era en la evolución de la integración continua se da a partir de 2010 con el hito de la publicación del libro de Humble y Farley: Continuous Delivery. Este libro aún hoy, con más de 10 años, sigue siendo un referencia indiscutible en la materia. Entre otras cuestiones, este libro formalizó el término «pipeline». En lo personal transité gran parte de esta época utilizando Jenkins y Travis-CI.

3.0: CI/CD

Ya a partir de 2016 y de la mano del movimiento DevOps empezó a tomar una gran popularidad el término «CI/CD» haciendo referencia a «Continuous Integracion / Continuous Delivery» y gradualmente la práctica de integración continua fue llegando al mainstream. La cantidad de herramientas para implementar esta práctica inundaron el mercado (Spinnaker, Tekton, Bitrise y CircleCI por nombrar algunos) y los proveedores de servicios de Git se sumaron la fiesta (BitBucket Pipelines, Github Actions, Gitlab-CI, etc).

Como suele ocurrir, junto con la popularidad, llegan los negocios, las imprecisiones y las confusiones. En parte esto es lo que me motivó a proponer mi sesión: aclarar algunas cuestiones.

La idea de mi sesión es comenzar haciendo un breve repaso del origen y evolución de la práctica (lo que describí aquí pero con mayor detalle) y luego adentrarnos en un conjunto de recomendaciones y patrones para su implementación que he ido recogiendo a los largo de 20 años usando esta práctica. Veremos opciones para: diseñar pipelines desde cero, refactorizar pipelines existentes, escalar, manejar particularidades para pipelines de mobile, de frontend, entre otros. Nos vemos…

Testear en Producción, pero seriamente

Para muchos «testear en producción» es una acción temeraria, un pecado, una situación riesgosa, indeseada. Y es típicamente así cuando el único testing que hacemos es en producción, cuando cada cambio que introducimos en producción es muy grande, cuando los procesos de despliegue son manuales y esporádicos.

Pero si trabajamos en pequeños incrementos, hacemos TDD, testeamos de forma sistematizada, automatizamos la tareas repetitivas y desplegamos de forma frecuente, entonces no hay mucho de que temer. Esto es lo que comentaba Nayan Hajratwala en su sesión «Embrace these Three Fearsome Words: Test in Production» en Agile 2023. Estoy muy de acuerdo con esto pues esta propuesta esta muy en línea con lo que yo mismo hice las pocas veces que decidí probar en producción.

Un habilitador imprescindible en mi opinión para poder testear en producción es tener la capacidad de «segmentar funcionalidades por grupos de usuarios», esto es: poder definir subconjuntos de usuarios para que solo ellos puedan acceder a ciertas funcionalidades. Algunos autores llaman a esto «Dark launch«. Esta práctica no es más que una variación de la práctica de feature toggles que permite desacoplar el deploy («instalación» en producción) y el release (disponibilización para el usuario).

Alguien podrá preguntarse, ¿porque testear en producción si tengo la posibilidad de testear en ambientes previos? Puede haber varias razones, comparto dos que son las que he experimentado:

  1. Hay ocasiones en las que testeamos en producción porque hay ciertas condiciones que solo están disponibles en dicho ambiente, típicamente integraciones con otros sistemas. En ese caso lo que estamos haciendo en producción es una prueba de integración y la hacemos luego de haber testeado todo nuestro código de forma previa al despliegue en producción.
  2. Hay otras ocasiones que testeamos en producción para tener feedback real a nivel «negocio». Caso típico: queremos validar una hipótesis de negocio, queremos ver como nuestros clientes/usuarios reaccionan ante una nueva funcionalidad o variante de una funcionalidad existente. En este caso no estamos testeando si el software hace lo que habíamos pensado, sino que estamos testeando una idea de negocio.

Nuevo plan de Ingeniería Informática en FIUBA (2023)

Finalmente el martes pasado, 8 de agosto, el Consejo Directivo de la FIUBA aprobó el nuevo plan de estudios de la carrera de Ingeniería en Informática. Esto ocurre en el contexto de la iniciativa «Plan 2020» en la cual la facultad se propuso generar nuevos planes para todas sus carreras, pero que por motivos diversos, llega con años de retraso.

El lo personal no estuve involucrado en la creación de este nuevo plan, es una tarea de la Comisión Curricular de la carrera de la cual yo no formo parte. Pero como docente del departamento de computación suelo recibir consultas de los alumnos respecto de la carrera en general. Es por ello que comparto aquí algunas opiniones respecto de este nuevo plan.

Cabe destacar que tiempo atrás escribí sobre un borrador de plan que se había compartido, pero había sido elaborado por otra comisión, o sea: el plan se empezó a trabajar con una determinada formación de la comisión curricular y un director pero el plan publicado ahora fue creado por una comisión liderada por otro director de carrera y otros miembros. Y si bien algunos miembros se mantienen, no estoy seguro de hasta qué punto esta comisión mantuvo el trabajo realizado por la anterior o hasta que punto, hicieron borrón y cuenta nueva.

En primer lugar hay un cambio significativo respecto de las cuestiones de ciencia básica. No hay ninguna materia de química (ni siquiera en el CBC) y solo quedan dos materias de Física: la del CBC y una nueva materia llamada «Física para Informáticos». También hay algunos cambios menores en las materias de matemática.

Por otro lado, en cuestiones de informática, hay varias cuestiones a notar, detallo algunas materias:

  • Introducción al Desarrollo de Software: me parecen interesantes los contenidos que plantea de forma temprana en la carrera, me gusta que ya tempranamente habla de Desarrollo Orientado por Pruebas (asumo que se refiere a TDD). No me gusta tanto la mención explícita a front-end y back-end pues me parece que es una cuestión tecnológica «de moda».
  • Paradigmas de Programación: entiendo que se la considera equivalente a Algo3 pero no lo veo tan así pues por un lado incluye cuestiones de otros paradigmas más allá de OO y al mismo tiempo no veo ninguna mención a cuestiones de ing. de software (nada de TDD, ni unit testing y tampoco patrones)
  • Ingeniería de Software 1: parece que algunas de las cuestiones que «sacaron de algo3» las metieron aquí, puntualmente las cosas de diseño, oo, patrones. Creo que quedó más parecida a la materia de Ingeniería de Software 1 que se dicta en Exactas. Yo la veo distinta a MeMo 1 en parte por contenido y también porque es una materia 8 créditos (MeMo 1 es de 6).
  • Ingeniería de Software 2: pinta como lo que vengo dando en MeMo2 (de hecho los contenidos mínimos son los mismos) pero tiene 8 créditos cuando MeMo2 tiene 6. Intentaré averiguar que onda.
  • Taller de programación: sus contenidos mínimos me suenan muy distintos a los de la materia que se dicta actualmente y me resulta intrigante cómo se plasmaran en un curso.
  • Empresas de Base Tecnológica: la 1 me parece como un mix de varios temas «de materias de Las Heras» (en general en Las Heras se dicta materia de organización/gestión). La 2 pinta mejor, trae algunas cuestiones de innovación, startups, etc.
  • Gestión del Desarrollo de Sistemas Informáticos: entiendo que esto es lo que viene dictando Carlos Fontela en la materia de gestión de proyectos que dicta actualmente. Pinta bien aunque me llama la atención lo de «Análisis del Impacto Socioambiental» (según averigué es un lineamiento de la facultad que todas las carreras tengan algo de esto)
  • Taller de Seguridad Informática: me parece bien que se haya puesto esta materia, creo que seguridad es un tema muchas veces postergado. Los contenidos son debatibles pero por algo hay que empezar.
  • Electivas: veo muchas que me suenan a «data / machine learning» y solo arquitectura de software del área de Ingeniería de Software. No vi ninguna materia relacionada a operaciones, infraestructura, data centers, etc, cosa que si había en alguna versión preliminar del plan.

En lo personal creo que es un buen plan, mucho más adecuado a los tiempos actuales que el plan anterior. También creo que está mucho más enfocado en cuestiones de informática (y no tantas generalidades de ciencia básica). Por último pero no menos importante, el plan tiene una estructura distinta que entre otras cosas elimina las orientaciones y que constituye una carrera más corta (al menos en los papeles): son en total 10 cuatrimestres incluyendo el ciclo de ingreso.

Este nuevo plan se pondrá en funcionamiento este segundo cuatrimestre de 2023 con la oferta de 3 materias aún cuando falta la aprobación del Consejo Superior de la UBA, cosa que debería ocurrir en las próximas semanas.

Actualización 2023-09-08: el plan ya es oficial, fue aprobado por el consejo superior. Aún no lo actualizan en la página de la facultad pero se puede descargar desde la página de UBA, aquí.

Nuevo proyecto: refactoring, Python y OpenAI

Esta semana comencé a trabajar en un nuevo proyecto. En términos simples voy a acompañar a un grupo de devs en el refactor de una de sus aplicaciones. A la pasada vamos a revisar algunas cuestiones de diseño, arquitectura, testing y posiblemente a la pasada veremos un poco de TDD.

Venía intentando escaparle a la ola de AI, pero ya no más pues este proyecto trabaja con OpenAI, así que, más obligado que por gusto, me toca meterme en este mundillo.

El refactor surge a partir de la necesidad de agregar ciertas nuevas funcionalidades que con el diseño actual podrían resultar no tan fáciles de introducir. Entonces la idea es seguir la estrategia de Beck: «for each desired change, make the change easy (warning: this may be hard), then make the easy change» o sea:

  • primero vamos a refactorizar el código existente para facilitar la implementación de las nuevas funcionalidades
  • a partir de esa refactorización vamos a poder agregar algunos test «chicos/unitarios» ya que el código solo tiene pruebas «grandes/de aceptación» que son caras y no ofrecen suficiente cobertura
  • una vez finalizado el refactor y agregados nuevos tests, avanzamos el desarrollo de la nueva funcionalidad
  • bonus track: el desarrollo de la nueva funcionalidad lo hacemos guiado por tests (tdd)

Continuará…

Carrera de Postgrado en Ingeniería de Software Continua

Luego de varios años dando vueltas sobre este tema, tenemos una carrera. Estoy tentando de decir que tenemos 3 carreras (una diplomatura, una especialización y una maestría) pero en términos formales y por el momento solo tenemos la diplomatura, las otras dos están aún «in-progress».

El detalle interesante es que estas tres titulaciones están armadas en manera incremental. En forma simplificada tenemos nueve materias, cuatro de ellas constituyen el diploma. Luego la especialización agrega cinco materias más y finalmente la maestría agrega una materia más y una tesis. Hay algunos detalles de «articulación» que aún nos falta definir pero la parte interesante es que la diplomatura ya está lista y la empezaremos a dictar el mes próximo: Septiembre 2023.

La diplomatura consta de las siguientes 4 materias:

  • Software Delivery: esta materia es la que vengo dictando desde hace 4 años bajo el nombre de «Seminario de Software Delivery». En el contexto de la diplomatura seguirá a mi cargo.
  • Operación y Gestión de Servicios de Software con DevOps: a cargo de Federico Casuscelli
  • Ingeniería de Software Moderna: a cargo de mi estimado Carlos Fontela
  • Diseño y Evolución de Arquitecturas de Software: a cargo de los doctores Diego Fontdevila y Andrés Diaz Pace.

La diplomatura se dicta en modalidad virtual, dos materias por cuatrimestre. A su vez cada materia consta de 6 encuentros online que se realizan cada dos semanas. Finalmente en términos de calendario, las materias que se dictan en el mismo cuatrimestre, se encuentran «defasadas» en una semana. De esta forma el alumno cursa durante 12 semanas consecutivas, una clase por semana, las semanas pares cursa una materia y las semanas impares cursa la otra materia.

En particular, este segundo cuatrimestre de 2023 comenzaremos con el dictado de Ingeniería de Software Moderna y Diseño y Evolución de Arquitecturas. La cursada comenzará a mediados de septiembre. Estamos planificando una charla de presentación para la tercer semana de Agosto.

Respecto del costo, es algo que me excede pero según lineamientos institucionales, creo que serán algo así como 10 cuotas de ~ $40.000 (cuarenta mil pesos argentinos)

Pueden encontrar más detalles sobre las materias y la diplomatura en general en el folleto de difusión.

Los interesados en cursar pueden completar el formulario de pre-inscripción y recibirán más detalles.

Finalmente por cualquier duda pueden escribir a ingenieriadesoftware@untref.edu.ar y con gusto contestaremos todas sus inquietudes.

Mis notas de la conferencia Agile2023

Esta fue mi tercera participación en la conferencia Agile y al igual que en mis dos participaciones anteriores, también tuve la posibilidad de presentar una charla (ya hablé de ello en el post anterior).

Como es tendencia en todas las conferencias de Agile, la cantidad de charlas técnicas está en extinción. Mucho contenido de producto, transformaciones, chatgpt (¿¡!?) y curiosamente también muchas charlas de nivel inicial. Digo curiosamente porque a esta altura me resulta curioso que las charlas iniciales (agile essentials, como se las denominaba en la conferencia) hayan sido de las más concurridas.

De las charlas que asistí creo que las dos mejores fueron:

  • la de Jeff Patton, Shift: why it’s so hard to shift to a product mindset
  • la de Chris Edwards, Zero-Downtime Data migrations – Mastering Continuous Deployment

Otras que también me resultaron muy interesantes fueron

  • la de Nayan Hajratwala, Embrace these Three Fearsome Words: Test in Production
  • la Llewellyn Falco y Jay Bazuzi, Provable Refactoring – Safety without Tests
  • la de Jen Krieger, The developer-centric mindset will disrupt how all of us work
  • la de James Grenning y Jeff Langr, Your first test-driven development
  • la de Marisa Smith, Faster, Better, Stronger with Ephemeral Environments

En siguientes posts iré compartiendo detalles de algunas de estas charlas.

La organización como siempre, impecable, aunque me resultó raro y hasta inconveniente la duración de las charlas: en general los slots eran de 75 minutos. A mi me resultó bien (en parte porque tenia contenido para 2 horas más) pero en la mayoría de las charlas que participé sobró bastante tiempo. Una de las sesiones que participé sobraron literalmente ¡20 minutos!.

En lo personal tuve la oportunidad de compartir un par de días con colegas que no suelo ver: Hiro, Andrés y Martin que viven en Lima(Perú), Rosario(Arg) y Orlando(USA) respectivamente. Al margen de nosotros había unos cuantos colegas de Latam (al menos 15). También aproveché el viaje para hacerme de algunos libros: dos nuevos (The Joy of Agility y Wild West to Agile) y dos clásicos (Waltzing with Bears y Extreme Programming Explored).

Luego de haber participado en 3 ediciones creo que es una conferencia interesante, ofrece contenido variado y muchas oportunidades de networking. Al mismo tiempo participar puede resultar «bastante picante»: pasaje a USA, alojamiento y una entrada que ronda los $2.500. El «truco» es participar como speaker, ya que en ese caso la entrada está bonificada y alojamiento cubierto.

Cierro con una noticia: el año próximo la conferencia se realizará el Dallas, Texas.