Foto von Unsplash für "Pipeline"
Allgemeiner Ansatz
Hallo! Ich beginne eine Reihe von Beiträgen zu Pipelines in der Entwicklung und nicht nur dazu, die Qualität der zu entwickelnden mobilen Anwendungen zu überprüfen. Die Hauptidee ist es, alle Ansätze für die mobile Entwicklung herauszustellen, die jetzt relevant sind: native Entwicklung für Android und iOS, React Native, Xamarin und Flutter. Ich werde mit Android beginnen, aber zuerst möchte ich eine allgemeine Vorstellung davon geben, worum es geht.
Beachten Sie, dass dies ein allgemeiner Überblick über Tools und Vorgehensweisen ist, die sich bei der Entwicklung von Android-Anwendungen als nützlich erweisen können, und kein Tutorial zur Konfiguration dieser Tools.
Wofür ist das alles?
Beginnen wir mit der bekannten Wahrheit: Je später Sie einen Fehler in der Anwendung finden, desto teurer ist die Behebung. Angenommen, Sie haben einen Fehler entdeckt, der sich bereits in der Produktion befindet. Ihre Tester müssen diesen Fehler lokal reproduzieren, ihn registrieren, priorisieren, an die Entwickler weitergeben und ihn dann beheben, eine neue Assembly erstellen, ihn wieder an die Tester übertragen, damit sie davon überzeugt sind, dass alles behoben ist, und dann die Freigabe erstellen erst dann senden Sie die neue Version an die Benutzer.
Viele Stunden Arbeit könnten eingespart werden, wenn Sie Mechanismen hätten, um das Auftreten von Fehlern zu Beginn zu verhindern. Ich sage nicht, dass es eine Silberkugel gibt, die alle Bugs beseitigt - das ist unmöglich. Möglich ist es jedoch, Barrieren (auch als Quality Gates bezeichnet) zu errichten, die die Wahrscheinlichkeit erhöhen, dass Fehler in Ihrem Code so früh wie möglich erkannt werden.
Auf dem Computer des Entwicklers
Als Entwickler arbeiten Sie immer mit einer IDE und Befehlszeilentools auf Ihrem Computer. Mal sehen, was es für Android-Entwickler gibt.
Android Studio
Dies ist jetzt die Standardoption für Android-Entwickler. Da diese Option auf der IntelliJ-Plattform basiert, gibt es zahlreiche Überprüfungen für Java, Kotlin und XML. Ich rate Ihnen, sich in einem Team auf die spezifischen Regeln zu einigen, die Sie verwenden möchten, diese auf einem Computer zu konfigurieren und die settings.jar-Datei mit diesen Regeln auf Ihr Versionskontrollsystem oder eine Art Tool für die Zusammenarbeit (wie Confluence) hochzuladen.
Inspektionseinstellungen in Android Studio
AS verfügt auch über Schnellkorrekturen, die durch Drücken von Alt + Eingabetaste auf Ihren Code angewendet werden können.
Beispiel für eine schnelle Fehlerbehebung aus Android Studio
Android Lint
Dies ist ein statisches Analysetool, das speziell für die Android-Entwicklung entwickelt wurde und Hunderte von Regeln enthält, die Sie verwenden können. Lint kann auch über die Gradle-Task (Task) gestartet und direkt in Android Studio aufgefordert und ein Bericht erstellt werden. Es gibt viele Prüfungen, die in Kategorien unterteilt sind - Sicherheit, Internationalisierung, Benutzerfreundlichkeit, Leistung ...
Aber die Möglichkeit, eigene Regeln hinzuzufügen, macht es besonders leistungsfähig. Room hat beispielsweise einen eigenen Satz von Regeln, die Timber- Protokollierungsbibliothek hat einen eigenen Satz von Regeln. Sie können Regeln für Ihr Team oder Projekt erstellen und sicherstellen, dass niemand bestimmte typische Fehler macht. (Übrigens wird es bald auf der Mobius-Konferenz einen Bericht darüber geben, in dem sowohl die theoretische als auch die praktische Seite erläutert werden).
Beispiel für einen Android Lint Report
Mehr statische Analyse
Natürlich gibt es viele statische Analyse-Tools, die nicht speziell für Android, sondern generell für Java und Kotlin entwickelt wurden : PMD , FindBugs (aufgegeben, SpotBugs verwenden ), Checkstyle , Ktlink , Detekt und andere. Wählen Sie nach Ihren Wünschen, integrieren Sie es in Ihre Pipeline und stellen Sie sicher, dass es tatsächlich verwendet wird (wie genau? Lesen Sie weiter).
Beispiel von FindBugs melden
Es reicht jedoch nicht aus, ein Tool zu haben, das Daten darüber liefert, was behoben werden muss. Außerdem finden Sie die folgenden Informationen nützlich:
- Wie ändert sich die Codeabdeckung bei Tests im Laufe der Zeit?
- Wie lange werde ich brauchen, um alle gefundenen Probleme zu beheben?
- Wie viel doppelter Code befindet sich im Projekt?
- Wie erweitere ich meine Regeln auf mehrere Teams?
Und viele andere. Wir bei EPAM Systems konzentrieren uns auf Qualität und haben SonarQube als Werkzeug ausgewählt, um diese Fragen zu beantworten. Weitere Vorteile von SonarQube finden Sie hier .
Unit-Test
Hoffentlich müssen Sie sich nicht noch einmal versichern, dass Ihr verdammter Code aus verschiedenen Gründen Komponententests benötigt. Es spielt keine Rolle, ob Sie die TDD befolgen, das Prinzip der Testpyramide oder die neue Idee des Testpilzes einhalten. Es ist nicht so wichtig, welchen Abdeckungsgrad Sie sich als Ziel gesetzt haben. In jedem Fall sind Ihre Unit-Tests eine notwendige Komponente. Sie müssen sie also schreiben und ausführen! Glücklicherweise haben wir in 11 Jahren Evolution einen recht praktischen Mechanismus zum Ausführen von Tests mit dem Gradle- und Android-Gradle-Plug-in erhalten.
Die Android gredl-Projektvorgaben haben testDebugUnitTest Problem (haben Sie es, natürlich variieren, je nach Geschmack), und dass es führt Tests. Stellen Sie sicher, dass Sie es verwenden, und dass die Codeabdeckung mit der Zeit zunimmt. Der Vorteil von Java-Komponententests besteht darin, dass sie auf der JVM-Workstation und nicht auf Dalvik / ART ausgeführt werden, was einen Geschwindigkeitsvorteil darstellt.
Bei Android-Unit-Tests gibt es ein grundlegendes Problem: die Abhängigkeit vom Android-SDK. Dies ist einer der Gründe, warum all diese Ansätze für die Benutzeroberflächenebene wie MVP, MVVM, MVI und andere MV * erschienen. Das spezifische Problem, abhängig von der Klasse unter Android, ist, dass Komponententests aufgrund der Verwendung von Stubs dieses Android selbst einfach fallen, was einfach eine Ausnahme auslöst. Natürlich gibt es einige Optionen: entweder Tests für diese Klasse überspringen oder einen Teil der Logik in andere Klassen extrahieren oder Schnittstellen für Android-abhängige Klassen erstellen, um eine Logik auf hoher Ebene zu testen, oder Robolectric verwenden (was alles andere als ideal ist). Eine weitere Option ist die Verwendung instrumentierter Tests, mit denen das Verhalten einer Aktivität überprüft werden kann. Der aktuelle Trend ist jedoch, dass die Aktivität keine Tests enthalten sollte.
Zur Frage der Abdeckung: Sie möchten wissen, was es zu Ihrem Zeitpunkt ist und wie es sich im Laufe der Zeit ändert, so dass Sie auch hierfür ein Tool benötigen würden. Soweit ich weiß, ist jacoco ein Industriestandard für Java und wird von Kotlin unterstützt.
Instrumentierte Tests
Diese Tests werden auf dem Android-Emulator ausgeführt, mit dem sie das Android Framework verwenden können. Leider sind sie langsam und instabil (aufgrund einiger Probleme mit dem Emulator), so dass die meisten mir persönlich bekannten Entwickler versuchen, sie zu vermeiden. Da die Unterstützung jedoch in Gradle und Android Studio erfolgt, sind sie möglicherweise für Sie geeignet.
Sicherheitsaudit
Neben einfachen Fehlern, Tippfehlern, Problemen beim Kopieren und Einfügen gibt es auch eine große Kategorie von Problemen, auf die Sie achten sollten: Sicherheit. Natürlich bietet Android Lint bereits einige relevante Tipps, aber es ist besser, sich um spezielle Tools speziell für diese Aufgabe zu kümmern. Diese Tools können sowohl im statischen als auch im dynamischen Modus ausgeführt werden. Abhängig von Ihren Sicherheitsanforderungen möchten Sie möglicherweise einen dieser Modi oder beide verwenden. Möglicherweise möchten Sie beispielsweise mit dem Mobile Security Framework beginnen und später kostenpflichtige Optionen in Betracht ziehen.
Glücklicherweise gibt es eine Liste von statischen Analyse-Tools, die direkt von OWASP erstellt wurden. Sie können beispielsweise Sicherheitslücken suchen auswählen oder das OWASP SonarCube-Projekt verwenden .
Überprüfungen
Wie gesagt, je kürzer der Feedback-Zyklus ist, desto weniger Zeit und Geld wird für die Behebung von Fehlern aufgewendet. Daher möchte ich sichergehen, dass der Code der Produktionsqualität entspricht, bevor er überhaupt ins Repository gelangt oder sogar lokal kommuniziert wird. Natürlich können Sie Ihre Entwickler einfach bitten, Überprüfungen durchzuführen, aber es gibt eine viel bessere Option: Git-Hooks.
Ich empfehle, einen Pre-Commit-Hook für alle oben diskutierten Prüfungen hinzuzufügen: Lint, statische Code-Analyse und Unit-Tests. Ein Beispiel für den Einrichtungsvorgang finden Sie hier .
CI / CD-Pipeline
Ein Android-Projekt ohne CI / CD-Pipeline ist kaum vorstellbar. Ihr Ziel ist es, alle oben genannten Prüfungen in der Montagephase zu wiederholen. Dafür gibt es mehrere Gründe:
- Git-Hooks können mit der Option --no-verify leicht umgangen werden
- Der Code kann alle Prüfungen lokal erfolgreich bestehen, führt jedoch nach dem Zusammenführen zu Problemen
- Benötigen Sie Test- und Abdeckungsberichte
Beispiel auf bitrise.io melden
Glücklicherweise müssen Sie diese Sicherheitsüberprüfungen nur direkt im Gradle-Build-Skript erwähnen oder die entsprechenden Tasks in Ihrer CI / CD-Pipeline aufrufen. Wenn Sie Schwierigkeiten haben, eine Pipeline aufzubauen, habe ich kürzlich auf der DevOops-Konferenz über mobile DevOps im Jahr 2019 einen Vortrag gehalten .
Bitte machen Sie auch folgendes:
- Führen Sie alle Überprüfungen für Pull-Anforderungen durch. Lassen Sie keine Anfragen zusammenführen, die gegen eine der Regeln verstoßen. Dies ist sehr wichtig: Wenn die Regel nicht ausgeführt wird, ist sie tatsächlich nicht vorhanden.
- Führen Sie alle Überprüfungen während der Montage und Bereitstellung durch. Sie möchten Ihren Qualitätsbalken nicht senken.
- Wenn der Build beschädigt ist, hat dies die höchste Priorität. Das Team sollte das Problem sofort beheben, da es Ihre kontinuierliche Lieferpraxis verletzt und das Team daran hindert, Qualitätscode zu schreiben.
Und viel Glück beim Verbessern Ihres Codes!
Wenn Ihnen dieser Artikel gefallen hat, folgen Sie mir auf Twitter, damit Sie Folgendes nicht verpassen. Und wenn Sie im Dezember in Moskau sein werden oder kommen können, kommen Sie zu unserer Mobius- Konferenz und lernen Sie viele andere Dinge über die Entwicklung für Android (und iOS) kennen!
PS Dank an vixentael für die Beantwortung von Sicherheitsfragen, an Alexei Nikitin für die Überprüfung und Kommentare, an Alexander Bakanov für das Korrekturlesen.