ကျွန်တော်တို့ ရေးထားတဲ့ app တွေကို server တွေပေါ် build and deploy လုပ်တာကို manual အစား github actions ကို အသုံးပြုပြီး automate လုပ်ထားလို့ရပါတယ်။ code block က yml config က build and deploy လုပ်ဖို့ လိုအပ်တဲ့ steps အပြည့်အစုံပါ။ ကျွန်တော် workflow ရဲ့အဓိကအပိုင်းလေးတွေပဲ ပြောပြသွားပါမယ်။ Details နဲ့ လုပ်လို့ရတာတွေ ပိုသိအောင် official github actions docs မှာ ဖတ်ကြည့်တာကောင်းပါတယ်

name: Buid & Deploy

run-name: Build and deploy by @${{ github.actor }}

on: workflow_dispatch

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Setup Java JDK
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: '21'

    - name: Build with Maven
      run: mvn install

    - name: Archive production artifacts
      uses: actions/upload-artifact@v4
      with:
        name: application artifacts
        path: marketplace-application/target/

  deploy:
    needs: build
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - uses: actions/download-artifact@v4
      with:
        name: application artifacts
        path: marketplace-application/target/

    - name: Upload to hosting
      uses: appleboy/scp-action@v0.1.7
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        key: ${{ secrets.KEY }}
        source: "marketplace-application/target/marketplace-application-1.0.0.jar"
        target: "/opt/marketplace/backend"
        strip_components: 2
        overwrite: true

    - name: Executing remote ssh commands
      uses: appleboy/ssh-action@v1.0.3
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        key: ${{ secrets.KEY }}
        script: |
          sudo systemctl restart marketplace-backend

1. ဒီ workflow ကို ဘယ်အချိန်မှာ run မှာလည်းဆိုတာ သတ်မှတ်ပေးရပါတယ် ကျွန်တော် ထားထားတဲ့ on: workflow_dispatch က manual run မယ်လို့ပြောတဲ့သဘောပါ အဲ့တာကြောင့် ကိုယ်က web ကပဲ ဖြစ်ဖြစ် CLI ကပဲ ဖြစ်ဖြစ် run ချင်တဲ့အခါ trigger သွားလုပ်ပေးရပါတယ်။ တစ်ခြား branch push, release, issue, cron etc., event တွေများကြီးရှိပါတယ် docs မှာဖတ်ကြည့်ပါ။

2. ကိုယ် run မဲ့ jobs တွေ သတ်မှတ်ပေးရပါတယ်။ ကျွန်တော်က build and deploy ဆိုပြီး job နှစ်ခုခွဲထားပါတယ်။ အရင်ဆုံး application ကို build လုပ်မယ် သူ‌ success ဖြစ်မှ deploy တာကို ဆက်လုပ်မယ်ပေါ့ deploy job မှာ build job ကို needs ဆိုပြီးသတ်မှတ်ထားတာဖြစ်တဲ့အတွက် deploy run ဖို့ build job success ဖြစ်မှရမယ်ပေါ့။ job ထဲမှာ runs-on ဆိုတာက ကိုယ် run မဲ့ runner VM ပါ တစ်ခြား သူ support တာတွေရှိပါတယ်။ ပြီးတော့ jobs တွေထဲမှာ ဘာပြီးဘာလုပ်မယ်ဆိုတဲ့ steps တွေသတ်မှတ်ရပါတယ်။ အဲ့ steps တွေထဲမှာ လိုအပ်တဲ့ process အတွက် သူများလုပ်ပြီးသား actions လေးတွေပြန်သုံးလို့ရပါတယ် သက်သာတာပေါ့ ကိုယ်တိုင် လုပ်ချင်လည်းရပါတယ် အချိန်တော့ကုန်တာပေါ့။

build job ထဲမှာ ကိုယ် ရဲ့ repo ကို runner ပေါ် checkout ဖို့အတွက် checkout actions သုံးတယ် spring boot build ဖို့အတွက် java setup action သုံးတယ် ပြီးတော့မှ maven install command run ပြီး build တယ် output ထွက်လာတဲ့ application jar file ကို deploy job မှာသုံးဖို upload artifact action ကိုသုံးပြီး သိမ်းထားလိုက်တယ်။

deploy job ရောက်တော့ ခုဏက သိမ်းထားတဲ့ file ကို ပြန်ယူဖို့ download artifact action ကိုသုံးတယ် ပြီးတော့ အဲ့ဒီ file ကို server instant ပေါ် scp နဲ့ upload ဖို့ appleboy/scp-action ကိုသုံးတယ် ဒီနေရာမှာ server instance နဲ့ ချိတ်ဆက်ဖို့ ssh credentials တွေထည့်‌ပေးဖို့ လိုလာတယ် အဲ့တာကြောင့် host ရယ် username ရယ် private key ရယ်ကို actions secret အနေနဲ့ repository setting ထဲမှာ key-value သွားသတ်မှတ်ပြီး ဒီမှာပြန်သုံးရပါတယ် အရေးကြီး credentials တွေဖြစ်လို့ ဒီ workflow file ထဲမှာ မရေးပါနဲ့ actions secret အနေနဲ့ သွားထားပြီး ဒီမှာပြန်သုံးပါ။ scp နဲ့ upload ပြီးတော့ application ကို တစ်ခါထည်း run ဖို့ server instance ကို ssh login ဝင်ဖို့အတွက် appleboy/ssh-action ကို သုံးတယ် credentials တွေကတော့ scp နဲ့တူတူပါပဲ ပြီးတာနဲ့ application run command ကို script မှာ သတ်မှတ်ပေးလိုက်ရင်ရပါပြီ ကျွန်တော်က systemd အနေနဲ့ server မှာ သတ်မှတ်ထားလို့ systemctl နဲ့ run ပါတယ် ကိုယ်က တစ်ခြားပုံစံလုပ်ထားရင် တော့ command မတူဘူးဖြစ်ပါလိမ့်မယ်။

အကယ်၍ deploy မှာတစ်ခုခု ကြောင့် failed သွားလည်း build ကို ပြန်မ run ပဲ deploy ပဲ re-run ပြန်လုပ်လည်းရပါတယ်။

နောက်တစ်ခုရှိတာက server instance တွေဘက်က ssh အတွက် firewall rule မှာ ip allow ဖို့အတွက်ကျ github hosted runner တွေ က ip တွေ အများကြီးဆိုတော့ အဆင်မပြေဘူး ကြည့်ချင်ရင်ကရတယ် CIDR range တွေနဲ့ ပေးထားတယ် ဒါပေမဲ့ သူလည်း recommend မပေးဘူး။ အဲ့တော့ ကျွန်တော်ကတော့ လုပ်တဲ့အချိန်ခဏ * နဲ့ဖွင့်လိုက်တယ် 🥲။ self hosted runner နဲ့ enterprise runner သုံးနိုင်ရင်တော့ အဆင်ပြေပါတယ်။

တစ်ခြား application deployment တွေလည်း သဘောတရားအတူတူဖြစ်တော့ လုပ်ကြည့်လို့ အဆင်ပြေပါလိမ်မယ် ကိုလုပ်ရမဲ့ steps တွေ အဓိကသိရင်အဆင်ပြေပါပြီ။ အရေးကြီး credentials တွေသတိထားပေးပါ။ Happy learning...