Version Control System

“ကဲ ….. Demo ပြဖို့ အားလုံးအသင့်ပဲလားဟေ့”

  “ဟုတ်ကဲ့ နေ့လည်လောက်ဆိုရင်တော့ အသင့်ဖြစ်ပါပြီ ”

 “ဘယ်လို ဖြစ်တာလဲ။မနေ့ကတည်းက အားလုံးပြီးနေပြီ မဟုတ်လား။”

“ဟုတ်ပါတယ်။ Code တစ်ချို့ပြင်လိုက်မိတာ အလုပ်မလုပ်တော့လို့ ပြန်စစ်နေတာခင်ဗျ”

“ဟာ …..ပြဿနာပဲကွာ။ဘာလို့ အခုချိန်ကျမှ ပြင်တာလဲ။ဒီနေ့ Demo ပြမယ်လို့ ပြောထားပြီးပြီ။နဂို အလုပ်လုပ်နေတဲ့အတိုင်း ပြန်ထားလိုက်လေ။”

“ဟုတ်ကဲ့ ….. နဂိုအတိုင်း ပြန်ထားပြီးပြီ။ ဒါလည်းအလုပ်မလုပ်သေးဘူး။ ဘာဖြစ်သွားလဲ မသိဘူး။”

“ခက်တာပဲကွာ။တော်သေးတာပေါ့၊အရင် version တွေ ငါသိမ်းထားမိလို့။ Share Folder ထဲကို ဝင်ပြီး အရင် version ကိုယူလိုက်။”

“share folder ထဲမှာတွေ့ပါတယ်။ ဒါပေမယ့် project-latest, project-update, project-final, project-stable, project-update-final, project-real-latest အများကြီးဖြစ်နေတယ်။ အဲ့ထဲက ဘယ်ဟာကို ကူးရမလဲ”

“project-latest ကိုယူလေကွာ။ အဲ….နေဦး။ project-real-latest ဖြစ်မယ်ထင်တယ်။ ရှုပ်တယ်ကွာ ဘယ်ဟာနောက်ဆုံး  version လဲ ‌သေချာအောင်  တစ်ခုချင်းသာ လိုက်စမ်းကြည့်လိုက်တော့။”

ဒီလို ပြဿနာဟာ version control system ကို အသုံးမပြုတဲ့ software team တွေမှာ ကြုံတွေ့ရတဲ့ ပြဿနာတစ်ခုပဲ  ဖြစ်ပါတယ်။ software projects တစ်ခုဆိုတာ အချိန်နဲ့အမျှ ပြောင်းလဲ နိုင်ပါတယ်။ အလုပ်လုပ်နေတဲ့ code ကို တစ်နေရာမှာ ပြုပြင်ခြင်းအားဖြင့် အခြားတစ်နေရာမှာ မမျှော်လင့်ပဲသက်ရောက်သွားပြီး bugs တွေလည်း ဖြစ်နိုင်ပါတယ်။

ဒီလို အခက်အခဲတွေရှိလို့ ဆိုပြီး ပြင်ဆင်မှုတွေ မလုပ်ချင်လို့မရပါဘူး။ ပြောင်းလဲမှုတွေရှိလာလို့ ပြုပြင်ဖြည့်စွက်ရတဲ့အခါ မမျှော်မှန်းထားတဲ့ အမှားတစ်ခုကြောင့် မူလ အလုပ်လုပ်နေတဲ့စနစ်ကို ထိခိုက်ပြီး အလုပ်မလုပ်တော့တာမျိုး ဖြစ်တတ်ပါတယ်။ ဒါကြောင့် လက်ရှိအလုပ်လုပ်နေတဲ့ အဆင့်တစ်ခုကို version တစ်ခုကို သတ်မှတ်ပြီး သီးခြားခွဲခြား သိမ်းဆည်းထားပြီးမှ ဖြည့်စွက်ပြင်ဆင်မှုတွေကို ဆက်လက်ဆောင်ရွက်ရတဲ့သဘောရှိပါတယ်။

