How It Works

What Is a Pipeline

এই section-এ শব্দটি বারবার আসবে, তাই আগে মানে পরিষ্কার করে নেওয়া দরকার।

Pipeline হলো কতগুলো ধাপের একটি সারি, যেগুলো একের পর এক নিজে থেকে চলে। আপনি শুরু করিয়ে দিলেন, বাকিটা নিজে হয়।

আপনি এখন হাতে যা করেন সেটিও আসলে একটি pipeline — শুধু প্রতিটি ধাপ নিজে চালান:

code লিখুন → push → ssh → git pull → docker compose up -d --build

CI/CD-র কাজ হলো এই সারিটিকে একটি file-এ লিখে রাখা, যাতে একটি machine প্রতিবার হুবহু একইভাবে চালায়।

দুটি নিয়ম মনে রাখুন:

• ধাপগুলো উপর থেকে নিচে চলে, একটা শেষ হলে পরেরটা
• কোনো ধাপ fail করলে সেখানেই সব থেমে যায়

দ্বিতীয় নিয়মটিই pipeline-কে নিরাপদ করে। Build fail করলে deploy-এর ধাপ পর্যন্ত পৌঁছানোই যাবে না, তাই ভাঙা code কখনো server-এ যেতে পারবে না।

CI and CD

দুটি আলাদা কাজ, একসাথে লেখা হয় বলে অনেকে গুলিয়ে ফেলেন।

CI — Continuous Integration প্রতিটি code change build করে দেখা হয় ঠিক আছে কিনা। কিছু ভাঙলে সেখানেই ধরা পড়ে। Server-এ কিছু হয় না।

CD — Continuous Deployment Build পাশ করলে সেই জিনিস নিজে থেকে server-এ চলে যায়।

What Is a Runner

Runner হলো একটি অস্থায়ী Ubuntu machine যা GitHub আপনাকে প্রতিবার নতুন করে দেয়। আপনার সব build এই machine-এ হবে।

তিনটি কথা মনে রাখুন:

• প্রতিবার সম্পূর্ণ নতুন — আগের run-এর কিছুই থাকে না
• কাজ শেষ হলে মুছে যায়
• আপনার server-এর সাথে এর কোনো সম্পর্ক নেই

শেষ কথাটি জরুরি। Runner আপনার server চেনে না, তার কাছে কোনো password বা key নেই। আপনি না দিলে সে ঢুকতে পারবে না। এই কারণেই পরের page-এ SSH key আর GitHub Secrets নিয়ে কাজ করতে হবে।

Where the Build Runs

এটিই এই page-এর সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন। উত্তরটি পুরো pipeline-এর আকার ঠিক করে দেয়।

পথ ১ — Server নিজে build করে

push → server → git pull → docker compose up -d --build

অনেকেই এভাবে করেন। কাজ করে, কিন্তু production-এ তিনটি সমস্যা:

• Build-এ RAM আর CPU লাগে। ছোট VPS-এ Next.js build প্রায়ই Killed হয়ে যায়, আর build চলার সময় live site ধীর হয়ে থাকে
• Server প্রতিবার নতুন করে package টানে। একই commit থেকে দুইবার build করলে দুটি আলাদা জিনিস তৈরি হতে পারে
• Source code server-এ পড়ে থাকে। কেউ ঢুকে পড়লে আপনার পুরো codebase আর git history তার হাতে

পথ ২ — Runner build করে, server শুধু চালায়

push → runner image বানায় → registry-তে রাখে → server টেনে চালায়

Server আর কিছু বানায় না। সে একটি তৈরি image টেনে এনে চালায়, ব্যস।

এই section-এ পথ ২ শেখানো হবে। VPS-এ Docker দিয়ে deploy করার standard পদ্ধতি এটিই।

What Is a Registry

Runner image বানাল। কিন্তু runner তো কিছুক্ষণ পরে মুছে যাবে। তাহলে image-টি রাখব কোথায়?

Registry হলো image রাখার গুদাম। GitHub-এর নিজের registry-র নাম GHCR — GitHub Container Registry। আপনার repository-র সাথেই আসে, আলাদা account লাগে না।

Runner image বানায়
      ↓  docker push
GHCR
      ↓  docker pull
Server image টেনে চালায়

Image Tags

একটি image-এর নামের শেষে একটি tag থাকে। এই tag দিয়েই কোন version চলছে তা বোঝা যায়।

ghcr.io/your-username/myapp:latest     ← কোনটা? বলা যাচ্ছে না
ghcr.io/your-username/myapp:a3f9c21    ← এই commit-এর, নিশ্চিত

আমরা প্রতিটি image-কে তার commit-এর নাম দিয়ে tag করব। GitHub Actions-এ এটি github.sha নামে পাওয়া যায়।

এতে তিনটি লাভ:

• Production-এ ঠিক কোন code চলছে তা এক নজরে বলা যায়
• পুরোনো প্রতিটি version registry-তে জমা থাকে
• Rollback মানে শুধু পুরোনো tag-টি আবার চালানো

Two Kinds of Compose File

Docker section-এ আপনি compose.yaml দেখেছেন code-এর পাশে, project-এর root folder-এ। এই section-এ সেটি থাকবে server-এ, একা।

