Pare la línea o bombee su tubería, yo

Si sus lanzamientos son rápidos, automatizados y confiables, no puede leer este artículo.

Anteriormente, nuestro proceso de lanzamiento era manual, lento y con errores.
Fallamos el sprint después del sprint, porque no tuvimos tiempo de hacer y presentar las características para la próxima Revisión de Sprint. Odiamos nuestros lanzamientos. A menudo duraban de tres a cuatro días.

En este artículo, describiremos la práctica Stop the Line, que nos ayudó a centrarnos en solucionar problemas de diseño. En solo tres meses, logramos aumentar la tasa de implementación en 10 veces. Hoy, nuestro despliegue está totalmente automatizado, y el lanzamiento del monolito lleva solo de 4 a 5 horas.

Detén la línea. Práctica inventada por el equipo.

Recuerdo cómo se nos ocurrió Stop the Line. En una retrospectiva general, discutimos lanzamientos largos que nos impidieron alcanzar objetivos de sprint. Uno de nuestros desarrolladores sugirió:

- [Sergey] Limitemos el volumen de lanzamiento. Esto nos ayudará a probar, corregir errores e implementar más rápido.
- [Dima] ¿Podemos introducir una restricción en el trabajo en progreso (límite de WIP)? Por ejemplo, tan pronto como hayamos completado 10 tareas, detenemos el desarrollo.
- [Desarrolladores] Pero las tareas pueden ser diferentes en tamaño. Esto no resolverá el problema de los lanzamientos grandes.
- [I] Vamos a introducir una restricción basada en la duración del lanzamiento, y no en la cantidad de tareas. Detendremos el desarrollo si el lanzamiento lleva demasiado tiempo.

Decidimos que si el lanzamiento dura más de 48 horas, entonces encendemos la luz intermitente y detenemos el trabajo de todos los equipos sobre las características comerciales del monolito. Todos los equipos que trabajan en el monolito deben detener el desarrollo y centrarse en impulsar el lanzamiento actual en la venta o eliminar las razones que retrasaron el lanzamiento. Cuando el lanzamiento está atascado, no tiene sentido crear nuevas funciones, ya que seguirán llegando pronto. En este momento, está prohibido escribir código nuevo, incluso en ramas separadas.

También presentamos "Stop the Line Board" en un simple rotafolio. En él, escribimos tareas que ayudan a impulsar la versión actual o ayudan a evitar las razones de su retraso.

Por supuesto, Stop The Line no es una decisión fácil, pero esta práctica es un paso importante hacia la entrega continua y DevOps genuinos.

Liberemos rápidamente: del problema a la práctica adaptada Stop the line

El dolor de las liberaciones lentas. ¿Por qué son tan largos? Análisis

La programación extrema (XP) tiene una regla de oro: si algo duele, hágalo con la mayor frecuencia posible. Nuestros lanzamientos siempre han sido un dolor. Pasamos varios días para implementar el entorno de prueba, restaurar la base de datos, ejecutar las pruebas (generalmente varias veces), descubrir por qué se cayeron, corregir errores y, finalmente, liberar.

El sprint dura 2 semanas, y el lanzamiento dura tres días. Para poder lanzarlo antes de Sprint Review el viernes, debes comenzar el lanzamiento el lunes de una buena manera. Esto significa que estamos trabajando en el objetivo de correr solo el 50% del tiempo. Y si pudiéramos lanzar todos los días, entonces el período productivo de trabajo crecería al 80-90%.

Nuestro lanzamiento promedio usualmente tomó de dos a tres días. Al principio, seis equipos trabajaron en el código en la rama de desarrollo general (y con el crecimiento de la compañía, el número de equipos aumentó a nueve). Justo antes del lanzamiento, ramificamos la rama de lanzamiento. Mientras esta rama se prueba y regresa, los equipos continúan desarrollándose en la rama de desarrollo general. Antes de que la rama de lanzamiento alcance las ventas, los equipos escribirán bastante código.

Cuantos más cambios en el incremento, más probable es que los cambios realizados por diferentes equipos se afecten entre sí, lo que significa que cuanto más cuidadosamente se debe probar el incremento, y más tiempo llevará liberarlo. Este es un ciclo de auto-refuerzo (ver Fig. 2). Cuantos más cambios se produzcan en la versión (versión "caballo"), mayor será el tiempo de regresión. Cuanto más largo es el tiempo de regresión, más tiempo entre lanzamientos y más cambios realiza el equipo antes del próximo lanzamiento. Lo llamamos "los caballos dan a luz a los caballos". El siguiente diagrama CLD (Diagrama de bucle causal) ilustra esta relación:


Fig. 2. Diagrama CLD: los lanzamientos largos conducen a lanzamientos aún más largos

Automatización de regresión con comando de control de calidad

Al principio decidimos deshacernos de las pruebas de regresión manual, pero el camino hacia esto fue largo y difícil. Hace dos años, la regresión manual de Dodo IS duró una semana completa. Luego tuvimos un equipo completo de probadores manuales que probaron las mismas características en 10 países semana tras semana. No envidiarás tal trabajo.

En junio de 2017, formamos el equipo de control de calidad. El objetivo principal del equipo era automatizar la regresión de las operaciones comerciales más importantes: recibir pedidos y fabricar productos. Tan pronto como tuvimos suficientes pruebas para comenzar a confiar en nosotros, abandonamos por completo las pruebas manuales. Pero esto solo sucedió 1.5 años después de que comenzamos la automatización de regresión. Después de eso, disolvimos el equipo de control de calidad, y el equipo de control de calidad se unió a los equipos de desarrollo.

Sin embargo, las pruebas de IU tienen inconvenientes significativos. Como dependen de los datos reales en la base de datos, estos datos deben configurarse. Una prueba puede dañar los datos para otra prueba. La prueba puede fallar no solo porque parte de la lógica está rota, sino también por una red lenta o datos obsoletos en el caché. Tuvimos que hacer un gran esfuerzo para deshacernos de las pruebas de parpadeo y hacerlas confiables y reproducibles.

Un paso para detener la línea. #IReleaseEveryDay Initiative

Creamos una comunidad de ideas afines #IReleaseEveryDay y pensamos en cómo acelerar la implementación. Las primeras acciones fueron las siguientes:

• redujimos significativamente el conjunto de pruebas de IU al descartar pruebas repetidas e innecesarias. Esto redujo el tiempo de prueba en varias decenas de minutos;
• Redujimos significativamente el tiempo para configurar el entorno debido a la recuperación preliminar de la base de datos y el cifrado de datos. Por ejemplo, ahora creamos una copia de seguridad de la base de datos por la noche, y tan pronto como comienza el lanzamiento, cambiamos el entorno de prueba a la base de datos de respaldo en unos segundos.

Gracias a las soluciones anteriores, redujimos el tiempo de lanzamiento promedio, pero aún así fue molestamente largo. Es hora de cambios en el sistema.

¿Y si ...

Introdujimos la regla de que si el lanzamiento dura más de 48 horas, entonces encendemos la luz intermitente y detenemos el trabajo de todos los equipos sobre las características comerciales del monolito. Todos los equipos que trabajan en el monolito deberían detener el desarrollo y centrarse en lanzar el lanzamiento actual a la venta o eliminar las razones que retrasaron el lanzamiento.

Cuando el lanzamiento está atascado, no tiene sentido crear nuevas funciones, ya que seguirán llegando pronto. En este momento, está prohibido escribir código nuevo, incluso en ramas separadas. Este principio se describe en el artículo de entrega continua de Martin Fowler: "En caso de problemas con el diseño, su equipo debe priorizar la solución de estos problemas antes de trabajar en nuevas características".

Entourage flasher

Durante Stop the line, se enciende una luz intermitente naranja en la oficina. Cualquiera que llegue al tercer piso, donde trabajan los desarrolladores de Dodo IS, ve esta señal visual. Decidimos no volver locos a nuestros desarrolladores con el sonido de una sirena y solo dejamos una molesta luz intermitente. Así concebido. ¿Cómo podemos sentirnos cómodos cuando un lanzamiento está en problemas?

Fig. 3. Blinker Stop the Line

Equipo de resistencia y pequeño sabotaje

Al principio, a Stop the Line le gustaron todos los equipos, porque fue divertido. Todos estaban felices como niños y presentaron fotos de nuestras luces de emergencia. Pero cuando se quema 3-4 días seguidos, no se vuelve divertido. Un día, uno de los equipos rompió las reglas y subió el código a la rama de desarrollo durante Stop the Line para salvar su objetivo de sprint. Es más fácil romper una regla si te impide trabajar. Esta es una manera rápida y sucia de hacer una función comercial, ignorando un problema del sistema.

