Die Größe ist wichtig! Teil 3 / Sudo Null IT-News

Im vorherigen Teil haben wir die Automatisierung der Regressionserkennung in einer Android-Anwendung auf Pull-Request-Ebene analysiert und herausgefunden, welche Nachteile sie hat.

Zur Erinnerung: Der einzige Nachteil ist, dass bei jedem Commit ein Entwicklungs-Build erstellt wird, was unser CI stark unter Druck setzt, da wir nicht immer die Entwicklungs-Apk zum Vergleich abfragen müssen, abhängig von den geänderten Dateien.

Lösung

Weigern Sie sich, apk im Entwicklungszweig für jeden Commit zu erstellen

In einer Pull-Anfrage bleibt unser Ablauf fast gleich, mit Ausnahme einiger Schritte:

1. Wir sammeln das App-Bundle ./gradlew bundleRelease

2. Wir erfassen eine bestimmte APK mit einer einzigen Gerätespezifikation.json

3. Da wir apk im Entwicklungszweig nicht fertig haben, müssen wir es aus einer Pull-Anforderung erstellen. Dazu holen wir uns den Head (Connecting) Commit der Development- und Feature-Branchs. Wir checken diesen Commit aus:

head_commit=$(git merge-base „development“ „feature/task1“) git checkout $head_commit

4. Wir sammeln das Release-App-Bundle von diesem Head-Commit ./gradlew bundleRelease

5. Wir erfassen eine bestimmte APK mit einer einzelnen Geräte-spec.json

Außerdem ist alles dasselbe wie im vorherigen Ablauf. Und da das Erstellen der APK des aktuellen Pull-Request-Commits und das Erstellen der APK aus dem Head-Commit nicht verwandt sind, können Sie sie parallelisieren, was Zeit spart.

6. Vergleichen Sie unsere apk mit dem Diffuse-Tool

7. Posten Sie das Ergebnis des Vergleichs als Kommentar im Pull-Request

8. Blockieren / Entsperren von Pull-Anforderungen in Abhängigkeit von der Regressionserkennung

Ergebnis

Unser endgültiger Ablauf sieht folgendermaßen aus:

Pull-Request-FlowPull-Request-Flow

Jetzt erstellen wir Release-APKs nur, wenn wir die Größe der Anwendung überprüfen müssen (abhängig von den geänderten Dateien). Dies ermöglicht es Ihnen, CI nicht zu laden, da die Prüfung der Anwendungsgröße in ~ 30 % der offenen Pull-Anforderungen erforderlich ist, wie die Praxis zeigt.

Als Ergebnis haben wir auch:

  • Automatisierte Erkennung der Regression der Anwendungsgröße auf Pull-Request-Ebene

  • Vollständige Transparenz bei der Größenänderung von Anwendungen während der Entwicklung

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *