Mobile Release Train

Mobile Release Train

Mobile နဲ့ Web ရဲ့ ကွာခြားချက်တွေအများကြီးထဲက တစ်ခုက Release Cycle တွေပဲ။​ Web မှာ က Build Pipeline ကောင်းကောင်းတစ်ခုရှိတယ်ဆိုရင် တင်လိုက်သမျှ ကုဒ်တွေက ချက်ချင်း deploy ဖြစ်တယ်။​ Mobile မှာကျ အဲလိုလုပ်လို့မရဘူး။ ​ Play Store/App Store Review တွေ ဖြတ်သန်းရတော့ ချက်ချင်း release လို့မရဘူး။​ ဒီမှာ အမှားတစ်ခုက Feature ေတွအကုန်ပြီးမှ တင်မယ်ဟေ့ဆိုတဲ့ အယူရှိတယ်။ Team သုံး၊ လေးခုလောက် ရှိတယ်ပဲထား။ ပထမတစ်ချက် ပြဿနာက​ Team 1 က ပြီးသွားပြီဟေ့ဆိုတဲ့အချိန်မှာ တစ်ခြားလူတွေကို ထိုင်စောင့်ရတော့မယ်။​ ဒါဟာ User လက်ထဲရောက်ဖို့ နောက်ကျသွားစေတယ်။ Feedback cycle ကကြာလေ၊​ကိုယ်လုပ်နေတာတွေ မှားနေလား မှန်နေလား စီစစ်ဖို့ နောက်ကျသွားလေပဲ ဖြစ်မယ်။​​​ နောက်တစ်ချက် က Release Cycle သေချာမရှိရင် Team တွေကြားမှာ Release လုပ်ဖို့ အဆင်သင့် ဖြစ်ပြီလား ဆိုတာ သိဖို့ Meeting တွေလုပ်နေရမယ်။ မလိုအပ်ပဲ အချိန်တွေ တအားကုန်တယ်။

ဒီတော့ Continuous Deployment လုပ်ဖို့ Release Train ဆိုတဲ့ နည်းကို သုံးကြတယ်။ Release Train ရဲ့ နည်းကရှင်းပါတယ်။​ ခင်ဗျား ရထားဘူတာမှာ ရထားလာဖို့ စောင့်ရသလိုပဲ။​ ၁၅ မိနစ် တစ်စီးလာတယ်ဆိုပါဆို။​ ရထားက မှန်မှန်လာနေမှာပဲ၊​​ ဒါကို လိုက်ချင်တယ်ဆိုတဲ့ သူက သူလာမဲ့အချိန်ကို မှီအောင်လာရမယ်။​ ရထားဂိတ်လာတဲ့လမ်းမှာ ကားပိတ်နေလို့ "ခဏစောင့်ပါဦး"လုပ်လို့မရဘူး။။ မမှီရင် နောက်တစ်စီးစောင့်ပဲ။

ဒီမှာ ရထားဆိုတာက ကျွန်တော်တို့ရဲ့ Release လုပ်မဲ့ အချိန်ကိုပြောတာ။​ ဒါက Team maturity ပေါ်မူတည်ပြီး တစ်ညတစ်ခါတင်ပေးတဲ့  nightly build ဖြစ်နိုင်သလို၊ တစ်ပတ်တစ်ခါ၊ တစ်လတစ်ခါလည်းဖြစ်နိုင်တယ်။ ဥပမာအနေနဲ့ တစ်ပတ်တစ်ခါ ဗုဒ္ဓဟူး နေ့တိုင်း Release လုပ်မယ်ဆို၊ အင်္ဂါနေ့ ည ၁၂ နာရီထိုးလို့မှ မပြီးတဲ့ Feature အကုန်လုံး ကို ထားခဲ့ပြီး Release လုပ်စရှာရှိတာဆက်လုပ်ရမယ်။ Feature ဘာမှ အသစ်ပြီးတာမရှိလည်း လုပ်ကိုလုပ်ရမယ်။

Release Train

အပေါ်ကပုံမှာဆို ပထမတစ်ကြိမ် Release လုပ်တဲ့အခါ Feature A နဲ့ Feature B ပဲပါသွားမယ်။ Feature C ကမပြီးသေးရင် ချန်ခဲ့ရမယ်။ ဒါပေမဲ့ နောက်တစ်ကြိမ် ရထားဘူတာဆိုက်ရင်တော့ Feature C နဲ့ Feature E ပါသွားလိမ့်မယ်။​ Release Train က အချိန်မှန်လာမယ်၊ ပြီးရင် သူကဘယ်သူ့ကိုမှ မစောင့်ဘူးဆိုတာ အားလုံးလက်ခံထားရမယ်။

Feature Toggles

Feature တွေက မပြီးသေးလည်း Release လုပ်ဆိုတော့ User က​ Feature တစ်ဝက်တစ်ပျက်ကြီး မြင်နေရမှာပေါ့လို့ မေးစရာရှိမယ်။ ဒီအတွက် ကျွန်တော်တို့ Feature Toggle လေးတွေသုံးတယ်။ ကျွန်တော်တို့ Feature စရေးပြီဆိုကတည်းက အရင်ဆုံး Feature Toggle လေးတွေ စ setup လုပ်တယ်။ Toggle ကို Backend ကနေ မဖွင့်မခြင်း User က လုပ်လက်စ မပြီး Feature ကိုမမြင်ရဘူး။

A text that says "is Version > 5.0.0" and branching out to two different screens based on yes or no
Version 5.0 အထပ်မှ Feature အသစ်လေးကိုမြင်ရမယ်

