Hari rilis dalam pengembangan aplikasi: esensi, tahapan dan persiapan

Q: Hari apa yang terbaik untuk merilis aplikasi mobile?

Hari terbaik — Selasa, Rabu atau Kamis. Senin — lalu lintas tinggi dari akhir pekan, Jumat — risiko memasuki akhir pekan dengan rilis yang bermasalah. Hindari Jumat: jika setelah deploy ditemukan masalah, tim akan memperbaikinya di akhir pekan atau menunggu hingga Senin.

Q: Apa yang harus dilakukan jika App Store Review menolak build?

Baca alasan penolakan di Resolution Center, perbaiki dan unggah ulang build. Penyebab umum: tautan tidak berfungsi, bidang tidak diisi, konten tanpa langganan (jika diperlukan), tangkapan layar usang. App Review rejection menunda rilis 24-48 jam, oleh karena itu unggahan build pertama harus dilakukan 3-5 hari sebelum tanggal rilis yang direncanakan.

Q: Berapa persentase staged rollout yang optimal untuk memulai?

Untuk rilis besar (major changes) — 1%. Untuk patch rilis — 5-10%. Tahap pertama harus cukup kecil sehingga jika terjadi kesalahan dampaknya minimal, tetapi cukup besar untuk mendapatkan metrik yang signifikan secara statistik. 1% untuk aplikasi dengan 10 juta pengguna — 100 ribu orang, cukup untuk menemukan masalah kritis.

Q: Apakah perlu mengadakan pesta rilis?

Release party (perayaan tim) — opsional, tetapi baik untuk moral. Lebih baik dilakukan setelah rollout berhasil 100%, bukan pada saat mengunggah build. Release celebration dapat digabungkan dengan release retrospective untuk mendiskusikan apa yang berjalan dengan baik dan apa yang dapat ditingkatkan.

Q: Siapa yang bertanggung jawab atas keputusan "rilis atau tunda"?

Tanggung jawab ada pada release manager (biasanya senior engineer atau tech lead). Keputusan dibuat berdasarkan data dari release dashboard, bukan berdasarkan tenggat waktu. Release manager memiliki wewenang untuk menunda rilis jika metrik tidak lolos go/no-go gate.

Penulis: IT Sectr Diterbitkan: 2026-08-07 Waktu membaca: 8 mnt

Hari rilis (release day) — tanggal yang direncanakan untuk merilis versi baru aplikasi mobile, termasuk persiapan build, review toko, staged rollout, dan pemantauan. Untuk aplikasi iOS, proses dimulai dengan mengunggah build ke App Store Connect 24-48 jam sebelum tanggal rilis yang direncanakan karena review Apple yang wajib. Untuk Android — pembuatan dan unggah ke Google Play Console, di mana proses review biasanya memakan waktu 1-4 jam. Menurut Apple Developer Guidelines (2025), 90% build melewati review dalam 24 jam. Staged rollout memungkinkan meminimalkan dampak jika ditemukan kesalahan setelah publikasi.

Poin utama

Release day — serangkaian tindakan dari pembuatan build hingga pemantauan setelah rollout
Staged rollout — peluncuran bertahap: 1%, 10%, 50%, 100%
Smoke testing — pemeriksaan akhir build sebelum dikirim ke toko
Rollback plan — skenario pengembalian yang disiapkan sebelumnya untuk kesalahan kritis
Release retrospective — analisis proses setelah rollout selesai 100%

Apa itu hari rilis dan bagaimana mempersiapkannya

Hari rilis — bukan hanya momen menekan tombol Publish. Ini adalah proses terkoordinasi yang melibatkan pengembang, QA, devops, product manager, dan terkadang dukungan. Persiapan dimulai 2-3 minggu sebelum hari rilis: penyesuaian scope, code freeze, pengujian regresi, persiapan release notes dan materi pemasaran. Semakin teliti persiapannya, semakin tenang hari rilis berjalan.

