Suelte el tren. Informe Yandex

Los procesos de lanzamiento en diferentes equipos de Yandex (y en cualquier gran empresa de TI) se organizan de manera similar, pero difieren en muchos detalles. Los desarrolladores móviles tienen sus propios detalles: sus lanzamientos se ven afectados por el orden de diseño en la App Store y Google Play. Desarrollador de Android Dmitry PolyakovDmpolyakov Habló sobre los procesos a su alrededor: cómo su equipo envía un tren de lanzamiento en un horario, cómo lanzar lanzamientos no programados, agregar trailers a un lanzamiento ya dejado y qué hacer para mantenerse en el camino.


- Hola a todos, soy Dmitry Polyakov, desarrollador de Android de la aplicación móvil que tomo.



Ahora en dos equipos: desarrollo de Android e iOS, 13 personas cada uno. Esto nos permite hacer muchas tareas geniales en paralelo y transferirlas rápidamente a los usuarios. En el informe contaré cómo aprendimos a trabajar con git y vivir en un repositorio.

A continuación, te diré cómo funciona nuestro ciclo de lanzamiento. Los gerentes se acercan a nosotros y nos dicen que queremos implementar esta función lo antes posible. Entonces, probablemente, cualquier gerente lo desee, así que configuramos el proceso de lanzamiento para que vayamos a la App Store y Google Play todas las semanas. También hablaré sobre las herramientas que tenemos y que le recomendaría que pruebe, son geniales.

Flujo git

Comencemos con Git Flow. Como base, tomamos el clásico Git Flow, sin embargo, ha cambiado mucho en nuestras condiciones, en nuestro equipo. También te ves, y tal vez algo de esto te convenga, pero algo no. Cada equipo tiene su propio enfoque para trabajar con git.

¿Cómo funciona con nosotros? Epic es la rama raíz de su función, para una gran funcionalidad. Para que quede más claro, veamos de inmediato el ejemplo del producto.



El gerente viene y dice: el desarrollador, háganos la funcionalidad de la lista de deseos con los productos seleccionados en la aplicación. El desarrollador comienza una nueva rama épica y la llama lista de deseos.



Además, lo descompone en tareas más pequeñas, que comienzan en el rastreador. Quizás esto esté funcionando con la red, renderizando la IU, escribiendo pruebas. Para cada característica de este tipo, comienza una tarea en el rastreador. Y tan pronto como comienza a completar la tarea, comienza la rama de características correspondiente. La desprende de la misma epopeya.

Tan pronto como termina de trabajar en una de esas características, la vierte en la épica a través de la solicitud de grupo. La solicitud de grupo es un mecanismo de este tipo cuando otros desarrolladores de su equipo verifican su código. Si no les gusta algo, entonces su código puede no alcanzar su épico, lo que significa que no será liberado hasta que llegue a un acuerdo con ellos.

Hay dos de estos revisores en nuestro equipo. Se asignan al azar. Este es un proceso automatizado, selecciona de aquellos desarrolladores que recientemente trabajaron con los mismos archivos que usted cambió en su solicitud de grupo.



Por lo tanto, resulta que varias epopeyas con su propio conjunto de características viven en el proyecto en paralelo. Una epopeya puede tener solo una característica. Esto puede suceder si queremos subir esta función a través de la solicitud de grupo a epic.



Tan pronto como se completa el trabajo en todas las características dentro de una épica, la tarea primero se deja al equipo de prueba, al equipo de control de calidad, y ellos prueban funcionalmente la rama. Una vez que encuentran errores, los edita como parte de esta epopeya. Una vez que se solucionan todos los errores, llenas esta épica para desarrollarla. Aquí, su equipo no lleva a cabo una revisión adicional del código, ya que todo el código ya se ha analizado durante la etapa de congelación de características en épica.

Nuestro desarrollo es una rama en la que visita el código ya probado, porque en la etapa épica se prueba y el código pasó por la solicitud del grupo.



