Apa yang Berbeda Saat Mengirim Aplikasi Mobile

Jika Anda bertahun-tahun mengirim aplikasi web, pengiriman aplikasi mobile terasa seperti melangkah ke dunia yang berbeda. Dengan aplikasi web, Anda membangun, mengunggah ke server, dan selesai. Pengguna menyegarkan browser mereka, dan mereka melihat versi terbaru. Anda mengendalikan semuanya: server, infrastruktur, waktu rilis.

Aplikasi mobile tidak bekerja seperti itu. Dan perbedaannya cukup dalam sehingga seluruh pipeline CI/CD Anda perlu berubah.

Aplikasi Hidup di Perangkat Orang Lain

Perbedaan pertama dan paling mendasar adalah di mana aplikasi sebenarnya berjalan. Aplikasi mobile tidak hidup di server yang Anda kelola. Ia hidup di perangkat di saku seseorang. Anda tidak bisa mengganti file di server. Anda tidak bisa mendorong hotfix dan membuatnya berlaku seketika.

Setiap kali Anda ingin mengirim versi baru, Anda harus membangun ulang aplikasi, menandatanganinya secara digital, dan mengirimkannya ke toko aplikasi. Kemudian pengguna harus mengunduh dan menginstal pembaruan itu sendiri. Beberapa pengguna akan memperbarui segera. Yang lain akan mengabaikan notifikasi selama berminggu-minggu. Beberapa tidak akan pernah memperbarui sama sekali.

Ini mengubah cara Anda berpikir tentang pengiriman. Anda tidak bisa berasumsi semua orang menggunakan versi terbaru. Anda tidak bisa memperbaiki bug kritis dan membuatnya menjangkau semua pengguna dalam hitungan menit. Kendali yang Anda miliki dengan pengiriman web telah hilang.

Dua Platform, Dua Sistem Build

Pengiriman mobile berarti berurusan dengan beberapa sistem build. Android menggunakan Gradle. iOS menggunakan Xcode. Masing-masing memiliki aturan sendiri tentang versi SDK, dependensi, dan format output. Anda tidak bisa membangun aplikasi Android di macOS dan mengirimkannya ke pengguna iOS, atau sebaliknya.

Pipeline Anda perlu menangani dua jalur build terpisah. Mereka bisa berjalan paralel atau berurutan, tergantung pada pengaturan Anda, tetapi mereka tidak pernah sama. Konfigurasi build untuk Android ada di file Gradle. Konfigurasi build untuk iOS ada di file proyek Xcode dan skema. Dependensi dikelola secara berbeda. Proses penandatanganan benar-benar berbeda.

Jika Anda mendukung kedua platform, pipeline CI/CD Anda secara efektif menjadi dua pipeline yang berbagi beberapa logika pengujian dan notifikasi tetapi bercabang pada langkah build.

Penandatanganan Bukan Opsional

Sebelum aplikasi mobile dapat diinstal di perangkat pengguna, aplikasi harus ditandatangani secara digital. Tanda tangan ini membuktikan bahwa aplikasi berasal dari Anda, bukan dari orang yang berpura-pura menjadi Anda. Android menggunakan file keystore. iOS menggunakan sertifikat dan profil provisioning.

Ini adalah file rahasia. Jika bocor, orang lain dapat menerbitkan aplikasi yang terlihat seperti milik Anda. Jika Anda kehilangannya, Anda tidak akan pernah bisa mengirim pembaruan lain ke aplikasi yang sudah ada di Play Store atau App Store. Tidak ada pemulihan. Anda harus membuat daftar aplikasi baru dan kehilangan semua pengguna yang ada.

Di pipeline Anda, file-file ini harus disimpan dengan aman. Jangan pernah hardcode di repositori Anda. Jangan pernah commit ke version control. Gunakan pengelola rahasia, penyimpanan terenkripsi di sistem CI Anda, atau layanan penandatanganan khusus. Pipeline hanya boleh mengakses file-file ini selama langkah penandatanganan dan tidak di tempat lain.

Toko Mengontrol Waktu Rilis Anda

Anda tidak bisa begitu saja mengirim file APK atau IPA ke pengguna. Aplikasi harus melalui toko aplikasi. Google Play Store dan Apple App Store keduanya memiliki proses review. Google Play biasanya review dalam hitungan jam. Review Apple bisa lebih lama dan seringkali lebih ketat.

