Metí la pata

Hace unas semanas, estaba con gripe en casa. Estaba aburrido y me puse a ver que podía mejorar una KB Genexus. Para esto, me puse a probar una opción de KBDoctor que permite identificar cuales son los objetos que tienen problemas y arreglar los mas comunes.

Los tipos de problemas que soluciona son:

• variables que no están basadas en dominios / atributos
• parámetros que no tienen indicador de in/out
• atributos que no tienen dominios 

Estos arreglos son semiautomáticos, donde KBDoctor cambia el fuente en forma automática, pero  luego tiene que verificarse en forma manual, pues el cambio no siempre es el correcto, porque se usan heuristicas que no siempre hacen lo correcto. 

Primero probé estos  con una KB chica y bien conocida y todo funcionó bien. 

Con el viento en la camiseta y pensando que nada podía salir mal, hice una corrida en una KB grande que están en desarrollo desde el año 1998, que tiene código viejo. 

Tal vez por la gripe y la fiebre, cuando quise acordar había cambiado mas de 1600 objetos.  Ya había subido muchos objetos, cuando me di cuenta que el cambio podía tener efectos complicados. 

En ese momento, debería haber valorado el cambio y hacerlo mas paulatino. Si bien el cambio agrega mucho valor en la KB, el hacerlo en forma tan repentina, puede dificultar la detección de los problemas.  Mande un mail a todo el grupo de desarrollo tratando de explicar la situación y advirtiendo que podía haber metido algún bug con el cambio. 

El código llego a producción y efectivamente tuvimos tres errores que afectaron la operativa del sistema.  Los problemas fueron que parámetros que tenían que ser OUT, quedaron como IN: . GeneXus no daba error, porque los mismos eran modificados en llamadas a procedimientos.

Para peor, de los errores detectados, dos ya los habíamos detectado y corregido en el ambiente de desarrollo, pero no me di cuenta que esos errores debían pasarse en forma urgente al ambiente de stage para pasar a producción lo antes posible.

En fin, son varios errores de los cuales se pueden sacar muchas experiencias (para no repetir errores)

• Si se hacen cambios grandes, hay que testear mucho mas. 

Tenemos definido un proceso de deploy diferente (escalonado) para cuando hacemos migraciones (que son cambios grandes) y en este caso no lo usamos. 

• No alcanza con corregir errores, hay que asegurarse que los mismos lleguen a los ambientes adecuados en los momentos adecuados. 

• Los cambios de código en forma automática, necesitan mas control que los cambios manuales. 

Esto nos costó que todo el grupo de desarrollo tuvo que revisar los objetos que habían cambiado las reglas de parámetros (eran muchos), el costo de la imagen del sistema, que por un buen rato (mas de 4 horas) estuvo funcionando mal y muy probablemente una multa por parte del cliente.

A pesar de todo, estoy convencido que hay que rejuvenecer el código viejo, para hacerlo mas mantenible y que no nos de sorpresas en el futuro. Solo que la próxima vez, tendré la precaución de hacerlo con mas cuidado. 


También tengo que recordar, que el año que viene no debo vacunarme contra la gripe, de forma de no tener que quedarme toda un semana en casa con tos y dolor de garganta.