Continuous integration — pipeline, build, test আর দ্রুত feedback

১ · Continuous integration কী — “integration hell” থেকে দিনে বহুবার মেলানো

পর্ব ১৭-এ (Branching strategy) হিসাব করে দেখেছেন, একটি branch যত দিন আলাদা থাকে, মেলানোর সময় conflict আর লুকানো ভুলের ঝুঁকি তত বাড়ে। বহু সপ্তাহ আলাদা কাজের পর একসাথে মেলানোর সেই যন্ত্রণার নাম integration hell. Continuous integration (CI) এর উল্টো উত্তর: মেলানো কষ্টের হলে, সেটি আরও ঘন ঘন করুন — এত ঘন যে প্রতিবারের পরিবর্তন ছোট, আর ভাঙলে কারণ খুঁজতে মিনিট লাগে, সপ্তাহ নয়।

CI একটি অনুশীলন, tool নয়

এই পর্বের সবচেয়ে জরুরি বাক্য এটি। CI tool — যে software প্রতিটি push-এ build আর test চালায় — CI-এর একটি অংশ মাত্র। মূল অনুশীলন মানুষের অভ্যাস: সবাই ঘন ঘন mainline-এ মেলান, আর mainline ভাঙলে সবাই থেমে আগে সেটি ঠিক করেন. একটি দল যদি প্রতিটি feature branch-এ চমৎকার pipeline চালায়, কিন্তু branch-গুলো তিন সপ্তাহ পরে main-এ মেলে, তাহলে integration হচ্ছে তিন সপ্তাহে একবার — “continuous” নয়। Jez Humble-এর একটি বহুল-উদ্ধৃত পরীক্ষায় তিনটি প্রশ্ন আছে (শব্দ উৎসভেদে একটু আলাদা):

1. দলের প্রত্যেকে কি অন্তত দিনে একবার mainline-এ (feature branch-এ নয়) কোড মেলান?
2. প্রতিটি commit কি স্বয়ংক্রিয় build আর test চালায়?
3. Build ভাঙলে কি সাধারণত দশ মিনিটের মধ্যে আবার ঠিক হয়?

তিনটিতেই “হ্যাঁ” না হলে, যতই সুন্দর tool থাকুক, দলটি পুরো অর্থে CI করছে না। এই কারণেই CI trunk-based development-এর ঘনিষ্ঠ সঙ্গী (পর্ব ১৭): ছোট, স্বল্পজীবী branch বা সরাসরি trunk, আর অসম্পূর্ণ কাজ feature flag-এর আড়ালে।

২ · Fowler-এর অনুশীলনগুলো — একটি repository থেকে “সবাই ফল দেখতে পান”

Fowler-এর ২০০৬ সংস্করণে প্রায় দশটি অনুশীলন ছিল। নিচের তালিকা সেই লেখার মূল কথাগুলোর সারাংশ — শব্দ হুবহু নয়, আর ২০২৪-এর সংশোধনে কিছু নাম ও ক্রম বদলেছে বলে জানা যায়; মূল লেখাটি নিজে পড়ে মিলিয়ে নিন।

“দশ মিনিট” সংখ্যাটি নিয়ে সাবধান হোন। এটি এসেছে XP থেকে — Beck-এর বইয়ের দ্বিতীয় সংস্করণে (২০০৪) “Ten-Minute Build” আলাদা অনুশীলন — আর Fowler একে নির্দেশিকা হিসেবে উল্লেখ করেছেন। এটি কোনো মান-সংস্থার নিয়ম নয়, অভিজ্ঞতার সীমা: এর বেশি হলে মানুষ অপেক্ষা না করে অন্য কাজে যান, আর commit জমিয়ে বড় করে পাঠাতে শুরু করেন। বড় project তাই প্রায়ই ভাগ করে: দ্রুত “commit stage” প্রতিটি push-এ, ধীর suite পরে — Jez Humble ও David Farley-এর Continuous Delivery (২০১০) বইয়ের deployment pipeline, পর্ব ৫৯-এ।

৩ · Pipeline-এর গঠন — trigger থেকে status check

একটি CI pipeline হলো স্বয়ংক্রিয় ধাপের সাজানো ক্রম। শব্দগুলো platform-ভেদে একটু আলাদা, কিন্তু কাঠামো প্রায় সব জায়গায় একই:

• Trigger: কোন ঘটনায় pipeline চলবে — branch-এ push, pull request খোলা বা নতুন commit, সময়সূচি (যেমন প্রতি রাতে; nightly build), বা কেউ হাতে চালালেন।
• Job: কাজের একক, যা একটি runner-এ নিজের আলাদা, নতুন পরিবেশে চলে। দুটি job-এর মধ্যে file আপনা-আপনি যায় না — পাঠাতে হয় artifact দিয়ে (অংশ ৫)।
• Step: একটি job-এর ভেতরে পরপর চলা ধাপ — একটি shell command (npm test) বা অন্যের লেখা একটি তৈরি action. কোনো command শূন্য ছাড়া অন্য exit code দিলে step ব্যর্থ, আর সাধারণত job সেখানেই থামে।
• Stage: job-গুলোর দল। একই stage-এর job সমান্তরালে চলে; আগের stage সফল হলে পরেরটি শুরু হয়। আরও সূক্ষ্ম পথ: প্রতিটি job বলে দেয় সে কোন job-এর জন্য অপেক্ষা করবে (GitHub Actions-এ needs, GitLab-এ needs) — তখন pipeline একটি DAG.
• Runner বা agent: যে যন্ত্র job চালায় — platform-এর দেওয়া hosted runner (প্রতিটি job-এ নতুন virtual machine, কাজ শেষে মুছে ফেলা হয়) বা দলের নিজের self-hosted runner.
• Status reporting: শেষে ফল ফেরত যায় commit বা PR-এ, status check হিসেবে — সবুজ টিক, লাল ক্রস, বা হলুদ “চলছে”। পর্ব ১৬-এ (Pull request আর fork) দেখেছেন, branch protection চাইলে নির্দিষ্ট check সবুজ না হলে merge বন্ধ থাকে।

একটি সাধারণ pipeline-এ ধাপগুলোর ক্রম মোটামুটি এমন — সস্তা আর দ্রুত check আগে, যাতে সবচেয়ে সাধারণ ভুল সবচেয়ে আগে ধরা পড়ে:

DAG ধরে চালানো আর fail-fast — একটি ছোট pipeline runner

Platform-গুলো ভেতরে যা করে, তার একটি খেলনা মডেল নিচে। প্রতিটি stage-এর needs তালিকা বলে সে কার জন্য অপেক্ষা করবে; runner প্রথমে একটি topological order বানায় (প্রতিটি stage তার সব needs-এর পরে), তারপর চালায়। কোনো need সফল না হলে stage-টি চলেই না — fail fast. সময় আর ফল (pass বা fail) দেওয়া মান; আসলে কিছু চালানো হচ্ছে না। আর ধরা হয়েছে, যথেষ্ট runner আছে, তাই যার needs শেষ, সে সাথে সাথে শুরু করে:

// Tiny CI pipeline runner. Stages form a DAG through "needs".
// Durations (seconds) and pass/fail are STATED inputs; no real work runs.
const STAGES = [
  { name: "checkout",    needs: [],                                   sec: 5,   ok: true  },
  { name: "install",     needs: ["checkout"],                         sec: 40,  ok: true  },
  { name: "lint",        needs: ["install"],                          sec: 20,  ok: true  },
  { name: "build",       needs: ["install"],                          sec: 60,  ok: true  },
  { name: "unit",        needs: ["build"],                            sec: 90,  ok: false },
  { name: "security",    needs: ["install"],                          sec: 45,  ok: true  },
  { name: "integration", needs: ["unit"],                             sec: 180, ok: true  },
  { name: "artifact",    needs: ["lint", "integration", "security"],  sec: 15,  ok: true  },
];
function runPipeline(stages) {
  const by = Object.fromEntries(stages.map(s => [s.name, s]));
  const order = [], seen = new Set();
  const visit = n => { if (seen.has(n)) return; seen.add(n); by[n].needs.forEach(visit); order.push(n); };
  stages.forEach(s => visit(s.name));                 // topological order (DFS)
  const state = {}, end = {};
  for (const n of order) {
    const s = by[n], blocked = s.needs.filter(d => state[d] !== "passed");
    if (blocked.length) {                              // fail-fast: dependents never start
      state[n] = "skipped"; console.log(`SKIP ${n.padEnd(12)} needs ${blocked.join(", ")}`); continue;
    }
    const start = Math.max(0, ...s.needs.map(d => end[d]));  // parallel: start when needs finish
    end[n] = start + s.sec; state[n] = s.ok ? "passed" : "failed";
    console.log(`${s.ok ? "PASS" : "FAIL"} ${n.padEnd(12)} ${start}s -> ${end[n]}s`);
  }
  const pick = st => order.filter(n => state[n] === st);
  const ran = order.filter(n => n in end);
  console.log(`wall clock ${Math.max(...ran.map(n => end[n]))}s, serial would be ${ran.reduce((a, n) => a + by[n].sec, 0)}s`);
  console.log(`status: ${pick("failed").length ? "FAILED" : "PASSED"}` +
    ` | failed: ${pick("failed").join(", ") || "-"} | skipped: ${pick("skipped").join(", ") || "-"}`);
}
runPipeline(STAGES);

PASS checkout     0s -> 5s
PASS install      5s -> 45s
PASS lint         45s -> 65s
PASS build        45s -> 105s
FAIL unit         105s -> 195s
PASS security     45s -> 90s
SKIP integration  needs unit
SKIP artifact     needs integration
wall clock 195s, serial would be 260s
status: FAILED | failed: unit | skipped: integration, artifact

এবার একটি সত্যিকারের PR-এর জীবন, push থেকে সবুজ check পর্যন্ত। কাল্পনিক অনলাইন বাজার অ্যাপ bazar-cart-এ নাদিয়া coupon-এর একটি পরিবর্তন পাঠালেন। সময়গুলো উদাহরণের জন্য ধরা:

৪ · Matrix, parallelism আর test sharding

একটি library অনেক জায়গায় চলবে — Linux, Windows, macOS; Node-এর তিনটি version. প্রতিটির জন্য আলাদা job হাতে লেখা ভুলপ্রবণ। Matrix build একবার job লিখে বলে দেয় কোন মাত্রার সব জোড়ায় চালাতে হবে: ৩টি OS × ৩টি version = ৯টি job. দুটি নিয়মে ছাঁটা যায়:

• exclude: কিছু জোড়া বাদ — যেমন পুরোনো version-টি macOS-এ পরীক্ষা অপ্রয়োজনীয় বা দামি।
• include: GitHub Actions-এর documentation অনুযায়ী (লেখার সময়ে) include বস্তু matrix-এর নিজের key-তে কোনো বিদ্যমান জোড়ার সাথে মিললে সেই job-এ বাড়তি key যোগ হয়, না মিললে নতুন job; exclude আগে, include পরে। আসল নিয়মের আরও সূক্ষ্ম অবস্থা আছে; নিচের মডেল সরলীকৃত।

Matrix job-গুলো কত দ্রুত শেষ হবে, তা নির্ভর করে কয়টি runner একসাথে পাওয়া যায় তার ওপর। প্রতিটি job-এর সময় নিচে দেওয়া — মাপা নয়। Scheduler সারির ক্রমে job নেয়, আর যে runner আগে খালি হয়, তাকে দেয়:

// Matrix expansion (simplified GitHub-Actions-style rules), then scheduling on N runners.
const matrix  = { os: ["ubuntu", "windows", "macos"], node: [22, 24, 26] };
const exclude = [{ os: "macos", node: 22 }];
const include = [{ os: "ubuntu", node: 24, coverage: true },   // matches a job: adds a key
                 { os: "ubuntu-arm", node: 24 }];              // matches none: new job
const MINUTES = { ubuntu: 4, "ubuntu-arm": 5, windows: 7, macos: 6 };   // STATED job times
const minutes = j => MINUTES[j.os] + (j.coverage ? 2 : 0);     // coverage costs 2 more

function expand(m, exc, inc) {
  let jobs = [{}];                                              // cartesian product
  for (const [k, vals] of Object.entries(m)) jobs = jobs.flatMap(j => vals.map(v => ({ ...j, [k]: v })));
  const fits = (j, r) => Object.keys(r).every(k => j[k] === r[k]);
  jobs = jobs.filter(j => !exc.some(e => fits(j, e)));          // exclude first
  for (const add of inc) {
    const keys = Object.keys(add).filter(k => k in m);          // only the matrix's own keys
    const hit = jobs.filter(j => keys.every(k => j[k] === add[k]));
    if (hit.length) hit.forEach(j => Object.assign(j, add)); else jobs.push({ ...add });
  }
  return jobs;
}
function schedule(jobs, runners) {                              // queue order, earliest-free runner
  const free = Array(runners).fill(0);
  for (const j of jobs) { const r = free.indexOf(Math.min(...free)); free[r] += minutes(j); }
  return Math.max(...free);
}
const jobs = expand(matrix, exclude, include);
jobs.forEach((j, i) => console.log(`job ${i + 1}: ${j.os}/node${j.node}${j.coverage ? " +coverage" : ""} ${minutes(j)} min`));
const total = jobs.reduce((a, j) => a + minutes(j), 0);
console.log(`${jobs.length} jobs, ${total} runner-minutes`);
for (const n of [1, 2, 4, jobs.length]) console.log(`${String(n).padStart(2)} runners -> wall clock ${schedule(jobs, n)} min`);

job 1: ubuntu/node22 4 min
job 2: ubuntu/node24 +coverage 6 min
job 3: ubuntu/node26 4 min
job 4: windows/node22 7 min
job 5: windows/node24 7 min
job 6: windows/node26 7 min
job 7: macos/node24 6 min
job 8: macos/node26 6 min
job 9: ubuntu-arm/node24 5 min
9 jobs, 52 runner-minutes
 1 runners -> wall clock 52 min
 2 runners -> wall clock 26 min
 4 runners -> wall clock 16 min
 9 runners -> wall clock 7 min

Parallelism আর test sharding

Matrix একই test-কে ভিন্ন পরিবেশে চালায়। Test sharding উল্টো: একই পরিবেশে, একটি বড় suite-কে কয়েকটি ভাগে ভেঙে কয়েকটি runner-এ। ১২ মিনিটের suite চারটি shard-এ ভাঙলে আদর্শে ৩ মিনিট — কিন্তু তিনটি শর্তে:

• প্রতিটি shard নিজের setup-এর খরচ দেয়: setup ২ মিনিট হলে চার shard-এর প্রতিটি ৫ মিনিট, মোট ২০ runner-মিনিট (একটিতে ছিল ১৪)। Cache এখানে সবচেয়ে কাজের (অংশ ৫)।
• ভাগ সময়ে সমান হতে হবে, test-এর সংখ্যায় নয়; অনেক tool আগের run-এর সময় দেখে ভাগ করে।
• Test-গুলো স্বাধীন হতে হবে: পর্ব ৫১-এর (Test pyramid আর integration test) hermetic test-এর শর্ত; suite-এর গতি আর flaky test সেখানে বিস্তারিত।

৫ · Cache আর artifact — একই রকম দেখতে, কাজ আলাদা

Hosted runner প্রতিটি job-এ শূন্য থেকে শুরু করে। তাই দুটি প্রশ্ন বারবার আসে: “গতবার যে dependency নামিয়েছিলাম, আবার নামাব কেন?” আর “build job-এর তৈরি file test job পাবে কীভাবে?” প্রথমটির উত্তর cache, দ্বিতীয়টির artifact.

সবচেয়ে গুরুত্বপূর্ণ সারি শেষটি: cache ছাড়াও pipeline-কে সঠিক ফল দিতে হবে. Cache শুধু গতি দেয়। তাই cache-এর key এমন হতে হবে, যা dependency বদলালেই বদলায় — নইলে পুরোনো dependency দিয়ে test pass করবে, অথচ নতুন যন্ত্রে ভাঙবে। সবচেয়ে প্রচলিত কৌশল: lockfile-এর হুবহু byte-এর hash. GitHub Actions-এর hashFiles('**/package-lock.json') বা setup-node-এর cache: npm এই কাজই করে; GitLab-এ cache:key:files.

নিচের Python প্রোগ্রাম চারটি run-এ cache key হিসাব করে, আর একটি নকল cache store-এ খোঁজে। Key হুবহু না মিললে “restore keys”-এর মতো একটি prefix দিয়ে সবচেয়ে নতুন কাছাকাছি cache নেয় — partial hit; তারপর package manager শুধু বদলানো অংশ নামায়:

# Dependency-cache key from a lockfile's exact bytes (like hashFiles() in CI).
import hashlib

def cache_key(os_name, lock_text):
    digest = hashlib.sha256(lock_text.encode("utf-8")).hexdigest()[:12]
    return f"{os_name}-pip-{digest}"

def restore(store, key, prefix):
    if key in store:
        return "exact hit"
    partial = [k for k in store if k.startswith(prefix)]   # like restore-keys
    return f"partial hit ({partial[-1]})" if partial else "miss"

lock_v1 = "requests==2.32.3\nurllib3==2.2.3\n"
runs = [
    ("1 first run",              lock_v1),
    ("2 only app code changed",  lock_v1),                     # lockfile identical
    ("3 a comment added",        lock_v1 + "# pinned on 2026-01-15\n"),
    ("4 urllib3 upgraded",       lock_v1.replace("2.2.3", "2.3.0")),
]
store = []                                   # saved cache keys, oldest first
for label, lock in runs:
    key = cache_key("linux", lock)
    result = restore(store, key, "linux-pip-")
    print(f"{label:25} {key}  {result}")
    if result != "exact hit":
        store.append(key)                    # job ends: save under the new key
print("keys saved:", len(store))

1 first run               linux-pip-91146d24db58  miss
2 only app code changed   linux-pip-91146d24db58  exact hit
3 a comment added         linux-pip-67521875981f  partial hit (linux-pip-91146d24db58)
4 urllib3 upgraded        linux-pip-e6c8af766b30  partial hit (linux-pip-67521875981f)
keys saved: 3

৬ · Pipeline লেখা — GitHub Actions আর GitLab CI-এর YAML

প্রায় সব আধুনিক CI platform pipeline-এর বিবরণ একটি YAML file-এ রাখে, আর file-টি থাকে repository-র ভেতরেই — “pipeline as code”. সুবিধা বড়: pipeline-এর প্রতিটি বদল একটি commit, review হয় PR-এ, আর পুরোনো commit-এ ফিরলে তখনকার pipeline-ও ফেরে। YAML-এ গঠন বোঝায় indentation (space, tab নয়); key: value হলো map, - দিয়ে শুরু লাইন হলো list-এর উপাদান।

নিচে কাল্পনিক bazar-cart-এর একটি workflow, GitHub Actions-এর জন্য। এটি চালানোর উদাহরণ নয় — এখানে চলবে না — কিন্তু লেখার সময়ের documentation অনুযায়ী বৈধ গঠন। Action-এর version (@v7, @v8) অক্টোবর ২০২৬-এ ওই repository-গুলোর সর্বশেষ major tag দেখে লেখা; আপনি ব্যবহারের আগে নিজে মিলিয়ে নিন।

# .github/workflows/ci.yml  (bazar-cart, a fictional Node.js shop app)
name: ci
on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "0 20 * * *"          # 20:00 UTC = 02:00 in Dhaka
permissions:
  contents: read                  # least privilege for GITHUB_TOKEN
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}  # PRs only

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm              # key = hash of package-lock.json
      - run: npm ci
      - run: npm run lint
      - run: npm run build
      - uses: actions/upload-artifact@v7
        with:
          name: dist
          path: dist/

  test:
    needs: build                  # waits for build; skipped if it fails
    strategy:
      fail-fast: true
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node: [22, 24, 26]
        exclude:
          - os: macos-latest
            node: 22
    runs-on: ${{ matrix.os }}
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - uses: actions/download-artifact@v8
        with:
          name: dist
          path: dist/
      - run: npm test

একই pipeline GitLab CI/CD-তে। শব্দ আলাদা, ধারণা একই: stages ক্রম ঠিক করে, প্রতিটি job-এ stage আর script, পরিবেশ আসে container image থেকে, আর কখন চলবে তা ঠিক করে rules. এটিও চালানোর জন্য নয়, তবে লেখার সময়ের GitLab documentation অনুযায়ী বৈধ গঠন:

# .gitlab-ci.yml  (the same fictional pipeline on GitLab CI/CD)
stages: [build, test, nightly]

workflow:
  rules:                                   # when does a pipeline exist at all?
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "schedule"

default:
  image: node:24
  cache:
    key:
      files: [package-lock.json]           # new key only when the lockfile changes
    paths: [.npm/]

build:
  stage: build
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run lint
    - npm run build
  artifacts:
    paths: [dist/]
    expire_in: 1 week

test:
  stage: test
  image: node:$NODE
  parallel:
    matrix:
      - NODE: ["22", "24", "26"]
  script:
    - npm ci --cache .npm --prefer-offline
    - npm test                             # dist/ arrives from build's artifacts

e2e:
  stage: nightly
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"   # slow suite: only on the nightly run
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run test:e2e

৭ · CI-এর নিরাপত্তা — secret, OIDC, fork-এর PR আর SHA pinning

CI runner এমন একটি যন্ত্র, যেখানে অন্যের লেখা কোড (dependency, action, PR-এর কোড) চলে আর প্রায়ই deploy-এর key থাকে। আক্রমণকারীর কাছে এটি সোনার খনি। পর্ব ৫৭-এ (Git-এ নিরাপত্তা) repository-তে secret ফাঁস ঠেকানো দেখেছেন; এখানে CI-এর দিকটি।

Secret রাখার নিয়ম

• YAML-এ নয়, platform-এর secret store-এ: GitHub-এর repository বা environment secret, GitLab-এর CI/CD variable. Job চলার সময় environment variable হিসেবে আসে।
• Masked: masked variable-এর মান log-এ ছাপা হলে platform তা *** দিয়ে ঢেকে দেয়। কিন্তু এটি শুধু হুবহু মান খোঁজে — base64 করে, ভেঙে বা উল্টে ছাপালে ঢাকা না-ও পড়তে পারে। তাই নিয়ম: secret কখনো echo নয়, debug-এর জন্যও নয়।
• সীমিত পরিসর: GitLab-এর “protected” variable শুধু protected branch আর tag-এর pipeline পায়; GitHub-এর environment secret পাওয়া যায় নির্দিষ্ট environment-এর job-এ, চাইলে মানুষের অনুমোদনের পরে (platform-ভেদে আলাদা)। Deploy-এর key test job-এর হাতে থাকার দরকার নেই।
• ন্যূনতম অনুমতি: workflow-এর স্বয়ংক্রিয় token-এর অনুমতি শুরুতে contents: read; যে job-এর লেখার দরকার, শুধু সেখানে বাড়ানো।

দীর্ঘমেয়াদি key-এর বদলে OIDC

পুরোনো পথ: cloud-এ একটি স্থায়ী access key বানিয়ে CI-এর secret-এ রাখা। ফাঁস হলে, কেউ খেয়াল না করা পর্যন্ত — মাসের পর মাস — সেটি কাজ করে। আধুনিক পথ OIDC: প্রতিটি job platform থেকে একটি স্বল্পমেয়াদি, স্বাক্ষরিত পরিচয়পত্র (token) চায়, যাতে লেখা থাকে “এটি example/bazar-cart repository-র main branch-এর একটি job”. Cloud আগে থেকে ঠিক করা নিয়মে এটি যাচাই করে কয়েক মিনিট বা ঘণ্টার জন্য অনুমতি দেয়। GitHub Actions-এ লেখার সময়ে এর জন্য job-কে id-token: write অনুমতি দিতে হয়; বড় cloud provider-গুলো এটি সমর্থন করে (বিস্তারিত platform আর provider-ভেদে আলাদা)।

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production          # its own secrets and approval rules
    permissions:
      contents: read
      id-token: write                # may request a short-lived OIDC token
    steps:
      - run: echo "exchange the OIDC token for cloud credentials here"

Fork থেকে আসা PR

Open-source project-এ যে কেউ fork থেকে PR পাঠাতে পারেন, আর সেই PR-এর কোড আপনার CI-তে চলে। তাই GitHub Actions-এ লেখার সময়ের নিয়মে fork-এর PR-এর সাধারণ pull_request event-এ secret দেওয়া হয় না, আর স্বয়ংক্রিয় token শুধু পড়তে পারে; নতুন বাইরের অবদানকারীর run-এর আগে maintainer-এর অনুমোদনও লাগতে পারে। বিপদ pull_request_target-এ: এটি মূল repository-র প্রেক্ষাপটে secret-সহ চলে (লেবেল বসানোর মতো কাজের জন্য)। এমন workflow-এ PR-এর কোড checkout করে চালালে বাইরের কোড secret-এর নাগাল পায় — GitHub Security Lab একে “pwn request” বলেছে। অন্য platform-এর নিয়ম আলাদা; documentation দেখুন।

তৃতীয় পক্ষের action — tag নয়, commit SHA

uses: someone/tool@v3 লিখলে আপনি বলছেন “v3 tag এখন যে commit-এ, সেটি চালান”। কিন্তু Git-এ tag সরানো যায় (পর্ব ১৮)। কেউ সেই repository-র নিয়ন্ত্রণ পেলে v3-কে একটি ক্ষতিকর commit-এ সরিয়ে দিতে পারেন, আর পরের run থেকে হাজারো pipeline সেটি চালাবে — একটি supply-chain attack. ২০২৫ সালের মার্চে একটি জনপ্রিয় তৃতীয় পক্ষের action (tj-actions/changed-files)-এর ক্ষেত্রে প্রকাশিত বিবরণ অনুযায়ী ঠিক এমনটি ঘটে: tag-গুলো এমন commit-এ সরানো হয়, যা runner-এর secret log-এ ছাপিয়ে দিত। প্রতিরক্ষা SHA pinning: পুরো ৪০ অক্ষরের commit hash দিয়ে pin, পাশে comment-এ মানুষের পড়ার মতো version. Commit hash কনটেন্ট থেকে তৈরি (পর্ব ৫২, Git-এর ভেতরে), তাই নিঃশব্দে বদলানো যায় না।

      # mutable: whatever commit the tag points to today
      - uses: actions/checkout@v7
      # immutable: exactly this commit (v7.0.1, checked with git ls-remote, Oct 2026)
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1

SHA pin করলে হালনাগাদ নিজে থেকে আসে না — Dependabot বা Renovate-এর মতো tool নতুন version-এর PR খোলে, আর সেটি review হয়। Action-এর নিজের ভেতরের dependency অবশ্য SHA pin-এ ঢাকা পড়ে না। ২০২১ সালের Codecov ঘটনায় (প্রকাশিত বিবরণ অনুযায়ী) একটি জনপ্রিয় upload script বদলে বহু গ্রাহকের CI থেকে environment variable বাইরে পাঠানো হয়েছিল — শিক্ষা একই: CI-তে যা নামিয়ে চালান তা যাচাই করুন, আর secret রাখুন যতটা কম সম্ভব।

৮ · Main সবুজ রাখা — required check, merge queue আর আগে revert

লাল mainline-এর খরচ সবার: যিনি এইমাত্র main থেকে branch নিলেন, তিনি ভাঙা কোডে শুরু করলেন; যাঁর PR এখন test হচ্ছে, তিনি বুঝবেন না দোষ কার; আর লাল যত দীর্ঘ, তার ওপর তত পরিবর্তন জমে। তাই CI-এর প্রথম নিয়ম: broken build ঠিক করা দলের প্রথম অগ্রাধিকার। তিন স্তরের প্রতিরক্ষা:

1. Required status check: branch protection-এ নির্দিষ্ট check-কে বাধ্যতামূলক — সবুজ না হলে PR merge হয় না, আর main-এ সরাসরি push বন্ধ (পর্ব ১৬)। খেয়াল রাখুন check-এর নাম বাধ্যতামূলক করা হয়; YAML-এ job-এর নাম বদলালে পুরোনো নামের check চিরকাল “অপেক্ষমাণ” থাকতে পারে।
2. Merge queue: PR সবুজ, main সবুজ — তবু merge-এর পরে লাল হতে পারে: একজন function-এর নাম বদলালেন, অন্যজন পুরোনো নামে নতুন ডাক যোগ করলেন — Git-এর কোনো conflict নেই, অথচ একসাথে ভাঙা। Merge queue প্রতিটি PR-কে সারির আগেরগুলোর সাথে মিলিয়ে তখনকার main-এর ওপর আবার test করে, তারপর merge করে। পরিচয় পর্ব ১৬-এ; queue কীভাবে working tree ছাড়াই merge-এর ফল হিসাব করে (git merge-tree), তা পর্ব ৫৪-এ (Merge-এর ভেতরে)।
3. লাল হলে আগে revert: চাপের মধ্যে তাড়াহুড়োর fix প্রায়ই নতুন ভুল আনে। প্রচলিত নিয়ম: কয়েক মিনিটে (ধরুন দশ) নিশ্চিত fix না হলে ভাঙা commit-টি git revert করে main সবুজ করুন, তারপর branch-এ শান্ত মাথায় ঠিক করুন। Revert ইতিহাস মোছে না — একটি নতুন উল্টো commit (পর্ব ১১)।

লাল main-এর সাথে flaky test-এর লাল গুলিয়ে ফেলবেন না: একই commit-এ আবার চালালে সবুজ হলে সমস্যাটি test-এর, commit-এর নয় — revert করে লাভ নেই। Flaky test শনাক্ত, quarantine আর ঠিক করার পদ্ধতি পর্ব ৫১-এ। আর কোন commit ভেঙেছে তা পরিষ্কার না হলে git bisect run দিয়ে স্বয়ংক্রিয়ভাবে খোঁজা যায় — CI-তেও — পর্ব ৫৫-এ (Git দিয়ে bug খোঁজা)।

স্থানীয় hook বনাম CI — একটি আসল transcript

অনেক দল push-এর আগেই নিজের কম্পিউটারে check চালায় একটি pre-push hook দিয়ে — .git/hooks/pre-push script, যা ব্যর্থ হলে push থামে (hook-এর বিস্তারিত পর্ব ৫৬-এ, Git-এর শক্তিশালী হাতিয়ার)। মূল কৌশলটি খেয়াল করুন: hook আর CI দুজনেই একই script চালায় — ci/check.sh. নিচের transcript এই যন্ত্রে Git ২.৫৩-এ একটি খালি scratch repository-তে তৈরি, একটি local bare repository-কে remote ধরে; লেখক Rahim, তারিখ নির্দিষ্ট করা, তাই hash আপনার যন্ত্রেও একই আসবে:

$ cat ci/check.sh
#!/bin/sh
# The ONE script both the pre-push hook and the CI job run.
set -e
python -m py_compile price.py
python test_price.py
$ cat .git/hooks/pre-push
#!/bin/sh
echo "pre-push: running ci/check.sh"
sh ci/check.sh || { echo "pre-push: checks failed, push blocked"; exit 1; }

Rahim coupon-এর হিসাব “সরল” করতে গিয়ে coupon // 100-কে ভুল করে coupon // 10 লিখলেন, commit করে push করলেন:

$ git commit -q -am "perf: simplify coupon maths"
$ git push origin main
pre-push: running ci/check.sh
ok   total([100, 200], 0) = 300 (want 300)
FAIL total([100, 200], 10) = 0 (want 270)
ok   total([], 50) = 0 (want 0)
tests: 3 failed: 1
pre-push: checks failed, push blocked
error: failed to push some refs to '../origin.git'
$ git push --no-verify origin main
To ../origin.git
   3b7b2d9..7521f2d  main -> main
$ git log --oneline
7521f2d perf: simplify coupon maths
3b7b2d9 feat: add price total with coupon

সাত মিনিট পরে CI-তে main লাল। দল আগে revert করল:

$ git revert --no-edit HEAD
[main 3afa6a2] Revert "perf: simplify coupon maths"
 Date: Thu Jan 15 10:10:00 2026 +0600
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git push origin main
pre-push: running ci/check.sh
ok   total([100, 200], 0) = 300 (want 300)
ok   total([100, 200], 10) = 270 (want 270)
ok   total([], 50) = 0 (want 0)
tests: 3 failed: 0
To ../origin.git
   7521f2d..3afa6a2  main -> main
$ git log --oneline
3afa6a2 Revert "perf: simplify coupon maths"
7521f2d perf: simplify coupon maths
3b7b2d9 feat: add price total with coupon

স্থানীয়ভাবে CI পুনরুৎপাদন

• একই script আর version: make test বা ci/check.sh — YAML শুধু এদের ডাকে; lockfile আর .nvmrc-এর মতো version file CI-ও পড়ে।
• একই পরিবেশ: CI-এর job যে container image-এ চলে, স্থানীয়ভাবেও সেটি চালানো যায় (docker run … node:24 sh ci/check.sh); মূল ধারণা Operating Systems কোর্সের Container পর্বে। Runner-এ আগে থেকে বসানো tool-এর ওপর লুকানো নির্ভরতা রাখবেন না।

৯ · CI-এর স্বাস্থ্য মাপা — মেট্রিক আর CI theatre

“আমাদের CI কেমন চলছে?” — অনুভূতিতে নয়, চারটি সংখ্যায় উত্তর দেওয়া যায়:

• সময় (duration): গড় নয়, percentile — p50 (সাধারণ দিন) আর p90 (খারাপ দিন); মানুষ মনে রাখে খারাপ দিন।
• Failure rate: main-এর কত শতাংশ build লাল। খুব বেশি মানে অস্থির কোড বা flaky test; শূন্যের কাছে হলে প্রশ্ন — test কি কিছু ধরছে?
• Time to fix: লাল থেকে আবার সবুজ, প্রতিটি লাল ধারার জন্য একবার; এটি দলের অভ্যাস মাপে।
• Queue time: runner পাওয়ার অপেক্ষা; বাড়লে কোড না বদলেও feedback ধীর।

