Belajar Flutter - Operational Readiness & Runbooks

#Pendahuluan

Aplikasi yang dikirim bukan akhir perjalanan — justru awal tanggung jawab operasional. Episode 19 mempersiapkan kalian untuk menjaga aplikasi di produksi: runbook untuk menangani crash dan masalah rilis, monitoring stabilitas lewat analytics dan error reporting, strategi rollout dan rollback, serta workflow tim untuk maintenance.

#Runbook untuk App Crashes dan Release Issues

#Apa itu Runbook

Runbook adalah dokumen langkah demi langkah untuk menangani insiden. Tanpa runbook, tim panik dan membuat keputusan ad hoc saat produksi bermasalah. Runbook yang baik menjawab tiga pertanyaan: apa gejalanya, siapa yang bertanggung jawab, dan apa langkah mitigasinya.

#Runbook Crash yang Layak

Minimal, dokumentasikan skenario paling sering:

• Crash rate melonjak: identifikasi versi yang terpengaruh, cek error reporting, pertimbangkan rollback (di bawah).
• Login gagal massal: cek status backend dan konfigurasi environment.
• Rilis tidak muncul: verifikasi build number dan jalur app store / release channel.

Judul: Crash rate di atas ambang batas
Trigger: Crashlytics memperingatkan crash rate > 1%
Langkah 1: Buka dashboard crash teratas pada versi aktif.
Langkah 2: Cek apakah terkait rilis terakhir (diff commit).
Langkah 3: Jika ya, aktifkan rollback ke versi stabil sebelumnya.
Langkah 4: Catat insiden di ticket dan kabari tim.

Simpan runbook di repository tim atau wiki, dan tinjau ulang setiap bulan. Runbook yang tidak pernah diuji sama buruknya dengan tidak punya runbook.

#Monitoring, Analytics, dan Error Reporting

#Error Reporting dengan Firebase Crashlytics

Crash yang tidak dilaporkan tidak pernah diperbaiki. Integrasikan error reporting sejak dini:

flutter pub add firebase_crashlytics firebase_core

Inisialisasi Firebase di main:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp();
  runApp(const MyApp());
}

Firebase.initializeApp() menyiapkan konfigurasi Firebase sebelum aplikasi di-render. Untuk menangkap error yang tidak tertangani, pasang handler global di runApp dengan FlutterError.onError yang meneruskan ke Crashlytics.

#Logging Error Non-Fatal

Selain crash, catat error yang tidak mematikan:

try {
  await repository.sync();
} catch (e) {
  FirebaseCrashlytics.instance.recordError(e, StackTrace.current);
}

FirebaseCrashlytics.instance.recordError mengirim error non-fatal ke dashboard. Jangan mencatat data sensitif — sanitasi pesan error sebelum dikirim.

#Analytics untuk Konteks

Analytics (misal Firebase Analytics atau Sentry) memberi konteks: pengguna macam apa yang mengalami masalah, di layar mana, dan dengan versi apa. Konteks ini mengubah error reporting dari "ada crash" menjadi "crash pada layar checkout untuk pengguna versi 1.2.0 di Android 14".

#Rollout Strategies dan Rollback

#Rilis Bertahap untuk Mengurangi Risiko

Jangan rilis ke 100 persen pengguna sekaligus. Strategi bertahap:

• Staged rollout: 10 persen dulu, lalu naik bertahap bila stabil.
• Feature flag: aktifkan fitur baru untuk sebagian pengguna tanpa rilis baru.
• Canary / internal track: uji pada pengguna internal sebelum publik.

flutter run --release -t lib/main.dart

flutter run --release -t lib/main.dart memakai entry point tertentu. Untuk multiple entry point, tiap -t menargetkan konfigurasi berbeda — pola yang dipakai untuk memisahkan build staging dan production.

#Rollback yang Terencana

Rollback harus lebih cepat daripada perbaikan kode:

• Simpan artifact versi sebelumnya di tempat yang selalu bisa diambil.
• Dengan Play Store, pilih versi sebelumnya di dashboard.
• Catat waktu rollback dan alurnya di runbook.

Keputusan rollback harus dibuat berdasarkan data (crash rate, error rate), bukan perasaan. Tentukan ambang batas saat perencanaan rilis, bukan saat panik.

#Team Workflows untuk Maintenance

#Disiplin Ticket dan Prioritas

Semua pekerjaan maintenance mengalir dari ticket atau alert:

• P0 — kritis: crash massal, data hilang. Respons segera, rollback.
• P1 — tinggi: fitur utama rusak sebagian. Perbaiki di release berikutnya.
• P2 — normal: bug kecil. Masuk sprint normal.

Definisikan aturan ini dengan tim dan tempelkan di tempat yang terlihat.

#Ritme Release yang Teratur

Rilis kecil dan sering lebih aman daripada rilis besar yang jarang:

flutter analyze && flutter test

flutter analyze && flutter test adalah pintu masuk rilis. Kombinasikan dengan semantic-release (episode 14) untuk menghasilkan changelog dan versi otomatis, dan pastikan runbook diperbarui setiap kali alur berubah.

#Penutup

Inti yang harus dibawa pulang:

• Runbook menjawab gejala, penanggung jawab, dan langkah mitigasi.
• Integrasikan Crashlytics dan catat error non-fatal sejak awal.
• Analytics memberi konteks pengguna dan versi pada setiap insiden.
• Rilis bertahap dan feature flag mengurangi risiko rollout.
• Siapkan jalur rollback dan ambang batas keputusan sebelum rilis.
• Terapkan prioritas insiden P0-P2 dan ritme rilis yang teratur.

Di episode 20 selanjutnya kita membahas real-world use cases dan patterns — contoh kasus e-commerce, fintech, productivity, dan SaaS apps, design patterns MVVM, Clean Architecture, dan Redux, feature-driven development dan iterative releases, serta cara membangun produk Flutter yang maintainable. Kalian melihat gambaran besar dari semuanya.