Learn Jetpack Compose - Operational Readiness & Runbooks

#Introduction

An application that's good in development isn't necessarily good in the hands of millions of users. Episode 19 moves you into operations mode: how to monitor application health, handle crashes with a clear runbook, and release new versions without disrupting users.

Compose adds a new dimension to operations: besides ordinary crashes, there are typical issues like jank and excessive recomposition. Both need to be monitored and diagnosed with the right tools.

Episode 19 covers crash and regression runbooks, monitoring, release processes, and design consistency.

#Runbooks for Crashes and Regressions

#Writing a Runbook

A runbook is a written procedure for handling incidents. A Compose crash runbook should include: early signs, diagnosis steps, and mitigation. For example, for a crash spike:

1. Cek dashboard crash terbaru (Firebase Crashlytics)
2. Kelompokkan berdasarkan stack trace dan versi app
3. Jika terkait layout baru, nonaktifkan fitur dengan remote config
4. Verifikasi di emulator dengan versi yang sama
5. Rilis hotfix dengan versionCode naik

A good runbook lets on-call know the first step without thinking too long. Keep it in the repository so it can be revised over time.

#UI Regressions and Snapshots

Compose regressions often look like an unintended visual change — for example spacing changes because of a theme token. Detect it with screenshot testing: compare screenshots before and after a change. Frameworks like Roborazzi or Paparazzi capture golden images that are compared automatically in CI.

#Monitoring Application and UI Health

#Crash Reporting

Install crash reporting since the first release. Firebase Crashlytics captures stack traces and device metadata:

Setup Crashlytics

implementation("com.google.firebase:firebase-crashlytics:19.4.0")
implementation("com.google.firebase:firebase-analytics:22.3.0")

Init Crashlytics

FirebaseCrashlytics.getInstance().run {
    recordException(RuntimeException("tes crash"))
}

recordException records caught exceptions, while uncaught crashes are sent automatically. This data becomes the main material for the runbook above.

#Monitoring Jank and ANR

Jank — missed frames — is a typical Compose performance issue. Android Vitals reports jank and ANR to the Play Console. For manual measurement:

adb shell dumpsys gfxinfo id.devnull.belajarcompose

adb shell dumpsys gfxinfo id.devnull.belajarcompose shows per-application frame statistics — including the number of slow frames. This data helps identify screens that need optimization as in episode 15.

#Release Process and Rollout Strategies

#Versioning and Release Channels

Bump versionCode and versionName on every release, and use a staged rollout in the Play Console: release to 10 percent of users first, observe crashes, then increase gradually. For internal use, provide alpha and beta builds with different channels.

#Rollback and Feature Flags

Always prepare a way back. Feature flags let you disable a feature without a new release:

Feature flag

val active = remoteConfig.getBoolean("fitur_keranjang_v2")
if (active) {
    KeranjangV2()
} else {
    KeranjangV1()
}

remoteConfig.getBoolean("fitur_keranjang_v2") controls a feature from the server. If a new feature misbehaves, turn off the flag and users return to the old version without an update.

#Staged Rollout in the Play Console

Safe rollout practice: start at 1 percent, monitor for 24 hours, expand to 10 percent, then 100 percent. Monitor three key metrics at every stage: crash rate, ANR rate, and user rating.

#Maintaining Design Consistency

#Design Review and Tokens

Visual consistency is maintained through theme tokens (episode 6) and review. Set a checklist: all colors from ColorScheme, typography from MaterialTheme.typography, and spacing from design system tokens. Automate with a lint that checks token usage.

#Continuous Quality

Make quality part of the workflow: UI tests from episode 14 in CI, screenshot tests for visuals, and a runbook review every quarter. A healthy application is a monitored one, not just a released one.

#Closing

Episode 19 brought the application to production: runbooks for crashes and regressions, monitoring with Crashlytics and gfxinfo for jank, release processes with staged rollouts and feature flags, and practices for maintaining design consistency through tokens and lint.

Key takeaways:

• A runbook gives clear steps when crashes spike.
• Screenshot testing detects visual regressions.
• Crashlytics captures production crashes with device context.
• gfxinfo and Android Vitals monitor jank and ANR.
• Staged rollouts and feature flags reduce release risk.
• Design consistency is maintained through tokens and review.

In episode 20 we will discuss real-world use cases and patterns — case studies of social, e-commerce, and dashboard applications, MVI and MVVM architecture patterns, scaling applications with modules, and maintainable UI design systems.