Met een groeiend mobiel team en wekelijkse releases is het essentieel om een betrouwbare CI-pijplijn te hebben. We moeten onze apps kunnen bouwen en testen en ze kunnen implementeren in de App Store en Google Play Store. We onderhouden ook interne previewversies om de nieuwste functies te testen.
Ontdek hoe we ClickUp, Fastlane en GitHub Actions gebruiken voor de automatisering van onze Continuous Integration (CI) en Continuous Delivery (CD).
Het leven van een bug 🐜
Laten we beginnen met een kort overzicht van ons proces voor het beheren en oplossen van bugs.
- Een bug (of functieverzoek) wordt gemeld en er wordt een taak aangemaakt in ClickUp.
- De taak wordt toegewezen aan een ontwikkelaar en vastgelegd in een PR tegen de staging branch.
- De CI voert alle tests uit, bouwt de app, implementeert een webpreview en uploadt alles naar de ClickUp-taak.
- Ons QA-team controleert de oplossing en als deze goed is, wordt de taak gemarkeerd als Klaar.
- De PR wordt automatisch samengevoegd in staging.
- De vertakking voor de fase wordt gebouwd en geïmplementeerd in onze interne TestFlight.
- Elke woensdag wordt een release-vertakking aangemaakt, gebouwd en getest.
- Op vrijdag maken we een release op GitHub en de CI implementeert de release in de App Store en Play Store.
Een ClickUp-taak bevat alle informatie over de bug. We gebruiken aangepaste statussen zoals 'In uitvoering' of 'Codereview' om de bug bij te houden. De CI-werkstroom wijzigt de status automatisch. Aangepaste velden bevatten aanvullende informatie, zoals wie de bug heeft gemeld, wie eraan werkt, wanneer deze wordt vrijgegeven, enz.
PR-werkstroom 📜
De eerste twee stappen die hierboven worden beschreven, hebben niet echt met CI te maken, maar de derde stap is interessant...
Onze ontwikkelingswerkstroom wordt voor elke PR uitgevoerd. Deze controleert lints, format en voert alle tests uit voordat het begint met het bouwen van de Android- en iOS-artefacten.
Wanneer een build succesvol is, plaatst de CI een bericht in de gekoppelde taak. QA-engineers kunnen naar de PR gaan, de build-artefacten downloaden of de webpreview gebruiken.
Een geautomatiseerd CI-bericht dat na een succesvolle build in de gekoppelde ClickUp-taak wordt geplaatst.
Flutter instellingen op de CI-runner 🛠
We gebruiken de bekende GitHub-actie subosito/flutter-action om Flutter op de CI in te stellen. Standaard wordt de nieuwste stabiele Flutter-release geïnstalleerd. Om te voorkomen dat uw CI-werkstroom wordt onderbroken wanneer er een nieuwe Flutter-versie wordt uitgebracht, moet u de versie handmatig specificeren.
Als u meerdere werkstroomen hebt, kunt u de Flutter-versie beter in een bestand opslaan. Wij gebruiken FLUTTER_VERSION in de root van de opslagplaats.
Een andere eenvoudige oplossing is om de Flutter-versie op te slaan als GitHub-geheim en deze te openen met {{ secrets. FLUTER_VERSION }}.
Webvoorbeeld 🕸
Dankzij de mogelijkheid van Flutter om op het web te draaien, kunnen we een volledig functionele webpreview van pull-aanvragen maken. Met behulp van het device_preview-pakket kunnen de apparaatgrootte en instellingen worden aangepast.
De preview is erg nuttig gebleken en wordt niet alleen door ons QA-team gebruikt. Ontwerpers en productmanagers vinden het ook handig om snel nieuwe functies te kunnen testen.
via Flutter
Hoe maak je een webvoorvertoning 🐶
Zorg er om te beginnen voor dat uw app compatibel is met Flutter web. Niet alle API's worden ondersteund.
In onze app moesten we bijvoorbeeld notificaties en websockets uitschakelen.
Deze voorbeeldwerkstroom bouwt een webpreview van uw Flutter-app en uploadt deze naar een S3-bucket. We gebruiken een ENABLE_DEVICE_PREVIEW-omgevingsvariabele om device_preview in productie uit te schakelen.
De Fix base href-stap is nodig omdat het voorbeeld niet in de root van de bucket staat.
En wat code om device_preview te schakelen op basis van een voorwaarde.
Omgevingsvariabelen zijn een krachtig hulpmiddel en zorgen ervoor dat het tree shaking-algoritme van Flutter debugcode kan verwijderen voor release-builds.
Fastlane 💨
Fastlane vereenvoudigt het bouwen, ondertekenen en implementeren van Flutter-apps aanzienlijk. Het beheert onze certificaten, provisioningprofielen en andere instellingen. We gebruiken GitHub-geheimen om wachtwoorden en tokens veilig op te slaan.
Handige Fastlane-acties:
- fastlane match om iOS-sleutels en -profielen te maken en op te slaan in een GitHub-opslagplaats
- build_app om iOS- en Android-apps te bouwen
- upload_to_testflight en lever om iOS-builds te implementeren
- upload_to_play_store om Android-builds te implementeren
Steekproef van een iOS-ontwikkelingsbuild 🍏
Vergeet setup_ci niet, het bespaart je rare fouten 👾. Meer informatie over Fastlane voor Flutter-apps.
Android-ondertekening 🔒
De eenvoudigste manier om Android-releasebuilds veilig te ondertekenen, is door de tokens op te slaan als GitHub-geheimen en omgevingsvariabelen en een tijdelijke sleutel te gebruiken. jks gemaakt door de CI:
We slaan de sleutel jks op als een base64-gecodeerde reeks in GitHub Secrets en decoderen deze in de werkstroom:
Release- en productiewerkstroom 🚀
De pre-release werkstroom wordt uitgevoerd voor vertakkingen die beginnen met release/v. Alle debugging en interne code wordt verwijderd om ervoor te zorgen dat we dezelfde code testen die zal worden vrijgegeven.
Bovendien worden in de pre-release werkstroom berichten naar verschillende Slack-kanalen gestuurd om QA- en marketingteams via inkomende webhooks op de hoogte te brengen van een nieuwe release.
Nadat alles grondig is getest, maken we een release op GitHub die de productiewerkstroom triggert. Deze bouwt en ondertekent de app met productiecertificaten en stuurt deze naar de App Store.
Meer tips voor uw CI 🦾
Als je de push-trigger voor GitHub Actions gebruikt, zul je waarschijnlijk problemen ondervinden als er snel achter elkaar meerdere pushes naar dezelfde vertakking worden uitgevoerd. Er worden dan meerdere exemplaren van de werkstroom gestart, wat bouwminuten kost of andere problemen veroorzaakt.
- We raden aan om de actie 'Werkstroom annuleren' te gebruiken om alle eerdere Instances van de werkstroom te annuleren.
- Als u op zoek bent naar een eenvoudige en onderhoudsvriendelijke oplossing voor het genereren van opeenvolgende buildnummers, probeer dan de Build Number Generator. U kunt ook de GITHUB_RUN_ID gebruiken, maar die kan niet worden aangepast.
- Bekijk de ClickUp GitHub-app om vertakkingen, commits en GitHub-status rechtstreeks in uw ClickUp-taken te zien. Gebruik ClickUp Automations of de openbare API van ClickUp voor geavanceerde automatiseringen.
Samenvatting 🍩
Het opzetten van uw CI is een leuk proces. Het is gemakkelijk om mee te beginnen en u kunt het gaandeweg verder ontwikkelen. Onze CI is gebaseerd op een van de kernwaarden van ClickUp: Voortgang naar perfectie. We werken voortdurend aan CI-verbeteringen voor onze QA- en engineeringteams.
De combinatie van ClickUp, GitHub Actions en Fastlane is zeer krachtig en maakt het mogelijk om in minder dan een uur een flexibele en volledig geautomatiseerde CI/CD-pijplijn te bouwen. Probeer het eens!
We hebben veel interessante onderwerpen in de pijplijn, dus houd de ClickUp Engineering-blog in de gaten! 🦄