salut! Mon nom est Mikhail Bulgakov (non, pas un parent), je travaille comme ingénieur de publication chez Badoo. Il y a cinq ans, j'ai repris l'automatisation des versions d'applications iOS, que j'ai décrites en détail dans cet article . Et puis il s'est lancé dans les applications Android.
Aujourd'hui, je vais résumer quelques résultats: je vais vous dire à quoi nous sommes arrivés pendant cette période. Bref: tout employé impliqué dans le processus peut publier au moins toutes nos applications sur les deux plateformes en quelques clics - sans maux de tête, sans prise de temps, sans inscription et sans SMS. Ainsi, notre département d'ingénieurs de libération en 2019 a économisé environ 830 heures.
Pour plus de détails - bienvenue au chat!
Ce qui se cache derrière la version mobile
Une version d'application sur Badoo comporte trois phases:
- Développement.
- : , — , App Store Google Play.
- , -.
Lorsque l'application est complètement prête et que la première étape est passée, il est important de ne pas la fixer au stade de la libération et d'amener le produit au «comptoir». Cette dernière étape semble être la plus simple, mais en fait elle prend beaucoup de temps et son succès dépend de quelques personnes.
La plupart du temps est consacré à la préparation de la fenêtre d'application sur l'App Store ou Google Play: il faut remplir de belles captures d'écran, faire une description alléchante optimisée pour une meilleure indexation, sélectionner des mots-clés pour la recherche. La popularité de l'application dépend directement de la qualité de ce travail, c'est-à-dire du résultat des activités des développeurs, des testeurs, des concepteurs, des chefs de produit, des spécialistes du marketing - toutes les personnes impliquées dans la création du produit.
Si l'application doit exister en plusieurs langues, au moins une personne distincte ou même plusieurs employés sont nécessaires pour préparer la vitrine: un chef de produit qui rédigera les textes de description, organisera la traduction dans toutes les langues et préparera les spécifications techniques pour la création de captures d'écran, un concepteur qui dessinera des captures d'écran à partir de texte superposé, contours de l'appareil, etc., et, bien sûr, des traducteurs qui traduisent toutes les captures d'écran et les textes dans différentes langues.
Le dernier travail est le processus de publication lui-même. Cela prend un temps considérable pour une petite équipe d'ingénieurs de version. À ce stade crucial, mais plutôt routinier, nous avons cherché à minimiser le nombre d'erreurs et l'influence du facteur humain. Pour ce faire, il a tout d'abord fallu automatiser le chargement des métadonnées (texte et graphisme de la fenêtre de l'application): cela permet de réduire considérablement les coûts de temps et de réaliser rapidement des versions commerciales (par exemple, styliser l'application pour la Saint Valentin).
Puisque la décision de savoir si l'application est prête à être publiée dans Badoo est prise par une équipe d'ingénieurs QA, nous avons décidé de leur donner le droit de cliquer sur le «bouton rouge» pour lancer la version. En même temps, nous voulions qu'il soit accessible même à partir d'appareils mobiles (avec un affichage visuel de la progression du script).
Premiers pas vers l'automatisation: chargement des métadonnées
Comment cela a fonctionné au tout début: pour chaque version, un tableau a été créé dans Google Sheets, dans lequel le chef de produit a rempli le texte principal vérifié en anglais, après quoi les traducteurs l'ont adapté pour un pays, un dialecte et un public spécifiques, puis l'ingénieur de publication a transféré toutes les informations à partir de ce tableau dans l'App Store ou Google Play.
La première étape vers l'automatisation que nous avons prise a été d'intégrer la traduction de textes dans notre processus global de traduction. Je ne m'attarderai pas là-dessus - il s'agit d'un grand système séparé, sur lequel vous pouvez lire dans notre récent article... Le point principal est que les traducteurs ne perdent pas de temps sur les tablettes et travaillent avec l'interface pour un chargement pratique à la main (lire: ctrl + c ctrl + v) les versions traduites en str. En outre, il existe les ingrédients du contrôle de version et la base de l'infrastructure en tant que code.
Dans le même temps, nous avons ajouté le déchargement des traductions prêtes à l'emploi de la base de données et leur intégration dans le fichier IPA collecté (extension de fichier d'application iOS). L'application est construite avec TeamCity. Ainsi, chaque version de l'application avait toujours une nouvelle traduction sans intervention manuelle dans le processus de construction.
Pendant un certain temps, nous avons vécu comme ça, et dans l'ensemble, tout nous convenait. Mais le nombre d'applications a augmenté, et avec lui le temps de préparer chaque version.
Notre réalité à partir de 2015
En moyenne, la libération d'une application en présence de la version actuelle des captures d'écran a pris environ une heure et demie à deux heures de travail par l'ingénieur de publication dans le cas d'iOS et environ une demi-heure dans le cas d'Android. La différence est due au fait que les applications iOS doivent passer par ce que l'on appelle le traitement, ce qui prend un certain temps (il est impossible d'envoyer une demande en révision avant la réussite du traitement). De plus, l'App Store lui-même était beaucoup plus lent que Google Play pour la plupart des opérations à l'époque.
Il est devenu évident que nous avions besoin d'un outil supplémentaire pour fournir des applications aux magasins. Et juste à ce moment, un produit appelé Fastlane a commencé à gagner en popularité sur le marché open-source. Malgré le fait qu'il était encore humide à l'époque, il pouvait déjà résoudre une énorme couche de nos problèmes ...
Je dirai quelques mots à son sujet, afin que ce soit plus clair ce qui sera discuté plus loin.
Fastlane en bref
Aujourd'hui Fastlane est un produit qui est capable d'automatiser presque complètement toutes les actions depuis le moment de la fin du développement jusqu'à la sortie d'une application sur l'App Store et Google Play. Et il ne s'agit pas seulement de télécharger des textes, des captures d'écran et l'application elle-même - voici la gestion des certificats, les tests bêta, la signature de code et bien plus encore.
Nous avons fait la connaissance de Fastlane durant sa «jeunesse» et son instabilité. Mais maintenant, il s'agit d'un composant intégré et fonctionnant en toute confiance de nombreuses équipes de développement d'applications mobiles qui sont confrontées au problème des coûts de temps énormes pour la livraison de leurs produits aux utilisateurs. La chose la plus intéressante à ce sujet est la possibilité d'écrire vos propres plugins pour le composant principal et d'utiliser des plugins écrits par la communauté. Pour un produit aussi spécifique, c'est une bonne solution, ce qui (ce qui est important) permet de ne pas produire de technologies «supplémentaires» dans DevTools.
Cela inspire également confiance que le fondateur et développeur principal de Fastlane a été embauché par Google: désormais, le composant prend en charge non seulement la communauté, mais aussi elle-même.
Au fil du temps, nous avons implémenté la plupart des capacités de Fastlane dans les systèmes de construction, de signature, de remplissage et plus de nos applications. Et ils en sont incroyablement heureux. Pourquoi réinventer la roue, et même conserver sa forme correcte, alors que vous pouvez écrire une fois un script unifié qui tournera tout seul dans un système CI / CD?
Automatisation des versions IOS
Étant donné que Google Play est plus convivial pour les développeurs, il a fallu très peu de temps pour publier une application Android: quelques minutes sans mettre à jour les textes, les vidéos et les captures d'écran. Par conséquent, il n'y a pas besoin d'automatisation. Mais avec l'App Store, le problème était très tangible: il fallait trop de temps pour soumettre des demandes à Review. Par conséquent, il a été décidé de commencer l'automatisation avec iOS.
Nous avons réfléchi à la ressemblance de notre système d'automatisation d'interaction avec l'App Store (et même fait des prototypes), mais nous n'avions pas les ressources pour terminer et mettre à jour. Il n'y avait pas non plus d'API plus ou moins adéquate d'Apple. Eh bien, le dernier clou dans le cercueil de notre solution personnalisée a été entraîné par des mises à jour régulières de l'App Store et de ses mécanismes. Nous avons donc décidé d'essayer Fastlane - puis toujours la version 2015.
La première étape a consisté à écrire un mécanisme de déchargement des textes traduits pour les applications dans la structure souhaitée en tant que composant de notre système interne commun AIDA (Automated Interactive Deploy Assistant). Ce système est une sorte de hub, un lien entre tous les systèmes, technologies et composants utilisés dans Badoo. Il fonctionne sur un système de files d'attente auto-écrit implémenté sur Golang et MySQL. L'entretient et l'améliore principalement par le département Release Engineering. Nous en avons parlé plus en détail dans un article en 2013, depuis lors, beaucoup de choses ont changé. Nous promettons de vous en parler à nouveau - AIDA est génial!
À l'étape suivante, les textes téléchargés ont été envoyés à Fastlane, qui les a téléchargés sur l'App Store. Après cela, je devais aller dans l'interface de l'App Store, sélectionner manuellement la version téléchargée souhaitée et envoyer l'application pour vérification si le traitement était déjà terminé d'ici là.
Cela a réduit le temps de préparation de la sortie de quelques heures à environ 30 minutes, dont seulement une minute et demie a dû faire quelque chose avec vos mains! Le reste du temps est à attendre. Attendez la fin du traitement. Le mécanisme était une percée à ce moment-là précisément parce qu'il nous a presque complètement évité le travail manuel lors de la préparation de l'AppStore pour la sortie. Dans le cadre du script, nous avons créé un référentiel, qui a été donné accès à des personnes directement liées aux versions (chefs de projet, ingénieurs de version).
Nous avons vécu dans ce mode pendant un certain temps. Mais à un moment donné, ce schéma a conduit à l'accumulation de beaucoup de "connaissances sacrées", dont le propriétaire et, par conséquent, l'image générale des événements est devenue une seule personne, et ce n'est pas bon. Surtout pour cette personne elle-même: vous ne pouvez même pas partir en vacances sans ordinateur portable.
De plus, il y avait beaucoup de composants d'infrastructure dispersés autour de ce mécanisme, pratiquement sans rapport les uns avec les autres.
- Nous avons dû aller à TeamCity pour une nouvelle version, télécharger le fichier IPA à partir de là, le télécharger sur l'App Store via le gestionnaire d'applications.
- Ensuite, allez dans l'interface avec les traductions dans AIDA, voyez si toutes les traductions sont prêtes, exécutez le script, assurez-vous qu'il fonctionne correctement (après tout, Fastlane était encore humide à ce moment-là).
- App Store , Processing.
- Review.
Et donc à chaque application. Permettez-moi de vous rappeler qu'à l'époque, nous en avions huit.
L'étape suivante consistait à transférer le script sur notre AIDA, en combinant et en automatisant toutes les étapes jusqu'à l'envoi de la demande: vérification de l'état de préparation des traductions, collecte des données de TeamCity, notification, journalisation et tous les autres avantages du 21e siècle. En parallèle, nous avons commencé à charger toutes les versions assemblées dans TestFlight au stade de la construction.
TestFlight est une application tierce, une fois achetée par Apple pour tester l'application terminée par des testeurs externes dans presque un environnement de production, c'est-à-dire avec des notifications push et tout ça.
AIDA bien fait, soyez comme AIDA!
Tout cela a conduit à une réduction du temps d'une demi-heure à une minute et demie pour tout sur tout: le fichier IPA a eu le temps de passer en traitement avant même le moment où l'équipe d'ingénierie QA a donné le feu vert pour lancer la version. Néanmoins, nous devions toujours aller sur l'App Store, sélectionner la bonne version et l'envoyer à Review.
De plus, une interface simple a été dessinée: nous aimons tous les klats-klats.
Donc, onglet par onglet, Ctrl + C Ctrl + V ...
Automatisation des versions Android
Ensuite, la question s'est posée de l'automatisation des versions des applications Android. Bien que ce processus ait été beaucoup plus rapide, il a fallu faire beaucoup de choses à la main:
- Accédez à la console Google Play pour vous assurer que la version précédente est déployée à 100% ou gelée.
- Créez une nouvelle version de la version avec des textes et des captures d'écran mis à jour (le cas échéant).
- Téléchargez le fichier APK (package Android), téléchargez le fichier de mappage.
- Accédez à HockeyApp (utilisé pour la journalisation des plantages à ce moment-là), téléchargez-y le fichier APK et le fichier de mappage.
- Accédez au chat et désabonnez-vous du statut de la version.
Et donc à chaque application.
Oui, Google Play a sa propre API. Mais pourquoi créer un wrapper, surveiller les modifications du protocole, le maintenir et générer des entités inutilement si nous utilisons déjà Fastlane pour les versions iOS? De plus, il existe confortablement sur notre serveur, est brassé dans son propre jus et généralement mis à jour. Et à ce moment-là, il avait également appris à publier correctement des applications Android. Les étoiles se sont réunies!
Tout d'abord, nous avons supprimé tout ce qui était ancien de partout: les scripts individuels, les croquis d'automatisation, les anciens wrappers API - cela a été créé une fois à titre expérimental et n'avait pas une valeur particulière. Immédiatement après cela, nous avons ajouté une équipe à AIDA, qui savait déjà comment récupérer ce dont TeamCity avait besoin, télécharger ce qui était nécessaire là où c'était nécessaire dans HockeyApp, envoyer des notifications, enregistrer l'activité et, en général, elle était membre de l'équipe.
Fastlane était responsable du téléchargement des fichiers APK et de mappage sur Google Play. Je dois dire qu'il est beaucoup plus facile de parcourir les sentiers battus: cela s'est réalisé assez rapidement avec un minimum d'effort.
À un certain stade de la mise en œuvre de l'automatisation, il y a eu une transition des archives APK vers AAB (Android App Bundle). Encore une fois, nous avons eu la chance que sur les talons, nous avons rapidement réussi à tout réparer, mais le «divertissement» a été ajouté en lien avec cette transition. Par exemple, il a gâté HockeyApp, qui ne savait pas comment utiliser les archives AAB pour se préparer à l'auto-sciage. Donc, pour continuer à l'utiliser confortablement, il était nécessaire de démonter l'archive assemblée après l'assemblage AAB, d'en obtenir le fichier de cartographie, qui volera vers HockeyApp, et de l'AAB, il était nécessaire de collecter séparément le fichier APK et de le télécharger ensuite sur la même HockeyApp. Ça a l'air amusant. Dans le même temps, Google Play décompose parfaitement l'AAB, en extrait le fichier Mapping et l'insère si nécessaire. Nous nous sommes donc débarrassés d'une étape et en avons ajouté quelques-unes, mais nous n'avons pas pu la contourner.
Une interface a été écrite (encore une fois, par analogie avec iOS), qui a pu télécharger une nouvelle version, vérifier la version le long et à travers, gérer la version active actuelle (par exemple, augmenter le pourcentage de déploiement). Dans ce formulaire, nous l'avons remis aux membres de l'équipe Android QA responsable des versions, avons commencé à recueillir des commentaires, à corriger des bugs, à affiner la logique (et que se passe-t-il d'autre après la version 1.0?).
En passant, à l'avenir, l'automatisation nous a donné la possibilité de télécharger automatiquement des versions bêta d'applications sur Google Play selon un calendrier, ce qui, à son tour, a considérablement accéléré le processus de test automatique et de régression.
Unification du flux des versions mobiles
Au moment où les versions d'Android ont été automatisées, Fastlane avait enfin appris à soumettre des versions des applications iOS pour examen. Et nous avons légèrement amélioré le système de contrôle de version dans AIDA.
Il est temps d'externaliser les versions iOS à l'équipe QA. Pour ce faire, nous avons décidé de dessiner une belle forme qui couvrirait complètement les besoins qui se poseraient lors de la sortie des applications iOS: cela permettrait de sélectionner la build souhaitée dans TeamCity selon des paramètres prédéfinis, de choisir l'option des textes téléchargés, de mettre à jour ou non des champs optionnels (par exemple, Texte promotionnel) .
À peine dit que c'était fait. L'emporte-pièce s'est avéré être très joli et satisfait pleinement toutes les demandes. De plus, avec son introduction, il est devenu possible de sélectionner immédiatement toutes les applications nécessaires avec tous les paramètres requis, afin que l'interaction avec l'interface soit minimisée. La commande AIDA on envoie un lien vers le journal de construction, par lequel vous pouvez suivre les erreurs qui se produisent, vous assurer que tout s'est bien passé, obtenir une sorte d'informations de débogage comme la version du fichier IPA téléchargé, la version, etc.C'est ainsi que les belles versions iOS sont. et ont été transférés à l'équipe QA iOS.
Eh bien, est-ce mignon?
Nous avons tellement aimé l'idée du moule que nous avons décidé de faire de même pour les versions Android. Alors que nous avons une application entièrement écrite en React Native, et que l'équipe QA de l'application est responsable des versions iOS et Android.
L'interface déjà utilisée par l'équipe d'Android QA a été intégrée avec des changements dans une forme similaire, le processus a été adapté aux nouvelles réalités - tout était au plus proche des processus de l'équipe iOS. Cela a incité à esquisser enfin une version plus ou moins finale de la documentation pour les deux plates-formes (dans le processus de changements constants, nous ne voulions catégoriquement pas le faire), et aussi à découpler le processus de publication de toutes les restrictions artificielles qui se sont développées historiquement et ont conduit à des gestes inutiles dans des situations non standard, nécessitant équipe d'action d'ingénieurs de publication.
Production
De manière aussi amusante pendant environ cinq ans (à partir du moment où nous avons commencé à développer l'activité mobile à ce jour), nous avons complètement automatisé les processus d'assemblage, de test et de publication, les avons rendus aussi efficaces que possible et avons transféré la responsabilité des versions aux membres de l'équipe QA qui acceptent décision sur le degré de préparation de la demande.
En plus des avantages évidents, nous nous sommes complètement débarrassés des scripts épars, de toutes sortes de «connaissances secrètes» liées à une seule personne, avons intégré un nouveau composant dans notre écosystème, qui est soutenu par une petite équipe d'ingénieurs de publication.
C'est formidable qu'il soit désormais possible d'automatiser la plupart des actions de routine, que les ingénieurs puissent écrire du code quand ils le souhaitent et que tout code puisse être pris en charge par des développeurs tiers, sans perdre un temps précieux à fouiller dans des interfaces complexes. Il est particulièrement difficile de comprendre des choses comme «Où dois-je cocher?», Lorsque l’horloge est minuit, personne n’est au bureau et le correctif doit être téléchargé ici et maintenant.
Cinq ans. Pourquoi si longtemps? Premièrement, les versions mobiles sont loin d'être le seul domaine de responsabilité de notre petite équipe. Deuxièmement, bien sûr, il a fallu du temps pour développer le nouveau projet open source Fastlane; notre système de version a évolué avec lui.
Nous avons parcouru un long chemin dans ce domaine. Ce n'est peut-être pas le plus efficace, peut-être qu'un râteau aurait pu être prévu et contourné. Mais c'était comme ça. Quand nous avons commencé, il n'y avait pas d'articles similaires - nous avons nous-mêmes progressé. Et si vous êtes confronté à une tâche similaire maintenant et que cet article vous aidera avec quelque chose, je serai incroyablement heureux. Mais même si vous n'avez pas appris des informations fondamentalement nouvelles, j'espère qu'au moins c'était intéressant à lire à votre guise. Et, peut-être, à comparer avec leur expérience. Et si vous avez quelque chose à dire sur ce sujet, bienvenue dans les commentaires!