¿El tamaño del equipo o de la aplicación afecta el proceso de lanzamiento? Bueno, eso depende. Imaginemos una startup con un pequeño equipo. En este caso, el equipo suele crear una función y luego simplemente la lanza. Ahora imaginemos un gran proyecto, por ejemplo una aplicación bancaria, con muchos equipos trabajando en él.

En este caso, probablemente debería haber un proceso, ciclos de lanzamiento y tal vez algo de burocracia. Sin eso, habrá caos.

Entonces, ¿cuándo queda claro que es momento de configurar dicho proceso para su aplicación?

En este artículo, compartiré mi experiencia en la implementación de Release Train para la aplicación Dodo Pizza (Android e iOS) y los problemas que enfrentamos que hicieron que nuestro equipo implementara Release Train.

Si eres el líder de equipo/líder técnico de un proyecto de Android o iOS que está creciendo rápidamente y aún no has gestionado el proceso de lanzamiento, espero que nuestra experiencia te ayude.

Como solía ser

En 2021, ya estábamos utilizando un enfoque de desarrollo basado en troncales (TBD) en nuestros equipos. Cubrimos el código con alternancia de funciones, tareas descompuestas y ejecutamos pruebas unitarias y de interfaz de usuario. Nuestras ramas de funciones no duraron mucho y teníamos CI funcionando.

El proceso de lanzamiento fue muy simple: quien estaba listo para implementar su función, la implementó.

Escenario ideal

Así es aproximadamente cómo se veía el flujo de trabajo de nuestra sucursal. Varios equipos (gris, azul, naranja y verde) trabajaron en diferentes funciones. Como estábamos trabajando de acuerdo con TBD, cada característica podría pasar por varias ramas consecutivas.

Por ejemplo, el equipo gris hizo su función en 4 pasos, los equipos azul y naranja hicieron la suya en 1 paso y el equipo verde hizo la suya en 2 pasos.

Cuando un equipo terminaba una función, podía implementar una versión. Por ejemplo, si el equipo azul terminó una función, podrían lanzarla. Luego, el equipo naranja terminaría una función y realizaría otra versión.

Teníamos la fluidez perfecta, como parecía entonces. Funcionó muy bien hasta cierto punto, pero todo lo bueno llega a su fin.

Algo salió mal: difícil, abarrotado e impredecible

Mamut

El primer problema que encontramos fue que las versiones comenzaron a acumular muchas funciones y se volvieron demasiado grandes.

Los equipos no siempre quisieron lanzar sus funciones de inmediato. El proceso de liberación y regresión llevó mucho tiempo y duró entre 3 y 4 días. Entonces, si su función era pequeña y no urgente, no siempre podía publicarla usted mismo porque probablemente otro equipo haría un lanzamiento pronto y se incluiría en ese lanzamiento. Aproximadamente se veía así:

Se trataba de un acuerdo bastante frágil, especialmente cuando el número de equipos empezó a crecer. Muchos equipos desarrollaron muchas funciones pequeñas y el volumen total de código nuevo en cada nueva versión se volvió enorme. Cuando alguien lanzó su gran característica, tuvo que lanzar todo un mamut junto con ella.

Las liberaciones gigantescas resultaron en:

• regresión retrasada;

• mayor riesgo de errores de regresión;

• mayor riesgo de sufrir un error en producción.

Necesitábamos hacerlo de modo que incluso si el equipo azul y naranja del ejemplo no quisiera realizar el lanzamiento, el lanzamiento se realizaría de alguna manera.

Cuellos de botella

Cada equipo es único y cada característica es diferente. A veces, las cosas sucedían de tal manera que varios equipos terminaban sus funciones aproximadamente al mismo tiempo. En este caso, hubo muchos “espérame, lo fusionaré mañana por la mañana, ¡lo prometo!” dando vueltas.

Al final, estos cuellos de botella dieron como resultado:

• lanzamientos que se convierten en mamuts;

• lanzamientos retrasados que afectan negativamente los planes del equipo de lanzamiento, especialmente si se satisficieron las necesidades de todos los demás.

Necesitábamos hacer 2 cambios cruciales:

1. El equipo de liberación no debería necesitar esperar a nadie;

   
   

2. Todos los demás equipos deberían saber cuándo se espera el próximo lanzamiento.

Falta de previsibilidad