Checklist persiapan untuk hari rilis meliputi: proses QA akhir (regression + smoke suite) pada build rilis; pemeriksaan metadata di toko (nama, deskripsi, tangkapan layar, keywords); penyesuaian persentase staged rollout dengan product manager; persiapan rencana rollback (tag mana yang akan di-deploy ulang, berapa lama waktu yang dibutuhkan); pemberitahuan kepada tim dan layanan terkait tentang rilis yang akan datang. Release checklist harus diotomatisasi melalui CI/CD — misalnya, dalam bentuk GitHub Actions workflow yang memeriksa semua poin sebelum membuat tag rilis.

Elemen penting dari persiapan — periode blackout (periode ketika deploy ke produksi dilarang). Biasanya blackout diberlakukan 48 jam sebelum hari rilis dan dicabut 24 jam setelah rollout berhasil 100%. Ini mencegah deploy tidak sengaja yang dapat mengganggu rilis. Change freeze selama periode blackout berlaku untuk semua layanan yang terkait dengan rilis.

Persiapan build: code freeze, penandaan dan pembuatan

24-48 jam sebelum hari rilis, code freeze diberlakukan — penghentian total perubahan pada kode. Pengembang beralih ke persiapan dokumentasi dan release notes. DevOps membuat build rilis dari tag yang ditetapkan (misalnya v2.6.0-rc1). Build menjalani regression suite lengkap (tes otomatis + manual). Jika ditemukan critical bugs — diperbaiki sebelum code freeze atau rilis ditunda. Release candidate (RC) — build yang telah melewati QA dan siap dikirim ke toko.

Penandaan di Git: tag anotasi dibuat (git tag -a v2.6.0 -m "Release v2.6.0"). Pipeline CI/CD membuat AAB (Android App Bundle) untuk Google Play dan IPA (iOS App Store Package) untuk Apple App Store. Build dilampiri: file checksum (SHA256), changelog dan daftar masalah yang diketahui (known issues). Reproducible builds — praktik ideal di mana pembuatan ulang dari tag yang sama memberikan hasil biner yang identik.

bash

# Pipeline rilis — pembuatan tag dan pembangunan
# Mengasumsikan code freeze sudah aktif

# Buat cabang rilis dari develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0

# Code freeze: aturan perlindungan cabang memblokir PR baru
# Jalankan suite regresi di CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest

# Buat tag rilis setelah QA berhasil
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0

# Bangun biner rilis melalui CI/CD
# fastlane build_release menghasilkan AAB + APK universal
fastlane build_release

Penting: version bump (pembaruan version code dan version name) dilakukan sebelum code freeze. Setelah code freeze, versi tidak berubah. Untuk Android: versionCode — bilangan bulat yang meningkat secara monoton; versionName — versi semantik (2.6.0). Untuk iOS: CFBundleVersion (build number) dan CFBundleShortVersionString (versi semantik). Versioning harus diotomatisasi di gradle/xcconfig.

Unggah ke toko dan melewati review

Untuk iOS: build diunggah melalui Xcode, Transporter atau fastlane ke App Store Connect. Setelah diunggah, build menjalani pemeriksaan otomatis Apple (processing), kemudian dikirim ke review manual. Waktu review rata-rata — 24 jam, tetapi dapat bervariasi dari 1 jam hingga 7 hari tergantung pada beban reviewer Apple dan persyaratan kepatuhan. Expedited review — permintaan review dipercepat untuk perbaikan bug kritis (tersedia maksimal sekali sebulan, tidak dijamin).

Untuk Android: build diunggah melalui Google Play Console. Google menggunakan pendekatan gabungan: pengujian otomatis (accessibility, malware, policy compliance) + review manual selektif. Waktu review rata-rata — 1-4 jam. Internal test track dan Closed track memungkinkan pengujian akhir sebelum dipublikasikan ke Production track. Direkomendasikan: 1-2 hari untuk Internal test → 1 hari untuk Closed beta → rollout Production bertahap.