Esto nos permite crear de manera segura una nueva rama de lanzamiento al comienzo del ciclo de lanzamiento. Sin temor a que haya muchos errores que aún no se han probado. Por lo tanto, estamos creando una nueva rama de lanzamiento desde el desarrollo, se está probando. Tan pronto como se prueba el lanzamiento y estamos listos para salir más allá de la puerta, esta rama se fusiona en maestra.

A veces tenemos hotfix, y hay un tipo de rama separado para ello. Esta es una versión muy corta que debe implementarse rápidamente. No tenemos tiempo para esperar tres o cuatro días para que comience el próximo ciclo de lanzamiento. Por lo general, esto es algo pequeño.

Por ejemplo, si algún tipo de error entró en producción y es muy crítico, debemos solucionarlo con urgencia. Por lo tanto, detenemos la versión actual, ejecutamos la revisión de este error y actualizamos nuestra versión. Pero la revisión no siempre es una historia sobre errores. A veces tenemos una necesidad de producto.



Por ejemplo, tan pronto como se introdujo el modo de autoaislamiento en Moscú, tuvimos una necesidad de productos para que los usuarios pudieran ordenar productos sin contacto. Ahora, al realizar un pedido en nuestra aplicación, el usuario puede seleccionar la función "Dejar en la puerta". Llega el servicio de mensajería, deja el paquete debajo de la puerta y se lo entrega sin contacto.

Con esta tarea en el hotfix también incluimos widgets tan diferentes que lo instan a quedarse en casa y ordenar los productos por mensajería. No vaya a los puntos de recogida ahora. Implementamos estas tareas a través de una revisión para poder transmitirlas al usuario lo antes posible, porque las consideramos importantes.

Cuando tenemos una revisión, la enviamos desde master. Desde el desarrollo no se puede derivar, porque en ese momento lo nuevo podría desarrollar una épica, que aún no se había lanzado. Pero no queremos llevarnos estas epopeyas a revisión, para que no nos afecten al azar y bloqueen nuestra revisión. Una vez que se completa el hotfix, lo inyectamos en master y también lo agregamos para desarrollar, ya que este código aún no existía en desarrollo.



Master es una base de código correspondiente a la última versión de la aplicación, que ahora está en la tienda del usuario. Está limpio, sin errores, porque las pruebas funcionales y de regresión ya han pasado allí, esta es una rama de respaldo.

Cuando se completa nuestro lanzamiento, también lo volvemos a desarrollar. Porque como parte del lanzamiento, se pueden encontrar errores que no se encontraron en las pruebas funcionales, y diferentes épicas pueden entrar en conflicto entre sí. Por lo tanto, también inyectamos la versión en desarrollo para que también tengamos estas soluciones en desarrollo.



Se puede hacer mucho trabajo en épica, y para mantenerse al día con el código en desarrollo, el desarrollador a veces lo agrega a su épica, para que haya menos conflictos de congelación.



Como agregamos desarrollar a épico, es necesario agregar épico por las mismas razones a su función.



En los nombres de las ramas épicas y características, tenemos un número de ticket en el rastreador de tareas. Esto es genial, porque es precisamente por el número de ticket que podemos encontrar completamente desde cualquier parte de nuestra aplicación, dentro de qué tickets cambió, quién escribió este código y para qué se escribió.



La rama de lanzamiento y revisión tiene en su nombre el número de versión de lanzamiento actual de la aplicación. Algunos equipos combinan el número de revisión con el número de versión, justificando esto con el hecho de que la revisión es algo pequeño y quizás no muy importante para el usuario. Por lo tanto, no aumentan la versión de la aplicación. No utilizamos este enfoque, porque nos llegan varios informes de fallas de los fabricantes, y queremos saber exactamente si este informe estaba en revisión o en la versión, para saber dónde buscar el problema.



Dominar y desarrollar son ramas que viven constantemente en nuestro repositorio. Una vez creado, y en vivo. Por lo tanto, se nombran tan sucintamente.

