¡Hola! Mi nombre es Mikhail Bulgakov (no, no es pariente), trabajo como ingeniero de lanzamiento en Badoo. Hace cinco años, comencé a automatizar los lanzamientos de aplicaciones de iOS, que describí en detalle en este artículo . Y luego tomó las aplicaciones de Android.
Hoy resumiré algunos resultados: les diré a qué hemos llegado durante este tiempo. En pocas palabras: cualquier empleado involucrado en el proceso puede lanzar al menos todas nuestras aplicaciones en ambas plataformas en unos pocos clics, sin dolores de cabeza, tiempo, registro y SMS. Entonces, nuestro departamento de ingenieros de lanzamiento en 2019 ahorró aproximadamente 830 horas.
Para más detalles, ¡bienvenido debajo del corte!
¿Qué hay detrás del lanzamiento móvil?
El lanzamiento de la aplicación en Badoo consta de tres etapas:
- Desarrollo.
- : , — , App Store Google Play.
- , -.
Cuando la aplicación esté completamente lista y la primera etapa haya pasado, es importante no arreglarla en la etapa de lanzamiento y llevar el producto al "mostrador". Esta última etapa parece ser la más fácil, pero de hecho lleva mucho tiempo y su éxito depende de unas pocas personas.
La mayor parte del tiempo se dedica a preparar la ventana de la aplicación en la App Store o Google Play: debe completar hermosas capturas de pantalla, hacer una descripción atractiva optimizada para una mejor indexación, seleccionar palabras clave para la búsqueda. La popularidad de la aplicación depende directamente de la calidad de este trabajo, que es, de hecho, el resultado de las actividades de los desarrolladores, evaluadores, diseñadores, gerentes de producto, comercializadores: todos los involucrados en la creación del producto.
Si la aplicación debe existir en varios idiomas, se requiere al menos una persona separada para preparar el escaparate, o incluso varios empleados: un gerente de producto que escribirá textos para la descripción, organizará la traducción a todos los idiomas y preparará un ToR para crear capturas de pantalla, un diseñador que dibujará capturas de pantalla con texto superpuesto, esquemas de dispositivos, etc. y, por supuesto, traductores que traducirán todas las capturas de pantalla y textos a diferentes idiomas.
El último trabajo es el proceso de lanzamiento en sí. Se necesita una cantidad considerable de tiempo para un pequeño equipo de ingeniería de lanzamiento. En esta etapa crítica, pero más bien rutinaria, tratamos de minimizar la cantidad de errores y la influencia del factor humano. Para hacer esto, en primer lugar, era necesario automatizar la carga de metadatos (diseño de texto y gráfico del escaparate de la aplicación): esto le permite reducir significativamente los costos de tiempo e implementar rápidamente lanzamientos comerciales (por ejemplo, diseñar la aplicación para el Día de San Valentín).
Dado que la decisión sobre la preparación de la aplicación para el lanzamiento en Badoo la toma el equipo de ingenieros de control de calidad, decidimos darles el derecho de presionar el "botón rojo" para lanzar el lanzamiento. Al mismo tiempo, queríamos que fuera accesible incluso desde dispositivos móviles (con una visualización visual del progreso del script).
Primeros pasos hacia la automatización: carga de metadatos
Cómo funcionó al principio: para cada lanzamiento, se creó una tabla en Hojas de cálculo de Google, en la cual el gerente de producto completó el texto maestro verificado en inglés, después de lo cual los traductores lo adaptaron para un país, dialecto y audiencia específicos, y luego el ingeniero de lanzamiento transfirió toda la información de esta tabla en App Store o Google Play.
El primer paso que dimos hacia la automatización fue integrar la traducción de textos en nuestro proceso general de traducción. No me detendré en esto: este es un sistema grande separado, sobre el cual puedes leer en nuestro artículo reciente... El punto principal es que los traductores no pierden el tiempo en tabletas y trabajan con la interfaz para una carga conveniente a mano (leer: ctrl + c ctrl + v) versiones traducidas en str. Además, existen las características de las versiones y la base para Infraestructura como Código.
Al mismo tiempo, agregamos la descarga de traducciones preparadas de la base de datos y las incluimos en el archivo IPA recopilado (extensión de archivo de la aplicación iOS). La aplicación está construida con TeamCity. Por lo tanto, cada versión de la aplicación siempre tuvo una traducción nueva sin intervención manual en el proceso de compilación.
Durante un tiempo vivimos así y, en general, todo nos vino bien. Pero el número de aplicaciones aumentó y, con ello, el tiempo para preparar cada lanzamiento.
Nuestra realidad a partir de 2015
En promedio, el lanzamiento de una aplicación con la versión actual de las capturas de pantalla tomó aproximadamente una hora y media o dos horas de trabajo del ingeniero de lanzamiento en el caso de iOS y aproximadamente media hora en el caso de Android. La diferencia se debe al hecho de que las aplicaciones de iOS tienen que pasar por el llamado Procesamiento, que lleva algún tiempo (es imposible enviar una aplicación a Revisión antes de que el Procesamiento se complete con éxito). Además, la App Store en sí era mucho más lenta que Google Play para la mayoría de las operaciones en ese momento.
Se hizo evidente que necesitábamos una herramienta adicional para entregar aplicaciones a las tiendas. Y justo en ese momento, un producto llamado Fastlane comenzó a ganar popularidad en el mercado de código abierto. A pesar de que todavía estaba húmedo en ese momento, ya podía resolver una gran capa de nuestros problemas ...
Diré algunas palabras sobre él para aclarar lo que se discutirá más a fondo.
Fastlane de un vistazo
Hoy Fastlane es un producto que es capaz de automatizar casi por completo todas las acciones desde el momento del final del desarrollo hasta el lanzamiento de una aplicación en la App Store y Google Play. Y no se trata solo de descargar textos, capturas de pantalla y la aplicación en sí: aquí están la administración de certificados, las pruebas beta, la firma de código y mucho más.
Conocimos a Fastlane durante su "juventud" e inestabilidad. Pero ahora es un componente integral y de trabajo confiable de muchos equipos de desarrollo de aplicaciones móviles que enfrentan el problema de los enormes costos de tiempo para entregar sus productos a los usuarios. Lo más interesante es la capacidad de escribir sus propios complementos para el componente principal y usar complementos escritos por la comunidad.. Para un producto tan específico, esta es una buena solución, que (lo cual es importante) ayuda a no producir tecnologías "adicionales" en DevTools.
La confianza también se inspira en el hecho de que Google contrató al fundador y desarrollador principal de Fastlane: ahora el componente no solo es compatible con la comunidad, sino también con Sam.
Con el tiempo, hemos implementado la mayoría de las capacidades de Fastlane en los sistemas de compilación, firma, relleno y más de nuestras aplicaciones. E increíblemente feliz por eso. ¿Por qué reinventar la rueda e incluso mantener su forma correcta, cuando puede escribir una secuencia de comandos unificada una vez que gire en un sistema CI / CD?
Automatizar lanzamientos de iOS
Debido al hecho de que Google Play es más amigable para los desarrolladores, llevó muy poco tiempo lanzar una aplicación de Android: un par de minutos sin actualizar textos, videos y capturas de pantalla. Por lo tanto, no hay necesidad de automatización. Pero con la App Store, el problema era muy tangible: se tardó demasiado en enviar las aplicaciones a Review. Por lo tanto, se decidió iniciar la automatización con iOS.
Pensamos en la similitud de nuestro sistema para automatizar la interacción con la App Store (e incluso fabricamos prototipos), pero no teníamos los recursos para terminar y actualizar. Además, no había una API más o menos adecuada de Apple. Bueno, el último clavo en el ataúd de nuestra solución personalizada fue impulsado por actualizaciones periódicas de la App Store y sus mecanismos. En general, decidimos probar Fastlane, luego otra versión de 2015.
El primer paso fue escribir un mecanismo para descargar textos traducidos para aplicaciones en la estructura deseada como un componente de nuestro sistema interno común AIDA (Asistente de despliegue interactivo automatizado). Este sistema es un tipo de hub, un enlace entre todos los sistemas, tecnologías y componentes utilizados en Badoo. Funciona en un sistema de colas autoescrito implementado en Golang y MySQL. Lo mantiene y lo mejora principalmente Departamento de Ingeniería de Lanzamiento. Hablamos de ello con más detalle en el artículo en 2013, desde entonces mucho ha cambiado. Nos comprometemos a contarle de nuevo: ¡AIDA es increíble!
En el siguiente paso, los textos cargados se enviaron a Fastlane, que los cargó en la App Store. Después de eso, tuve que ir a la interfaz de la tienda de aplicaciones, seleccionar manualmente la versión descargada deseada y enviar la aplicación para verificar si el procesamiento ya se había completado para entonces.
¡Esto redujo el tiempo de preparación del lanzamiento de un par de horas a aproximadamente 30 minutos, de los cuales solo un minuto y medio tuvieron que hacer algo con las manos! El resto del tiempo es esperar. Espere al final del procesamiento. El mecanismo se convirtió en un gran avance en ese momento precisamente porque nos salvó casi por completo del trabajo manual al preparar la AppStore para su lanzamiento. Bajo el guión, creamos un repositorio, que daba acceso a personas que están directamente relacionadas con los lanzamientos (gerentes de proyecto, ingenieros de lanzamiento).
En este modo, vivimos por algún tiempo. Pero en algún momento, este esquema condujo a la acumulación de muchos "conocimientos sagrados", cuyo propietario y, como resultado, la imagen general de los acontecimientos se convirtió en una sola persona, y esto no es bueno. Especialmente para esta persona: ni siquiera puede irse de vacaciones sin una computadora portátil.
Además, había muchos componentes de infraestructura dispersos alrededor de este mecanismo, prácticamente no relacionados entre sí.
- Debía ir a TeamCity para obtener una compilación nueva, descargar el archivo IPA desde allí, subirlo a la App Store a través del Administrador de aplicaciones.
- Luego vaya a la interfaz con traducciones en AIDA, vea si todas las traducciones están listas, ejecute el script, asegúrese de que funcionó correctamente (después de todo, Fastlane todavía estaba húmedo en ese momento).
- App Store , Processing.
- Review.
Y así con cada aplicación. Déjame recordarte, en ese momento teníamos ocho de ellos.
El siguiente paso fue transferir el script a nuestra AIDA, al mismo tiempo que combina y automatiza todos los pasos hasta que se envíe la aplicación: verificar la disponibilidad de las traducciones, recopilar datos de TeamCity, notificaciones, registros y todos los demás beneficios del siglo XXI. Paralelamente, comenzamos a cargar todas las versiones compiladas en TestFlight en la etapa de compilación.
TestFlight es una aplicación de terceros, una vez comprada por Apple para probar la aplicación terminada por probadores externos en casi un entorno de producción, es decir, con notificaciones push y todo eso.
AIDA bien hecho, ¡sé como AIDA!
Todo esto condujo a una reducción en el tiempo de media hora a un minuto y medio para todo sobre todo: el archivo IPA logró pasar por Procesamiento antes del momento en que el equipo de ingenieros de QA dio el visto bueno para lanzar el lanzamiento. Sin embargo, todavía teníamos que ir a la tienda de aplicaciones, seleccionar la versión que deseamos y enviarla a revisión.
Además, se dibujó una interfaz simple: a todos nos encanta hacer clic y hacer clic.
Entonces, pestaña por pestaña, Ctrl + C Ctrl + V ...
Android Release Automation
A continuación, surgió la pregunta sobre la automatización de los lanzamientos de aplicaciones de Android. Aunque este proceso fue mucho más rápido, fue necesario hacer mucho a mano:
- Vaya a la consola de Google Play para asegurarse de que la versión anterior se implemente al 100% de los usuarios o se congele.
- Cree una nueva versión del lanzamiento con textos actualizados y capturas de pantalla (si corresponde).
- Cargue el archivo APK (paquete de Android), cargue el archivo de mapeo.
- Vaya a HockeyApp (utilizado para registrar bloqueos en ese momento), cargue el archivo APK y el archivo de mapeo allí.
- Vaya al chat y cancele la suscripción sobre el estado del lanzamiento.
Y así con cada aplicación.
Sí, Google Play tiene su propia API. Pero, ¿por qué hacer un contenedor, realizar un seguimiento de los cambios en el protocolo, mantenerlo y producir entidades sin la necesidad si ya usamos Fastlane para las versiones de iOS? Además, existe cómodamente en nuestro servidor, se elabora en su propio jugo y generalmente se actualiza. Y para entonces, también había aprendido cómo lanzar adecuadamente las aplicaciones de Android. ¡Las estrellas se unieron!
En primer lugar, eliminamos todo lo antiguo de todas partes: guiones individuales, bocetos de automatización, envoltorios de API antiguos: esto se creó una vez como un experimento y no tenía un valor particular. Inmediatamente después de eso, agregamos un equipo a AIDA, que ya sabía cómo tomar lo que necesitábamos de TeamCity, cargar lo que necesitábamos en HockeyApp, enviar alertas, registrar la actividad y, en general, era un miembro del equipo.
Fastlane fue responsable de cargar archivos APK y Mapping en Google Play. Debo decir que es mucho más fácil seguir el camino trillado: se realizó lo suficientemente rápido con un mínimo esfuerzo.
En una determinada etapa de la implementación de la automatización, hubo una transición de los archivos APK a AAB (Paquete de aplicaciones de Android). Nuevamente, tuvimos la suerte de que pisando los talones logramos arreglar todo rápidamente, pero se agregó "entretenimiento" en relación con esta transición. Por ejemplo, echó a perder HockeyApp, que no sabía cómo usar los archivos AAB en relación con la preparación para el auto-aserrado. Por lo tanto, para continuar utilizándolo cómodamente, fue necesario desmontar el archivo ensamblado después del ensamblaje AAB, obtener el archivo de mapeo, que volará a HockeyApp, y desde AAB fue necesario recopilar por separado el archivo APK y solo luego cargarlo en el mismo HockeyApp. Suena divertido. Al mismo tiempo, Google Play descompone perfectamente el AAB, saca el archivo de mapeo desde allí y lo inserta donde sea necesario. Así que nos deshicimos de un paso y agregamos algunos, pero no hubo forma de evitarlo.
Se escribió una interfaz (de nuevo, por analogía con iOS), que pudo descargar una nueva versión, verificar el lanzamiento a lo largo y ancho, administrar la versión activa actual (por ejemplo, aumentar el porcentaje de despliegue). De esta forma, se lo dimos a los miembros del equipo de control de calidad de Android responsables de los lanzamientos, comenzamos a recopilar comentarios, corregir errores, refinar la lógica (¿y qué más sucede después del lanzamiento 1.0?).
Por cierto, en el futuro, la automatización nos dio la oportunidad de cargar versiones beta de aplicaciones a Google Play automáticamente en un horario, lo que, a su vez, aceleró enormemente el proceso de pruebas automáticas y de regresión.
Unificación del flujo de lanzamientos móviles
Cuando los lanzamientos de Android se automatizaron, Fastlane finalmente había aprendido cómo enviar versiones de aplicaciones iOS para su revisión. Y hemos mejorado ligeramente el sistema de control de versiones en AIDA.
Es hora de dar lanzamientos de iOS a merced de un equipo de ingenieros de control de calidad. Para hacer esto, decidimos dibujar un formulario hermoso que cubriera por completo las necesidades que surgen durante el lanzamiento de las aplicaciones de iOS: permitiría seleccionar la compilación deseada en TeamCity de acuerdo con parámetros predefinidos, elegir la opción de textos descargados, actualizar o no los campos opcionales (por ejemplo, Texto promocional) ...
Dicho y hecho. El molde resultó ser muy agradable y satisface completamente todas las solicitudes. Además, con su introducción, se hizo posible seleccionar inmediatamente todas las aplicaciones necesarias con todos los parámetros requeridos, de modo que se minimizara la interacción con la interfaz. En el comando, AIDA envía un enlace al registro de compilación, mediante el cual puede rastrear los errores que ocurren, asegurarse de que todo salió bien, obtener algún tipo de información de depuración, como la versión del archivo IPA descargado, la versión de lanzamiento, etc. Así de hermosas son las versiones de iOS. y fueron transferidos al equipo de control de calidad de iOS.
Bueno, es lindo?
Nos gustó tanto la idea con el molde que decidimos hacer lo mismo con los lanzamientos de Android. Mientras que tenemos una aplicación escrita completamente en React Native y que el equipo de control de calidad de esa aplicación es responsable de los lanzamientos de iOS y Android.
La interfaz ya utilizada por el equipo de control de calidad de Android se integró con cambios de forma similar, el proceso se adaptó a las nuevas realidades: todo estaba lo más cerca posible de los procesos del equipo de iOS. Esto dio un incentivo para finalmente esbozar una versión más o menos final de la documentación para ambas plataformas (en el proceso de cambios constantes, categóricamente no queríamos hacer esto), y también para desacoplar el proceso de liberación de todas las restricciones artificiales que se habían desarrollado históricamente y condujeron a gestos innecesarios en situaciones no estándar, que requieren Equipo de acción de ingenieros de lanzamiento.
Salida
De una manera tan aburrida, durante aproximadamente cinco años (desde el momento en que comenzamos a desarrollar la dirección móvil hasta la actualidad), hemos automatizado completamente los procesos de creación, prueba y lanzamiento, los hemos hecho lo más eficientes posible y hemos transferido la responsabilidad de los lanzamientos a los miembros del equipo de control de calidad, que aceptan decisión sobre el grado de preparación de la aplicación.
Además de las ventajas obvias, nos deshicimos por completo de los guiones dispersos, de todo tipo de "conocimiento secreto" vinculado a una sola persona, integramos un nuevo componente en nuestro ecosistema, que es respaldado por un pequeño equipo de ingenieros de lanzamiento.
Es genial que ahora haya una oportunidad para automatizar la mayoría de las acciones de rutina, que los ingenieros puedan escribir código cuando lo deseen, y que los desarrolladores de terceros puedan admitir cualquier código sin perder un tiempo precioso indagando en interfaces complejas. Puede ser especialmente difícil entender momentos como ¿Dónde debo poner una marca de verificación? ”, Cuando el reloj es medianoche, no hay nadie en la oficina, y la revisión debe completarse aquí y ahora.
Cinco años. ¿Porque tan largo? En primer lugar, los lanzamientos móviles están lejos de ser la única área de responsabilidad de nuestro pequeño equipo. En segundo lugar, por supuesto, llevó tiempo desarrollar el nuevo proyecto de código abierto Fastlane; nuestro sistema de lanzamiento evolucionó con él.
Hemos recorrido un largo camino en esta área. Tal vez no sea el más efectivo, tal vez podría haberse previsto y anulado algún rastrillo. Pero fue como era. Cuando lo comenzamos, no había artículos similares, nosotros mismos trabajamos para ascender. Y si te enfrentas a una tarea similar ahora y este artículo te ayudará con algo, estaré increíblemente feliz. Pero incluso si no obtuvo ninguna información radicalmente nueva, espero que al menos sea interesante leer en su tiempo libre. Y, tal vez, compárelo con su experiencia. Y si tiene algo que decir sobre este tema, ¡bienvenido a comentar!