Dengan tim mobile yang terus berkembang dan rilis mingguan, memiliki pipeline CI yang andal sangat penting. Kami perlu dapat membangun dan menguji aplikasi kami serta mengunggahnya ke App Store dan Google Play Store. Kami juga memelihara versi pratinjau internal untuk menguji fitur-fitur terbaru.
Pelajari cara kami menggunakan ClickUp, Fastlane, dan GitHub Actions untuk mengotomatisasi Continuous Integration (CI) dan Continuous Delivery (CD) kami.
Perjalanan sebuah bug 🐜
Mari kita mulai dengan membahas secara singkat proses kami dalam mengelola dan memperbaiki bug.
- Sebuah bug (atau permintaan fitur) dilaporkan dan tugas dibuat di ClickUp.
- Tugas tersebut ditugaskan kepada seorang pengembang dan diperbaiki dalam PR terhadap cabang staging.
- CI menjalankan semua tes, membangun aplikasi, mengunggah pratinjau web, dan mengunggah semuanya ke tugas ClickUp.
- Tim QA kami memverifikasi perbaikan tersebut, dan jika dianggap baik, tugas tersebut akan ditandai sebagai selesai.
- Permintaan pull (PR) secara otomatis digabungkan ke lingkungan staging.
- Cabang staging dibangun dan diimplementasikan ke TestFlight internal kami.
- Setiap Rabu, cabang rilis dibuat, dibangun, dan diuji.
- Setiap Jumat, kami membuat rilis di GitHub dan CI akan mengimplementasikan rilis tersebut ke App Store dan Play Store.
Sebuah tugas ClickUp mencakup semua informasi tentang bug. Kami menggunakan Status Kustom seperti "Dalam Proses" atau "Review Kode" untuk melacak status bug. Alur kerja CI secara otomatis mengubah status tersebut. Bidang Kustom berisi informasi tambahan seperti siapa yang melaporkan bug, siapa yang mengerjakannya, kapan akan dirilis, dan sebagainya.
Alur kerja PR 📜
Langkah pertama dan kedua yang dijelaskan di atas sebenarnya tidak terkait dengan CI, tetapi langkah ketiga cukup menarik…
Alur kerja pengembangan kami berjalan untuk setiap permintaan pull (PR). Alur kerja ini memeriksa linting, format, dan menjalankan semua tes sebelum memulai proses pembangunan artefak Android dan iOS.
Ketika proses build berhasil, CI akan memposting pesan di tugas yang terhubung. Insinyur QA dapat mengunjungi PR, mengunduh artefak build, atau menggunakan pratinjau web.
Pesan CI otomatis yang diposting di tugas ClickUp yang terhubung setelah proses build berhasil.
Mengonfigurasi Flutter pada CI runner 🛠
Kami menggunakan GitHub Action subosito/flutter-action yang terkenal untuk mengonfigurasi Flutter pada CI. Secara default, alat ini akan menginstal rilis stabil terbaru Flutter. Untuk menghindari gangguan pada alur kerja CI Anda saat rilis versi Flutter baru, Anda disarankan untuk menentukan versi secara manual.
Jika Anda memiliki beberapa alur kerja, lebih baik menyimpan versi Flutter dalam berkas. Kami menggunakan FLUTTER_VERSION di akar repositori.
Solusi lain yang mudah adalah menyimpan versi Flutter sebagai rahasia GitHub dan mengaksesnya menggunakan {{ secrets. FLUTER_VERSION }}.
Pratinjau Web 🕸
Berkat kemampuan Flutter untuk berjalan di web, kami dapat membuat pratinjau web yang sepenuhnya fungsional untuk permintaan pull. Dengan menggunakan paket device_preview, ukuran dan pengaturan perangkat dapat disesuaikan.
Fitur pratinjau ini terbukti sangat berguna dan tidak hanya digunakan oleh tim QA kami. Desainer dan Manajer Produk juga menyukainya untuk menguji fitur baru dengan cepat.
melalui Flutter
Cara membuat pratinjau web 🐶
Untuk memulai, pastikan aplikasi Anda kompatibel dengan Flutter web—tidak semua API didukung.
Misalnya, dalam aplikasi kami, kami perlu menonaktifkan notifikasi push dan web sockets.
Alur kerja contoh ini membangun pratinjau web aplikasi Flutter Anda dan mengunggahnya ke bucket S3. Kami menggunakan variabel lingkungan ENABLE_DEVICE_PREVIEW untuk menonaktifkan fitur device_preview di lingkungan produksi.
Langkah Fix base href diperlukan karena pratinjau tidak akan berada di akar bucket.
Dan beberapa kode untuk mengaktifkan secara kondisional fitur device_preview.
Variabel lingkungan adalah alat yang sangat berguna dan memungkinkan algoritma tree shaking Flutter untuk menghapus kode debug pada build rilis.
Fastlane 💨
Fastlane sangat mempermudah proses membangun, menandatangani, dan mendistribusikan aplikasi Flutter. Alat ini mengelola sertifikat, profil penyediaan, dan pengaturan lainnya. Kami menggunakan GitHub secrets untuk menyimpan kata sandi dan token secara aman.
Aksi Fastlane yang berguna:
- fastlane match untuk membuat dan menyimpan kunci dan profil iOS di repositori GitHub.
- build_app untuk mengembangkan aplikasi iOS dan Android.
- unggah ke TestFlight dan kirimkan untuk mengimplementasikan build iOS.
- upload_to_play_store untuk mengimplementasikan build Android.
Contoh build pengembangan iOS 🍏
Jangan lupa setup_ci, ini akan menyelamatkan Anda dari kesalahan aneh 👾. Pelajari lebih lanjut tentang Fastlane untuk aplikasi Flutter.
Penandatanganan Android 🔒
Cara termudah untuk menandatangani build rilis Android secara aman adalah dengan menyimpan token sebagai rahasia GitHub dan menggunakan variabel lingkungan serta kunci sementara yang dibuat oleh CI:
Kami menyimpan kunci .jks sebagai string yang dienkripsi base64 di Github Secrets dan mendekripsinya dalam alur kerja:
Proses rilis dan produksi 🚀
Alur kerja pra-rilis dijalankan untuk cabang yang dimulai dengan release/v. Alur kerja ini menghapus semua kode debugging dan kode internal untuk memastikan kami menguji kode yang sama yang akan dirilis.
Selain itu, alur kerja pra-rilis mengirimkan pemberitahuan ke berbagai saluran Slack untuk memberitahu tim QA dan pemasaran tentang rilis baru menggunakan webhook masuk.
Setelah semuanya diuji secara menyeluruh, kami membuat rilis di GitHub yang memicu alur kerja produksi. Rilis ini membangun dan menandatangani aplikasi dengan sertifikat produksi, lalu mengirimkannya ke App Store.
Tips tambahan untuk CI Anda 🦾
Jika Anda menggunakan pemicu push untuk GitHub Actions, Anda mungkin akan mengalami masalah jika ada beberapa push ke cabang yang sama dalam waktu singkat. Lebih dari satu instance alur kerja akan dimulai dan menghabiskan waktu build atau menyebabkan masalah lain.
- Kami merekomendasikan untuk menggunakan tindakan " Cancel Workflow Action" untuk membatalkan semua instance sebelumnya dari alur kerja.
- Jika Anda mencari solusi yang mudah dan mudah dipelihara untuk menghasilkan nomor build berurutan, coba Build Number Generator. Anda juga dapat menggunakan GITHUB_RUN_ID, tetapi itu tidak dapat disesuaikan.
- Lihat aplikasi ClickUp GitHub untuk melihat cabang, commit, dan status GitHub langsung di tugas ClickUp Anda. Gunakan ClickUp Automations atau API publik ClickUp untuk otomatisasi lanjutan.
Ringkasan 🍩
Membangun CI Anda adalah proses yang menyenangkan. Mudah untuk memulai dan Anda dapat mengembangkannya seiring waktu. CI kami didasarkan pada salah satu Nilai Inti ClickUp: Maju menuju kesempurnaan. Kami terus bekerja untuk meningkatkan CI demi tim QA dan engineering kami.
Kombinasi ClickUp, GitHub Actions, dan Fastlane sangat powerful dan memungkinkan Anda membangun pipeline CI/CD yang fleksibel dan sepenuhnya otomatis dalam waktu kurang dari satu jam. Coba sekarang!
Kami memiliki banyak topik menarik yang akan datang, jadi terus pantau blog Teknik ClickUp! 🦄