Así es como vivimos. Ahora estamos cómodos, convenientes.

Liberar tren

Pasamos a nuestros procesos de lanzamiento. Pero antes de hablar sobre los lanzamientos y cómo los construimos, hablaré sobre los roles que tenemos para apoyar el lanzamiento.

Tenemos un desarrollador de guardia que, dentro de una semana laboral, deja de ocuparse de las tareas del producto y corrige los errores de la versión actual. Si no tiene tareas para la versión actual, corregirá algunas deudas técnicas que hemos acumulado, tomará tareas del trabajo atrasado y las corregirá.

También hay un probador de servicio. También deja de probar las tareas del producto dentro de una semana laboral y verifica la versión actual. Si no tiene tareas para la versión actual, prueba lo que se ha corregido como parte de la deuda técnica.



El lanzamiento comienza el viernes. Es en este día que tenemos una fecha límite difícil. A las 18 en punto de la tarde, el probador de servicio hace clic en el botón "Iniciar liberación". Después de este momento, todo lo que se vertirá en desarrollo ya no caerá en la versión actual, porque después de hacer clic en el botón se ha creado una rama de liberación, el desarrollo se ha fusionado y no se verterá más allí.

Otro proceso importante tendrá lugar el viernes, otro elemento de la versión actual, que analizaré más adelante.



Tenemos un descanso los fines de semana, así que el segundo día de lanzamiento es el lunes. El desarrollador de turno comienza el día con un análisis. Él está mirando lo que ha cambiado en la versión actual en términos de código. Toma git diff entre la rama de lanzamiento actual y el maestro. Y con esta diferencia, observa qué componentes se han visto afectados. Puede afectar el proceso de pago o la cesta, y el trabajo con pedestales no se ve afectado.

Por lo tanto, forma una lista de varios casos que serán probados durante la prueba. Esto nos ayuda a acelerar nuestra regresión, verifique no toda la aplicación. Cuando se compila la lista, el equipo de prueba verifica la aplicación y el desarrollador de turno corrige los errores. Si tiene muchos errores, puede delegar parte a otros desarrolladores que han trabajado recientemente con estas piezas de código.



El martes, continuamos probando nuestro lanzamiento y corrigiendo errores de lanzamiento. Hacia la tarde, nuestra prueba de regresión termina y estamos listos para partir hacia la puerta. Lanzamos nuestro tren de lanzamiento, de hecho, incluso varios trenes de lanzamiento, porque recientemente ingresamos a un nuevo mercado para nosotros. También te recomiendo que intentes publicar no solo en Google Play, sino también en algunos otros. La ventaja no solo es que obtienes una nueva audiencia leal.

De alguna manera, publicamos nuestro lanzamiento y después de unas horas descubrimos que la cantidad de errores entre los usuarios ha crecido significativamente. Observamos estos errores, los analizamos y vimos que solo ocurren en dispositivos Huawei. No entendimos de inmediato lo que estaba sucediendo, pero teníamos Huawei, los probamos, encontramos un error, lo arreglamos y fuimos a actualizar.

Tan pronto como llegamos con la actualización en Google Play, vimos un gran banner que decía que debido a la situación actual en el mundo, Google Play tiene una carga muy pesada y no tienen tiempo para verificar las aplicaciones tan rápido como de costumbre. Resultó que todavía no teníamos tiempo para revisar nuestra aplicación, no llegamos a los usuarios de Google Play, pero solo se publicaron en la Galería de aplicaciones de Huawei. Y esa fue la razón por la que solo teníamos errores en Huawei. Por lo tanto, fue posible detectar y corregir un error crítico incluso antes de publicar en Google Play.

A continuación, le diré cómo se organizan las publicaciones a través de Google Play, porque tenemos una gran cantidad de usuarios allí. Y en Huawei AppGallery, recientemente nos fuimos y todavía estamos tratando de entender cómo se organiza todo allí.

