Con el auge de las iniciativas DevOps/SRE resultan cada vez más importantes ciertos aspectos de cómo desarrollamos software, pues ciertas propiedades del software desarrollado pueden tener un impacto muy importante en la operación del software. Este conjunto de propiedades que van mucho más allá de la arquitectura bien podrían caracterizarse como «factores de operabilidad» o como las denomina James Shore «Build for Operations». Aquí tenemos cuestiones tales como: Threat Modeling, Configuration, Logging, Secrets y Monitoreo entre otras.
Desde hace ya un tiempo vengo incorporando algunas de estas cuestiones en mis materias y es por ello que he decidido inaugurar una nueva serie de videos titulada «Build for Operations» para ir cubriendo estos temas. Aquí les comparto el primer video de la serie: «Manejo de Logs»
En mi opinión no hay una definición única sobre qué es una prueba de integración. En términos muy generales suele asumirse que prueba de integración verifica la integración de dos (o más) componentes. La cuestión (o diferencia) radica en qué son esos componentes.
Algunos (¿la mayoría?) considera que esos dos componentes son componentes de nuestra propia autoría, por ejemplo: tengo dos clases desarrolladas por mi con algún tipo de dependencia entre ellas, claseA y claseB, entonces mi prueba de integración busca verificar la correcta interacción de esas dos clases entre sí.
Otros, donde me cuento yo, pensamos más en línea con la propuesta de Freeman. En este caso uno de los componentes en la prueba de integración no está bajo nuestro control, o sea: no lo desarrollamos nosotros. Esto hace que el foco de la prueba de integración pase por verificar la interacción del código que está bajo nuestro control con código que no lo está. Un caso típico es cuando nuestra aplicación debe interactuar con una aplicación/servicio/api externo como ser una API REST desarrollada por otro equipo/organización. En este caso, no tiene ningun sentido utiliza mocks (dobles de prueba) porque justamente lo que quiero verificar es la interacción con ese sistema externo, entonces de nada sirve reemplazar ese sistema externo con un doble de prueba.
La semana pasada grabamos con mi colega Martín Alaimo una conversión «Detrás de Escena» sobre varios temas de «Agilidad Técnica» que son parte de mi Taller de Prácticas Técnicas para Scrum Masters.
Me resultó muy interesante la charla, Martín es un gran entrevistador, hablamos de varias cuestiones más allá de lo que sugiere el título.
Comparto aquí la grabación y aprovecho para mencionar que en noviembre estaré dictando una nueva edición de este taller enfocado en Scrum Masters y facilitadores de equipos que quieran profundizar en las cuestiones que mencioné en la charla la Martín.
En los últimos años se ha hablado bastante en Argentina sobre el tamaño y los costos del estado. Este es un tema, que como a todo el mundo, me toca como ciudadano pero también me toca como empleado de dos universidades públicas. En este sentido llevo más de 20 años trabajando como empleado público, siempre en universidades nacionales, generalmente en tareas de docencia e investigación y en este último tiempo también en cuestiones de gestión. En alguna ocasión también trabajé como proveedor del estado. Todas estas experiencia me llevaron a formar algunas opiniones.
Sin duda en el estado hay gente muy buena tanto en lo profesional como en sus intenciones. Tal vez incluso gente mejor que la que uno podría encontrar en el varias empresas del sector privado. Pero al mismo tiempo hay gente que no está a la altura de las tareas que debe desempeñar. En ocasiones es por falta de capacidad, gente que no está preparada y no tiene las herramientas intelectuales para hacer las tareas que tiene a su cargo. Pero en otras ocasiones es un falta de voluntad, desidia, un mindset de «hacer lo mínimo indispensable» para que no los despidan y cuando a esto le sumamos el clásico «en el estado no se despide gente» terminamos con gente haciendo prácticamente nada.
Pero la cuestión no termina ahí, por que esa gente sin capacidad o sin voluntad que no realiza su trabajo en tiempo y forma termina impactando en otras dos cuestiones. Por un lado, hay tareas que no se completan y se asume que es por falta de personal entonces la institución contrata más gente y es así que tenemos una planta de bastante más grande que lo necesario si cada uno hiciera sus tareas en tiempo y forma. Por otro lado, esa gente también impacta negativamente en las tareas que deben desempeñar otras personas provocando una bola de nieve de retrasos, impedimentos, ineficiencias, etc, etc.
Desconozco cuál es la solución para esto. Pero sin duda algo que podría ayudar sería tener algún mecanismo de evaluación de desempeño periódica que resulte vinculante para la continuidad de la contratación.
Esta edición tuvo 5 días: los primeros dos online y los otros 3 presenciales pero con transmisión en vivo. Estuve los 3 días presenciales y quedé sorprendido de la cantidad de gente que había. En particular, el viernes por la tarde no entraba un alfiler en la Gran Sala. Asimismo, al margen de la asistencia presencial, informan los organizadores que hubo más de 40.000 registrados.
El jueves pasé gran parte de la jornada hablando con colegas, varios de ellos ex-alumnos. Esto puede parecer una picardía pero yo no lo veo así pues creo que una de las cuestiones más ricas de este evento es la posibilidad de networking.
Más allá de las «charlas nerds» de temas de física, astronomía y demás, las 4 charlas de IT que más me tocaron fueron:
10 cosas que los devs deberían saber sobre las DB de Carlos Tutte
El sábado me tocó subir al escenario para dar mi sesión «Integración Continua 3.0». Una curiosidad de backstage es que me maquillaron para salir a escena :-). Me gustó como fluyó la charla, cumplí con los tiempos y creo que legué a compartir todo lo que me había propuesto.
Es increíble como este evento se supera año a año. Mis fecilitaciones a los organizadores.
El miércoles pasado comenzamos el dictado de la Diplomatura en Ingeniería de Software Continua en la Universidad Nacional de Tres de Febrero. Un importante paso de una idea que para que comenzó a gestarse hace ya varios años.
Esta primera cohorte tiene 13 participantes, un muy buen número para la propuesta didáctica queremos implementar en la toda la carrera. Entre los participantes tenemos un extranjero residente en Costa Rica y gente de diversos lugares de Argentina: La Plata, Bariloche, Mendoza, Córdoba y San Martín de los Andes entre otros.
En este primer cuatrimestre comenzamos con el dictado de dos materias: Ingeniería de Software Moderna (a cargo de Carlos Fontela) y Diseño y Evolución de Arquitecturas de Software (a cargo de Andrés Pace y Diego Fontdevila).
Dado que las 4 materias del diploma están armadas de forma autocontenida y no tiene correlatividades entre ellas, en marzo del año próximo volveremos abrir la inscripción para quienes quieran empezar a cursar las otras dos materias que se comenzarán a dictar en abril: Entrega Continua (a mi cargo) y Operación y Gestión de Servicios de Software con DevOps (a cargo de Fede Casuscelli).
Quienes quieran saber más sobre esta propuesta educativa aquí hay un documento formal con detalles de objetivos, contenidos y bibliografía.
Este es un tema recurrente a comienzo de cada cuatrimestre pues muchas veces los estudiantes vienen más enfocados en hacer codear correctamente los algoritmos que sea óptimos en lugar de que su código sea legible y mantenible. Es por esto que muchas veces agregan comentarios al código que no agregan valor. En parte es por esto que grabé un breve video sobre este tema.
Más allá de mi video, a quienes quieran profundizar en este tema le recomiendo el capítulo 42 del libro Code Complete de Steve McConnel.
Aprendí esta técnica allá por 2012 en un taller facilitado por Alejandra Alfonso. Por aquella época no había mucha información de esta técnica. Apenas un artículo en el blog de su autor, Jeff Patton, y algún otro artículo de gente que había aprendido la técnica con él.
Desde un comienzo esta técnica me ha resultado muy útil. Por eso, cuando escribimos «Una mirada ágil» allá por 2014 decidimos incluir una explicación de esta técnica acorde a la forma en que yo y los otros autores solíamos usarla. Casualmente el capítulo que describe la técnica es parte del extracto del libro que la editorial generó a modo promocional y que es de libre distribución. Ese material es el que uso actualmente en mi materia para explicar la técnica a mis alumnos.
Comparto aquí algunos otros recursos sobre Visual Story Mapping:
El capítulo «Definición de alcance» de mi libro «Una mirada ágil» y que incluye la explicación de esta técnica puede descargarse gratuitamente aquí.
El capítulo de «Product Discovery» del libro de Fede Zuppa también incluye una descripción de esta técnica con un ejemplo muy claro y está disponible para lectura gratuita online aquí.
En la página de Jeff Patton hay varios recursos sobre esta técnica incluyendo esta hoja de referencia.
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…
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:
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.
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.
Blog de NicoPaez 