Cómo gestiona DoorDash los lanzamientos para móviles

La publicación periódica de actualizaciones en App Store y Play Store es más compleja de lo que cabría esperar, especialmente para los equipos a gran escala y más aún cuando hay varias aplicaciones que publicar. Hay tantas formas de abordar las complejidades de la publicación que no hay dos equipos que lo hagan todo de la misma manera.

Es interesante ver cómo trabajan otros equipos. Discernir las similitudes y diferencias entre equipos puede ayudar a revelar nuevos enfoques potencialmente valiosos. Con ese espíritu, y con una experiencia de seis años en los procesos de lanzamiento de las aplicaciones para consumidores de DoorDash y Caviar, he aquí un resumen de alto nivel de la gestión de lanzamientos móviles de DoorDash.

Nota: En DoorDash, enviamos múltiples aplicaciones Android e iOS y cada equipo maneja los lanzamientos de manera diferente. Este artículo se centra en el equipo de iOS de DoorDash y sus procesos de lanzamiento.

Visión general del ciclo de lanzamiento

A grandes rasgos, nuestros ciclos de publicación son similares a los de muchas otras empresas. He aquí un rápido vistazo a cómo gestionamos las cosas: 

1. Enviamos una nueva versión de la aplicación cada semana, lo que significa que tenemos un corte de lanzamiento semanal.
2. Las pruebas comienzan cuando se corta una versión. En ese momento, tenemos hasta una semana para corregir cualquier regresión crítica, lo que hacemos mediante la selección de correcciones en la rama de lanzamiento.
3. Una vez finalizadas las pruebas y las correcciones, enviamos la aplicación para su revisión en el App Store, preferiblemente a mediados de semana, para tener un margen de seguridad ante posibles rechazos o plazos de revisión inesperadamente largos.
4. Una vez aprobada, la compilación espera su publicación hasta el final de la semana.
5. El día del lanzamiento, comenzamos una distribución escalonada al 1% de los usuarios para asegurarnos de que no surgen otros problemas importantes que pudieran haberse pasado por alto durante las pruebas.
6. Tras supervisar de cerca el estado de la versión, aceleramos el despliegue a todos los usuarios el tercer día.
7. En este momento, ya se está trabajando en el lanzamiento posterior, así que es cuestión de enjuagar y repetir.

Las siguientes secciones profundizan un poco más en nuestros procesos, sobre todo en lo que respecta a la colaboración y los aspectos humanos de nuestros procesos.

Responsabilidades de gestión de la publicación

Un pequeño equipo de voluntarios se va turnando en la gestión de las versiones y en la asunción de las responsabilidades de los gestores de versiones. Cada gestor de versiones se encarga de garantizar que la versión actual se lanza sin problemas y que la siguiente pasa la aprobación del App Store antes de su fecha de lanzamiento prevista.

Mantenemos deliberadamente un número relativamente bajo de gestores de versiones. Tenemos suficientes gestores para repartir la carga, pero no tantos como para que nadie pierda la práctica. Mantener el número bajo control ayuda a que las decisiones sean coherentes, sobre todo en los inevitables juicios de valor que pueden producirse. Los gestores no sólo se mantienen al día de los cambios y mejoras recientes en los procesos, sino que participan en la decisión de cómo deben cambiar esos procesos.

Gestión de la comunicación

Para mantener una comunicación clara y organizada a lo largo de las versiones y los lanzamientos, creamos un canal de Slack específico para cada versión, por ejemplo #ios-release-5-0-0. Esto centraliza las actualizaciones de estado y las conversaciones específicas de cada versión en un solo lugar. Esto centraliza las actualizaciones de estado y las conversaciones específicas de la versión en un solo lugar, lo que reduce el ruido en otros canales compartidos y facilita la búsqueda de detalles de una versión anterior si es necesario.

El canal Slack dedicado es especialmente útil cuando se producen revisiones. Dado que tenemos un calendario semanal de lanzamientos, el envío de una revisión para un problema en producción significa que hay dos lanzamientos distintos en curso simultáneamente. Aislar la comunicación de cada versión en su propio canal evita confusiones. Por ejemplo, en el ejemplo de la versión 5.0.0, todo lo relacionado con la revisión de la versión 5.0.1 se trataría en #ios-release-5-0-0, mientras que los asuntos relacionados con la próxima versión 5.1.0 se tratarían en #ios-release-5-1-0.

Pruebas de las versiones candidatas

Nuestras aplicaciones han crecido tanto que es imposible que una sola persona, o incluso unas pocas, se encargue por completo de las pruebas de versiones candidatas. El equipo dedicado exclusivamente al control de calidad de alto nivel tampoco puede gestionar fácilmente las intensas pruebas de regresión semanales. Teniendo en cuenta el volumen y el ritmo de los cambios continuos y el desarrollo de nuevas funciones en toda la aplicación, es difícil garantizar que se prueban las cosas correctas, y que se prueban correctamente. Las personas que crean las funciones y realizan los cambios son las más indicadas para saber qué hay de nuevo, qué es diferente y cómo probarlo todo correctamente.

Por eso nuestras pruebas de versiones candidatas se basan en un grupo de ingenieros que llamamos "propietarios de componentes". Cada uno de ellos es responsable de probar su propio componente -una característica o área del producto- en la versión candidata y de corregir o delegar la corrección de cualquier regresión detectada durante las pruebas. Por ejemplo, el equipo de inicio de sesión es responsable de realizar las pruebas relacionadas con el componente de inicio de sesión de la aplicación. Cada propietario de componente tiene pruebas específicas que debe ejecutar antes de aprobar el componente. Y todos y cada uno de los componentes deben ser aprobados antes de que la versión pueda someterse a revisión.

