Si duele, hacelo más seguido

Si duele, hacelo más seguido

Cuentos de la cripta

No podía fallar. Fer había sido promovido a gerente de ingeniería de software luego de 15 años de ver pasar un sinfín de gerentes traídos de afuera que nunca dieron pie con bola. Le había sido casi imposible pegar un ojo la noche anterior, y cuando su reloj marcó las 5 am del sábado con suerte llegaba a 4 horas de sueño y 23 despierto desde que comenzó su jornada el viernes. Buscaba desesperado con su equipo la causa del error que había dejado una actualización a medias, sin posibilidad de rollback por un backup que, acababa de descubrir, nunca había probado restaurarse. Su única opción era seguir adelante con el despliegue del release más importante de su incipiente gestión, mientras intentaba ubicar por teléfono al experto del equipo de infraestructura que se negaba a trabajar en la madrugada de un sábado, y menos en medio de sus vacaciones. Ya le habían advertido que, esta idea suya de hacer despliegues mensuales, era un delirio. Los pases a producción debían combinarse, como mínimo, con 3 meses de anticipación. No solo había que asegurarse de que todas las personas claves estuvieran disponibles, y completar una abultada cantidad de documentación con instrucciones para la copia de archivos y corrida de scripts, sino que cualquier cambio de software o esquema de datos podía requerir una actualización de las herramientas que sus predecesores le habían entregado a operaciones para la reconciliación manual de datos inconsistentes.

A pesar del stress y la urgencia, los planteos del grupo de operaciones le parecían razonables, y más aun los de su equipo que estaba harto de trabajar los fines de semana. Sin embargo, la compañía dependía cada vez más del software y, si no lograban moverse más rápido, la competencia iba a terminar de desplazarlos del mercado. No tenía la respuesta, pero estaba seguro de que sumar capas de planificación, documentación y ambientes extras, no iba a resolver el problema.

Alguien vivió una situación similar?

Yo sí. Más de una vez.

Y considerando que un grupo genial de autores escribieron The Phoenix Project con anécdotas similares, podríamos suponer que es un fenómeno extendido en el ámbito del desarrollo de software: si algo duele, en este caso un pase a producción, de alguna manera hacerlo menos seguido y más burocrático debería reducir el dolor, no?

Wrong!

Contraintuitivo como pueda parecer, la frecuencia reduce la dificultad. Esto puede observarse claramente en:

  1. Integración: a medida que se difiere la integración de código entre branches, el merge se vuelve más complejo, aumenta la probabilidad de generar bugs, se reduce la confianza del equipo, y se pierde velocidad de desarrollo.
  2. Despliegue: lo mismo ocurre a medida que se extiende el tiempo entre deploys a producción, como en el caso (inventado por mi pero basado en hechos reales) que da inicio a este post.

En Accelerate, libro prologado por Martin Fowler, los autores, aplicando técnicas de análisis estadístico y a partir de la información recolectada por el State of Devops Report, observan una correlación alta entre la capacidad de las empresas más innovadoras para entregar software y el desempeño organizacional, medido por rentabilidad, productividad y participación de mercado. Las empresas de mejor desempeño tienen:

  • Deploys 46 veces más frecuentes.
  • Tiempo entre commit y deploy 440 veces menor.
  • Tiempo de recuperación luego de una caída del servicio 70 veces menor.
  • Tasa de error por cambio 5 veces menor.

Es decir, lejos de reducir el riesgo con procesos más largos y aversión al cambio, los líderes de mercado tienen al delivery continuo en su ADN.

Kanban con muletas y la muerte del feature branch

Contraintuitivo como pueda parecer (de nuevo), de las capacidades necesarias para soportar un modelo de delivery continuo, las más arduas de incorporar no son las técnicas, sino las relacionadas con el proceso. Basta mencionar cualquiera de las buzzwords tales cómo microservices, docker containers, lambda functions, serverless, y todo el equipo de desarrollo se amontona para subirse al bote. Se vuelve un poco más difícil, en cambio, intentar borrar los límites de los sprints para alcanzar el delivery continuo: “Cómo podemos desplegar todos los días a producción si el sprint dura 2 semanas? Y ahora? Cuando hacemos el release planning?”. Por eso un gran amigo mío suele bromear que Scrum es “un Kanban con muletas“. ¯\_(ツ)_/¯