Untuk kedua platform, memeriksa metadata sebelum mengunggah build sangat penting: nama aplikasi, deskripsi (short + full), tangkapan layar untuk setiap perangkat yang didukung (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) atau store listing experiments (Android). Kesalahan dalam metadata dapat menunda review satu hari tambahan. App metadata harus dilokalisasi ke semua bahasa yang didukung.

Staged rollout: cara meluncurkan rilis tanpa risiko

Staged rollout (gradual rollout, staged deployment) — strategi di mana versi baru tersedia bagi pengguna tidak segera, tetapi secara bertahap. Skema tipikal untuk tim matang: 1% pengguna (2-4 jam pertama) → 10% (24 jam) → 25% (24 jam) → 50% (24 jam) → 100%. Setiap tahap mencakup pemantauan metrik dan pemeriksaan tidak adanya kesalahan kritis. Staged rollout — alat utama untuk meminimalkan risiko saat rilis.

Google Play Console menyediakan staged rollout bawaan: Anda dapat menentukan persentase pengguna dan merencanakan peningkatan bertahap. Untuk iOS App Store Connect tidak ada kemampuan bawaan seperti itu — staged rollout diimplementasikan melalui Phased Release (peningkatan cakupan otomatis selama 7 hari dengan kemampuan menjeda) atau melalui server-side feature flags dengan distribusi geografis. Phased release di App Store Connect memberikan kemampuan untuk Menjeda Rilis (Pause Release) jika ditemukan masalah.

Metrik utama untuk transisi ke tahap berikutnya: crash-free rate (≥99.9% untuk rilis baru), ANR rate (Android, ≤0.1%), error rate pada backend API (≤0.5% 5xx), peringkat pengguna (tidak lebih rendah dari versi sebelumnya), apdex score (≥0.94). Jika metrik apa pun melebihi ambang batas — rollout dijeda sampai penyebabnya ditemukan. Go/no-go gate di setiap tahap — tanggung jawab release manager atau insinyur on-call.

Pemantauan setelah rilis: apa yang diperhatikan di jam-jam pertama

4 jam pertama setelah rilis — waktu paling kritis. Tim memantau crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx di backend, custom events (pembayaran berhasil, login, pendaftaran), peringkat pengguna di App Store dan Google Play, penyebutan media sosial (Twitter, Reddit). Dasbor pemantauan harus disiapkan sebelumnya dan tersedia di layar besar di kantor atau di saluran Slack khusus. Release dashboard — jendela tunggal untuk semua metrik rilis.

Perhatian khusus — metrik regresi: perbandingan crash rate dengan versi sebelumnya untuk periode yang sama. Jika crash rate meningkat lebih dari 0.1% — ini adalah bendera merah yang memerlukan analisis segera. Juga penting untuk membandingkan latensi median dan p95 dari endpoint API utama: bahkan tanpa crash, perlambatan waktu respons sebesar 200ms dapat menandakan masalah. Metric comparison (baseline vs current) diotomatisasi di Datadog atau Grafana.

Umpan balik pengguna — tidak kalah pentingnya dengan metrik numerik. Di jam-jam pertama setelah rilis, pengguna secara aktif meninggalkan ulasan di toko dan menulis ke dukungan. Bug yang tidak tertangkap oleh pengujian dengan cepat muncul di ulasan. Team lead atau insinyur QA yang ditunjuk memantau ulasan setiap 30 menit dalam 4 jam pertama dan mengklasifikasikannya: false positive, known issue (sudah dalam daftar known issues), new bug. New bugs P0/P1 — pemicu untuk menjeda rollout.

Rollback: kapan dan bagaimana menarik kembali rilis

Rollback — kembali ke versi stabil sebelumnya ketika ditemukan masalah kritis. Keputusan rollback diambil oleh release manager bersama dengan tech lead, jika: crash-free rate rilis baru turun di bawah 99%, ditemukan kebocoran data, fungsionalitas kritis (pembayaran, otorisasi) tidak berfungsi untuk >5% pengguna, atau toko (App Store Review) menolak build setelah publikasi. Rollback trigger harus ditentukan sebelum rilis, sehingga keputusan dibuat berdasarkan fakta, bukan emosi.

