နားလည်ထားရမယ့် အချက်
framework ဘယ်ဟာနဲ့ ရေးထားထားပါစေ mobile app တိုင်းဟာ user ရဲ့ device ဆီ ရောက်ရှိသွားတဲ့အထိ တူညီတဲ့ pipeline ပုံစံတစ်ခုကို လိုက်နာကြပါတယ်။
- Source Code နှင့် Dependencies
- Compile / Bundle
- Platform Build
- Sign
- Package
- Test
- Distribute
development build ကတော့ debugging tool တွေ ပါဝင်ပြီး reload မြန်မြန်ဆန်ဆန် လုပ်နိုင်ကာ app တည်ဆောက်နေသူတွေအတွက်ပဲ ရည်ရွယ်ပါတယ်။ release build ကတော့ ဒါတွေကို ဖယ်ရှားပြီး optimization လုပ်ကာ sign လုပ်ထားပြီး user အစစ်ဆီ တကယ်ပို့မယ့်အရာ ဖြစ်ပါတယ်။ terminology တွေက framework အလိုက် ကွာဟနေပေမယ့် ခွဲခြားချက်ကတော့ universal ပါပဲ။
release build ကို platform တစ်ခုက ယုံကြည်စိတ်ချစေတဲ့ အရာအဖြစ် ပြောင်းပေးတာက signing ပါပဲ။ app build တစ်ခုနဲ့ signing credential တစ်ခု ပေါင်းစပ်ပြီး signed app တစ်ခု ဖြစ်ပေါ်လာကာ platform က ဒီ signature ကို identity နဲ့ ပြောင်းလဲမှု မရှိကြောင်း အတည်ပြုဖို့ စစ်ဆေးပါတယ်။
signing credential ကို ဘယ်တော့မှ commit မလုပ်ပါနဲ့
keystore၊ certificate၊ ဒါမှမဟုတ် private key တွေကို Git ထဲ ဘယ်တော့မှ commit မလုပ်ပါနဲ့ - တစ်ခါ push လုပ်ပြီးရင် ဖျက်လိုက်ပြီးနောက်တောင် history ထဲမှာ အမြဲကျန်ရှိနေနိုင်ပါတယ်။ repository အပြင်ဘက်မှာ သိမ်းပြီး ခိုင်မာအောင်ကာကွယ်ထားတဲ့နေရာမှာ backup ယူထားပါ။
versioning ကတော့ user နဲ့ store ကို ဂဏန်းနှစ်ခု ပေးပါတယ် - 1.4.0 လိုမျိုး human-facing version တစ်ခုနဲ့ visible version တူတူနဲ့ release တွေကြားမှာတောင် increment ဖြစ်နေတဲ့ build 27 လိုမျိုး internal build/version code တစ်ခုပါ။ တိကျတဲ့ field တွေကတော့ platform ပေါ် မူတည်ပါတယ်။
- App Signing
- App build တစ်ခုကို platform က ဘယ်သူ publish လုပ်တာလဲ၊ ပြောင်းလဲမှု ရှိမရှိ စစ်ဆေးနိုင်ဖို့ cryptographic signature တစ်ခု ထည့်ပေးတဲ့ လုပ်ငန်းစဉ်ပါ။
- Signing Credential
- app ရဲ့ signature ကို ထုတ်ပေးဖို့ သုံးတဲ့ private key၊ certificate ဒါမှမဟုတ် keystore ဖိုင်ပါ - password တစ်ခုလို ကာကွယ်ရမှာဖြစ်ပြီး source control ထဲ ဘယ်တော့မှ commit မလုပ်ရပါဘူး။
MOBILE BUILD PIPELINE
---------------------
MOBILE BUILD PIPELINE
-----------------------
Source Code
|
v
Dependencies
|
v
Compile / Bundle
|
v
Platform Build (Android / iOS toolchain)
|
v
Sign (App Build + Signing Credential -> Signed App)
|
v
Package
|
v
Test
|
v
Distributeလက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
လိုအပ်လာမှသာ မဟုတ်ဘဲ signing discipline ကို ကြိုတင်ထားပါ။ signing credential ကို တစ်ကြိမ်ဖန်တီးပြီး ရလာတဲ့ file ကို password တစ်ခုလို သဘောထားပါ။
- credential file ကို Git repository အပြင်ဘက်မှာ သိမ်းပြီး filename pattern ကို .gitignore ထဲ ချက်ချင်းထည့်ပါ။
- passphrase ကို chat, ticket, ဒါမှမဟုတ် commit message ထဲ ဘယ်တော့မှ မထည့်ပါနဲ့။
- password manager ဒါမှမဟုတ် secrets vault လိုမျိုး ခိုင်မာအောင်ကာကွယ်ထားတဲ့နေရာမှာ backup ကူးထားပါ။
development build နဲ့ release build ကို project configuration ထဲမှာ ရှင်းရှင်းလင်းလင်း ခွဲထားပါ - debug-signed build တစ်ခု user အစစ်ဆီ မတော်တဆ ပို့မိမှာ မဖြစ်ပါစေနဲ့။
Credential ကို အတည်ပြုပါ
ဒီ build ကို ဘယ် credential က တကယ် sign လုပ်ခဲ့လဲ စစ်ဆေးပါ။
Visible Version ကို တိုးပါ
user မြင်ရမယ့် version number ကို သင့်လျော်စွာ ပြောင်းလဲထားလား အတည်ပြုပါ။
Build Number ကို တိုးပါ
platform နဲ့ crash tool တွေက build တွေကို ခွဲခြားနိုင်ဖို့ internal build number ကို တိုးပေးပါ။
Signing Credential ကို Git ထဲ ဘယ်တော့မှ Commit မလုပ်ပါနဲ့
keystore, certificate, ဒါမှမဟုတ် private key တွေကို source control ထဲ ဘယ်တော့မှ commit မလုပ်ပါနဲ့ - repository အပြင်ဘက်မှာ password manager ဒါမှမဟုတ် secrets vault ထဲ backup ယူပြီး access ကို ကန့်သတ်ထားပါ။
အတူတူ စမ်းရေးကြည့်မယ်
function auditSigningSetup(setup) {
const risks = [];
if (!setup.keystoreInGitignore) {
risks.push("Signing files are not gitignored -- they could end up committed to source control.");
}
if (!setup.signingCredentialsBackedUp) {
risks.push("No backup of signing credentials -- losing them can block future updates to this app.");
}
if (setup.usingDebugSigningForRelease) {
risks.push("Release build is signed with a debug key -- not acceptable for distribution.");
}
return { riskCount: risks.length, risks, verdict: risks.length === 0 ? "safe" : "needs-attention" };
}
const riskySetup = {
keystoreInGitignore: false,
signingCredentialsBackedUp: false,
usingDebugSigningForRelease: true
};
const safeSetup = {
keystoreInGitignore: true,
signingCredentialsBackedUp: true,
usingDebugSigningForRelease: false
};
console.log("Risky setup:", auditSigningSetup(riskySetup));
console.log("Safe setup:", auditSigningSetup(safeSetup));risky setup က riskCount: 3 ပြပြီး risk message သုံးခုလုံး (keystore gitignore မလုပ်ထား၊ backup မရှိ၊ release ကို debug signing သုံး) ကို ဖော်ပြကာ verdict: 'needs-attention' ဖြစ်ပါတယ်။ safe setup ကတော့ riskCount: 0၊ risks array အလွတ်၊ verdict: 'safe' ဖြစ်ပါတယ်။၅ မိနစ် စမ်းကြည့်
စိတ်ကူးထားတဲ့ project setup တစ်ခုကို flag သုံးခုလုံး false ထားပြီး ဒီသင်ခန်းစာက auditSigningSetup-စတိုင် checker ကို run ကြည့်ပါ။ ဖော်ပြလာမယ့် risk တွေအားလုံးကို list လုပ်ပါ၊ ပြီးရင် flag တစ်ခုချင်းစီကို true ပြောင်းပြီး risk list ဘယ်လိုလျော့သွားလဲ သတိထားကြည့်ပါ။
သတိလေးတစ်ချက်
keystore ဒါမှမဟုတ် certificate ကို Git ထဲ ခေတ္တလောက်ပဲထားရင်တောင် commit လုပ်တာ - ဖျက်လိုက်ပြီးနောက်တောင် history ထဲ ကျန်ရှိနေနိုင်ပါတယ်။
release build ကို debug key နဲ့ မတော်တဆ sign လုပ်မိတာ၊ ဒါမှမဟုတ် backup မရှိတဲ့ signing credential ကို ဆုံးရှုံးလိုက်ပြီး နောက်ပိုင်း update တွေ ပိတ်ဆို့သွားတာ။
Code signing - Wikipedia — How Mobile Apps Work