Get best of the week

Open Source: CI / CD- und Avito-Testinfrastruktur für Android

Wir haben die Open Source-Infrastruktur von Avito für Android verschoben: Gradle-Plugins, Emulatoren und Testbibliotheken. Unser Code wird bei der Automatisierung von CI / CD hilfreich sein und auch das Schreiben und die Unterstützung von Autotests erleichtern.

In diesem Übersichtsartikel werden wir erklären, warum wir beschlossen haben, unsere Arbeit offen zu machen, über die wichtigsten Bibliotheken des Projekts und uns darauf konzentrieren, wohin wir mit neu auftretenden Problemen gehen sollen. In den folgenden Materialien werden wir einzelne Bibliotheken, Gradle-Plugins und unsere Entwicklungsansätze detailliert analysieren.



Wer wir sind und was wir tun


Wir arbeiten im Speed-Plattform-Team an der Android-Branche. Wir sind zu viert:
Seryozha Boishtyan
Senior Engineer
Twitter-Account


Dima Voronin
Leitender Ingenieur
Twitter-Account


Zhenya Krivobokov Twitter-Account für
leitende Ingenieure



Daniil Popov
Senior Engineer
Twitter-Account


Wir sind dafür verantwortlich, den Benutzern Änderungen in allen Avito Android-Anwendungen schneller zur Verfügung zu stellen. Unser Verantwortungsbereich umfasst:

  • Lokale Arbeit mit dem Projekt: Damit alles schnell zusammengestellt wird und die IDE nicht langsamer wird.
  • CI-Pipeline: Tests, alle möglichen Prüfungen.
  • CD: Tools für Release-Ingenieure.

Warum brauchen wir Open Source?


Wir wollten den Code nicht nur in einem offenen Repository auf Github spiegeln, sondern zum Nutzen von uns selbst und der Ingenieurgemeinschaft. Die Hauptgründe, das Projekt auf Open Source umzustellen, sind fünf:

  • Rückmeldung bekommen.
  • Einfluss auf Industriestandards.
  • Neue Dinge lernen.
  • Betroffen sind Bibliotheken von Drittanbietern.
  • Steigern Sie Ihre persönliche Marke.

Lassen Sie uns kurz darauf eingehen.

Erhalten Sie Feedback und vereinfachen Sie die Wiederverwendung von Code


Wir optimieren für Avito-Ingenieure, und unsere Benutzer benötigen alle Lösungen, um einfach zu funktionieren. Uns fehlt die Sicht der Entwickler, die ähnliche Probleme lösen. Es wird cool sein, wenn sie auf Probleme bei der internen Implementierung und die Bequemlichkeit der Verbindung zu unserem Projekt hinweisen.

Wir haben bereits gesehen, wie durch die Portierung von Code nach Github die Probleme der Wiederverwendung hervorgehoben wurden. Wenn Sie verstehen, dass andere Unternehmen dies nutzen können, sehen Sie die Architektur anders. Die Wiederverwendung von Code ist kein Selbstzweck. Dieses externe Kriterium sagt jedoch viel über die Qualität der Architektur und ihre Flexibilität aus.

Einfluss auf Industriestandards


Wir entwickeln seit 2017 eine Infrastruktur für mobile Anwendungen und sprechen regelmäßig auf Konferenzen und Tagungen darüber:


Zusätzlich zu den Geschichten wollten wir den Code immer teilen und die Möglichkeit geben, ihn wiederzuverwenden. In der Tat stehen viele Android-Entwickler vor ähnlichen Herausforderungen:

  • Wie schreibe ich Autotests, damit sie davon profitieren?
  • So führen Sie sie in Pull-Anforderungen aus.
  • Wie billiger, um die Infrastruktur zu warten.