အဲ့ဒီလို့ခွဲခြားထားမှလည်း ဖြည့်စွက် code ကို ရဲရဲဝံ့ဝံ့ ဖြည့်စွက်စမ်းသပ်နိုင်မှာ ဖြစ်ပါတယ်။ အသစ်ဖြည့်စွက်မှုကြောင့် အမှားအယွင်း တစ်စုံတစ်ရာ ဖြစ်ခဲ့ရင်လည်း  မူလအလုပ်လုပ်နေတဲ့ အ‌ခြေအနေကို အချိန်မရွေး ပြန်လည်ရရှိနိုင်မှာ ဖြစ်ပါတယ်။ Version ခွဲခြားမထားရင် မှားယွင်းမှုဖြစ်သွားမှာကို စိုးရိမ်စိတ်နဲ့ ပြင်ဆင်ဖြည့်စွက်မှုတွေကို ရဲရဲဝံ့ဝံ့ မလုပ်ရဲတော့တဲ့အတွက် အလုပ်မတွင်ဖြစ်တတ်ပါတယ်။ ဒီထက်ပိုဆိုးတာက ပြင်ဆင်ဖြည့်စွက်မှုကြောင့် အမှားအယွင်းရှိလာတဲ့အခါ မူလအ‌‌ခြေအနေပြန်ရအောင် အတော်လေး အချိန်ပေးပြီး ပြန်လည်ရှင်းရလို့ အချိန်တွေ ကုန်ပါတယ်။

ဒီလို Version တွေ ခွဲခြားမှတ်တမ်းတင်တဲ့ လုပ်ငန်းဆောင်ရွက်ရာမှာ  source code file တွေကို ကိုယ်တိုင် copy တွေကူး၊ နာမည်အမျိုးမျိုးပေးစသဖြင့် Manual လုပ်စရာမလိုပဲ စနစ်ကျ ထိရောက်အောင် ကူညီပေးနိုင်တာကတော့ version control system (VCS) ပါပဲ။ Version Control System ကို Revision Control System လို့လည်း ခေါ်သလို Source Code Management System (SCM) လို့လည်း ခေါ်ကြပါတယ်။

Version Control System တွေက Version တွေသာမက Branch လုပ်ဆောင်ချက်တွေလည်းပါဝင်ပါတယ်။ ဥပမာ Code Base တစ်ခုတည်းကို အ‌ခြေခံပြီး Free Version, Pro Version စသဖြင့် branch များ ခွဲခြားဆောင်ရွက်နိုင်ပါတယ်။

Figure(1) : Branching in VCS

Version Control System တွေက Version တွေသာမက Branch လုပ်ဆောင်ချက်တွေလည်းပါဝင်ပါတယ်။ ဥပမာ Code Base တစ်ခုတည်းကို အ‌ခြေခံပြီး Free Version, Pro Version စသဖြင့် branch များ ခွဲခြားဆောင်ရွက်နိုင်ပါတယ်။

Figure (1) ရှိ v1, v2, v3 စတဲ့ version တွေဟာ အဆင့်လိုက်မှတ်တမ်းတင်ထားတဲ့  မူလ version တွေ ဖြစ်ပါတယ်။ ဒီလို Code Base ကနေ လုပ်ဆောင်ချက်အနည်းငယ် ကွဲပြားသွားတဲ့ သီးခြား version တွေ ဖန်တီးဖို့အတွက် နောက်ထပ် project တစ်ခု ဖန်တီးဖို့ မလိုပါဘူး။ လက်ရှိ Code Base ကနေ Branch အဖြစ်ခွဲထုတ်လိုက်ပြီး အတူတကွ ဆက်လက်ဆောင်ရွက်စေနိုင်မှာပဲ ဖြစ်ပါတယ်။မူလ Code Base ကို Trunk (သို့မဟုတ်) Master လို့ ခေါ်ကြပါတယ်။

VCS က master နဲ့ branch တွေအကြား အပြန်အလှန် ကူးပြောင်းအလုပ်လုပ်နိုင်အောင် စီမံပေးထားပါတယ်။ Master ကိုရွေးထားပြီး ပြင်ဆင်မှုတွေ ပြုလုပ်ရင် ပြုလုပ်လိုက်တဲ့ပြင်ဆင်မှုတွေက master code base ကိုပဲ သက်ရောက်မှာ ဖြစ်သလို Branch တစ်ခုကို ရွေးထားပြီး ပြင်ဆင်မှုတွေပြုလုပ်ရင်တော့ ရွေးချယ်ထားတဲ့ branch ကိုပဲ ပြင်ဆင်မှုက သက်ရောက်မှာ ဖြစ်ပါတယ်။

Branch တွေကို စမ်းသပ်လုပ်ဆောင်ချက်တွေ ထည့်သွင်းစမ်းသပ်ဖို့လည်း အသုံးပြုကြပါတယ်။

