CI/CD ဆိုတာ ဘာလဲ?

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

CI/CD ဟာ အတူတကွ ကြီးထွားလာတဲ့ အယူအဆ နှစ်ခုပါ။ Continuous Integration (CI) ဆိုတာ developer တိုင်းက ကိုယ့်အလုပ်ကို shared branch တစ်ခုတည်းထဲကို မကြာခဏ - အနည်းဆုံး တစ်ရက်တစ်ခါ - merge လုပ်ပြီး၊ merge တိုင်းကို build နဲ့ test suite နဲ့ အလိုအလျောက် စစ်ဆေးတဲ့ အလေ့အထပါ။ ဒီနေရာမှာ "integration" ဆိုတဲ့ စကားလုံးက အဓိကပါ။ CI မရှိခင်က team တွေဟာ သီးခြား branch တွေပေါ်မှာ ရက်သတ္တပတ်များစွာ အလုပ်လုပ်ပြီးမှ၊ နောက်ဆုံးမှာ လူသုံးယောက်က module တစ်ခုတည်းကို တစ်ယောက်နဲ့တစ်ယောက် မကိုက်ညီတဲ့ ပုံစံနဲ့ ပြန်ရေးထားတာကို ရှာဖွေဖြေရှင်းရင်း ရက်သတ္တပတ်တွေ ကုန်ခဲ့ရပါတယ်။ အဲဒါကို integration hell လို့ခေါ်ပါတယ်။ CI က conflict တွေကို ပျောက်အောင်လုပ်တာ မဟုတ်ပါဘူး - မကြာခဏ merge ခိုင်းခြင်းဖြင့် conflict တွေကို သေးငယ်အောင်လုပ်ပြီး၊ လူတစ်ယောက်ယောက် test run လုပ်ဖို့ သတိရမလားဆိုတာကို မျှော်လင့်နေမယ့်အစား အလိုအလျောက် စစ်ဆေးခြင်းဖြင့် အမြင်နဲ့ ထင်သာအောင် လုပ်ပေးတာပါ။

CD ကျတော့ လူတွေ အများဆုံး ရှုပ်ထွေးတဲ့ နေရာပါ။ အကြောင်းက CD က မတူတဲ့ အရာနှစ်ခုကို ကိုယ်စားပြုနေလို့ပါ။ Continuous Delivery ဆိုတာ CI အောင်မြင်တဲ့ commit တိုင်းက အချိန်မရွေး release လုပ်နိုင်တဲ့ artifact တစ်ခုကို ထုတ်ပေးတယ်၊ ဒါပေမယ့် ဘယ်အချိန်မှာ ထုတ်မလဲဆိုတာကို လူက ဆုံးဖြတ်တယ် ဆိုတာပါ။ Continuous Deployment ကျတော့ အဲဒီ ခလုတ်ကို ဖယ်လိုက်တာပါ - build အစိမ်းရောင်ဖြစ်တာနဲ့ production ကို သူ့ဘာသာသူ ရောက်သွားပါတယ်။ Delivery က pipeline ရဲ့ technical အရည်အသွေးဖြစ်ပြီး၊ Deployment ကတော့ risk နဲ့ ပတ်သက်တဲ့ organisational ဆုံးဖြတ်ချက်ပါ။ team အများစုဟာ Delivery ကို အရင်ရောက်သင့်ပြီး၊ Deployment ကို ဘယ်တော့မှ မလိုချင်တာလည်း ဖြစ်နိုင်ပါတယ်။

ဒီအားလုံးရဲ့ အောက်ခြေမှာရှိတဲ့ တန်ဖိုးက feedback loop ရဲ့ အရှည်ပါ။ code ရေးပြီး ၉၀ စက္ကန့်အကြာမှာ တွေ့တဲ့ bug ဟာ ကိုယ့်ခေါင်းထဲမှာ context ရှိနေသေးလို့ ပြင်ရလွယ်ပါတယ်။ အဲဒီ bug အတူတူကို သုံးပတ်ကြာမှ staging မှာ တွေ့ရင်တော့ တူးဖော်ရေးလုပ်ငန်း ဖြစ်သွားပါပြီ။ CI/CD ရဲ့ ရည်ရွယ်ချက်က ဒီအကွာအဝေးကို ဖြစ်နိုင်သမျှ တိုအောင် လုပ်ဖို့ပါပဲ။