Ini berarti waktu antara saat build Anda selesai dan saat pengguna mulai menggunakan versi baru tidak berada di bawah kendali Anda. Pihak ketiga yang memutuskan kapan aplikasi Anda tayang. Jika mereka menolak pengiriman Anda, Anda harus memperbaiki masalah, membangun ulang, dan mengirim ulang. Waktu direset.

Ini juga mempengaruhi strategi rollback Anda. Di web, rollback berarti menyebarkan versi sebelumnya. Di mobile, Anda tidak bisa memaksa pengguna untuk kembali. Pengguna yang sudah memperbarui akan tetap menggunakan versi yang rusak sampai Anda mengirimkan perbaikan. Dan perbaikan itu harus melalui review lagi.

Rilis Bertahap Menjadi Penting

Karena Anda tidak bisa rollback dengan mudah, Anda perlu berhati-hati tentang cara Anda merilis. Baik Android maupun iOS mendukung rilis bertahap. Android menyebutnya staged rollout. iOS menyebutnya phased release.

Idenya sederhana: Anda merilis versi baru ke persentase kecil pengguna terlebih dahulu. Mungkin 1% atau 5%. Anda memantau laporan crash, tingkat kesalahan, dan umpan balik pengguna. Jika semuanya terlihat baik, Anda memperluas rilis ke 10%, lalu 25%, lalu 50%, lalu 100%. Jika ada yang salah, Anda menjeda rilis. Hanya kelompok kecil pengguna yang sudah menerima pembaruan yang terpengaruh.

Ini bukan opsional untuk pengiriman mobile yang serius. Ini adalah cara utama untuk mengurangi risiko ketika Anda tidak bisa langsung rollback.

Apa Artinya Ini untuk Pipeline Anda

Semua perbedaan ini menghasilkan pipeline CI/CD yang sangat berbeda dari pipeline web. Pipeline mobile Anda harus menangani:

Diagram alir berikut menunjukkan dua jalur secara berdampingan, menyoroti di mana mobile menambahkan gerbang tambahan.

flowchart TD subgraph Web W1[Build] --> W2[Upload to server] W2 --> W3[Users refresh browser] end subgraph Mobile M1[Build] --> M2[Sign app] M2 --> M3[Submit to store] M3 --> M4[Store review] M4 --> M5[User downloads update] end W1 -.-> M1
  • Build spesifik platform dengan toolchain yang berbeda
  • Penandatanganan aman dengan rahasia yang tidak boleh bocor
  • Unggah ke toko aplikasi dengan pengiriman otomatis
  • Strategi rilis bertahap yang bisa dijeda atau diperluas

Anda juga perlu berpikir tentang pengujian secara berbeda. Emulator dan simulator dapat menangkap banyak masalah, tetapi tidak sempurna. Beberapa bug hanya muncul di perangkat nyata dengan perangkat keras, sensor, atau kondisi jaringan tertentu. Pipeline Anda harus mencakup pengujian otomatis pada perangkat virtual dan proses pengujian pada perangkat fisik sebelum rilis penuh.

Daftar Periksa Cepat untuk CI/CD Mobile

  • Simpan kunci penandatanganan dan sertifikat di pengelola rahasia yang aman, bukan di repositori Anda
  • Siapkan job build terpisah untuk Android dan iOS dengan toolchain masing-masing
  • Otomatiskan unggah ke Google Play Console dan App Store Connect
  • Terapkan staged rollout atau phased release di pipeline Anda
  • Tambahkan pelaporan crash dan pemantauan yang memicu peringatan selama rilis bertahap
  • Uji pada emulator dan perangkat nyata sebelum memperluas persentase rilis

Kesimpulan

Pengiriman mobile bukanlah pengiriman web dengan langkah build yang berbeda. Aplikasi hidup di perangkat yang tidak Anda kendalikan. Toko mengontrol waktu rilis Anda. Rollback bukan tombol yang Anda tekan. Pipeline CI/CD Anda harus memperhitungkan realitas ini sejak awal. Bangun untuk platform, tandatangani dengan aman, rilis secara bertahap, dan pantau tanpa henti. Itulah satu-satunya cara untuk mengirim aplikasi mobile tanpa terbangun karena insiden produksi yang tidak bisa Anda perbaiki sampai siklus review berikutnya.