El viaje de Driftrock hacia la entrega continua

Durante el último año, Driftrock ha recorrido un camino bastante típico (puede que lo hayas oído antes): pasamos de las implantaciones manuales y la apatía por el envío de software a implantaciones automatizadas y repetibles centradas en aportar valor.

En lugar de aburrirles con otro post sobre los méritos de la Entrega Continua, aunque me gustaría hacerlo, intentaré centrarme en cómo hemos logrado este cambio. Inspirándome en el libro More Fearless Change de Mary Lynn Manns y Linda Rising, haré todo lo posible por recordar los pasos que dimos y, más concretamente, los patrones que seguimos utilizando para intentar cambiar los comportamientos del equipo.

Retroceder año(s)

En primer lugar, un poco de contexto, en junio de 2016 un cambio en cualquiera de nuestras aplicaciones serpentearía su camino a la producción. Había muy poca conciencia de si un cambio se había desplegado, había un modelo de ramificación frustrantemente popular que aumentaba drásticamente la carga cognitiva y los despliegues se activaban manualmente desde la máquina de un desarrollador a través de la CLI de Heroku.

Un nuevo cambio de desarrollo a producción se parecía un poco a esto:

Verde: paso automatizado.
Naranja: paso manual inevitable o paso manual que (aún) no queremos cambiar.
Rojo: paso manual evitable.

También había una serie de inconsistencias en ese proceso de despliegue dependiendo de la aplicación. Algunas no tenían un entorno de montaje, las que lo tenían podían o no desplegarse automáticamente en el entorno de montaje y no todas las aplicaciones tenían pruebas automatizadas que se ejecutaban en master o en cualquier otra rama. En resumen, era innecesariamente complejo, muy incoherente y poco o nada automatizado. Así que no es de extrañar que hubiera una falta de interés por parte del equipo a la hora de desplegar software.

Todo lo anterior significaba que las implantaciones eran irregulares y arriesgadas. La mayoría de las veces se lanzaba un gran lote de cambios, lo que aumentaba previsiblemente la probabilidad de que algo saliera mal y, en ocasiones, eliminaba la posibilidad de revertir los cambios de forma segura.

Pasitos de bebé

Intentaré explicar los pasos que dimos y los patrones relevantes que utilizamos para mejorar el escenario descrito anteriormente. Al final de esta página hay una referencia para los patrones mencionados a lo largo de estos pasos. También puedes encontrar todos los patrones convenientemente listados y descritos aquí.

Paso 1 - Implicar a todos

De forma poco convencional, empezó mejorando nuestras retrospectivas. El equipo necesitaba una plataforma para debatir problemas y sugerir mejoras(Involucrar a todos). Aunque teníamos una charla semanal llamada retrospectiva, se parecía muy poco a las retrospectivas que había visto en otras empresas. Al principio, esta reunión era mucho más parecida a una actualización semanal de la situación y se centraba en las tareas cotidianas y su progreso, en lugar de analizar cómo podemos mejorar nuestra forma de trabajar. Sugerir y luego demostrar un enfoque más estructurado de las retrospectivas (facilitando las primeras retrospectivas) tuvo un impacto significativo en el equipo más allá de la Entrega Continua, pero uno de los primeros puntos de discusión fue sobre cómo desplegamos nuestro software(Plant the Seeds).

Paso 2 - Hágalo

Con el equipo un poco inseguro acerca de cómo un movimiento hacia la entrega continua podría beneficiarles el siguiente paso era simple - mostrarles un ejemplo(Just Do It). Creé una sencilla aplicación API HTTP con un punto final que devolvía '200 OK' y creé un canal de despliegue en Snap CI. Intenté imitar cómo podríamos tratar nuestras aplicaciones habituales y sólo abordé los problemas más inmediatos (Elige tus batallas); despliegues manuales y gestión de múltiples ramas en el despliegue. Esto último también reduciendo la distancia entre el desarrollo local y la producción. Demostrando que nuestro proceso de despliegue podría empezar a evolucionar hacia esto:

Como era de esperar (al igual que con el software de trabajo), se convirtió en un gran punto de referencia para demostrar y explicar el valor de CD y cómo se compara con lo que estábamos haciendo.

Paso 3 - Prueba

Con esa semilla plantada, un ejemplo de trabajo y problemas regulares en el envío de software de calidad (sólo destacando la gravedad - Wake-up Call) la aceptación por parte del resto del equipo fue en constante aumento. El siguiente paso fue comprometer al equipo a trasladar una o dos aplicaciones reales al nuevo sistema(prueba de funcionamiento). Tomamos dos aplicaciones problemáticas para validar nuestras suposiciones lo antes posible, creamos canalizaciones de despliegue para ellas, las desplegamos con éxito y dejamos que el cambio se asentara. En este punto, por suerte, conté con algo de ayuda(Ask for Help), lo que hizo que el progreso fuera mucho más rápido y que el posible contragolpe fuera más fácil de sortear.

Paso 4 - Relaciones públicas persistentes