Como Scrum Master, no podía soportar las violaciones de las reglas, por lo que planteé este problema en una retrospectiva general. Tuvimos una conversación difícil. La mayoría de los equipos acordaron que las reglas se aplican a todos. Acordamos que cada equipo debe cumplir con las reglas, incluso si no está de acuerdo con ellas. Y al mismo tiempo sobre cómo puede cambiar las reglas sin esperar la próxima retrospectiva.

¿Qué no funcionó según lo previsto?

Inicialmente, los desarrolladores no se centraron en resolver problemas del sistema con la canalización de implementación. Cuando el lanzamiento se atascó, en lugar de ayudar a eliminar las causas de la demora, prefirieron desarrollar microservicios que no estaban sujetos a la regla Stop the Line. Los microservicios son buenos, pero los problemas del monolito no se resolverán por sí solos. Para resolver estos problemas, introdujimos la acumulación de Stop The Line.

Algunas soluciones fueron soluciones rápidas que ocultaron los problemas en lugar de resolverlos. Por ejemplo, muchas pruebas se repararon aumentando los tiempos de espera o agregando retransmisiones. Una de estas pruebas se ejecutó durante 21 minutos. La prueba buscó al empleado creado más recientemente en una tabla sin índice. En lugar de corregir la lógica de la solicitud, el programador agregó 3 reintentos. Como resultado, la prueba lenta se hizo aún más lenta. Cuando Stop The Line creó un equipo propietario que se centró en los problemas de las pruebas, durante los siguientes tres sprints lograron acelerar nuestras pruebas 2-3 veces.

¿Cómo fue el comportamiento de los equipos después de practicar Stop the Line?

Anteriormente, solo un equipo tenía problemas con una versión, una que respaldaba la versión. Los equipos intentaron deshacerse de este desagradable deber lo antes posible, en lugar de invertir en mejoras a largo plazo. Por ejemplo, si las pruebas en el entorno de prueba han caído, pueden reiniciarse localmente y, si las pruebas pasan, continúe con el lanzamiento. Con la introducción de Stop The Line, los equipos ahora tienen tiempo para estabilizar las pruebas. Reescribimos el código de preparación de prueba, reemplazamos algunas pruebas de IU con pruebas de API y eliminamos tiempos de espera innecesarios. Ahora casi todas las pruebas pasan rápidamente y en cualquier entorno.

Anteriormente, los equipos no participaban sistemáticamente en deuda técnica. Ahora tenemos una acumulación de mejoras técnicas que analizamos durante Stop the Line. Por ejemplo, reescribimos las pruebas en .Net Core, lo que nos permitió ejecutarlas en Docker. La ejecución de pruebas en Docker nos permitió utilizar Selenium Grid para paralelizar las pruebas y reducir aún más su tiempo de ejecución.

Anteriormente, los equipos dependían de un equipo de control de calidad para las pruebas y un equipo de infraestructura para la implementación. Ahora no hay nadie en quien confiar excepto ellos mismos. Los equipos mismos prueban y lanzan el código en Producción. Estos son DevOps genuinos, no falsos.

La evolución del método Stop the line

En una retrospectiva general de sprint, estamos revisando experimentos. En las próximas retrospectivas, hemos realizado muchos cambios en las reglas Stop the Line, por ejemplo:

• Liberar canal. Toda la información sobre la versión actual se encuentra en un canal separado de Slack. El canal tiene todos los equipos cuyos cambios están incluidos en el lanzamiento. En este canal, el comunicador pide ayuda.
• Lanzamiento de la revista. La persona responsable de la liberación registra sus acciones. Esto ayuda a encontrar las razones del retraso en el lanzamiento y descubrir patrones.
• La regla de los cinco minutos. Cinco minutos después del anuncio de Stop the Line, los representantes del equipo se reúnen alrededor de la luz de emergencia.
• Atrasos Detener la línea. Hay un rotafolio en la pared con la acumulación de Stop The Line, una lista de tareas que los equipos pueden realizar mientras la línea se detiene.
• No tenga en cuenta el último viernes del sprint. Es injusto comparar dos lanzamientos, por ejemplo, uno que comenzó el lunes y otro que comenzó el viernes. El primer equipo puede pasar dos días completos apoyando el lanzamiento, y durante el segundo lanzamiento habrá muchos eventos el viernes (Sprint Review, Team Retrospective, General Retrospective) y el próximo lunes (General y Team Sprint Planning), por lo que el equipo del viernes tiene menos tiempo para lanzamiento de soporte. El lanzamiento del viernes se detendrá más probable que el lunes. Por lo tanto, decidimos excluir el último viernes del sprint de la ecuación.
• Eliminación de la deuda técnica. Después de un par de meses, los equipos decidieron que durante la parada podrían trabajar en la deuda técnica, y no solo en acelerar el proceso de despliegue.
• Propietario Stop the Line. Uno de los desarrolladores se ofreció como voluntario para convertirse en el propietario de Stop The Line. Está profundamente inmerso en los motivos de la demora en los lanzamientos y gestiona la acumulación de Stop the Line. Cuando la línea se detiene, el propietario puede atraer a cualquier equipo para que trabaje en los elementos de la acumulación de Stop the Line.
• Post mortem. El propietario de Stop the Line tiene una autopsia después de cada parada.

Costo de perdidas

Debido a Stop the Line, no hemos cumplido varios objetivos de sprint. Los representantes comerciales no estaban muy satisfechos con nuestro progreso y formularon muchas preguntas en la Revisión de Sprint. Siguiendo el principio de transparencia, hablamos sobre qué es Stop the Line y por qué debería esperar algunos sprints más. En cada Revisión de Sprint, mostramos a los equipos y partes interesadas cuánto dinero perdimos debido a Stop the Line. El costo se calcula como el salario total de los equipos de desarrollo durante el tiempo de inactividad.

• Noviembre - 2 106 000 p.
• Diciembre - 503 504 p.
• Enero - 1 219 767 p.
• Febrero - 2 002 278 p.
• Marzo - 0 p.
• abril - 0 p.
• Mayo - 361 138 p.

Dicha transparencia crea una presión saludable y motiva a los equipos a resolver de inmediato los problemas de la tubería de implementación. Al ver estos números, nuestros equipos entienden que nada es gratis, y cada Stop the Line nos da un centavo.

Resultados

De hecho, la práctica Stop the Line convierte un ciclo de autorreforzamiento (Fig. 2) en dos ciclos de equilibrio (Fig. 4). Stop the Line nos ayuda a centrarnos en mejorar la canalización de implementación cuando es demasiado lenta. En solo 4 sprints, nosotros:

• Se lanzaron 12 versiones estables
• Se redujo el tiempo de construcción en un 30%.
• UI estabilizado y pruebas de API. Ahora transmiten todos los entornos e incluso localmente.
• Deshágase de las pruebas de flasheo
• Comenzó a confiar en nuestras pruebas.

Fig. 4. Gráfico CLD: detener el tiempo de liberación de saldos de línea

Conclusiones de Scrum Masters

Stop The Line es un excelente ejemplo de una poderosa solución inventada por los propios equipos de desarrollo. Scrum Master no puede simplemente tomar y llevar a los equipos una nueva práctica brillante. La práctica solo funcionará si los equipos mismos la idearon. Esto requiere condiciones favorables: una atmósfera de confianza y una cultura de experimentación.

Ciertamente, se necesita la confianza y el apoyo del negocio, lo cual es posible solo con total transparencia. La retroalimentación, como una retrospectiva general y regular con todos los representantes del equipo, ayuda a inventar, implementar y modificar nuevas prácticas.

Con el tiempo, la práctica de Stop the Line debería suicidarse. Cuanto más frenemos la línea, más invertimos en la canalización de implementación, más estable y rápida se vuelve la liberación, menos razones hay para detenerse. Al final, la línea nunca se detendrá, a menos que decidamos reducir el umbral, por ejemplo, de 48 a 24 horas. Pero, gracias a esta práctica, hemos mejorado mucho el procedimiento de lanzamiento. Los equipos ganaron experiencia no solo en el desarrollo, sino también en la entrega rápida de valor a los productos. Estos son DevOps genuinos.

Que sigue No lo se Quizás pronto abandonemos esta práctica. Los equipos decidirán. Pero es obvio que continuaremos avanzando hacia la Entrega continua y DevOps. Un día, mi sueño de lanzar un monolito varias veces al día se hará realidad.