Imagínese, el equipo azul creó una pequeña característica y esperaba que el equipo naranja la lanzara pronto. Pero algo salió mal y el equipo naranja tampoco lanzó el lanzamiento debido a algunos problemas propios.

Como resultado, el equipo azul le dijo a la empresa que la función estaría en producción pronto, pero resultó que no fue lo suficientemente pronto. Como resultado, es imposible predecir cuándo estará en producción la función.

Esto no quiere decir que el equipo azul sea irresponsable. Si tienen una característica muy importante o urgente, por supuesto la publicarán ellos mismos. Pero en otros casos, no hay forma de saber exactamente cuándo la función estará disponible para los usuarios.

Como puedes imaginar, experimentábamos este tipo de problemas con bastante frecuencia. Necesitábamos poder saber exactamente cuándo los clientes pondrían una función en producción, independientemente de su tamaño o urgencia. Los tres problemas (liberaciones gigantescas, cuellos de botella y falta de previsibilidad) están estrechamente relacionados y se complementan entre sí.

Sin embargo, probablemente el más fundamental e importante de todos ellos es la falta de previsibilidad. Genera otros problemas.

Tren de liberación

Ya hemos tenido suficiente; Ya era hora de hacer un cambio. Se suponía que el Tren de Liberación nos ayudaría a lograrlo.

El término Release Train significa cosas diferentes: un proceso de lanzamiento programado o un equipo dedicado que gestiona el proceso de lanzamiento. Aquí vamos a hablar sobre el proceso de lanzamiento programado.

Me gusta la forma en que Martin Fowler describe Release Train en el artículo " Patrones para administrar ramas de código fuente " y la definición dada por Thoughtworks en su radar tecnológico (tal vez también pertenezca a Martin).

Así es como hemos definido Release Train para nosotros mismos:

Release Train es el proceso de coordinación de lanzamientos entre equipos. Todos los lanzamientos se realizan según un cronograma fijo, independientemente de si las funciones están listas o no. El tren no espera a nadie. Si llegas tarde, tendrás que esperar al siguiente.

Analicémoslo con un par de ejemplos utilizando nuestros equipos codificados por colores.

Resolviendo el problema del mamut

La liberación del tren ocurre según lo programado y no depende de quién haya fusionado qué en la rama principal. En el siguiente ejemplo, se publicarán las funciones de los equipos azul y naranja. El resto esperará el próximo tren. Podríamos esperar un poco más, pero entonces obtendríamos un mamut.

Resolver cuellos de botella

Al mismo tiempo, Release Train nos ayuda a planificar nuestro trabajo de manera más eficiente. Digamos que el equipo azul originalmente planeó terminar una función más tarde. Pero como todos conocen la fecha de lanzamiento, pueden reorganizar ligeramente sus planes para finalizar la función antes.

O, por el contrario, pueden darse cuenta de que definitivamente no llegarán a tiempo al siguiente tren y, por lo tanto, podrán terminar la función de forma segura porque conocen el horario completo.

En el siguiente ejemplo, el equipo azul quería llegar al lanzamiento y fusionar todos sus cambios antes del lanzamiento. De lo contrario, podría haber habido un cuello de botella.

Lo más importante es que Release Train nos brindó previsibilidad por diseño .

Estos ejemplos pueden parecer obvios para algunos, pero resolvimos los problemas a medida que surgieron. Cuando no hubo problemas con los lanzamientos, no nos molestamos en usar Release Train. Cuando los problemas se acumularon, nos dimos cuenta de que había llegado el momento.

Cómo implementar el tren de liberación en su equipo

Lo primero que hicimos fue escribir un RFC . Un RFC se refiere tanto al proceso en sí como al documento de diseño que muchas empresas utilizan antes de empezar a trabajar en un proyecto. Algunos usan RFC específicamente, otros usan ADR y otros simplemente los llaman por el término más genérico Design Doc.

En Dodo Engineering utilizamos tanto RFC como ADR.

Nuestro proceso RFC se veía así:

1. Redactamos un documento RFC;

   
   

2. lo discutimos en un grupo pequeño, recopilamos comentarios e hicimos ajustes;

   
   

3. luego el RFC fue comunicado a un grupo más amplio;

   
   

4. luego lo implementamos;

   
   

5. después de eso, recopilamos comentarios, realizamos un seguimiento de las métricas y evaluamos los resultados.

La estructura del documento RFC para nuestro Release Train fue la siguiente:

• descripción del proceso del Tren de Liberación;

• qué equipos están involucrados, qué están haciendo;

• cuál será el horario;

• métrica.

En la redacción del RFC nos basamos en la experiencia de otras empresas:

• SkyScanner
• nube de sonido
• monzó
• Facebook

Primera implementación

Primero, se nos ocurrió este proceso:

• lanzamiento cada semana;

• crear una rama de lanzamiento el miércoles por la mañana;

• completar la regresión y enviar la aplicación para su revisión el viernes;

• comience a implementar el lanzamiento el lunes.

• Equipo de lanzamiento:

  • 1 desarrollador de iOS y 1 de Android de uno de los equipos destacados;

  • 2 ingenieros de control de calidad.

    
    

• crear una nueva rama de lanzamiento el miércoles;

• Haga un cronograma con un trimestre de anticipación, indicando cuándo es el turno de lanzamiento de cada equipo. Después del cuarto nos juntamos y ampliamos el horario.

Esquemáticamente, nuestro tren de liberación se veía así:

No todo salió bien

Después de un mes, quedó claro que, aunque la primera experiencia fue estupenda,

• Fue realmente difícil hacer una regresión cada semana y terminar el viernes;

• No había tiempo para correcciones y, a veces, ocurrían.

En 2021, nuestra prueba de regresión solía tardar entre 3 y 4 días en promedio. Logramos acortarlo a 2 o 3 días en 2022, pero a veces superaba ese plazo. Seguimos cubriendo casos de regresión con pruebas e2e, pero aún no teníamos una cobertura del 100%. Tuvimos aproximadamente un 70% y un 60% de cobertura de casos de regresión en cada plataforma, respectivamente.

La conclusión de esto es que siempre que tenga pruebas de regresión que tarden unos días en completarse, probablemente será incómodo ejecutar un ciclo de lanzamiento cada semana.

La respuesta final

Terminamos pasando a ciclos de lanzamiento de 2 semanas y Release Train ahora se ve así:

• liberar cada 2 semanas;
• crear una rama de lanzamiento el miércoles por la mañana;
• retroceder y enviar la aplicación para su revisión el viernes;
• comience a implementar el lanzamiento el lunes.

• Equipo de lanzamiento:

  • 1 desarrollador de iOS y 1 de Android de uno de los equipos destacados;

  • 2 ingenieros de control de calidad.

    
    

• Haga un cronograma con un trimestre de anticipación, indicando cuándo es el turno de lanzamiento de cada equipo. Después del trimestre, juntaos y ampliad el horario.
• despliegue el lanzamiento gradualmente;
• hacer las revisiones si es necesario, ahora que tengamos tiempo para ellas;
• una semana después, el miércoles, cree una nueva rama de lanzamiento.

Así es como se ve el proceso si todo va según lo planeado:

Todo parece un ciclo semanal, excepto que queda mucho tiempo para posibles correcciones. Así es como se verá en el caso de pruebas de regresión extendidas:

Tampoco es gran cosa; Todavía hay tiempo incluso para revisiones.

¿Cómo afectó el nuevo proceso a la previsibilidad?

El principal objetivo para nosotros era aumentar la previsibilidad . Se puede dividir en dos partes:

1. ¿Cuándo se publicará la solicitud?
2. ¿En qué versión entrará mi función?

Respondimos a la pregunta "¿Cuándo habrá un lanzamiento?" implementando el proceso Release Train. Ahora, cada equipo podrá responder la pregunta "¿en qué versión terminará mi función?" de forma independiente en el momento en que planifican y evalúan la característica.

Antes, era imposible decirlo con certeza porque otro equipo podría hacer el lanzamiento o no. Ahora, todo depende sólo de la propia planificación de ese equipo.

Para confirmar esto aún más, realizamos encuestas entre desarrolladores móviles, control de calidad y gerentes de producto, donde, junto con otras preguntas, preguntamos:

• ¿Cuándo es el próximo lanzamiento? (El 100% respondió a esta pregunta).

• ¿Te ayudó Release Train a planificar tu trabajo en equipo? (El 75% respondió afirmativamente, pero algunos predijeron perfectamente su trabajo incluso sin Release Train).