No publicamos de inmediato a todos los usuarios en Google Play, por lo que algún tipo de error aleatorio no afecta a toda nuestra audiencia. Publicamos solo para todos los evaluadores que se suscriban al hecho de que pueden tener un error, pero serán los primeros en recibir nuestros cambios y lanzamientos. Además, publicamos solo el cinco por ciento de la audiencia.



El miércoles, el desarrollador de turno está viendo un nuevo lanzamiento sin fallas. Es importante para nosotros que no haya un nuevo accidente y que no haya muchos viejos. Si todo es normal, aún verifica las métricas del producto. Por ejemplo, para que el número de pedidos no disminuya en comparación con el mismo período. Si las métricas de nuestros productos y sin bloqueos son buenas, implementaremos otro 5%, un total de 10%.



El jueves, el desarrollador de turno revisa las reseñas en la tienda. De hecho, los mira el miércoles. Es cierto que el miércoles todavía tenemos una pequeña audiencia, una o dos reseñas. Pero el jueves hay más críticas para juzgar el lanzamiento. Puede haber 10-15 piezas.

¿Por qué incluso mira las revisiones si tenemos muchas métricas y gráficos? Es posible que la aplicación no se bloquee, incluso las métricas pueden estar en orden. Pero es posible que el usuario tenga fuentes o que algún filtro no funcione para él. Intentamos que el uso de la aplicación para el usuario sea lo más conveniente posible y analizar dichas revisiones, corregir errores o problemas que el usuario encuentre.

Si las revisiones están en orden, sin fallas también es normal y las métricas del producto no han disminuido, ya estamos implementando un 20%.



Y aquí comienza el viernes, el día del lanzamiento de nuestro lanzamiento. El tercer punto del que quería hablar es que el viernes completaremos el lanzamiento actual. Lo pasamos del 20% inmediatamente al 100%. Parece ser un gran salto y muy arriesgado. Pero depende del equipo y de tu audiencia.

El 20% de nuestra audiencia nos permite con una alta probabilidad de juzgar la estabilidad del lanzamiento. Y si todo está bien en un 20%, y el viernes no vimos ningún problema, entonces iremos directamente a la centésima.

Conozco los equipos que usan el truco de la vida en Google Play; tal vez él también te ayude. Puede implementar no al 100%, sino al 99.9%. Esto te dejará con un botón en Google Play para detener urgentemente el lanzamiento. Y si despliegas al 100%, este botón desaparece. Pero, como dije, en un veinte por ciento de nuestra audiencia podemos juzgar con precisión la estabilidad del lanzamiento. Por lo tanto, implementamos con calma al 100%, esto nos salva de pasos adicionales. Y luego necesitas rodar otro 0.01%.

Este es nuestro proceso, así que viajamos todas las semanas e intentamos no perdernos.


¿Qué otras herramientas tenemos para apoyar la buena vida del usuario de su lado? Estos son Actualización forzada, Actualización suave y Conmutación de funciones.



Actualización forzada: un mecanismo que bloquea el uso de la aplicación si su versión está muy desactualizada. La versión que se considera obsoleta se configura en el panel de administración del servidor. Y tan pronto como se haya cambiado el número allí, algunas aplicaciones tendrán un cuadro que no lo dejará ir. Solo habrá un botón Actualizar, el usuario se verá obligado a actualizar.

Intentamos utilizar este mecanismo lo menos posible, pero a veces es muy importante. Por ejemplo, si rompimos la compatibilidad con versiones anteriores, implementamos una nueva característica que no es compatible con el código anterior. Entonces, el usuario de la versión desactualizada de la aplicación puede terminar en un estado no coherente. Irá a la canasta y, por ejemplo, no tendrá un pedido. No entenderá por qué, aunque en la nueva versión se registran todos los errores y quedará claro por qué no es posible realizar un pedido.