Por supuesto, asegurarse de que todos los propietarios de componentes han dado su visto bueno antes de la presentación y averiguar quién está todavía probando puede ser complicado. Utilizamos una plataforma móvil de gestión de versiones llamada Runway para facilitar la colaboración a lo largo de la semana. Captura el estado actual de las pruebas de componentes y también puede recordar automáticamente a los propietarios de componentes a través de Slack que completen sus pruebas.

Gestión de regresiones y hotfixes

Aunque nos esforzamos por que los lanzamientos sean fluidos (probar, aprobar y lanzar), obviamente no es posible el 100% de las veces. A veces detectamos regresiones durante las pruebas que hay que corregir antes de lanzar la aplicación. Dado que lleva tiempo averiguar cuál es la causa de un error y que, para corregirlo, hay que modificar el código (lo que supone un riesgo al final del ciclo), es importante realizar las pruebas de versiones candidatas lo antes posible durante la semana. Así tenemos tiempo suficiente para encontrar la solución correcta a la regresión y probar a fondo la corrección para asegurarnos de que nuestros cambios no rompen algo más. Dada la escala y la naturaleza de lo que construimos en DoorDash, incluso los pequeños problemas pueden tener un gran impacto, por lo que abordamos las regresiones y hotfixes con rigor y cuidado.

Si el propietario de un componente detecta una regresión durante las pruebas de la versión candidata, trabaja con su equipo para solucionar el problema y, a continuación, desarrolla una solución en nuestra rama principal mediante una solicitud de extracción periódica. Una vez fusionada la corrección, puede ser apta o no para ser transferida a la rama de lanzamiento. Debido a que los cambios que llegan tarde son tan arriesgados, no podemos simplemente permitir que todo entre en la versión. Tenemos requisitos estrictos que deben cumplirse antes de que cualquier cambio pueda añadirse a una versión. Por ejemplo, permitimos la corrección de regresiones o nuevos errores que tengan un efecto medible en la experiencia del usuario, pero no permitimos la integración de código para corregir errores menores que no afecten al usuario, y desde luego no utilizamos este proceso para introducir nuevas funciones que podrían no haberse incluido en la versión final. Hemos desarrollado un flujo para facilitar la escalada de correcciones para su posible inclusión en una versión; los equipos envían solicitudes de corrección, incluyendo explicaciones y pruebas, que luego son revisadas por el gestor de versiones.

Después del lanzamiento, el proceso para crear un hotfix es similar al utilizado para solicitar un cherry-pick en el ciclo, salvo que los criterios para permitir un hotfix después del lanzamiento son mucho más estrictos. Crear una revisión requiere mucho más trabajo y podría afectar a la versión normal que le sigue de cerca. Si detectamos un error en una fase tardía del ciclo de lanzamiento (por ejemplo, entre el momento en que la aplicación se somete a revisión y su lanzamiento), la decisión sobre su corrección dependerá de los mismos criterios estrictos utilizados para las revisiones posteriores al lanzamiento. Aunque la actualización aún no sea pública, puede estar a la espera de revisión o incluso ya aprobada; para aplicar una corrección, tendríamos que rechazar la compilación y volver a enviar la aplicación. Dado que esto podría retrasar el lanzamiento, evaluamos caso por caso si la corrección está justificada y cómo abordarla. Podríamos, por ejemplo, rechazar la compilación, aplicar una corrección y volver a enviarla, o dejar que el lanzamiento se produzca según lo previsto y aplicar inmediatamente después una corrección urgente. Otra posibilidad es determinar que el fallo no es lo bastante grave como para justificar una revisión, y enviarlo para que se corrija en el siguiente ciclo de publicación.

Seguimiento de las implantaciones

Después del lanzamiento, confiamos en que los propietarios de los componentes y sus equipos estén atentos a cualquier problema que pueda surgir en sus áreas de responsabilidad. Cada equipo tiene un conjunto único de métricas clave que controlan y supervisan, por lo que están mejor equipados para entender qué puede ir mal con sus componentes en la nueva versión.

Pero los gestores de versiones no están completamente libres de culpa. Deben vigilar medidas de salud de más alto nivel, como la tasa de fallos de la nueva versión y cualquier problema de tendencia. Utilizamos Sentry para hacer un seguimiento de los fallos de las aplicaciones. Dado que podemos integrarlo con Runway, podemos crear una única fuente de verdad para observar de cerca el estado de las aplicaciones. Si un gestor de versiones detecta algo inusual, puede delegar en los propietarios de componentes para que examinen a fondo el problema y realicen las correcciones necesarias. Pero si no surgen problemas, podemos pasar automáticamente a un despliegue completo.

Conclusión

Como se describe aquí, la publicación de aplicaciones móviles a gran escala requiere bastante trabajo y coordinación. Mantener los lanzamientos dentro del calendario requiere un esfuerzo que implica a las partes interesadas de muchos equipos para probar y salvaguardar la calidad; centralizar el control con gestores de lanzamientos garantiza que el proceso se ejecute de forma coherente y eficiente. La configuración descrita aquí nos permite mantener una cadencia de publicación semanal en varias aplicaciones, al tiempo que se mantiene una alta calidad y los miembros del equipo están contentos.