လွတ်မြောက်ရန် အသင့်ရှိခြင်း

Iroha အက်ပ်တစ်ခု (သို့) ကွန်ရက်အပြောင်းအလဲကို မကြံ့ခိုင်ခင်၊ သက်ဆိုင်ရာအန္တရာယ်ကို ဖော်ပြနိုင်တဲ့ အသေးဆုံး ပတ်ဝန်းကျင်မှာ ပြုမူပုံကို သက်သေပြပြီး မျှဝေထားတဲ့ စမ်းသပ်ရေးကွန်ရက်နဲ့ ထုတ်လုပ်မှုဂိတ်တွေကို သိသိသာသာ ဖြတ်သန်းပါ။

Localnet ဂိတ်

• တူညီတဲ့ Iroha track နဲ့ အနီးဆုံး လက်တွေ့ validator count ကိုသုံးပြီး local network တစ်ခုကို စတင်ပါ။
• Transaction Builders အတွက် Unit Tests တွေကို Run လုပ်ပါ၊ query parsing၊ rejection handling နဲ့ configuration loading တွေကိုပါ။
• SDK (သို့) CLI ပုံစံတစ်ခုတည်းဖြင့်အသေးဆုံးအောင်မြင်သောဖတ်ရေးလမ်းကြောင်းများကို လုပ်ဆောင်ပါ။ နောက်ပိုင်းမှာအသုံးပြုမယ့် အက်ပ်။
• စမ်းသပ်မှုလက်ရာများတွင်မျှော်လင့်ထားသော ငွေချေးမှု hashes များ၊ အခြေအနေများ၊ ဖြစ်ရပ်များနှင့်အခြေအနေဖတ်ခြင်းများကို သိမ်းဆည်းပါ။

Lunch Iroha 3 နှင့် SDK Tutorials ကိုကြည့်ပါ။

မျှဝေသော Testnet Gate

• Taira (သို့) အခြားမျှဝေထားသော testnet ကို endpoint ပြုမူမှု၊ အခွန်များ၊ အကောင့်ဖောင်ဒေးရှင်းများ၊ နှောင့်နှေးမှုနှင့် လုပ်ဆောင်ချက် စမ်းသပ်မှုများအတွက် အသုံးပြုပါ။
• Keep live testnet က opt-in ကို ရေးထားတယ်ဆိုတော့ သာမန် စမ်းသပ်မှု run တွေက ကွန်ရက်ရရှိနိုင်မှုနဲ့ testnet ရင်းနှီးမြှုပ်နှံမှုအပေါ် မမှီခိုပါဘူး။
• လက်မှတ်ရေးထိုးသူ၏ ငွေကြေး၊ အခွန်အရင်းအမြစ် metadata များ၊ အာဏာပိုင် ခွင့်ပြုချက်များနှင့် မျှော်မှန်းထားသော အခြေအနေများကို တိုက်ရိုက်စမ်းသပ်မှုစီမံကိန်းတစ်ခုစီကို မတင်မီ စစ်ဆေးပါ။
• terminal status ကို စောင့်ကြည့်ပြီးနောက် read only query နဲ့ resulting state ကို စစ်ဆေးပါ။

ကြည့်ပါ။ ဆက်လက်တည်ဆောက်ပါ SORA 3: Taira နှင့် Minamoto.

အဓိကကွန်ရက် (သို့) ထုတ်လုပ်ရေးဂိတ်

• သီးခြားထုတ်လုပ်မှု လက်မှတ်ရေးထိုးသူ၊ ငွေကြေးထောက်ပံ့မှု၊ ဒိုမိုင်းများနှင့် ညှိနှိုင်းလမ်းကြောင်းများကို အသုံးပြုပါ။ testnet key သို့မဟုတ် faucet အယူအဆများကို မတိုးတက်စေပါနဲ့။
• Compatibility Matrix နှင့်လိုအပ်သော cross-SDK စင်္ကြံများကို အတည်ပြုပါ။ deployment တွင်အသုံးပြုသည့် တိကျသော CLI, peer binary, configuration နှင့် network release ကို သီးခြား pin ဖြင့်စမ်းသပ်ပါ။
• Review ခွင့်ပြုချက်များ၊ အခွန်ထောက်ပံ့မှုများ၊ စျေးနှုန်း ကန့်သတ်ချက်များ၊ စောင့်ကြည့်ခြင်း၊ Backup အခြေအနေများနှင့် ပြန်လည်ဖြည့်စွက်ရန် သတ်မှတ်ချက်များကို ထုတ်ပြန်ခြင်း ပြတင်းပေါက်မတိုင်မီတွင်။
• သက်ရောက်မှုမြင့်မားသော စာရွက်စာတမ်းများအတွက် ရေးသားသော ငွေပေးချေမှု သို့မဟုတ် ရွှေ့ပြောင်းရေး အစီအစဉ်ကို တောင်းဆိုပါ။