Für diese Aufgaben gibt es keine allgemein anerkannten und etablierten Lösungen - jedes Unternehmen arbeitet auf seine Weise. Wir teilen unsere Best Practices, damit Entwickler in neuen Projekten nicht Stück für Stück Informationen zum Testen mobiler Anwendungen und zum Erstellen von CI / CD sammeln müssen. Ich hätte gerne vorgefertigte Lösungen für Routineprobleme, anstatt mein Fahrrad zu schreiben. Und selbst wenn niemand den Projektcode in seiner ursprünglichen Form verwendet, können Entwickler unsere Ansätze ausspionieren und ihre eigenen Bibliotheken verbessern.

Lernen Sie, indem Sie anderen erklären


Nur den Code in Open Source zu setzen, reicht nicht aus. Praktiken, Ansätze, Wege, Probleme zu finden und Entscheidungen zu treffen, sind wichtig. Wir zeigen ihnen, wie unsere Ideen und vorgefertigten Vorschläge außerhalb von Avito funktionieren.

Betroffen sind Bibliotheken von Drittanbietern und beheben Sie ihre Probleme schneller


Stellen Sie sich vor, Sie haben ein Problem mit Android oder einer Bibliothek und können keine Problemumgehung finden. Sie benötigen Hilfe von der Community oder von Code-Autoren. Sie haben eine Frage zum Stapelüberlauf gestellt, einen Fehler in Google IssueTracker erstellt, alles ausführlich beschrieben, aber das Problem wird nicht reproduziert. Sie werden nach einem Testfall gefragt. All dies braucht zusätzliche Zeit.

Mit Open Source können Sie schneller ein reproduzierbares Beispiel erstellen. Wir haben eine Testanwendung , die einen Teil der Infrastruktur nutzt. Seine Hauptaufgabe ist das Hundefutter, dh so früh wie möglich anhand eines einfachen und isolierten Beispiels zu überprüfen, ob alles funktioniert. Dieselbe Anwendung erleichtert jedoch das Anzeigen von Fehlern. Wenn wir ein reproduzierbares Beispiel in einer ausländischen Bibliothek geben, ist der Autor leichter zu verstehen, worum es geht. Dies erhöht die Chancen, dass er Verbesserungen vornehmen wird.

Die Popularität eines Open Source-Projekts erhöht auch die Wahrscheinlichkeit, dass es Ihnen Aufmerksamkeit schenkt. Das Aufzeigen eines Problems in einer Bibliothek mit einer Reihe von Sternen und Benutzern erhöht den Druck und ist schwerer zu ignorieren. Es ist schwieriger, ein solches Ergebnis ohne Open Source zu erzielen - Ihre Anwendung muss sehr beliebt sein, oder Sie sollten es persönlich kennen.

PR und persönliche Motivation


Last but not least ist persönlicher Gewinn. Jeder profitiert von der Publizität der täglichen Arbeit. Das Unternehmen macht durch ein nützliches Produkt auf sich aufmerksam, und wir fördern als Ingenieure eine persönliche Marke und erhalten zusätzliche Motivation für die Arbeit. Sie müssen abends nicht mehr nach Zeit für Ihre eigenen Projekte oder Commits in Open Source-Bibliotheken von Drittanbietern suchen.

Was wurde zu Open Source gebracht


Wir haben fast unsere gesamte Android- und CI / CD-Testinfrastruktur in das Github-Repository gestellt . Um anderen Entwicklern die Navigation im Projekt zu erleichtern, sind alle Module nach Zweck gruppiert:




Ich werde einige der wichtigsten Bibliotheken erwähnen.

Testläufer


Dies ist ein Gradle-Plugin zum Ausführen von Instrumentierungstests. Das nächste Analogon ist Marathon , aber unser Analogon ist nur für Android geschrieben.

Testläufer:

  • Beschreibt, welche Tests ausgeführt werden sollen. Es wird nach Anmerkungen, Paketen und Ergebnissen des letzten Starts gefiltert.
  • Beschreibt, auf welchen Emulatoren Tests ausgeführt werden sollen. Sichert sie in Kubernetes oder stellt eine Verbindung zu lokalen Emulatoren her.
  • Legt die Bedingungen für den Neustart der Tests fest.
  • Sendet einen Abschlussbericht mit den Ergebnissen des Testlaufs.

Die Ergebnisse werden in einem benutzerdefinierten TMS (Test Management System) gespeichert, nicht in Open Source. Wir arbeiten an der Möglichkeit, eine weitere Implementierung anzuschließen.



Einflussanalyse


Wir haben ungefähr 1600 Instrumentierungstests und 10K-Komponententests. Wir möchten alle Tests für Codeänderungen ausführen, dies ist jedoch nicht möglich - der Lauf dauert zu lange.

Eine einfache Lösung besteht darin, die Tests manuell in verschiedene Sätze zu unterteilen, z. B. Rauchtests, schnell, langsam und nur einen Teil auszuführen. Bei diesem Ansatz besteht jedoch immer die Möglichkeit, einen Fehler zu übersehen, da nicht klar ist, welcher Testsatz optimal ist. Die ideale Lösung besteht darin, zu verstehen, mit welcher Mindestmenge von Tests alle Änderungen überprüft werden. Dies wird als Testauswirkungsanalyse bezeichnet .

Wir haben ein Gradle-Plugin geschrieben , das nach Änderungen in Modulen sucht, Tests analysiert und festlegt, welche ausgeführt werden sollen.



Die Hauptmodule und -ansätze werden in der Projektdokumentation ausführlicher beschrieben .
Jetzt ist sie nicht sehr gut und auch nicht alles ist übersetzt. Wir möchten die Dokumentation verständlicher machen und benötigen Ihre Hilfe. Sagen Sie uns, was wir im Text in unserem Telegramm-Chat abschließen und korrigieren sollen .



Wie unsere Bibliotheken nützlich sein können


Da das Projekt viele Komponenten enthält, hängt seine Verwendung von Ihren Anforderungen ab. Wenn Sie ein ähnliches Problem lösen oder nur die Technologie verstehen möchten, schreiben Sie uns bitte in einem Telegramm-Chat auf Russisch oder Englisch . Wir werden Ihnen sagen, was wir wissen, versuchen zu helfen und relevante Beispiele zeigen.

Du kannst alles fragen:

  • Wie arbeiten Sie mit instabilen Tests?
  • Warum so viel Code? Er ist nutzlos.
  • Warum ist der gesamte Code in Gradle-Plugins enthalten, nicht in Python-Skripten?

Wenn Sie ein bestimmtes Modul verwenden möchten, können Sie es in einer Testanwendung ausprobieren . Jetzt zeigt es ein Beispiel für die Verwendung eines Testläufers.

Leider gibt es noch wenige Beispiele für die Wiederverwendung in anderen Projekten, sodass die Integration möglicherweise noch unbekannte Einschränkungen aufzeigt. Schreiben Sie uns, wenn dies passiert, und wir werden sehen, was finalisiert werden muss.

Fazit


In den folgenden Artikeln wollen wir darüber sprechen:

  • Unser Testläufer.
  • Anatomie des Tests - Was passiert, wenn Sie in der IDE auf die Schaltfläche „Ausführen“ klicken, um das Ergebnis zu erhalten?
  • Wie wir mit der Instabilität von Tests und Infrastruktur kämpfen.
  • Unsere Ansätze zum Schreiben von Infrastruktur.
  • Wie wir die Veröffentlichungszeit von Monat zu Woche verkürzt haben.

Es gibt Ideen zu allgemeineren Themen:

  • So beginnen Sie mit dem Schreiben von Tests.
  • Grundlagen des Testens für Anfänger - über gängige Ansätze und Technologien.

Sagen Sie uns in den Kommentaren, was Sie wissen möchten. Wir werden also verstehen, welchen Text wir zuerst schreiben müssen.

More articles:


All Articles