A növekvő mobil csapat és a heti kiadások miatt elengedhetetlen egy megbízható CI-folyamat. Képesnek kell lennünk alkalmazásaink fejlesztésére és tesztelésére, valamint azok App Store-ba és Google Play Store-ba való telepítésére. Emellett belső előzetes verziókat is fenntartunk a legújabb funkciók tesztelésére.
Ismerje meg, hogyan használjuk a ClickUp, a Fastlane és a GitHub Actions eszközöket a folyamatos integráció (CI) és a folyamatos szállítás (CD) automatizálásához.
A hiba élete 🐜
Kezdjük azzal, hogy röviden áttekintjük a hibák kezelésének és javításának folyamatát.
- Egy hiba (vagy funkciókérés) bejelentésre kerül, és egy feladat jön létre a ClickUp-ban.
- A feladatot egy fejlesztőnek rendelik, és a staging branch-hez tartozó PR-ben rögzítik.
- A CI futtatja az összes tesztet, összeállítja az alkalmazást, telepíti a webes előnézetet, és mindent feltölt a ClickUp feladatra.
- Minőségbiztosítási csapatunk ellenőrzi a javítást, és ha megfelelő, a feladat elvégzettként kerül megjelölésre.
- A PR automatikusan beolvad a stagingbe.
- A staging branch felépítésre kerül és telepítésre kerül a belső TestFlight rendszerünkre.
- Minden szerdán létrehozunk, összeállítunk és tesztelünk egy kiadási ágat.
- Péntekenként létrehozunk egy kiadást a GitHubon, és a CI telepíti a kiadást az App Store-ba és a Play Store-ba.
A ClickUp feladatok minden információt tartalmaznak a hibáról. A hiba nyomon követéséhez egyéni állapotokat használunk, például „Folyamatban” vagy „Kódfelülvizsgálat”. A CI munkafolyamatok automatikusan megváltoztatják az állapotot. Az egyéni mezők további információkat tartalmaznak, például ki jelentette a hibát, ki dolgozik rajta, mikor fog megjelenni stb.
PR munkafolyamat 📜
A fentiekben ismertetett első két lépés nem igazán kapcsolódik a CI-hez, de a harmadik érdekes...
Fejlesztési munkafolyamatunk minden PR esetében fut. Ellenőrzi a lintokat, a formázást és lefuttatja az összes tesztet, mielőtt megkezdené az Android és iOS artefaktumok építését.
Ha a build sikeres, a CI üzenetet küld a kapcsolódó feladathoz. A minőségbiztosítási mérnökök a PR-hez léphetnek, letölthetik a build artefaktumokat vagy használhatják a webes előnézetet.
Automatizált CI üzenet, amelyet a sikeres összeállítás után a kapcsolódó ClickUp feladathoz csatoltak.
A Flutter beállítása a CI futtatóprogramon 🛠
A jól ismert GitHub action subosito/flutter-action eszközt használjuk a Flutter beállításához a CI-n. Alapértelmezés szerint ez a legújabb stabil Flutter verziót telepíti. Annak érdekében, hogy a CI munkafolyamatok ne szakadjanak meg egy új Flutter verzió megjelenésekor, a verziót manuálisan kell megadni.
Ha több munkafolyamatod van, akkor jobb, ha a flutter verziót egy fájlban tárolod. Mi a FLUTTER_VERSION-t használjuk a repository gyökérkönyvtárában.
Egy másik egyszerű megoldás az, hogy a Flutter verziót GitHub titokként tárolja, és a {{ secrets. FLUTER_VERSION }} segítségével érje el.
Webes előnézet 🕸
A Flutter webes futtathatóságának köszönhetően teljes funkcionalitású webes előnézetet hozhatunk létre a pull requestekről. A device_preview csomag segítségével a készülék mérete és beállításai módosíthatók.
Az előnézet nagyon hasznosnak bizonyult, és nem csak a minőségbiztosítási csapatunk használja. A tervezők és a termékmenedzserek is kedvelik, mert segítségével gyorsan iterálhatnak az új funkciókon.
a Flutter segítségével
Hogyan készítsünk webes előnézetet 🐶
A kezdéshez győződjön meg arról, hogy alkalmazása kompatibilis a Flutter webes verziójával – nem minden API támogatott.
Alkalmazásunkban például le kellett tiltani a push értesítéseket és a web socketeket.
Ez a minta munkafolyamat webes előnézetet készít a Flutter alkalmazásáról, és feltölti azt egy S3-tárolóba. Az ENABLE_DEVICE_PREVIEW környezeti változót használjuk a device_preview letiltására a termelésben.
A Fix base href lépés azért szükséges, mert az előnézet nem a tároló gyökérkönyvtárában lesz.
És néhány kód, amely feltételesen engedélyezi a device_preview funkciót.
A környezeti változók hatékony eszközök, amelyek lehetővé teszik a Flutter fa-rázási algoritmusának, hogy a kiadási verziókhoz a hibakeresési kódot elhagyja.
Fastlane 💨
A Fastlane jelentősen leegyszerűsíti a Flutter alkalmazások létrehozását, aláírását és telepítését. Kezeljük vele tanúsítványainkat, provisioning profiljainkat és egyéb beállításainkat. A GitHub titkokat használjuk a jelszavak és tokenek biztonságos tárolására.
Hasznos Fastlane műveletek:
- fastlane match az iOS-kulcsok és profilok létrehozásához és tárolásához egy GitHub-tárolóban
- build_app iOS és Android alkalmazások készítéséhez
- upload_to_testflight és szállítás iOS-verziók telepítéséhez
- upload_to_play_store az Android-verziók telepítéséhez
iOS fejlesztői build minta 🍏
Ne felejtse el a setup_ci-t, ez megkíméli Önt a furcsa hibáktól 👾. Tudjon meg többet a Fastlane for Flutter alkalmazásokról.
Android aláírás 🔒
Az Android-kiadások biztonságos aláírásának legegyszerűbb módja, ha a tokeneket GitHub-titkokként tárolja, és környezeti változókat és ideiglenes kulcsot használ. A CI által létrehozott jks:
A kulcsot jks formátumban tároljuk base64 kódolású karakterláncként a Github Secrets-ben, és a munkafolyamatban dekódoljuk:
Kiadási és termelési munkafolyamat 🚀
A kiadás előtti munkafolyamat a release/v-vel kezdődő ágaknál fut. Ez eltávolítja az összes hibakeresési és belső kódot, hogy biztosan ugyanazt a kódot teszteljük, amelyet kiadunk.
Ezenkívül a kiadás előtti munkafolyamat különböző Slack-csatornákra küld bejegyzéseket, hogy a beérkező webhookok segítségével értesítse a minőségbiztosítási és marketing csapatokat az új kiadásról.
Miután mindent alaposan teszteltünk, létrehozunk egy kiadást a GitHubon, amely elindítja a termelési munkafolyamatot. Ez összeállítja és aláírja az alkalmazást a termelési tanúsítványokkal, majd elküldi az App Store-ba.
További trükkök a CI-hez 🦾
Ha a GitHub Actions push triggerét használja, akkor valószínűleg problémákba ütközik, ha több push történik gyorsan egymás után ugyanazon az ágon. Több példány indul el a munkafolyamatból, ami felemészti a build perceket, vagy más problémákat okoz.
- Javasoljuk a Munkafolyamat-művelet törlése funkció használatát az összes korábbi munkafolyamat-példány törléséhez.
- Ha egyszerű és karbantartható megoldást keres a sorszámok generálásához, próbálja ki a Build Number Generator alkalmazást. Használhatja a GITHUB_RUN_ID-t is, de az nem testreszabható.
- Nézze meg a ClickUp GitHub alkalmazást, hogy a ClickUp feladataiban közvetlenül láthassa az ágakat, a commitokat és a GitHub állapotát. Használja a ClickUp Automations vagy a ClickUp nyilvános API-ját a fejlett automatizáláshoz.
Összefoglalás 🍩
A CI felépítése szórakoztató folyamat. Könnyű elkezdeni, és folyamatosan fejlesztheti. CI-nk a ClickUp egyik alapértékét követi: A tökéletesség felé haladva. Folyamatosan dolgozunk a CI fejlesztésén a minőségbiztosítási és mérnöki csapataink számára.
A ClickUp, a GitHub Actions és a Fastlane kombinációja nagyon hatékony, és lehetővé teszi egy rugalmas és teljesen automatizált CI/CD folyamat felépítését kevesebb mint egy óra alatt. Próbálja ki!
Sok érdekes téma vár még ránk, ezért érdemes rendszeresen ellátogatni a ClickUp mérnöki blogjára! 🦄