Hay actualización suave para ayudar a forzar la actualización. Esto es algo nativo de Google, que simplemente está incrustado en su aplicación y no bloquea el uso. Pero ella dice: hay una actualización en Google Play, instálala y tendrás nuevas cosas interesantes.

Inicialmente, se implementa mediante dicho diálogo. Este es un diseño nativo de Android. Y luego se puede incrustar en su aplicación. Por ejemplo, lo implementamos en nuestro widget "Actualizar la aplicación" en nuestro esquema de color.

Soft Update nos permitió reducir en gran medida la cola de las versiones, y se implementa simplemente de acuerdo con la documentación. Pruébalo si tienes muchos lanzamientos.



Otra herramienta importante es la función de alternancia. Le permite ajustar parte de la funcionalidad en el lado del usuario, cambiándola en el panel de administración. Hay un conjunto de características que podemos activar y desactivar desde nuestro servidor sin actualizaciones adicionales de la aplicación.

Hablemos de cómo funciona Feature Toggle en el ejemplo de una aplicación de terceros: un vehículo. Inicialmente, los desarrolladores tienen una bicicleta así, que ya tiene dos funciones de alternar: un motor y un gran tamaño. Los clientes usan la bicicleta, luego el equipo de prueba dice: probamos el motor, funciona, conduce, se enfría, vamos a encenderlo para el usuario.



Vamos al panel de administración, activamos el alternador de funciones y la bicicleta sin actualizar al usuario, sobre la marcha se convierte en un ciclomotor. El usuario se siente cómodo, esto le permite moverse más rápido y más conveniente.

El producto se está desarrollando, la audiencia está creciendo, ya no cabe en un ciclomotor. Los usuarios quieren llevar a su familia con ellos, viajar juntos. Los desarrolladores y gerentes han proporcionado una alternancia de funciones adicional: un gran tamaño. Lo habilitamos en el panel de administración, y el vehículo del usuario se hace más grande sobre la marcha.



Parece genial: Feature Toggle nos ayuda. Esto es cierto, pero hay problemas que puede encontrar. Por ejemplo, debe monitorear la compatibilidad con versiones anteriores y la compatibilidad de alternancia de funciones. Supongamos que, en algún momento, la aplicación rompe el motor, se produce un bloqueo o error. O este motor consumirá muchos de nuestros recursos y no podremos admitir demasiados usuarios con el motor. Entonces tenemos que apagarlo.

Pero no queremos que la aplicación del usuario desaparezca. Queremos darle la oportunidad de usar la aplicación, a pesar de que todavía tiene un Toggle de gran tamaño. Por lo tanto, cuando apagamos el motor, debemos tener un mecanismo de retroceso para controlar el vehículo. En este caso, este es un híbrido.



Quizás valió la pena considerar que el techo se reclina. Quizás el conductor se sienta incómodo al sentarse en ese asiento. Pero aún podrá conducir un vehículo, usar la aplicación y no caminar.

¿De qué otra forma usamos la función de alternancia? Supongamos que los backends todavía se están desarrollando y no están listos para su lanzamiento. Luego podemos desarrollar parte de la funcionalidad, admitir el contrato de API para todas las comunicaciones con el back-end, admitir la interfaz de usuario y desplegar con la función de alternancia desactivada. Tan pronto como los backends estén listos, probaremos que todo funcione bien y, de ser así, habilitaremos el alternancia de funciones. Entonces el usuario no necesitará actualizarse para obtener nuevas funciones. Es decir, ya tendremos una audiencia, inmediatamente apareceremos en esta audiencia. Tan genial también.



Ahora, como ya dije, tenemos 13 personas en cada uno de los equipos de desarrollo de Android e iOS. Trabajamos en un flujo de Git, en un repositorio, configuramos nuestro proceso de lanzamiento planificado, redujimos el tiempo de comercialización y uso cada semana. Recientemente lanzamos Huawei AppGallery y miramos otras tiendas. Aprendimos a cambiar las aplicaciones de los usuarios sin actualizaciones debido a la función de alternancia. Gracias por la atención.