Feature Toggle က Release Train တစ်ခုလုပ်ဖို့ အကူအညီအများကြီးပေးတယ်။​ တကယ်လို့ Feature တစ်ခုက ရထားမှာပါသွားပြီးမှ တကယ် မပြီးသေးမှန်းသိရင်လည်း ပြန်ပိတ်ထားလို့ ရတယ်။ Feature Toggle အကြောင်းလည်း နောက်မှသေချာထပ်ရေးပေးဦးမယ်။ Mobile မှာတော့​ Firebase Remote Config လိုမျိုး Service တွေသုံးလို့ရတယ် LaunchDarkly လည်းအသုံးများလာတာ တွေ့ရတယ်။

Firebase Remote Config မှာ ထားထားတဲ့ Feature Toggle တစ်ခုရဲ့ Example Conditions

Trunk Based Development

Release Train လုပ်ဖို့ Branching Strategy အနေနဲ့ အကောင်းဆုံးက Trunk based သွားဖို့ပဲ။ Trunk based အပြည့်အဝမသွားနိုင်ရင်တောင် main branch ကို stable branch အဖြစ် သတ်မှတ်ဖို့ လိုတယ်။​ နောက်တစ်ခုက Release လုပ်တော့မဲ့အချိန်မှ ဟိုနားက crash ေနတယ် ဘာညာမဖြစ်ဖို့ Test တွေသေချာရေးဖို့၊​ Build pipeline ေသချာထားဖို့လည်းလိုမယ်။ နောက်တစ်ခု အရေးကြီးတာက Main ေပါ်တင်မဲ့ commit တိုင်းက ချက်ချင်း deploy လုပ်လို့ရတဲ့အနေအထားသွားဖို့လိုတယ်။​ ဒီလိုရဖို့ကလည်း Feature toggle ေတွ၊ Commit ေသးသေးလေးတွေများများလုပ်တာတွေ အစရှိတဲ့ Development Practice တွေကို ကျင့်သုံးဖို့လို အပ်တယ်။

Benefits

တကယ်လက်တွေ့ကျွန်တော့် project မှာလည်း စစက ၂ ပတ်တစ်ခါလုပ်ကြတယ်။ အဲတော့မှ Release လုပ်နေတုန်း Bug ေတွ့တယ်ဟေ့ဆို Release က ရပ်လိုက်ရတယ်။ တစ်ခါတစ်လေ တစ်လနေမှ တစ်ခါထုတ်တယ်။ ခုနောက်ပိုင်း Release Train သေချာရှိလာတော့ ဘာတွေသိသာလာလဲဆိုတော့

  • Bug တွေ့မှာကို အရမ်းကြီးမကြောက်ကြတော့ဘူး။​ ဖြစ်လည်း နောက် ၅ ရက်လောက်နေရင် Version တစ်ခုထွက်မှာဆိုတော့ Release တစ်ခုနဲ့တစ်ခုကြားက Bug ေတွပြင်တဲ့အချိန်က နည်းသထက်နည်းလာမယ်။
  • Bug ေတွ Error ေတွရှိရင်လည်း Changset လို့ခေါ်တဲ့ ပြောင်းသွားတဲ့ ကုဒ် အရေအတွက်က အရင်ကထက် ယှဥ်လိုက်ရင် ပိုနည်းသွားတော့ ဘယ် commit ကြောင့်ဖြစ်လဲဟေ့ဆိုပြီး ပြန်ရှာရတာလွယ်တယ်။
  • ရထားက အချိန်မှန်တော့ Product Owner ေတွအနေနဲ့ Release ဘယ်တော့လဲ ကြိုသိနိုင်တယ်၊။ ဒီတော့ သူတို့အတွက် Planning လုပ်ရတာပိုလွယ်ကူစေတယ်။
  • Main branch ကို အမြဲတမ်း စိမ်းနေအောင် ထားရတော့ ကျွန်တော်အပေါ်က ပြောတဲ့ Commit သေးသေးလေးတွေကို ခဏခဏ​တင်တဲ့ အကြင့်၊​ Testing သေချာရေးတဲ့ အကြင့်တွေ ဖြစ်လာပြီး အရည်အသွေးကိုပိုကောင်းလာစေတယ်။
  • အရည်အသွေးနဲ့ပတ်သက်ပြီးနောက်တစ်ခုက Release လုပ်ခါနီးမှ "ဒါလေးပြီးတော့မှာမလို့ ခဏစောင့်ပါ" ဆိုပြီး တက်သုတ်ရိုက် မှီအောင် အမြန်လုပ်တဲ့ အကြင့်တွေ နည်းလာတယ်။​ ဒီတော့ အရည်အသွေးကောင်းလာအောင် အေးဆေးသေချာအချိန်ယူရေးလို့ရတယ်။

ဒီနည်းက Uber တို့ Shopify တို့၊ Lyft တို့မှာပါ သုံးတဲ့နည်းလမ်းတစ်ခုဖြစ်လို့  ကျွန်တော် ပြောတာထက်ပိုတဲ့ အခြားကောင်းကြိုးတွေအများကြီး ရှိဦးမှာပါ။ ခင်ဗျား Team မှာလည်း Relase Cycle သေချာမရှိသေဘူးဆိုရင် စစမ်းကြည့်ပါ။ စစမှာတော့ အသားကျဖို့ခက်ပေမဲ့ ဖြည်းဖြည်းချင်း သိသာလာပါလိ့မယ်။


အချိန်မှန်မှန်နဲ့ အကုန်လုံးအဆင်ပြေစေမဲ့ Release Train တစ်ခုဖန်တီးနိုင်ကြပါစေ။တစ်ခြားမေးချင်တာ သိချင်တာရှိရင် အောက်က Discord Channel မှာ လာဆွေးနွေးလို့ရတယ်နော်။

Show Comments