COMMIT TO PRODUCTION: THE CI/CD PIPELINE
----------------------------------------
  developer                      shared repository
  +-----------+     push          +--------------------+
  |  feature  | ----------------> |   pull request     |
  +-----------+                   +--------------------+
                                            |
                                            v
                                 +----------------------+
                                 |  CI: build + test    |
                                 |  lint / unit / e2e   |
                                 +----------------------+
                                     |             |
                                  red X        green check
                                     |             |
                                     v             v
                              back to dev     merge to main
                                                   |
                                                   v
                                      +----------------------+
                                      |  CD: package + ship  |
                                      +----------------------+
                                        |        |         |
                                        v        v         v
                                     staging  canary   production

  DELIVERY   = a human approves the last arrow
  DEPLOYMENT = the last arrow happens on its own

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

လက်တွေ့မှာ CI ကို စတင်ဖို့ ဆုံးဖြတ်ချက်ကြီးတွေ မလိုပါဘူး။ repository ရဲ့ root မှာ .github/workflows/ci.yml ဆိုတဲ့ file တစ်ခု ဖန်တီးလိုက်ပါ။ အောက်က workflow က main ကို push လုပ်တိုင်းနဲ့ pull request တိုင်းမှာ run ပါတယ်။ ပထမဆုံး step က actions/checkout@v4 နဲ့ code ကို runner ပေါ် ကူးယူပါတယ် - ဒါမပါရင် runner ဟာ ဘာ file မှ မရှိတဲ့ ဗလာ machine တစ်လုံးသာ ဖြစ်နေပါလိမ့်မယ်။ ဒုတိယ step က Node 20 ကို တပ်ဆင်ပြီး npm cache ကိုပါ ဖွင့်ပေးလို့ နောက်ထပ် run တွေမှာ install ပိုမြန်ပါတယ်။ ပြီးမှ npm ci နဲ့ dependency တွေကို lockfile အတိုင်း တိတိကျကျ တပ်ဆင်ပြီး (npm install မဟုတ်ပါ - ci က lockfile ကို လေးစားပြီး reproducible ဖြစ်ပါတယ်)၊ နောက်ဆုံးမှာ npm test ကို run ပါတယ်။

အရေးအကြီးဆုံး အချက်က exit code ပါ။ step တစ်ခုက zero မဟုတ်တဲ့ exit code ပြန်ပေးရင် job ကျရှုံးပြီး commit မှာ အနီရောင် X တက်လာပါတယ်။ branch protection rule တစ်ခု ထည့်လိုက်မှသာ ဒီ check က တကယ့် အကာအကွယ် ဖြစ်လာပါတယ် - မဟုတ်ရင် အားလုံးက အနီရောင်ကို လျစ်လျူရှုပြီး merge လုပ်နိုင်နေဆဲပါ။ ဒါကြောင့် CI ကို ထည့်ပြီးတာနဲ့ Settings > Branches မှာ "Require status checks to pass" ကို ဖွင့်ဖို့ မမေ့ပါနဲ့။

• CI = မကြာခဏ merge + အလိုအလျောက် စစ်ဆေးခြင်း
• Delivery က လူဆုံးဖြတ်၊ Deployment က အလိုအလျောက်
• အဓိက အကျိုးက feedback loop တိုခြင်း

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

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: npm

      - name: Install dependencies from the lockfile
        run: npm ci

      - name: Run the test suite
        run: npm test

main ကို push လုပ်တာ (သို့) pull request ဖွင့်တာ/update လုပ်တာနဲ့ ဒီ workflow က run ပါတယ်။ build job တစ်ခုတည်းသာ ရှိပြီး ubuntu-latest runner အသစ်တစ်လုံးပေါ်မှာ step လေးခုကို အစဉ်လိုက် လုပ်ပါတယ် - repository ကို checkout လုပ်၊ Node 20 တပ်ဆင်၊ npm ci နဲ့ dependency တွေသွင်း၊ npm test ကို run။ npm test က zero မဟုတ်တဲ့ exit code ပြန်ရင် အဲဒီ step မှာပဲ job ရပ်သွားပြီး commit နဲ့ pull request မှာ အနီရောင် X ပြပါတယ်။ အားလုံး အောင်မြင်ရင် အစိမ်းရောင် အမှန်ခြစ် ပြပါတယ်။ branch protection မဖွင့်ထားရင် အနီရောင်ဖြစ်နေရင်တောင် merge လုပ်လို့ ရနေဆဲပါ။

GitHub Docs - Understanding GitHub Actions — CI/CD with GitHub Actions