GitHub Actions দিয়ে CI/CD: নিরাপদে test, build ও deploy

CI (continuous integration) মানে প্রতিটি বদল স্বয়ংক্রিয়ভাবে build ও test হয়। CD (continuous delivery বা deployment) মানে পাস করা বদল স্বয়ংক্রিয়ভাবে release হতে পারে। দুটি মিলে bug আগেই ধরে এবং release একঘেয়ে করে তোলে, যেটাই লক্ষ্য।

GitHub Actions আপনার repository-র ভেতরেই এই pipeline চালায়, আলাদা server সামলাতে হয় না।

অংশগুলো

• Workflow: .github/workflows/-এ একটি YAML ফাইল।
• Event (on): যা এটি শুরু করে, যেমন push, pull request, schedule বা হাতে চালানো।
• Job: এক মেশিনে (runner) চলা ধাপের দল। needs দিয়ে না বাঁধলে job সমান্তরালে চলে।
• Step: একটি কমান্ড বা একটি পুনর্ব্যবহারযোগ্য action।

প্রথম workflow: test ও build

name: CI
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test
      - run: npm run build

মন্তব্য:

• npm ci lockfile-এ যা লেখা ঠিক তাই install করে, ফলে build পুনরাবৃত্তিযোগ্য হয়।
• cache: npm নামানো package আবার ব্যবহার করে ও গতি বাড়ায়।
• permissions: contents read job-কে শুধু দরকারি access দেয়।
• Pull request একই পরীক্ষা চালায়, তাই ভাঙা বদল merge-এর আগেই দেখা যায়। পরীক্ষা পাস বাধ্যতামূলক করতে branch protection ব্যবহার করুন।

Secret

পাসওয়ার্ড, token ও key রাখুন Settings, Secrets and variables, Actions-এ, আর পড়ুন ${{ secrets.NAME }} হিসেবে।

• YAML-এ secret লিখবেন না, commit করবেন না।
• Log পরিচিত secret মান লুকায়, তবু ইচ্ছে করে print করবেন না।
• Token-কে ন্যূনতম scope দিন এবং ঘুরিয়ে বদলান।
• Fork থেকে আসা pull request-এর workflow ডিফল্টে আপনার secret পায় না। এটি তেমনই রাখুন।

সতর্ক deploy job

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy over SSH
        run: ./scripts/deploy.sh
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

• needs: test মানে test পাস করলেই deploy।
• if deploy শুধু main branch-এ সীমিত করে।
• environment: production হাতে অনুমোদন চাইতে পারে এবং নিজস্ব secret রাখে।
• Deploy script পুনরাবৃত্তিযোগ্য ও ফেরানোযোগ্য করুন, health check ও দ্রুত rollback-এর উপায়সহ।

ভালো অভ্যাস

• তৃতীয় পক্ষের action-কে সংস্করণে পিন করুন, সংবেদনশীল pipeline-এ commit SHA-তে, কারণ action এমন কোড যা আপনার secret-এর কাছাকাছি চলে।
• Workflow দ্রুত রাখুন: dependency cache করুন, স্বাধীন job সমান্তরালে চালান।
• দুটি deploy একসাথে এড়াতে concurrency ব্যবহার করুন।
• Pull request-এর শিরোনাম, branch-এর নাম ও issue-র লেখা অবিশ্বস্ত input ধরুন। সরাসরি shell কমান্ডে বসাবেন না।
• ব্যর্থ হলে জানান পান এবং লাল build দ্রুত ঠিক করুন। সবাই উপেক্ষা করে এমন pipeline অকেজো।

সাধারণ ভুল

• Repo বা log-এ secret রাখা।
• Workflow-কে দরকারের বেশি write permission দেওয়া।
• প্রতিটি branch থেকে deploy।
• Test না থাকা, ফলে pipeline শুধু প্রমাণ করে কোড compile হয়।

মূল কথা: প্রতিটি push ও pull request-এ install, test ও build করা workflow দিয়ে শুরু করুন, test পাস ও main branch শর্তে deploy job যোগ করুন, secret রাখুন secret store-এ, এবং workflow-কে ন্যূনতম দরকারি permission দিন।

---

Linux ও DevOps সিরিজ, পর্ব ২ (delivery ও পরিচালনা): 2 নম্বর (মোট 5)। আগের লেখা: Kubernetes-এর গোড়া: pod, deployment ও service.