একই নামের file, কিন্তু ভেতরে একটি শব্দ আলাদা — আর ওই শব্দটিই ঠিক করে দেয় file-টি কোথায় থাকবে।

build: — compose নিজে image বানায়

services:
  web:
    build:
      context: ./web

build: মানে compose-কে বলা হচ্ছে “তুমি image বানাও”। বানাতে code লাগে, Dockerfile লাগে। তাই এই file-টিকে code-এর পাশে থাকতেই হবে।

image: — compose শুধু চালায়

services:
  web:
    image: ghcr.io/your-username/myapp:${TAG}

image: মানে “বানানোর দরকার নেই, registry থেকে এই তৈরি জিনিসটি এনে চালাও”। Code লাগে না, তাই file-টি server-এ একা থাকতে পারে।

Runner    →  BUILD করে   →  লাগে: code + Dockerfile     (compose নেই)
Registry  →  জমা রাখে     →  লাগে: কিছুই না
Server    →  RUN করে     →  লাগে: compose.yaml + .env   (code নেই)

The Full Flow

সব মিলিয়ে push করার পর যা ঘটে:

আপনার Computer
      │  git push origin main
      ▼
GitHub Repository
      │  workflow file দেখে trigger হয়
      ▼
GitHub Runner  (নতুন খালি Ubuntu machine)
      │  ১. code clone করে
      │  ২. docker build            ← fail করলে এখানেই থেমে যায়
      │  ৩. docker push → GHCR
      ▼
GHCR Registry
      │  image জমা হলো, নাম: commit-এর sha
      ▼
আপনার Server  (SSH দিয়ে ঢোকে)
      │  ৪. .env-এ নতুন TAG লিখে দেয়
      │  ৫. docker compose pull
      │  ৬. docker compose up -d
      │  ৭. curl দিয়ে check করে
      ▼
Site Live      (fail করলে পুরোনো TAG ফিরিয়ে আনে)

The Workflow File

Pipeline-টি আসলে আপনার project-এ রাখা একটি YAML file। GitHub সেটি পড়ে কাজটি করে।

File-টি একটি নির্দিষ্ট folder-এ থাকতে হয়:

myapp/
├── .github/
│   └── workflows/
│       ├── ci.yml         ← pull request-এ build check
│       └── deploy.yml     ← main-এ push হলে deploy
├── Dockerfile
├── .dockerignore
└── package.json

Folder-এর নাম হুবহু .github/workflows হতে হবে। ভুল হলে GitHub file-টি খুঁজেই পাবে না, আর কোনো error ও দেখাবে না।

একটি ছোট workflow দেখে প্রতিটি অংশ বুঝে নিই:

name: CI
 
on:
  pull_request:
    branches: [main]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Build image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: false

uses and run

Step দুই ধরনের হয়।

uses — অন্যের লেখা তৈরি action চালায়:

- uses: actions/checkout@v4

actions/checkout হলো GitHub-এর নিজের লেখা একটি action, যা repo-র code runner-এ clone করে। নিজে লিখতে গেলে অনেক লাইন লাগত।

run — সরাসরি shell command চালায়, runner-এর ভেতরে:

- run: docker image ls

with

কোনো action-কে extra তথ্য দিতে with ব্যবহার হয়। উপরের example-এ docker/build-push-action-কে বলা হয়েছে কোথা থেকে build করবে (context) আর registry-তে পাঠাবে কিনা (push)।

Why Two Separate Jobs

Deploy workflow-এ দুটি job থাকবে, একটি নয়।

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # image build করে registry-তে পাঠায়
 
  deploy:
    needs: build          # ← মূল লাইন
    runs-on: ubuntu-latest
    steps:
      # server-এ SSH করে

needs: build লাইনটি বলছে — build job পাশ না করলে deploy job শুরুই হবে না।

এর মানে আপনার server তখনই ছোঁয়া হবে যখন image ইতিমধ্যে তৈরি হয়ে registry-তে পৌঁছে গেছে। Build fail করলে server আগের image নিয়েই চলতে থাকবে, কেউ টেরও পাবে না।

Reading a Failed Run

Pipeline fail করলে GitHub-এ Actions tab-এ যাবেন।

• লাল X মানে কোনো job fail করেছে
• সেটিতে click করলে step-গুলো, আবার click করলে পুরো log খুলবে
• Log-এর শেষ ২০ লাইন পড়ুন — আসল error প্রায় সবসময় সেখানেই

একটি step fail করলে পরেরগুলো চলেই না। তাই প্রথম লাল X-টিই আসল সমস্যা।

Real-World Note

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Quick Check

• Pipeline-এর কোনো ধাপ fail করলে পরেরগুলোর কী হয়?
• Build কেন server-এ না করে runner-এ করা উচিত?
• Registry কী এবং কেন লাগে?
• Image-এ শুধু latest tag দিলে কী হারাবেন?
• compose-এ build: আর image:-এর পার্থক্য কী?
• এই pipeline-এ image কে বানায় — compose, নাকি Dockerfile?
• needs: build না থাকলে কী সমস্যা হয়?

পরবর্তী → Setup