Untuk Android: rollback di Google Play Console — menghentikan staged rollout dan beralih ke versi sebelumnya. Jika build saat ini sudah pada 100% pengguna — publikasi versi sebelumnya sebagai rilis baru. Untuk iOS: melalui App Store Connect — Phased Release → Pause Release → merilis versi baru dengan perbaikan (App Store tidak memungkinkan kembali ke versi sebelumnya). iOS rollback lebih kompleks: pengembang harus membuat build baru dengan revert-commit dan melewati review lagi.

Setelah rollback, tim beralih ke mode insiden: root cause analysis, hotfix atau rilis berikutnya dengan perbaikan, post-mortem. Rollback — bukan kegagalan, melainkan prosedur standar. Tim yang tidak pernah melakukan rollback kemungkinan besar tidak melihat masalahnya, bukan merilis tanpa bug. Rollback rate — salah satu metrik DORA: tim berkinerja tinggi melakukan rollback pada <10% rilis dan pulih dalam <1 jam.

Pertanyaan yang sering diajukan

Hari apa yang terbaik untuk merilis aplikasi mobile?

Hari terbaik — Selasa, Rabu atau Kamis. Senin — lalu lintas tinggi dari akhir pekan, Jumat — risiko memasuki akhir pekan dengan rilis yang bermasalah. Hindari Jumat: jika setelah deploy ditemukan masalah, tim akan memperbaikinya di akhir pekan atau menunggu hingga Senin.

Apa yang harus dilakukan jika App Store Review menolak build?

Baca alasan penolakan di Resolution Center, perbaiki dan unggah ulang build. Penyebab umum: tautan tidak berfungsi, bidang tidak diisi, konten tanpa langganan (jika diperlukan), tangkapan layar usang. App Review rejection menunda rilis 24-48 jam, oleh karena itu unggahan build pertama harus dilakukan 3-5 hari sebelum tanggal rilis yang direncanakan.

Berapa persentase staged rollout yang optimal untuk memulai?

Untuk rilis besar (major changes) — 1%. Untuk patch rilis — 5-10%. Tahap pertama harus cukup kecil sehingga jika terjadi kesalahan dampaknya minimal, tetapi cukup besar untuk mendapatkan metrik yang signifikan secara statistik. 1% untuk aplikasi dengan 10 juta pengguna — 100 ribu orang, cukup untuk menemukan masalah kritis.

Apakah perlu mengadakan pesta rilis?

Release party (perayaan tim) — opsional, tetapi baik untuk moral. Lebih baik dilakukan setelah rollout berhasil 100%, bukan pada saat mengunggah build. Release celebration dapat digabungkan dengan release retrospective untuk mendiskusikan apa yang berjalan dengan baik dan apa yang dapat ditingkatkan.

Siapa yang bertanggung jawab atas keputusan "rilis atau tunda"?

Tanggung jawab ada pada release manager (biasanya senior engineer atau tech lead). Keputusan dibuat berdasarkan data dari release dashboard, bukan berdasarkan tenggat waktu. Release manager memiliki wewenang untuk menunda rilis jika metrik tidak lolos go/no-go gate.

Kesimpulan

Hari rilis — proses terkoordinasi dari code freeze hingga pemantauan setelah rollout
Persiapan — release candidate, proses QA, pemeriksaan metadata, rencana rollback
Staged rollout — 1% → 10% → 25% → 50% → 100% dengan go/no-go gate di setiap tahap
Pemantauan — crash-free rate, ANR, error rate 5xx, peringkat pengguna dalam 4 jam pertama
Rollback — prosedur standar ketika crash-free rate turun di bawah 99%
Komunikasi — pemberitahuan tim dan pemangku kepentingan sebelum dan setelah rilis
Release retrospective — analisis proses setelah rollout selesai 100%

Kami akan mengembangkan aplikasi seluler turnkey

IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.

Diskusikan proyek