[#ALM] Mejorando el proceso (todo el tiempo, tambien en Semana Santa)

Hola!

Hace unos días fueron los DevDays en Perú y hoy mientras repasaba algunos materiales, me encontré con esta slide de Ernesto y mientras corría 11KMs hice una pequeña reflexión sobre la misma.

En mi línea de trabajo el cambio es una constante. Alguna vez he comentado sobre el tipo de trabajo con equipos elásticos, donde usualmente somos 3 personas, y podemos subir a picos de 20 con un objetivo concreto y luego volver a ser 3. Esto hace que la inspección y adaptación sea un poco más compleja que lo habitual. Sin embargo la base de un trabajo con calidad, es algo que no debemos perder nunca.

Asi que con este escenario en mente, decidí volver atrás algunos pasos (unos 23 segun mis gráficos) e intentar actualizar 1 línea de código de un proyecto / demo que está en producción desde abril del año pasado y publicar el mismo nuevamente.

El proceso fue un poco engorroso y no me tomó más de 2 horas, y en el mismo vi lo siguiente:

– La descarga de código fue trivial, y la compilación no tuvo problemas.

– No puedo decir lo mismo de los unit Tests, empecé a tener problemas con algunos. Parece que a los amigos de JSON se les ha dado por actualizar desde abril del año pasado hasta ahora varias versiones.

– Eso se solucionó con la acutaliacion de un par de NuGet packages, y esto desencadenó otra serie de actualizaciones que ME OBLIGARON A TOCAR CODIGO. Especialmente con packages de SignalR, y EF.

– Hace un año, tuve una discusión con una persona del equipo que se había emperrado en usar Azure Mobile Services. Por suerte decidí implementar la capa de sercicios con WebApi y pasando de las ventajas de Azure Mobile Services. He abierto un proyecto de prueba con el que empezamos a trabajar y creo que en un año no se puede actualizar nada.

– Esa era la de cal, ahora la de arena. Yo me puse perro en usar LightSwitch para unos mantenimientos triviales de tablas. Esos mantenimientos triviales ahora tienen más funcionalidad que una aplicación de cálculo de crecmiento demográfico, y después de migrar la misma entre versiones de LightSwitch, hemos llegado a un punto de no retorno donde … bueno ahi lo dejo. Este error me lo como yo. En algún momento deberé subir la prioridad de este PBI y meterlo en un Sprint para hacer la app de nuevo.

Hay un par de historias más para contar, sin embargo la conclusión es que en mi caso tarde 2 horas en actualizar una línea de cósido de un proyecto en producción. Y esto en una app en la que nadie trabaja que tiene entre 11 y 12 meses de antiguedad. No quiero ni pensar lo que costaría “revirir” código que se mida en años.

Conclusión: Si bien no es un escenario corriente el encontrarme con la necesidad de modificaciones en código de este tipo, deberé comentar este escenario con los 3 participantes del equipo y ver la mejor forma de estar preparados para esta situación. 2 horas no es mucho cuando es código que te resulta familiar, en un entorno “hostil” estas 2 horas pueden ser fácilmente 2 días o más … Open-mouthed smile