Mobile Production Operations

နားလည်ထားရမယ့် အချက်

production ထဲမှာ mobile app run နေတဲ့အခါ developer ကိုယ်ပိုင် phone ပေါ်မှာ ဘယ်တော့မှ မပေါ်ပေါက်ဖူးတဲ့ problem တွေ ပေါ်လာပါတယ်။ app version ဘယ်ဟာတွေ, OS version ဘယ်ဟာတွေ, screen ဘယ်ဟာတွေမှာ crash ဖြစ်လဲဆိုတာ သင်ကိုယ်တိုင် ကိုင်ဆောင်ခွင့် ဘယ်တော့မှ မရမယ့် device fleet အစစ်တွေ အနှံ့ ကြည့်ရှုနိုင်ဖို့ လိုအပ်ပါတယ်။

version fragmentation ကတော့ နောက်ထပ် mobile-specific truth တစ်ခုပါ - သင့် user တွေဟာ နှစ်ပေါင်းများစွာ ဟောင်းနေတဲ့ version တစ်ခုအထိ update လုပ်ထားခဲ့တဲ့ app version အမျိုးမျိုးမှာ ပျံ့နှံ့နေကြပါတယ်။ သင့် backend API က app version အများကြီးကို တစ်ပြိုင်နက် ခေါ်နေတာကို support လုပ်ရပါတယ်။

• Optional update: user တွေကို ရိုးရိုးလှမ်းခေါ်တာ၊ လျစ်လျူရှုနိုင်ပါတယ်။
• Recommended update: block မလုပ်ဘဲ ပိုပြင်းထန်စွာ တွန်းအားပေးတာ။
• Force update: version ဟောင်းကို လုံးဝ block လုပ်တာ။
• Emergency security update: real vulnerability တစ်ခုအတွက် ပုံမှန်သတိထားမှုကို ကျော်လွန်တာ။

feature flag တွေက ဒီနေရာမှာ အထောက်အကူပြုပါတယ် - ship ထားပြီးသား code ကို backend က ဖွင့်ပေးမှသာ active ဖြစ်စေနိုင်ပြီး gradual rollout, beta, emergency disable ကို release အသစ်မလိုဘဲ လုပ်နိုင်ပါတယ်။

mobile rollback ဟာ web deployment လို instant မဟုတ်ဘဲ - version တစ်ခု device ပေါ် ရောက်သွားပြီဆိုရင် ပြန်ပြင်ဖို့ release အသစ် ဒါမှမဟုတ် flag flip တစ်ခုမှသာ ရနိုင်ပြီး redeploy တစ်ခုတည်းနဲ့ ဖြေရှင်းလို့ မရနိုင်ပါဘူး။

BACKWARD COMPATIBILITY CHALLENGE
--------------------------------
BACKWARD COMPATIBILITY CHALLENGE
----------------------------------
v1 App (older, still installed)  ---+
                                     |
                                     +--> Backend API
                                     |      (must support
v2 App (latest release)          ---+       both versions)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ပထမ release အစစ်မတိုင်ခင်ကတည်းက crash monitoring ကို ထားပါ၊ ပထမ problem ဆိုးတစ်ခုပြီးမှ မဟုတ်ဘဲ - user တွေ ညည်းညူပြီးမှ ထည့်ရင် incident ဆိုးဆုံးတွေရဲ့ data ကို လက်လွတ်ဆုံးရှုံးပြီးသားပါ။

app version, OS version, device model, crash ဖြစ်တဲ့ screen ကို ဖမ်းယူအောင် config လုပ်ပြီး password, token, ဒါမှမဟုတ် personal identifier ဆိုင်ရာ ဘာမဆို report ထဲ ကပ်ပါလာရင် ရှင်းလင်းဖယ်ရှားပါ။

• crash monitoring က app version, OS version, device/screen context ကို ဖမ်းယူသင့်ပေမယ့် sensitive user data ကို ဘယ်တော့မှ log မလုပ်ရပါဘူး။
• user တွေဟာ အချိန်မတူ update လုပ်ကြတဲ့အတွက် backend က app version အများကြီးကို တပြိုင်နက် ခေါ်နေတာကို support လုပ်ရပါတယ်။
• mobile rollback ဟာ web deployment လို instant မဟုတ်ပါဘူး - install ဖြစ်ပြီးသား version ဟာ release အသစ် ဒါမှမဟုတ် feature flag တစ်ခုနဲ့မှ အစားထိုးမှသာ ပြောင်းသွားမှာပါ။

အတူတူ စမ်းရေးကြည့်မယ်

function evaluateApiChangeSafety(change) {
  if (change.isBreakingChange && change.oldAppVersionsStillInUse) {
    return {
      safeToShip: false,
      recommendation: "Version the endpoint or support both old and new shapes until old app versions age out."
    };
  }
  if (change.isBreakingChange && !change.oldAppVersionsStillInUse) {
    return {
      safeToShip: true,
      recommendation: "No old versions depend on the previous shape -- confirm with real usage data before assuming so."
    };
  }
  return { safeToShip: true, recommendation: "Non-breaking change; ship normally." };
}

const riskyChange = { isBreakingChange: true, oldAppVersionsStillInUse: true };
const safeChange = { isBreakingChange: false, oldAppVersionsStillInUse: true };

console.log("Risky change:", evaluateApiChangeSafety(riskyChange));
console.log("Safe change:", evaluateApiChangeSafety(safeChange));

risky change (breaking ဖြစ်ပြီး old version တွေ သုံးနေသေးတဲ့) က { safeToShip: false, recommendation: 'Version the endpoint or support both old and new shapes...' } ကို ပြန်ပေးပါတယ်။ safe change (non-breaking) ကတော့ { safeToShip: true, recommendation: 'Non-breaking change; ship normally.' } ဖြစ်ပါတယ်။

Feature toggle - Wikipedia — How Mobile Apps Work