Get best of the week

Open source: infrastructure de test CI / CD et Avito pour Android

Nous avons déplacé l'infrastructure open source d'Avito pour Android: plugins Gradle, émulateurs et bibliothèques de test. Notre code sera utile pour automatiser CI / CD et facilitera également l'écriture et le support des autotests.

Dans cet article de revue, nous expliquerons pourquoi nous avons décidé de rendre notre travail ouvert, sur les bibliothèques les plus importantes du projet et orienterons où aller avec les problèmes émergents. Nous analyserons en détail les bibliothèques individuelles, les plugins Gradle et nos approches de développement dans les documents suivants.



Qui nous sommes et ce que nous faisons


Nous travaillons sur l'industrie Android au sein de l'équipe de la plateforme Speed. Nous sommes quatre:
Compte Twitter Seryozha Boishtyan
Ingénieur principal



Compte Twitter de Dima Voronin
Ingénieur en chef



Compte Twitter Zhenya Krivobokov
ingénieur principal



Compte Twitter Daniil Popov
Ingénieur principal



Nous sommes responsables de la livraison plus rapide des modifications dans toutes les applications Avito Android aux utilisateurs. Notre domaine de responsabilité comprend:

  • Travail local avec le projet: pour que tout soit rapidement assemblé et que l'IDE ne ralentisse pas.
  • Pipeline CI: tests, tous les contrôles possibles.
  • CD: outils pour les ingénieurs de version.

Pourquoi avons-nous besoin de l'open source


Nous voulions non seulement refléter le code dans le référentiel ouvert sur Github, mais le faire pour le bien de nous-mêmes et de la communauté des ingénieurs. Les principales raisons de mettre le projet en open source sont cinq:

  • Avoir un retour.
  • Influencer les normes de l'industrie.
  • Apprendre de nouvelles choses.
  • Affectez les bibliothèques tierces.
  • Boostez votre marque personnelle.

Examinons-les brièvement.

Obtenez des commentaires et facilitez la réutilisation du code


Nous faisons le réglage pour les ingénieurs Avito, et nos utilisateurs ont besoin de toutes les solutions pour fonctionner. Nous manquons de la vue des développeurs qui résolvent des problèmes similaires. Ce sera cool s'ils signalent des problèmes dans la mise en œuvre interne et la commodité de la connexion à notre projet.

Nous avons déjà vu comment le portage de code vers Github a mis en évidence les problèmes de réutilisation. Lorsque vous comprenez que d'autres entreprises peuvent l'utiliser, vous envisagez l'architecture différemment. La réutilisation du code n'est pas une fin en soi. Mais ce critère externe en dit long sur la qualité de l'architecture et sa flexibilité.

Influencer les normes de l'industrie


Nous développons des infrastructures pour applications mobiles depuis 2017 et en parlons régulièrement lors de conférences et réunions:


En plus des histoires, nous avons toujours voulu partager le code et donner la possibilité de le réutiliser. En effet, de nombreux développeurs Android sont confrontés à des défis similaires:

  • Comment écrire des autotests pour qu'ils en bénéficient.
  • Comment les exécuter dans les demandes de tirage.
  • Comment moins cher pour maintenir l'infrastructure.

Il n'y a pas de solutions généralement acceptées et établies pour ces tâches - chaque entreprise opère à sa manière. Nous partageons nos meilleures pratiques afin que dans les nouveaux projets, les développeurs n'aient pas à collecter des informations bit à bit sur le test des applications mobiles et la création de CI / CD. J'aimerais avoir des solutions toutes faites pour les problèmes courants au lieu d'écrire mon vélo. Et, même si personne n'utilise le code du projet dans sa forme originale, les développeurs pourront espionner nos approches et améliorer leurs propres bibliothèques.

Apprenez en expliquant aux autres


Il ne suffit pas de mettre le code en open source. Les pratiques, les approches, les façons de trouver des problèmes et de prendre des décisions sont importantes. En les montrant, nous vérifions le fonctionnement de nos idées et propositions toutes faites en dehors d'Avito.

Affectez les bibliothèques tierces et résolvez leurs problèmes plus rapidement


Imaginez que vous rencontrez un problème dans un Android ou une bibliothèque et que vous ne trouviez pas de solution. Vous avez besoin de l'aide de la communauté ou des auteurs de code. Vous avez posé une question sur Stack Overflow, créé un bogue dans Google IssueTracker, décrit tout en détail, mais le problème ne se reproduit pas. On vous demande un cas de test. Tout cela prend plus de temps.

L'open source vous aide à créer un exemple reproductible plus rapidement. Nous avons une application de test qui utilise une partie de l'infrastructure. Sa tâche principale est le dogfooding, c'est-à-dire le plus tôt possible pour vérifier avec un exemple simple et isolé que tout fonctionne. Mais cette même application facilite l'affichage des bogues. Lorsque nous donnons un exemple reproductible dans une bibliothèque étrangère, son auteur est plus facile à comprendre quel est le problème. Cela augmente les chances qu'il entreprenne des améliorations.

La popularité d'un projet open source augmente également la probabilité qu'il prête attention à vous. Souligner un problème dans une bibliothèque avec un tas d'étoiles et d'utilisateurs augmente la pression, c'est plus difficile à ignorer. Obtenir un tel résultat sans open source est plus difficile - votre application doit être super populaire ou vous devez la connaître personnellement.

Relations publiques et motivation personnelle


Le dernier, mais non le moindre, est le gain personnel. Tout le monde profite de la publicité du travail quotidien. L'entreprise attire l'attention grâce à un produit utile, et nous pompons une marque personnelle en tant qu'ingénieurs et obtenons une motivation supplémentaire pour le travail. Vous n'avez plus besoin de chercher du temps le soir pour vos propres projets ou de vous engager dans des bibliothèques open source tierces.

Ce qui a été apporté à l'open source


Nous avons mis presque toute notre infrastructure de test Android et CI / CD dans le référentiel Github . Pour faciliter la navigation du projet par d'autres développeurs, tous les modules sont regroupés par objectif:




Je vais noter quelques-unes des bibliothèques les plus importantes.

Runner de test


Il s'agit d'un plugin gradle pour exécuter des tests d'instrumentation. L'analogue le plus proche est Marathon , mais le nôtre est écrit uniquement pour Android.

Testeur:

  • Décrit les tests à exécuter. Il y a un filtrage par annotations, par packages, par les résultats du dernier lancement.
  • Décrit les émulateurs sur lesquels exécuter les tests. Les sauvegarde sur Kubernetes ou se connecte à des émulateurs locaux.
  • Définit les conditions de redémarrage des tests.
  • Envoie un rapport final avec les résultats du test.

Les résultats sont stockés dans un TMS personnalisé (système de gestion des tests), il n'est pas en open source. Nous travaillons sur la possibilité de connecter une autre implémentation.



Analyse d'impact


Nous avons environ 1600 tests d'instrumentation et 10K tests unitaires. Nous aimerions exécuter tous les tests pour tout changement de code, mais ce n'est pas possible - l'exécution prendra trop de temps.

Une solution simple consiste à diviser manuellement les tests en différents ensembles, par exemple, les tests de fumée, rapides, lents, et à exécuter uniquement une partie. Mais avec cette approche, il y a toujours une chance de manquer une erreur, car on ne sait pas quel ensemble de tests est optimal. La solution idéale est de comprendre quel ensemble minimum de tests vérifiera tous les changements. C'est ce qu'on appelle l' analyse d'impact du test .

Nous avons écrit un plugin Gradle qui recherche les changements dans les modules, analyse les tests et détermine ceux à exécuter.



Les principaux modules et approches sont décrits plus en détail dans la documentation du projet .
Maintenant, elle n'est pas très bonne, et même tout n'est pas traduit. Nous voulons faciliter la compréhension de la documentation et nous avons besoin de votre aide. Dites-nous quoi finaliser et corriger dans le texte de notre discussion par télégramme .



Comment nos bibliothèques peuvent être utiles


Le projet ayant de nombreux composants, son utilisation dépend de vos besoins. Si vous résolvez un problème similaire ou si vous voulez simplement comprendre la technologie, n'hésitez pas à nous écrire dans un chat télégramme en russe ou en anglais . Nous allons vous dire ce que nous savons, essayer d'aider et montrer des exemples pertinents.

Vous pouvez demander n'importe quoi:

  • Comment travaillez-vous avec des tests instables?
  • Pourquoi autant de code? Il est inutile.
  • Pourquoi tout le code dans les plugins Gradle, pas les scripts Python?

Si vous souhaitez utiliser un module spécifique, vous pouvez l'essayer dans une application de test . Maintenant, il montre un exemple d'utilisation du lanceur de test.

Malheureusement, nous avons encore quelques exemples de réutilisation dans d'autres projets, donc l'intégration peut encore révéler des restrictions inconnues. Écrivez-nous si cela se produit et nous verrons ce qui doit être finalisé.

Conclusion


Dans les articles suivants, nous prévoyons de parler de:

  • Notre testeur.
  • Anatomie du test - que se passe-t-il en appuyant sur le bouton "Exécuter" dans l'IDE pour obtenir le résultat.
  • Comment nous luttons avec l'instabilité des tests et des infrastructures.
  • Nos approches de l'écriture d'infrastructures.
  • Comment nous avons réduit le temps de sortie de mois en semaine.

Il y a des idées sur des sujets plus généraux:

  • Comment commencer à écrire des tests.
  • Fondamentaux des tests pour les débutants - sur les approches et technologies communes.

Dites-nous dans les commentaires ce que vous serez intéressé de savoir. Nous comprendrons donc quel texte écrire en premier.

More articles:


All Articles