En uno de los clientes que estoy trabajando ahora, tuvieron un problema en producción bastante peculiar. Observaron que se redujo la performance desde el punto de vista de algunas métricas puntuales, con lo cual se pusieron a analizar, y resulta que un archivo JavaScript muy usado pasó de tener ~100kb a ~450kb. Esto se pudo ver gracias a lo que Katrina Clokie en su libro incluye en lo que le llama testing en producción, o sea, a estar mirando y recolectando métricas constantemente de toda la actividad de los usuarios en el ambiente de producción, y utilizar esa información para evaluar la calidad del software.
Siguiendo con el análisis, pudieron identificar el cambio concreto. Por un lado observaron a partir de qué merge de código comenzó a observarse el problema, y como sus merges son pequeños entonces la cantidad de cambios a revisar era acotada. Sería imposible poder hacer esto si no fuera porque siguen una estrategia de Continuous Delivery, donde liberan pequeños cambios todos los días. Observando el log de Github pudieron ver todos los archivos que fueron cambiados en ese merge request, y así los candidatos eran tres cambios puntuales, con lo que fue fácil darse cuenta cuál generó el problema. Si liberaran una vez por semana, tendrían que haber analizado todos los cambios hechos en esa semana, lo cual hubiera sido mucho más complicado.
Continuous Delivery no solo nos permite entregar valor al usuario final de manera más frecuente, también nos permite levantar feedback más preciso gracias a observar el impacto de cada uno de los cambios y de tener una mejor trazabilidad.