Release Train también nos ha ayudado con congelaciones de código y congelaciones de versiones. Tuvimos varios de ellos, además de Nochevieja (por ejemplo, el 1 de septiembre y algunos días festivos). Ahora, con Release Train, no tenemos que ajustarnos a estas fechas creando ramas de lanzamiento, pruebas de regresión y todo eso. Los lanzamientos funcionan según lo previsto; Los abrimos en las tiendas más tarde.

Impacto en las métricas

Más allá de simplemente resolver problemas, también medimos métricas. Echemos un vistazo a los principales.

Tiempo de espera

La primera métrica importante que medimos fue el compromiso del plazo de entrega para el lanzamiento .

Así es como se ve el gráfico. Marqué el punto en el que iniciamos el proceso de Release Train con una flecha.

El gráfico muestra que el tiempo de entrega se redujo a alrededor de seis días. ¿Seis días es un tiempo largo o corto?

Puntos de referencia de Google

Hay puntos de referencia de Google para esta métrica , pero es principalmente para el backend. Según su escala, distinguen los siguientes grupos:

• Élite: menos de una hora
• Alta: 1 hora a 1 semana
• Mediano: 1 semana a 6 meses
• Baja: 6 meses o más

Creo que, para las aplicaciones móviles estándar, el plazo de entrega idealmente debería apuntar a la mitad del ciclo de lanzamiento. Esto equivale a fusionar una tarea en la rama principal todos los días. Dicho esto, si el ciclo de lanzamiento es de 14 días, el plazo de entrega debería ser de 7 días .

Errores por regresión

Otra métrica que rastreamos es la cantidad de errores por regresión. Describe qué tan estable es el candidato de lanzamiento. Si la versión anterior fue hace mucho tiempo, entonces probablemente creamos una gran cantidad de código nuevo que podría contener una gran cantidad de errores, y podríamos dedicar más tiempo a la regresión y las correcciones.

En un momento, esta métrica se redujo a tres errores. Las cifras específicas no son tan cruciales, pero en general se puede ver que la tendencia ha bajado.

Más métricas

Analizaré brevemente qué métricas también se monitorearon como parte del Release Train.

• Sin accidentes. Siempre estamos atentos a esta métrica. Existía la hipótesis de que disminuiría debido a nuestros intentos de ajustar la regresión a un marco temporal más ajustado. Bueno, no pasó ninguna caída.

• Nos preguntamos si los lanzamientos frecuentes (semanales) tendrían un impacto en la pérdida de clientes y en la eliminación de la aplicación. Como resultado, no detectamos ningún impacto.

Implementar, mejorar

Nos gusta el proceso actual porque creemos que ha logrado sus objetivos. También sabemos cómo mejorarlo aún más:

• Seguimos trabajando en la automatización de la regresión para hacerla más sencilla y rápida.

• Hasta ahora hemos omitido la parte sobre automatización del trabajo (scripts para bifurcaciones), pero esto también sería un gran punto de crecimiento en el futuro.

• Nuestra aplicación funciona en 20 países y necesitamos traducirla a muchos idiomas diferentes. Existe un servicio interno para esto, pero los desarrolladores aún deben participar en este proceso manualmente antes del lanzamiento. Automatizar este proceso podría potencialmente mejorar aún más el ciclo de lanzamiento.

Resumen

Si bien éramos relativamente pequeños, no necesitábamos un tren de liberación. Cuando nos enfrentamos al hecho de que no podíamos predecir los lanzamientos, su tamaño y número, decidimos implementar Release Train. Al principio, probamos ciclos de lanzamiento semanales, pero debido a las regresiones que consumían mucho tiempo, tuvimos que cambiar a ciclos de lanzamiento de dos semanas. Hemos estado viviendo de esta manera desde entonces.

Ahora tenemos previsibilidad de los lanzamientos y las métricas muestran una dinámica positiva. Planeamos aumentar la cobertura de casos de regresión con pruebas e2e, automatizar el proceso de trabajo con sucursales y optimizar el proceso de traducción.

Espero que este artículo y nuestra experiencia te ayuden, especialmente si ya has enfrentado problemas similares y te hicieron pensar en el proceso de lanzamiento.

Muchas gracias por leer mi artículo. Espero que lo hayan disfrutado. Si tienes alguna pregunta o sugerencia, escríbeme en los comentarios y ¡me aseguraré de leerla!

Y Sigueme en Twitter . Normalmente publico sobre desarrollo de Android e ingeniería de software en general.

También publicado aquí