Es el verano de 1858. Londres. El río Támesis se desborda con el olor de los desechos humanos e industriales. Los meses de verano excepcionalmente calurosos han exacerbado el problema. Pero esto no sucedió de la noche a la mañana. La falta de mantenimiento de un sistema de alcantarillado envejecido y una población creciente que lo usaba contribuyeron a un barril de pólvora de efluentes, lo que provocó brotes de cólera y envolvió a la ciudad en un olor que no desaparecía.
Hasta el día de hoy, los londinenses todavía hablan de el gran hedor. Las infecciones recurrentes de cólera llevaron al amanecer del campo de la epidemiología, un tema en el que todos nos hemos convertido recientemente en entusiastas aficionados.
Avance rápido hasta 2020 y verá que las canalizaciones de software modernas se enfrentan a un “gran hedor” similar debido, en gran parte, a la gran adopción de la integración continua (CI), la práctica de fusionar las copias de trabajo de todos los desarrolladores en un archivo compartido. línea principal varias veces al día y entrega continua (CD), la capacidad de obtener cambios de todo tipo, incluidas nuevas funciones, cambios de configuración, correcciones de errores y experimentos, en producción o en manos de los usuarios, de forma segura y rápida en un entorno sostenible. camino.
Si bien las fallas de software contemporáneas no propagarán enfermedades ni emitirán los olores rancios del pasado, ciertamente apestan a devastación, lo que hace que se pierdan miles de millones de dólares y se desperdicien millones de horas de desarrollo cada año.
Este tipo de desperdicio es la antítesis de la intención de CI/CD. Todo el mundo emplea CI/CD para acelerar la entrega de software; sin embargo, la acumulación cada vez mayor de fallas de prueba intermitentes y esporádicas está haciendo exactamente lo contrario. Se ha convertido en un lodo en crecimiento que se alimenta constantemente con fallas más rápidas de las que se pueden resolver. Esta acumulación debe eliminarse para que las canalizaciones de CI/CD vuelvan a tener todas sus capacidades.
¿Qué valor tiene un sistema que, en un esfuerzo por acelerar la entrega de software, deja a sabiendas una acumulación de errores que hace exactamente lo contrario? No llegamos a estas prácticas por casualidad, y sus practicantes no son tan flojos ni incompetentes; ¿Cómo llegamos aquí y qué podemos hacer para moderar el gran hedor del desarrollo de software moderno?
Bombas de relojería
Source link