ဒီနည်းနဲ့ စမ်းသပ်လိုတဲ့ Code တွေက master code base ကို မထိခိုက်စေပဲ  သီးခြားခွဲထားတဲ့ development branch ပေါ်မှာပဲ လွတ်လွတ်လပ်လပ် စမ်းသပ်ရေးသားနိုင်စေမှာ ဖြစ်ပါတယ်။ Development brand ပေါ်မှာ ရေးသားထားတဲ့ စမ်းသပ် လုပ်ဆောင်ချက်ကို မူလ Version မှာ ပါဝင်သင့်တယ်လို့ အတည်ပြုနိုင်တဲ့အခါ အဲ့ဒီ development branch ကို master code base နဲ့ပေါင်းစပ်လိုက်နိုင်ပါတယ်။ ဒီလုပ်ဆောင် ချက်ကို merge လုပ်တယ်လို့ခေါ်ပါတယ်။

Figure (1)မှာ ဖော်ပြထားချက်အရ အလယ်က V1, V2, V3 တို့သည် version တွေ ဖြစ်ပြီး အပေါ်က v1-free, v1.1-free စတဲ့ version တွေကတော့ မူလ master code base ကနေ လုပ်ဆောင်ချက်တစ်ချို့ ပြောင်းလဲထားတဲ့ သီးခြား Version အဖြစ် branch ခွဲယူထားခြင်း ဖြစ်ပါတယ်။အောက်ဘက်က v1.1 dev, v2.1 dev version တွေကတော့ စမ်းသပ်လုပ်ဆောင်ချက်‌တွေ ထည့်သွင်းစမ်းသပ်နိုင်ဖို့  ခွဲခြားထားတဲ့ branch ဖြစ်ပြီး အဲ့ဒီ branch ကို မူလ master code base နဲ့ တစ်နေရာမှာ merge လုပ်ထားတာကိုလည်း တွေ့ရပါတယ်။

Version Control System(VCS) တွေက master နဲ့ branch တွေပေါ်က မှတ်သားထားတဲ့ Version အမှတ်တိုင်းကို ပြန်သွားနိုင်အောင် စီမံပေးထားလို့ အမှားအယွင်း တစ်စုံတစ်ရာကြောင့်ပဲ ဖြစ်ဖြစ် အခြားအကြောင်းတစ်ခု ကြောင့်ပဲ ဖြစ်ဖြစ် လိုအပ်လာတဲ့အခါ အရင် version တွေကို အချိန်မရွေး ပြန်လည်ရယူနိုင်မှာ ဖြစ်ပါတယ်။

ဒါတင်မကပဲ အဖွဲ့လိုက် ပူးပေါင်းဆောင်ရွက်ရတဲ့အခါမှာလည်း code base တစ်ခုထဲကနေ VCS အကူအညီနဲ့ ရယူရေးသားခြင်းအားဖြင့် Developer တစ်ဦးရေးသားထားတဲ့ code နဲ့ ‌နောက် Developer တစ်ဦးရေးသားထားတဲ့ code ကို ပေါင်းစပ်တဲ့ လုပ်ငန်းကို Manual လုပ်နေစရာမလိုဘဲ VCS က စနစ်တစ်ကျ ပေါင်းစည်းပေးသွားမှာ ဖြစ်ပါတယ်။ဒါကြောင့် VCS တွေကို version တွေ သတ်မှတ်ဖို့သာမက အဖွဲ့လိုက်ပူးပေါင်းဆောင်ရွက်ရာမှာ အခြေခံ Tool တစ်ခုအဖြစ် အသုံးပြုကြပါတယ်။ဒါကြောင့်လည်း VCS တွေကို Source.  Code Management System (SCM) လို့ခေါ်ကြခြင်းဖြစ်ပါတယ်။ Version ကိုသာမက source code နဲ့ ပတ်သန်တဲ့ အခြားစီမံမှုတွေကိုပါ ဆောင်ရွက်ပေးတဲ့အတွက်ပါ။

Figure(2): Centralize VCS Workflow

ဒီလို အဖွဲ့အလိုက် ပူးပေါင်းဆောင်ရွက်နိုင်ဖို့ Centralize Source Code Server လိုအပ်တတ်ပါတယ်။ Figure(2)မှာ ဖော်ပြထားသလို Team မှှာပါဝင်တဲ့ developers တွေက အခြား developer တွေ ရေးသားထားတဲ့ နောက်ဆုံး results ကို central server ထံမှ ရယူခြင်း မိမိတို့ရေးသား ဖြည့်စွက်ချက်များကို central server ထံ ပြန်လည်ပေးပို့ခြင်းအားဖြင့် Code Base တစ်ခု တည်းကို developers အများ ပူပေါင်းဆောင်ရွက်ခြင်း လုပ်ဆောင်ချက်ကို ရရှိနိုင်မှာပါ။