নিচের প্রোগ্রাম main-এর ৪০টি build-এর একটি কাল্পনিক ইতিহাস তৈরি করে — seed-যুক্ত PRNG (mulberry32, seed 58) দিয়ে, তাই ফল প্রতিবার একই — আর চারটি মাপ হিসাব করে। Percentile-এর পদ্ধতি nearest-rank: n-টি মান সাজিয়ে p-তম percentile হলো ⌈p/100 × n⌉-তম মান। ইতিহাসে একটি ধারণা বসানো: আগের build লাল হলে পরেরটির লাল হওয়ার সম্ভাবনা বেশি (৫০%), কারণ প্রথম fix প্রায়ই অসম্পূর্ণ:

// CI health metrics from a SIMULATED build history of main (mulberry32 = seeded PRNG).
function mulberry32(a) {
  return () => { a |= 0; a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rand = mulberry32(58);
const builds = []; let clock = 0;                       // minutes since Monday 09:00
for (let i = 0; i < 40; i++) {
  clock += 15 + Math.floor(rand() * 60);                // next push: 15..74 min later
  const queue = Math.floor(rand() * 4);                 // waits 0..3 min for a runner
  const dur = 6 + Math.floor(rand() * 7) + (rand() < 0.1 ? 15 : 0);  // 6..12 min, sometimes +15
  const red = builds.length && builds.at(-1).red ? rand() < 0.5 : rand() < 0.25;
  builds.push({ start: clock, queue, dur, red, end: clock + queue + dur });
}
const nearestRank = (xs, p) => { const s = [...xs].sort((a, b) => a - b);
  return s[Math.ceil(p / 100 * s.length) - 1]; };
// time to fix: from the end of the first red build to the end of the next green build
const fixes = [];
for (let i = 0; i < builds.length; i++) {
  if (!builds[i].red || (i && builds[i - 1].red)) continue;      // start of a red streak only
  const g = builds.findIndex((b, j) => j > i && !b.red);
  if (g > 0) fixes.push(builds[g].end - builds[i].end);
}
const reds = builds.filter(b => b.red).length;
const durs = builds.map(b => b.dur), queues = builds.map(b => b.queue);
console.log(`builds ${builds.length}, red ${reds} -> failure rate ${(100 * reds / builds.length).toFixed(1)}%`);
console.log(`red streaks ${fixes.length}, time to fix (min): ${fixes.join(", ")}`);
console.log(`mean time to fix ${(fixes.reduce((a, b) => a + b, 0) / fixes.length).toFixed(1)} min`);
console.log(`duration p50 ${nearestRank(durs, 50)} min, p90 ${nearestRank(durs, 90)} min, max ${Math.max(...durs)} min`);
console.log(`queue p50 ${nearestRank(queues, 50)} min, p90 ${nearestRank(queues, 90)} min`);

builds 40, red 7 -> failure rate 17.5%
red streaks 5, time to fix (min): 30, 42, 86, 55, 93
mean time to fix 61.2 min
duration p50 10 min, p90 24 min, max 25 min
queue p50 1 min, p90 3 min

DORA-এর delivery মেট্রিক এই মাপগুলোর বড় ভাই, পুরো delivery-র পথের জন্য — পর্ব ৫৯-এ। একটি সাবধানতা: মেট্রিককে লক্ষ্য বানালে মানুষ সংখ্যা ঠিক করে, ব্যবস্থা নয় (Goodhart-এর সূত্র) — যেমন failure rate কমাতে test মুছে ফেলা।

CI theatre — tool আছে, অনুশীলন নেই

CI theatre কথাটি শিল্পে চালু, আর ২০১৯ সালের একটি গবেষণাপত্র (“Continuous Integration Theater”, Felidré ও সহকর্মীরা, ESEM) বহু open-source project-এ এর লক্ষণ খুঁজেছে — অনিয়মিত commit, দীর্ঘ সময় ভাঙা build, খুব ধীর build. চেনা লক্ষণ:

১০ · AI-এর যুগে — AI-লেখা pipeline যাচাই

AI কয়েক সেকেন্ডে চমৎকার দেখতে CI YAML দেয়। কিন্তু YAML-এর ভুল চুপচাপ থাকে: বানানো input নীরবে উপেক্ষিত হয়, আর নিরাপত্তার ভুল কোনো test-এ ধরা পড়ে না।

AI-এর লেখা pipeline — চেকলিস্ট

• প্রতিটি action-এর নাম, version আর input তার repository-র action.yml-এ মিলিয়েছি
• permissions শুরুতে শুধু পড়ার; বাড়তি অনুমতির কারণ লেখা আছে
• তৃতীয় পক্ষের action পুরো commit SHA দিয়ে pin, পাশে version-এর comment
• কোথাও secret ছাপানো হয় না; fork-এর কোড secret-এর নাগাল পায় না
• ইচ্ছে করে একটি test ভেঙে দেখেছি — pipeline সত্যিই লাল হয়
• Cache key-এ lockfile-এর hash আছে; cache মুছে দিলেও ফল একই
• YAML-এর যুক্তি repository-র script-এ, যা আমি নিজের যন্ত্রে একই ভাবে চালাতে পারি
• নতুন workflow প্রথমে একটি আলাদা branch বা throwaway repository-তে চালিয়ে দেখেছি