El primero de septiembre retomé el seguimiento de una actualización reciente de llvm. La versión 21 se acababa de publicar y aproveché para actualizar mi matriz de flags de diagnóstico de clang. Utilicé mi herramienta en Perl que rastrea la documentación y genera una tabla en markdown con las versiones disponibles para comparar.
Al generar la matriz detecté que la versión era 21.1.0, un patrón que ya había visto con 18.1.0 y que requería un tratamiento especial en la generación inicial. A continuación trabajé en el proxy al que apuntan los enlaces acortados. Allí descubrí que había pasado por alto el mismo patrón en 19.1.0 y 20.1.0, así que parcheé el proxy para esos casos también.
El proxy es una función serverless que desplegué tras aplicar los cambios. Hice una prueba rápida y todo parecía correcto, pero introduje un bug que no vi y al desplegar se disparó una alarma que tampoco detecté a tiempo. Días después recibí la notificación de que el monitor se había pausado por inactividad y finalmente pude investigar.
Con la introducción de soporte para 21.1.0, 19.1.0 y 20.1.0 había roto todo, y la alarma tuvo razón. Revisé el código buscando la causa y, para validar la hipótesis, consulté a mi paciente pair programmer. Sospechamos que el problema venía de una comparación incorrecta entre niveles mayores de versión hecha como cadenas en lugar de números, lo que provoca una comparación lexicográfica en lugar de numérica y resultados inesperados.
El problema típico es comparar versiones representadas como cadenas porque la comparación lexicográfica trata los valores carácter por carácter. Eso puede dar lugar a que 20 sea mayor que 18 cuando se comparan como cadenas, pero casos como 2 frente a 18 producen resultados sorprendentes por el orden de los caracteres. La solución correcta es convertir la cadena a entero antes de comparar. Un ejemplo de corrección en Go es:
major, err := strconv.Atoi(majorlevel) if err == nil && major >= 18 { // ... }
Reestructuré el código, desplegué una nueva versión y esta vez probé con más calma y cubrí los casos que habían fallado. Verifiqué que el proxy funcionara correctamente y que las alarmas ya no se activaran por ese motivo.
Lecciones aprendidas: testar los cambios aunque parezcan triviales, tener paciencia porque los incidentes suelen venir en pares y preparar mejores controles automáticos. Entre las medidas a tomar están crear pruebas automatizadas para el proxy, mejorar las revisiones de código y seguir profundizando en Go.
En Q2BSTUDIO aplicamos estas prácticas en nuestro día a día como empresa de desarrollo de software y aplicaciones a medida. Ofrecemos soluciones de software a medida y desarrollo de aplicaciones multiplataforma que integran buenas prácticas de calidad y despliegue continuo, puedes conocer más sobre desarrollo de aplicaciones y software a medida en desarrollo de aplicaciones y software multiplataforma. Además trabajamos con arquitecturas cloud y soluciones serverless en servicios cloud aws y azure para asegurar despliegues fiables, con información disponible en servicios cloud aws y azure.
También somos especialistas en inteligencia artificial, ciberseguridad, agentes IA, servicios de inteligencia de negocio y Power BI. Incorporamos IA para empresas, automatización de procesos y servicios de ciberseguridad como parte integral del ciclo de vida del software para minimizar riesgos y mejorar resiliencia operativa. Palabras clave que describen nuestros servicios: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi.
Si gestionas proyectos con dependencias de versiones y despliegues automatizados, plantéate invertir en pruebas automatizadas, revisiones cruzadas y monitorización proactiva. Un pequeño cambio puede parecer inocuo pero, como aprendimos, puede desencadenar incidentes en pares. En Q2BSTUDIO ayudamos a diseñar procesos y arquitecturas robustas para evitar ese tipo de sorpresas y acelerar la recuperación ante fallos.
.jpg)
.jpg)
.jpg)