La transición de los sprints de Scrum a un Kanban board es casi natural, es como un “sprint sin fecha de fin”, pero alcanzar el flow continuo (en términos de Lean Manufacturing), e integrar código a diario, requiere ir a contramano del hábito que tenemos los desarrolladores de sumergirnos en nuestro propio mundo a escribir código durante días. Esos días de código sumergido suelen almacenarse en feature branches, según la estrategia de branching de código conocida como GitFlow:

El problema de los feature branches, y su beneficio, como el de todos los branches, es que están diseñados para aislar una parte del código del resto, y si la integración continua se trata de integrar cambios tan frecuentemente como se pueda para obtener feedback rápido, cualquier forma de branching tiene la intención diametralmente opuesta. La propuesta del trunk based development es desalentar el uso de los features branches (o al menos el de los que viven mucho tiempo), y alentar el trabajo sobre un único branch, con branches cortos de máximo un par de días de vida. En palabras de Jez Humble:

Trunk based development is about “putting the needs of the team above the needs of the individual.” Effective trunk based development encourages communication and working with small batches

Cultura de experimentación

El desarrollo sobre un único branch presenta desafíos no menores, más aun cuando el delivery continuo transforma cualquier commit a master en un deploy automático a producción, pero se convierte en la piedra angular sobre la cual construir un proceso de desarrollo de software que responda eficientemente a las necesidades cambiantes del mercado actual:

La primera dificultad consiste en separar el release de funcionalidad en producción del despliegue de código. Aunque el despliegue en producción sea diario, no necesariamente se puede o se quiere liberar funcionalidad con la misma frecuencia. El mecanismo por el cual esta separación es posible, se denomina feature flags. A través de los features flags puede desplegarse funcionalidad incompleta y sin testear en producción como código latente, que se activará o no cuando la funcionalidad esté completa y testeada.

Incluso se observan ventajas adicionales, producto del delivery continuo, el trunk based development, los feature flags y el flow en un Kanban board:

  1. Homogeneidad de las unidades de trabajo: cuando no hay una fecha de fin de sprint, ni un día de merge con el trabajo del resto, ni un día de pase a producción, y el foco es el delivery continuo, el trabajo empieza a confluir en unidades de peso similar, idealmente cercano a un día. Como bien explica Vasco Duarte en su libro No estimates, el proceso, tanto de medición del progreso del equipo como del dimensionamiento del backlog, se empieza a parecer más a una simple suma de stories que a una maraña de gantts y estimaciones.
  2. Mejora en la calidad: tener un set de test unitarios robusto y en constante crecimiento, además de una manera de codificar que considere constantemente la retro-compatibilidad y el impacto en el código corriendo en producción, se vuelven condiciones sine qua non de estar siempre listos para pasar a producción.
  3. Equipos empoderados: cuando se organiza el trabajo para poder ser testeado y desplegado sin depender de servicios o entidades externas, los equipos y las personas empiezan a presentar “bajo acoplamiento” con los demás, y y las decisiones fluyen sin necesidad de escalar pidiendo permisos.
  4. Equipos productivos: según los autores de Accelerate, las empresas donde los pases a producción son los más dolorosos, presentan, no solo el peor desempeño organizacional, sino la cultura más pobre. El miedo y la ansiedad que genera desplegar en producción desaparecen en una cultura de delivery continuo. En MG, todos los desarrolladores hacen merges a master, y por ende despliegues automáticos a producción, todo el tiempo.
  5. Cultura de experimentación: los features flags permiten correr experimentos en producción a través del A/B Testing, habilitando funcionalidad diferente a distintos grupos de usuarios, para probar hipótesis del negocio. La cultura de experimentación, dirigida por la medición de los hábitos y gustos de los usuarios, reemplaza a la cultura de decisión de los Hippos (highest paid person’s opinion).

Dejémonos de joder con la línea de tres y los pies del arquero?

Mientras termino de escribir este post, Argentina se encuentra revolucionada por la derrota ante Croacia, producto, entre otras cosas, del error del arquero de salir jugando con los pies, y de la línea de 3 que presentó la defensa.

Gente que entiende infinitamente más que yo de fútbol critica que se experimente con los pies de los arqueros (a pesar de que Neuer en Alemania parecería dar resultado), y con un fútbol complejo de líneas de 3 cuando todo el mundo sabe que la defensa es con línea de 4.

Será ese el problema? Probar cosas diferentes? O probarlo una vez y cambiarlo la próxima?

La verdad no tengo idea, pero en mi experiencia, si algo duele o nos cuesta… hay que hacerlo más seguido.

Cerrar