Angesichts eines wachsenden mobilen Teams und wöchentlicher Releases ist eine zuverlässige CI-Pipeline unerlässlich. Wir müssen in der Lage sein, unsere Apps zu entwickeln, zu testen und im App Store und Google Play Store bereitzustellen. Außerdem pflegen wir interne Vorschau-Versionen, um die neuesten Features zu testen.
Erfahren Sie, wie wir ClickUp, Fastlane und GitHub Actions einsetzen, um unsere Continuous Integration (CI) und Continuous Delivery (CD) zu automatisieren.
Das Leben eines Bugs 🐜
Beginnen wir mit einem kurzen Überblick über unseren Prozess zur Verwaltung und Behebung von Fehlern.
- Ein Fehler (oder ein Feature) wird gemeldet und eine Aufgabe in ClickUp erstellt.
- Die Aufgabe wird einem Entwickler zugewiesen und in einem PR gegenüber dem Staging-Bereich festgelegt.
- Die CI führt alle Tests durch, erstellt die App, stellt eine Web-Vorschau bereit und lädt Alles in die ClickUp Aufgabe hoch.
- Unser QA-Team überprüft die Korrektur und wenn sie in Ordnung ist, wird die Aufgabe als erledigt markiert.
- Die PR wird automatisch mit der Staging-Umgebung zusammengeführt.
- Der Staging-Bereich wird erstellt und auf unserem internen TestFlight bereitgestellt.
- Jeden Mittwoch wird ein Release-Bereich erstellt, aufgebaut und getestet.
- Freitags erstellen wir ein Release auf GitHub, und die CI stellt das Release in den App-Stores und im Play Store bereit.
Eine ClickUp-Aufgabe enthält alle Informationen zum Bug. Wir verwenden benutzerdefinierte Status wie „In Bearbeitung“ oder „Codeüberprüfung“, um den Bug zu verfolgen. Die CI-Workflows ändern den Status automatisch. Benutzerdefinierte Felder enthalten zusätzliche Informationen wie z. B. wer den Bug gemeldet hat, wer daran arbeitet, wann er behoben sein wird usw.
PR-Workflow 📜
Die ersten beiden oben beschriebenen Schritte stehen nicht wirklich im Zusammenhang mit CI, aber der dritte ist interessant...
Unser Entwicklungs-Workflow läuft für jede PR. Er überprüft Lints und Formate und führt alle Tests durch, bevor er mit der Erstellung der Android- und iOS-Artefakte beginnt.
Wenn ein Build erfolgreich ist, veröffentlicht die CI eine Nachricht in der verknüpften Aufgabe. QA-Ingenieure können zum PR gehen, die Build-Artefakte herunterladen oder die Webvorschau verwenden.
Eine automatisierte CI-Nachricht, die nach einem erfolgreichen Build in der verknüpften ClickUp Aufgabe gepostet wird.
Einrichten von Flutter auf dem CI-Runner 🛠
Wir verwenden die bekannte GitHub-Aktion subosito/flutter-action, um Flutter auf der CI einzurichten. Standardmäßig wird die neueste stabile Flutter-Version installiert. Um zu vermeiden, dass Ihre CI-Workflows bei der Veröffentlichung einer neuen Flutter-Version unterbrochen werden, sollten Sie die Version manuell angeben.
Wenn Sie mehrere Workflows haben, ist es besser, die Flutter-Version in einer Datei zu speichern. Wir verwenden FLUTTER_VERSION im Stammverzeichnis des Repositorys.
Eine weitere einfache Lösung besteht darin, die Flutter-Version als GitHub-Geheimnis zu speichern und über {{ secrets. FLUTER_VERSION }} darauf zuzugreifen.
Web-Vorschau 🕸
Dank der Fähigkeit von Flutter, im Web ausgeführt zu werden, können wir eine voll funktionsfähige Webvorschau von Pull Requests erstellen. Mit dem Paket device_preview können die Größe des Geräts und die Einstellungen angepasst werden.
Die Vorschau hat sich als sehr nützlich erwiesen und wird nicht nur von unserem QA-Team genutzt. Auch Designer und Produktmanager schätzen sie, um neue Features schnell zu iterieren.
über Flutter
So erstellen Sie eine Webvorschau 🐶
Stellen Sie zunächst sicher, dass Ihre App mit Flutter Web kompatibel ist – nicht alle APIs werden unterstützt.
In unserer App mussten wir beispielsweise Push-Benachrichtigungen und Web-Sockets deaktivieren.
Dieser Beispiel-Workflow erstellt eine Webvorschau Ihrer Flutter-App und lädt sie in einen S3-Bucket hoch. Wir verwenden eine ENABLE_DEVICE_PREVIEW-Umgebungsvariable, um die device_preview in der Produktion zu deaktivieren.
Der Schritt „Fix base href“ ist erforderlich, da sich die Vorschau nicht im Stammverzeichnis des Buckets befindet.
Und etwas Code, um die device_preview unter bestimmten Bedingungen zu aktivieren.
Umgebungsvariablen sind ein leistungsstarkes tool und ermöglichen es dem Tree-Shaking-Algorithmus von Flutter, Debug-Code für Release-Builds zu entfernen.
Fastlane 💨
Fastlane vereinfacht die Erstellung, Signierung und Bereitstellung von Flutter-Apps erheblich. Es verwaltet unsere Zertifikate, Bereitstellungsprofile und andere Einstellungen. Wir verwenden GitHub-Secrets, um Passwörter und Tokens mit Sicherheit zu speichern.
Nützliche Fastlane-Aktionen:
- fastlane match zum Erstellen und Speichern von iOS-Schlüsseln und -Profilen in einem GitHub-Repository
- build_app zum Erstellen von iOS- und Android-Apps
- upload_to_testflight und Bereitstellung von iOS-Builds
- upload_to_play_store zum Bereitstellen von Android-Builds
Beispiel für einen iOS-Entwicklungsbuild 🍏
Vergessen Sie nicht setup_ci, es bewahrt Sie vor seltsamen Fehlern 👾. Weitere Informationen zu Fastlane für Flutter-Apps.
Android-Signierung 🔒
Die einfachste Möglichkeit, Android-Release-Builds mit Sicherheit zu signieren, besteht darin, die Tokens als GitHub-Geheimnisse zu speichern und Umgebungsvariablen sowie einen temporären Schlüssel zu verwenden. jks, erstellt durch die CI:
Wir speichern den Schlüssel „jks” als Base64-kodierte Zeichenfolge in GitHub Secrets und dekodieren ihn im Workflow:
Release- und Produktions-Workflow 🚀
Der Pre-Release-Workflow läuft für Bereiche, die mit release/v beginnen. Er entfernt alle Debugging- und internen Codes, um sicherzustellen, dass wir denselben Code testen, der auch veröffentlicht wird.
Darüber hinaus wird im Vorfeld der Veröffentlichung ein Workflow in verschiedenen Slack-Kanälen gepostet, um die QA- und Marketing-Teams mithilfe eingehender Webhooks über eine neue Version zu informieren.
Nachdem alles gründlich getestet wurde, erstellen wir ein Release auf GitHub, das der Auslöser für den Produktions-Workflow ist. Es erstellt und signiert die App mit Produktionszertifikaten und sendet sie an den App Store.
Weitere Tricks für Ihre CI 🦾
Wenn Sie den Push-Auslöser für GitHub Actions verwenden, werden Sie wahrscheinlich auf Probleme stoßen, wenn mehrere Pushes in schneller Folge auf denselben Bereich erfolgen. Es wird mehr als eine Instanz des Workflows gestartet, was Build-Minuten verbraucht oder andere Probleme verursacht.
- Wir empfehlen, die Aktion „Workflow abbrechen“ zu verwenden, um alle vorherigen Instanzen des Workflows abzubrechen.
- Wenn Sie nach einer einfachen und wartungsfreundlichen Lösung zur Generierung fortlaufender Build-Nummern suchen, probieren Sie den Build Number Generator aus. Sie können auch die GITHUB_RUN_ID verwenden, diese kann jedoch nicht benutzerdefiniert sein.
- Sehen Sie sich die ClickUp GitHub-App an, um Bereiche, Commits und den GitHub-Status direkt in Ihren ClickUp-Aufgaben anzuzeigen. Verwenden Sie ClickUp Automations oder die öffentliche API von ClickUp für erweiterte Automatisierungen.
Zusammenfassung 🍩
Der Aufbau Ihrer CI ist ein spannender Prozess. Der Einstieg ist einfach und Sie können ihn nach und nach weiterentwickeln. Unsere CI folgt einem der Werte von ClickUp: Fortschritt in Richtung Perfektion. Wir arbeiten ständig an CI-Verbesserungen für unsere QA- und Engineering-Teams.
Die Kombination aus ClickUp, GitHub Actions und Fastlane ist sehr leistungsstark und ermöglicht den Aufbau einer flexiblen und vollständig automatisierten CI/CD-Pipeline in weniger als einer Stunde. Probieren Sie es aus!
Wir haben viele spannende Themen in der Pipeline, also schauen Sie regelmäßig im ClickUp Engineering-Blog vorbei! 🦄