M. ISLAM

Day 28 — CI/CD Pipeline — Commit থেকে Production পর্যন্ত নিরাপদে যান 🚀

July 21, 20266 min read30 Days Of Backend Engineering

এতদিন তো অনেক কিছুই করলেন কিন্তু এখনো বেশ কিছু জায়গা আছে যেগুলোতে productivity একটু হলেও বাড়াতে পারেন। এবার আপনি development workflow-টাকে একটু optimize করার কথা চিন্তাভাবনা করলেন। এটা মাথায় রেখে আপনি প্রত্যেকটা team-এর workflow analysis করতে বসলেন। এখানে আপনি অনেকগুলো জিনিস লক্ষ্য করলেন। বিশেষত অনেকগুলো কাজ আছে যেগুলো প্রতিদিন repeatedly করতে হয়। সেগুলো হলো:

১. manually code test করা লাগে। ২. কোনো feature add হলে সেটা build করে, deploy করতে হয়। ৩. manually test করার কারণে, production-এ যেয়ে অনেক unwanted error দেখা দেয় সেগুলোও solve করা লাগে।

এছাড়াও এই repeated কাজ করতে করতে team member-রা bore হয়ে যাচ্ছে। তারা কিছু বলছে না কারণ তাদেরকে proper সুযোগ-সুবিধা দেয়া হচ্ছে এর জন্য। না হলে company থেকে চলে যেত।

উপরে যে repeated task-গুলো রয়েছে, সেগুলো docker এবং k8s introduce করার পর একটু কমে গেছে। আগে অনেক কিছু করা লাগত। এখন docker image build বা k8s deployment use করলেই কাজ শেষ।

এর পরের বিষয়গুলো তারপরও repeated কাজ। এগুলো automatic করা যায় কি না। তো আপনার মাথায় একটা idea আসল যে, এই কাজগুলো তো same, আপনি যদি একটা shell script লিখে ফেলেন তো কাজ হয়ে যাবে। shell script দিয়ে প্রথমে testing করার জন্য test-গুলো run করবো, then সেটাকে build করার দরকার হলে build করে দেখবো যে কোনো error আছে কি না, and finally সেটাকে deploy করে দেবো।

এটাকেই বলে CI/CD (Continuous Integration/Continuous Delivery)

CI vs CD

CI (Continuous Integration) — প্রতিটা code push-এ automatically test run করা, build করা হয়। মূলত চেকিং এর কাজ টা এই step এ হয়। কোনো problem হলে সেটা সাথে জানাবে এবং সামনের দিকে আগাবে না।

CD (Continuous Delivery) — CI পাস করলে staging-এ automatically deploy হয়ে যাবে।

CD (Continuous Deployment) — Production-এ auto deploy। Human approval নেই।

বেশিরভাগ team Continuous Delivery করে — staging auto deploy হয় আর production-এ একজন approve করলে তারপর deploy হয়।

GitHub Actions: সহজ শুরু

এখন আপনি একটা shell scripting করে আপনার একটা workflow automate করতে পারবেন। shell scripting আপনার একার জন্য একদম ঠিক আছে, কিন্তু আপনার company-তে team অনেক বেশি, অনেক manpower রয়েছে। আপনার style আর তাদের style-টা নাই match হতে পারে। তখন আবার complication বাড়বে। এর জন্য standard কিছু জিনিস দরকার। তবে একটা CI/CD-এর ক্ষেত্রে কোনো fixed standard নেই। এই standard-তো complication দূর করার জন্য আপনি নানারকমের tool use করতে পারেন। GitHub Actions is one of them।

নিচে একটা simple CI/CD pipeline লেখা আছে। দেখলে কিছুটা idea পাবেন।

# .github/workflows/ci.yml
name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm run test:ci

      - name: Build
        run: npm run build

GitHub Actions GitHub-এ run হয়। উপরের এই workflow-তে বলা হচ্ছে, যখন main branch-এ কোনো কিছু push করা হবে বা pull request create করা হবে তখন নিচের এই job-গুলো হবে। job-এর name-গুলো দেখলেই বুঝতে পারবেন যে এখানে development environment setup করে, প্রথমে linting, then testing and finally build করেছে। এখানে কোনো step-এ যদি কোনো error হয় তাহলে immediately তা stop হয়ে যাবে।

Docker Build + Push

build-and-push:
  runs-on: ubuntu-latest

  steps:
    - uses: actions/checkout@v4

    - name: Build Docker image
      run: docker build -t my-app:${{ github.sha }} .

    - name: Push to registry
      run: |
        docker tag my-app:${{ github.sha }} ghcr.io/myorg/my-app:${{ github.sha }}
        docker push ghcr.io/myorg/my-app:${{ github.sha }}

এখানে simply docker image build and push করা হয়েছে।

Deploy to Production

deploy:
  needs: build-and-push
  runs-on: ubuntu-latest
  environment: production # manual approval লাগবে
  permissions:
    id-token: write # OIDC authentication-এর জন্য
    contents: read

  steps:
    - uses: actions/checkout@v4

    # 1. AWS/GCP/Azure-এর সাথে নিরাপদ OIDC কানেকশন (কোনো permanent secret ছাড়া)
    - name: Authenticate with Cloud Provider (OIDC)
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy-role
        aws-region: us-east-1

    - name: Get K8s Context
      run: aws eks update-kubeconfig --name my-cluster --region us-east-1

    # 2. Deploy to K8s
    - name: Deploy to K8s
      run: |
        kubectl set image deployment/my-app \
          my-app=ghcr.io/myorg/my-app:${{ github.sha }}
        kubectl rollout status deployment/my-app

environment: production দিলে GitHub-এ reviewer approve না করলে deploy হবে না।

Branch Strategy: কোথায় কী deploy হবে

feature/* → CI only (test + lint)
develop   → CI + deploy to staging
main      → CI + deploy to production (manual approve)

Secrets Management

- name: Deploy
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
    API_KEY: ${{ secrets.API_KEY }}

workflow file-এর ভেতরে কোনো configuration related file রাখলে তা leak হওয়ার possibility থাকে। এর জন্য best হচ্ছে GitHub Secrets। এটা securely আপনার environment variable-গুলো maintain করতে help করে।

বটম লাইন

CI/CD মানে শুধু automation না — এটা confidence। Test pass না করলে deploy হবে না। Production-এ কোনো surprises নেই। একবার setup করুন, সারাজীবন সময় বাঁচান।

বি:দ্র: উপরের যে yaml file গুলা লেখা হয়েছে এইগুলো begginer friendly এবং simple ভাবে লেখা হয়েছে। এই গুলাকে আরও better ভাবে লেখা যেতে পারে।

আপনার team কোন CI/CD tool ব্যবহার করছে? কমেন্টে শেয়ার করুন! 👇

Back to publications