A lo largo de este proceso me llamó la atención una pauta mencionada en el libro: las relaciones públicas persistentes. Reflexionando sobre ello, apareció sutilmente en varios lugares, a veces intencionadamente, pero a menudo sin querer. He aquí un desglose de dónde aparecía:

• Cambiamos nuestra reunión habitual para que se centrara primero en lo que se había desplegado en producción, luego en la puesta en fase y después en el desarrollo activo, lo que se conoce como Walk the Board. Aunque es indirecta, sirve de recordatorio periódico al equipo para que se centre primero en la entrega del software y en cómo podemos pasar los elementos de trabajo a producción.
• En una reunión semanal de la empresa mostramos brevemente cómo habíamos cambiado nuestro enfoque de la implantación de software. Por cierto, esto surgió por casualidad, pero era una oportunidad que merecía la pena aprovechar(Smell of Success).
• Empezamos a capturar y comunicar métricas en torno al número de implantaciones en producción.
• Hemos introducido algunos circuitos de retroalimentación para facilitar el flujo de información en torno a las implantaciones:
• Notificaciones de Slack: envío de información sobre compilaciones fallidas o despliegues satisfactorios. De este modo, los desarrolladores no tenían que buscar el estado de sus cambios, sino que estos llegaban a ellos.
• Notas de la versión: empezamos a anunciar internamente los cambios orientados al cliente a medida que se iban introduciendo. Esto ayudó a generar interés y debate en torno a las nuevas funciones en toda la empresa.
• Monitorización: algo que aún no hemos resuelto del todo, pero seguimos experimentando con la monitorización y con mejores formas de recabar información de nuestros sistemas de producción.

Entonces, ¿dónde estamos ahora?

Actualmente estamos desplegando a producción unas 15 veces por semana, un buen ritmo sostenible para nuestro equipo de tamaño. Terminamos moviendo aproximadamente 30 proyectos a Snap CI. Creamos pipelines de CD para una variedad de aplicaciones; gemas Ruby, paquetes Elixir, sitios estáticos alojados en AWS, aplicaciones web en Heroku y otras alojadas en Kubernetes. Todos los miembros del equipo asumen la responsabilidad de garantizar que un cambio en el que están trabajando se despliegue en producción y trabajan estrechamente con otros miembros del equipo para probar la funcionalidad relevante. Cada vez dependemos más de las pruebas automatizadas, los cambios de funciones y la compatibilidad con versiones anteriores, temas que han tenido un gran protagonismo en nuestras retrospectivas.

Como nota al margen, Snap CI no estuvo a la altura de las expectativas, pero incluso esto generó algunos aspectos positivos. Después de experimentar varios problemas, empezamos a invertir en el uso de Docker para CI con el fin de aislar y controlar el entorno de compilación. Esto tuvo muchos efectos en cadena, como el uso de Docker en el desarrollo y la transición hacia Kubernetes. También redujo nuestra dependencia de nuestra elección de la herramienta CI/CD que pronto se convirtió en muy importante cuando Snap CI anunció que iba a desaparecer. Afortunadamente, ahora estamos en una posición mucho mejor para entender lo que necesitamos, por lo que estamos en el proceso de pasar a Buildkite(¡otro artículo para otro momento!).

Esperamos que esto le dé una idea de cómo continuamos la transición hacia la Entrega Continua y los patrones que nos ayudaron. Nuestro enfoque sigue evolucionando a medida que aprendemos y reconocemos que aún nos queda camino por recorrer. Resumir todo ese esfuerzo en cuatro pasos sin duda simplifica demasiado, llegar a donde estamos ahora llevó muchos meses incluso para nuestro pequeño equipo. Este viaje nos ha recordado que un cambio así no se produce de la noche a la mañana, sino que requiere muchos pequeños pasos en la dirección correcta.

Otros recursos útiles

Linda Rising - Mitos y patrones del cambio organizativo
Entrega continua - Jez Humble y Dave Farley
Entrega Continua - De la pobreza a la riqueza - Hibri Marzook
Desarrollo basado en troncos

Referencia de patrones de cambio

Parafraseando ligeramente el libro, he aquí una selección de los patrones que he mencionado antes:

Pasos de bebé - Da un pequeño paso cada vez hacia tu objetivo.
Involucra a todo el mundo - Todo el mundo debe tener la oportunidad de hacer su propia contribución.
Planta las semillas - Aprovecha todas las oportunidades que puedas para despertar el interés por una idea.
Simplemente hazlo - No esperes al momento perfecto, en lugar de eso da el primer paso de bebé y empieza a aprender.
Elige tus batallas - Centra tus esfuerzos en los problemas más acuciantes.
Prueba - Cuando haya reticencia a comprometerse con una idea, sugiere un experimento durante un breve periodo.
Llamada de atención - Señala los problemas que crean la necesidad de un cambio.
Pide ayuda - Busca personas y recursos que te ayuden en tus esfuerzos y fomenten la participación.
Relaciones públicas persistentes - Mantén la nueva idea delante de todo el mundo, promuévela constantemente de diversas maneras.
Olor a éxito - Cuando tus esfuerzos produzcan un resultado positivo visible, trátalo como un momento de enseñanza.

‍