ပြန်လည်ထူထောင်ခြင်း

• Code deployment ကနေ ဘယ်အပြောင်းအလဲတွေကို ပြန်လည်ဖြန့်ချိနိုင်မလဲ၊ ဘယ်အပြောင်းအရွှေ့ကို on-chain ငွေပေးချေမှု လိုအပ်သလဲ၊ ဘယ်အပြောင်းလဲတွေကို တိုက်ရိုက် ဖျက်ပစ်လို့မရဘူးဆိုတာကို သတ်မှတ်ပါ။
• On-chain ဒေတာပြောင်းလဲမှုအတွက် ပထမဦးဆုံးထုတ်လုပ်ရေးစာရင်းမတင်ခင် ကပ်ငွေပေးချေမှု (သို့) ရွှေ့ပြောင်းရေး စာသားများကို ပြင်ဆင်ပါ။
• ကွန်ရက်အပြောင်းအလဲများအတွက် အရင် Binary, Config Bundle, Signed Genesis နှင့် Operational Runbook များကို ဖြန့်ချိမှုအတွင်းရရှိနိုင်စေရန်။
• ငြင်းပယ်မှုနှုန်း၊ တန်းစီတိုးတက်မှု၊ နှောင့်နှေးမှု (သို့) အဖော်တွေရဲ့ ကျန်းမာရေးလို ဓမ္မဓိဋ္ဌာန်ကျတဲ့ အချက်ပြချက်တွေအပေါ် အခြေခံပြီး ဖြန့်ချိမှုကို ရပ်ဆိုင်းဖို့ ဆုံးဖြတ်ချက် ချမှတ်ပါ။

နောက်ဆုံး စစ်ဆေးစာရင်း

• Configuration ဟာ ပတ်ဝန်းကျင်ကို သီးသန့် သတ်မှတ်ထားပြီး စမ်းသပ်မှုအတွက် လျှို့ဝှက်ချက်တွေ မပါပါဘူး။
• ရင်းနှီးမြှုပ်နှံမှု ပြန်လည်ကြိုးပမ်းခြင်း ပြုမူပုံဟာ မတတ်နိုင်တာ (သို့) ရှင်းလင်းစွာ ကန့်သတ်ထားတာပါ။
• လျှောက်လွှာမှာ ငြင်းပယ်ခြင်း၊ သက်တမ်းကုန်ဆုံးခြင်း၊ အချိန်ဖြတ်ခြင်းနှင့် အဆုံးအသတ်မှတ်ချက်ရရှိမှု ကျရှုံးမှုတို့ကို ခွဲခြားနိုင်သည်။
• စောင့်ကြည့်မှုသည် ပမာဏ၊ နှောင့်နှေးမှု၊ အတန်းနက်၊ ငြင်းပယ်ချက်များ၊ မြင်ကွင်းပြောင်းလဲမှုများနှင့် သက်ဆိုင်ရာ လုပ်ငန်းဖြစ်ရပ်များကို ဖမ်းဆီးသည်။
• အော်ပရေတာတွေမှာ မျှော်လင့်ရတဲ့ ပျက်ကွက်မှုပုံစံတွေအတွက် Runbooks ရှိတယ်။
• လုံခြုံရေး စစ်ဆေးမှုက အဓိက ထိန်းသိမ်းမှု၊ ခွင့်ပြုချက်တွေ၊ ကွန်ရက် ထိတွေ့မှုတွေနဲ့ အလိုအလျောက် လုပ်ပိုင်ခွင့်ကို ဖေါ်ပြခဲ့တယ်။