CI/CD — lint, test, build, preview আর migration

১ · বাজারঘরের pipeline — প্রতিটি পরিবর্তনের একই পরীক্ষা

মডিউল ১১-এ বাজারঘরের জন্য চার স্তরের test লেখা হয়েছে: পর্ব ৭৩-এ Vitest-এর unit test, পর্ব ৭৪-এ component test, পর্ব ৭৫-এ test database-সহ integration test, আর পর্ব ৭৬-এ Playwright-এর E2E. কিন্তু test লেখা থাকলেই হয় না; কেউ সেগুলো চালাতে ভুলে গেলে, বা নিজের ল্যাপটপে পাস করে অন্যের কম্পিউটারে ফেল করলে, test-এর মূল্য অর্ধেক। এই পর্বের কাজ সেই ফাঁক বন্ধ করা: প্রতিটি পরিবর্তনে একটি পরিষ্কার মেশিন নিজে থেকে সব ধাপ চালাবে, আর ফল দেখাবে pull request-এর পাশে।

শব্দ দুটি আলাদা। Continuous integration (CI) মানে প্রত্যেকের পরিবর্তন ঘন ঘন মূল branch-এ মেলানো, আর প্রতিবার স্বয়ংক্রিয় build ও test. Continuous delivery বা deployment (CD) মানে সবুজ build যেকোনো সময় production-এ পাঠানোর মতো প্রস্তুত রাখা, আর পাঠানোর পথটিও স্বয়ংক্রিয় করা। Stage, job, DAG, runner, cache poisoning আর Amdahl-এর সীমার তত্ত্ব আছে Cloud ও DevOps কোর্সের pipeline নকশার পর্বে; rolling, blue-green আর canary আছে deployment strategy পর্বে; branch, pull request আর review-এর নিয়ম আছে Software Engineering-এর pull request পর্বে আর continuous integration পর্বে। এখানে তত্ত্ব আবার নয়; এখানে একটি নির্দিষ্ট অ্যাপের একটি নির্দিষ্ট pipeline, শুরু থেকে শেষ।

এই পর্বের প্রতিটি আউটপুট একটি সত্যিকারের ল্যাব থেকে, Windows 10-এর একটি কম্পিউটারে, কোনো CI সেবা ছাড়া। লেখার সময়ের version: Node 24.15.0, npm 11.12.1, create-next-app 16.4.4 দিয়ে বানানো Next.js 16.4.4 আর React 19.3.0, TypeScript 5.9.3, ESLint 9.39.5 (flat config), Prisma 7.10.1 (npm-এর latest একটি 8.0 release candidate, তাই stable 7.10.1 বেছে নেওয়া), Vitest 5.1.0, jsdom 30.1.3, Testing Library 16.3.3, Playwright 1.64.1, আর embedded-postgres 18.6.0-beta.19 প্যাকেজের PostgreSQL 18, যা চলেছে শুধু 127.0.0.1-এ, port 47823. Workflow ফাইল GitHub-এ চালানো হয়নি; সেটি যাচাই হয়েছে actionlint দিয়ে, আর তার প্রতিটি ধাপ একটি script একই ক্রমে নিজের কম্পিউটারে চালিয়েছে।

২ · Workflow ফাইল — trigger, permission, concurrency আর needs

GitHub Actions-এ pipeline লেখা হয় YAML ফাইলে, .github/workflows/ folder-এ। একটি ফাইল একটি workflow; তার ভেতরে কয়েকটি job, প্রতিটি job একটি আলাদা, নতুন runner-এ চলে, আর job-এর ভেতরে ধাপ বা step একটির পর একটি চলে। নিচে বাজারঘরের ci.yml-এর মাথা আর প্রথম job. পুরো ফাইলে পাঁচটি job: quality, integration, build, e2e (matrix-এ দুটি shard, তাই run-এ ছয়টি job দেখায়) আর e2e-report; deploy আলাদা ফাইলে (১০ নম্বর অংশে)।

name: ci

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read            # GITHUB_TOKEN শুধু পড়তে পারবে

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
  quality:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm audit --omit=dev --audit-level=high
      - run: npx prisma generate
      - run: npx eslint .
      - run: npx tsc --noEmit
      - run: npx vitest run

অংশগুলো একে একে। on: কখন চলবে। প্রতিটি pull request-এ, আর main-এ push হলে (merge-এর পরে)। permissions: প্রতিটি job একটি স্বয়ংক্রিয় GITHUB_TOKEN পায়; এখানে বলা হলো সেটি শুধু repository পড়তে পারবে। কম অধিকার দিয়ে শুরু, দরকার হলে নির্দিষ্ট job-এ বাড়ানো, এটি least privilege. concurrency: একই branch-এ নতুন push এলে পুরোনো run চালিয়ে লাভ নেই, তাই একই group-এর আগের run বাতিল হয়। লক্ষ করুন, শর্তটি শুধু pull request-এর জন্য সত্য; main-এর run বাতিল না করাই নিরাপদ, কারণ প্রতিটি merge-এর ফল আলাদা করে জানা দরকার। এই group-কে বলে concurrency group.

Action-গুলোর @-এর পরে একটি লম্বা hex সংখ্যা: এটি action-এর repository-র একটি নির্দিষ্ট commit, আর পাশের মন্তব্যে মানুষের পড়ার জন্য version. লেখার সময়ে GitHub-এর release পাতা থেকে নেওয়া: actions/checkout v7.0.1, actions/setup-node v7.1.0, actions/upload-artifact v7.0.2, actions/download-artifact v8.0.2 (আর actions/cache v6.1.0, যা এখানে আলাদা করে লাগেনি)। কেন tag-এর বদলে commit, তা ৯ নম্বর অংশে। Version বদলায়, তাই নিজের workflow লেখার দিন আবার release পাতা দেখুন।

Job-এর নির্ভরতা: needs

Job-গুলো সাধারণভাবে একসাথে শুরু হয়। কোনো job আগে অন্য job শেষ হওয়ার অপেক্ষা করবে, তা বলে needs: build-এ needs: [quality], e2e-তে needs: [build, integration]. এভাবে job-গুলো একটি DAG তৈরি করে (directed acyclic graph, অর্থাৎ দিকওয়ালা, চক্রহীন নির্ভরতার ছক)। GitHub-এর docs অনুযায়ী কোনো job ব্যর্থ বা skip হলে যে job তাকে needs করে, সেটিও skip হয়, যদি না তার if-এ always() বা !cancelled()-এর মতো শর্ত থাকে। আর job-এর ভেতরে ধাপগুলো fail-fast: একটি step ফেল করলে পরের step চলে না। নিচের ব্লক এই দুই নিয়মের একটি ছোট মডেল, একটি নকল ঘড়িতে। সংখ্যাগুলো ল্যাবের স্থানীয় সময়ের কাছাকাছি করে বানানো, আসল CI-এর মাপ নয়।

// Teaching model: jobs with "needs", a simulated clock, fail-fast steps.
const jobs = {
  quality:     { needs: [], steps: [['install', 20], ['lint', 2], ['typecheck', 2], ['unit', 2]] },
  integration: { needs: [], steps: [['install', 20], ['migrate', 1], ['int-tests', 1]] },
  build:       { needs: ['quality'], steps: [['install', 20], ['next build', 5]] },
  e2e_1:       { needs: ['build', 'integration'], steps: [['install', 20], ['shard 1/2', 4, 'FAIL'], ['upload', 1]] },
  e2e_2:       { needs: ['build', 'integration'], steps: [['install', 20], ['shard 2/2', 4]] },
  report:      { needs: ['e2e_1', 'e2e_2'], always: true, steps: [['merge-reports', 3]] },
  deploy:      { needs: ['e2e_1', 'e2e_2'], steps: [['migrate deploy', 2], ['release', 5]] },
};
const done = {};
let work = 0; // runner-seconds actually used
while (Object.keys(done).length < Object.keys(jobs).length) {
  for (const [name, job] of Object.entries(jobs)) {
    if (done[name] || job.needs.some((n) => !done[n])) continue; // wait for needs
    const start = Math.max(0, ...job.needs.map((n) => done[n].end));
    if (!job.always && job.needs.some((n) => done[n].status !== 'success')) {
      done[name] = { status: 'skipped', end: start };
      console.log(`${name.padEnd(12)} skipped (a needed job did not succeed)`);
      continue;
    }
    let t = start, status = 'success', ran = [];
    for (const [step, secs, result] of job.steps) {      // fail-fast inside a job
      t += secs; work += secs; ran.push(step);
      if (result === 'FAIL') { status = 'failure'; break; }
    }
    done[name] = { status, end: t };
    console.log(`${name.padEnd(12)} ${status.padEnd(8)} t=${start}s→${t}s  ran: ${ran.join(', ')}`);
  }
}
const wall = Math.max(...Object.values(done).map((d) => d.end));
console.log(`wall clock ${wall}s; runner time used ${work}s (the steps that really ran)`);

Workflow-ও কোড — actionlint দিয়ে যাচাই

YAML-এ বানান ভুল হলে GitHub push-এর পরেই তা জানায়, আর তখন একটি ভুলের জন্য একটি পুরো round trip. actionlint নামের open-source টুল workflow ফাইল নিজের কম্পিউটারেই পড়ে ভুল ধরে: অজানা key, ভুল needs, expression-এর type, পুরোনো action, আর কিছু নিরাপত্তার ঝুঁকি। ল্যাবে এর Windows binary নামানো হয়েছে GitHub release থেকে, আর release-এর checksum ফাইলের সাথে মিলিয়ে দেখা হয়েছে। সত্যিকারের run:

$ curl -sSLO …/v1.7.12/actionlint_1.7.12_windows_amd64.zip
$ curl -sSLO …/v1.7.12/actionlint_1.7.12_checksums.txt
$ sha256sum -c --ignore-missing actionlint_1.7.12_checksums.txt
actionlint_1.7.12_windows_amd64.zip: OK
$ actionlint -version
1.7.12
installed by downloading from release page
built with go1.26.1 compiler for windows/amd64

$ actionlint .github/workflows/ci.yml .github/workflows/deploy.yml
$ echo $?
0

কোনো আউটপুট নেই, exit code 0: দুটি ফাইলই পরিষ্কার। (Folder-টি git repository না হলে actionlint নিজে workflow folder খুঁজে পায় না, তাই ফাইলের নাম দিয়ে চালানো হয়েছে।) এবার ইচ্ছা করে চারটি ভুলসহ একটি ছোট ফাইল: পুরোনো checkout@v3, pull_request_target-এ PR-এর শিরোনাম সরাসরি shell-এ, needs-এ বানান ভুল, আর matrix-এর ভুল নাম।

$ actionlint bad.yml
bad.yml:9:15: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue [action]
bad.yml:10:33: "github.event.pull_request.title" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks for more details [expression]
bad.yml:12:3: job "e2e" needs job "biuld" which does not exist in this workflow [job-needs]
bad.yml:19:46: property "shrd" is not defined in object type {shard: number} [expression]
$ echo $?
1

চারটিই আসল ধরনের ভুল। দ্বিতীয়টি সবচেয়ে গুরুত্বপূর্ণ: PR-এর শিরোনাম যে কেউ লিখতে পারেন, আর ${{ … }} shell চলার আগে লেখার ভেতরে বসে যায়। শিরোনামে "; কোনো কমান্ড; " থাকলে সেটি runner-এ চলবে। একে বলে script injection; প্রতিকার actionlint নিজেই বলছে: মানটি env: দিয়ে environment variable-এ দিন, তারপর shell-এ "$TITLE" লিখুন। বাজারঘরের deploy.yml-এ একই কারণে inputs.build_sha সরাসরি না বসিয়ে env দিয়ে পাঠানো হয়েছে। একটি ভালো অভ্যাস: workflow ফাইল বদলানো প্রতিটি PR-এ actionlint চালানো, CI-তেই বা commit-এর আগে।

৩ · Install আর cache — npm ci, lockfile আর cache key

প্রতিটি job একটি খালি মেশিনে শুরু হয়, তাই প্রথম কাজ dependency বসানো। CI-তে npm install নয়, npm ci. পার্থক্য পর্ব ০৫-এ এসেছিল; সংক্ষেপে: npm ci node_modules পুরো মুছে lockfile-এ (package-lock.json) লেখা ঠিক version-গুলোই বসায়, package.json-এর সাথে lockfile না মিললে থেমে যায়, আর lockfile কখনো বদলায় না। ফলে আজকের CI আর গতকালের CI একই dependency পায়, আর কেউ চুপচাপ নতুন version ঢোকাতে পারে না।

Install-এর একটি আসল অভিজ্ঞতা দিয়ে শুরু। create-next-app-এর বানানো project-এ Vitest 5.1 যোগ করতে গিয়ে npm থামল:

$ npm i -D vitest@5.1.0 …
npm error code ERESOLVE
npm error While resolving: vitest@5.1.0
npm error Found: @types/node@20.19.43
…
npm error Could not resolve dependency:
npm error peerOptional @types/node@"^22.0.0 || >=24.0.0" from vitest@5.1.0

Template-এ ছিল "@types/node": "^20", অথচ Vitest 5.1 চায় 22 বা 24 থেকে। সমাধান --force নয়, বরং চলমান Node-এর সাথে মেলানো @types/node@^24. ঠিক এই কারণেই lockfile commit করা হয়: dependency মেলানোর এই সিদ্ধান্ত একবার নিজের কম্পিউটারে নেওয়া হয়, তারপর CI শুধু অনুসরণ করে।

Cache — কী রাখা হয়, কোন চাবিতে

actions/setup-node-এ cache: npm দিলে action-টি npm-এর global cache folder (Linux-এ সাধারণত ~/.npm) রেখে দেয়, node_modules নয়; docs-এও তা স্পষ্ট লেখা। Cache-এর key তৈরি হয় lockfile-এর hash থেকে, তাই lockfile না বদলালে পরের run একই cache ফিরে পায়। Docs আরও বলে, v6 থেকে package.json-এ packageManager (বা devEngines.packageManager) npm হলে cache নিজে থেকেই চালু হয়; না চাইলে package-manager-cache: false. বাজারঘরে cache: npm স্পষ্ট লেখা, যাতে পাঠক বুঝতে পারেন কী হচ্ছে।

Cache-এর মূল্য কত, তা মাপা হয়েছে। একটি খালি cache folder দিয়ে npm ci (cache miss-এর মতো), তারপর একই folder দিয়ে আবার দুবার। সত্যিকারের run, একটি স্থানীয় run, সাধারণ ফল নয়:

$ node measure-install.mjs
cache miss (empty)     100.4 s   added 565 packages in 2m
cache hit (same dir)    17.3 s   added 565 packages in 17s
cache hit again         17.0 s   added 565 packages in 17s

৫৬৫টি package, cache ছাড়া ১০০.৪ সেকেন্ড, cache থেকে ১৭ সেকেন্ডের মতো: প্রায় ছয় গুণ পার্থক্য। Cache থাকলেও ১৭ সেকেন্ড লাগে, কারণ npm ci তবুও node_modules নতুন করে লেখে; ল্যাবে সেই folder ৮৫০ MB. নিচের ব্লকে lockfile-এর hash থেকে key বানানোর একটি মডেল। আসল setup-node-এর key-তে কী কী থাকে, তা action-এর version অনুযায়ী আলাদা হতে পারে; ধারণাটি একই।

// Teaching model: a dependency cache keyed by the hash of package-lock.json.
const { createHash } = require('node:crypto');
const hash = (text) => createHash('sha256').update(text).digest('hex').slice(0, 12);
const keyFor = (os, lock) => `node-cache-${os}-npm-${hash(lock)}`;

const lockV1 = JSON.stringify({ packages: { next: '16.4.4', prisma: '7.10.1' } });
const lockV2 = JSON.stringify({ packages: { next: '16.4.4', prisma: '7.10.1', zod: '4.6.7' } });
const store = new Map(); // what the cache service already holds

function restore(os, lock) {
  const key = keyFor(os, lock);
  const hit = store.has(key);
  if (!hit) store.set(key, 'npm cache saved after a successful job');
  return `${hit ? 'HIT ' : 'MISS'} ${key}`;
}
console.log('run 1, linux, lock v1     ', restore('Linux', lockV1));
console.log('run 2, linux, lock v1     ', restore('Linux', lockV1));
console.log('run 3, only a .tsx changed', restore('Linux', lockV1));
console.log('run 4, zod added, lock v2 ', restore('Linux', lockV2));
console.log('run 5, windows, lock v2   ', restore('Windows', lockV2));
console.log('run 6, linux, lock v2     ', restore('Linux', lockV2));
console.log('one extra space in the lockfile, same key?', hash(lockV1) === hash(lockV1 + ' '));
console.log('entries in the cache store:', store.size);

৪ · দ্রুত check — lint, type check, unit আর component test

quality job-এ চারটি সস্তা পরীক্ষা, প্রতিটি কয়েক সেকেন্ডের। Lint: Next.js 16-এ next lint কমান্ড আর নেই, আর next build নিজে lint চালায় না; সরকারি upgrade guide-এ এটি স্পষ্ট লেখা। তাই ESLint সরাসরি চলে, create-next-app-এর বানানো flat config eslint.config.mjs দিয়ে, যা eslint-config-next-এর core-web-vitals আর typescript নিয়ম জোড়া দেয়। ল্যাবে এর globalIgnores-এ generated/** (Prisma-র বানানো client) আর Playwright-এর report folder যোগ করা হয়েছে, নইলে ESLint বানানো কোডেও অভিযোগ করে। Type check: tsc --noEmit, অর্থাৎ শুধু type যাচাই, কোনো JavaScript লেখা নয়। এর আগে prisma generate লাগে, কারণ Prisma 7-এর বানানো client ফাইল সাধারণত repository-তে রাখা হয় না (.gitignore-এ থাকে), তাই প্রতিবার schema থেকে বানাতে হয়। Unit ও component test: vitest run, jsdom-এ।

এই চারটির জন্য পুরো CI-তে অপেক্ষা না করে নিজের কম্পিউটারে push-এর আগেই চালানো যায়। ল্যাবের একটি git repository-তে (শুধু scratch folder-এ, আলাদা git config দিয়ে) একটি git hook বসানো হয়েছে: .githooks/pre-push, যা node scripts/ci-local.mjs lint typecheck unit+component চালায়। তারপর একটি commit-এ ইচ্ছা করে formatTaka('13490') লেখা হলো, যদিও function সংখ্যা চায়। সত্যিকারের run:

$ git push -u origin main
▶ lint: npx eslint .

▶ typecheck: npx tsc --noEmit
lib/price.ts(13,34): error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.
✖ typecheck failed after 2.1s — stopping (fail-fast)

step             seconds  result
lint                 2.6  ok
typecheck            2.1  FAILED
total                4.7
error: failed to push some refs to '../remote.git'

৪.৭ সেকেন্ডে ভুল ধরা, push হয়নি। সংশোধনের পরে একই hook: lint ২.০, typecheck ১.৭, unit ও component ১.৮, মোট ৫.৫ সেকেন্ড, তারপর * [new branch] main -> main. কিন্তু hook একটি সুবিধা, পাহারা নয়: git push --no-verify দিয়ে যে কেউ এটি এড়াতে পারেন, আর নতুন সদস্যের কম্পিউটারে hook বসানোই না থাকতে পারে। সিদ্ধান্তের কর্তৃত্ব থাকে CI-র হাতে।

প্রথম লাল run — একটি সত্যিকারের ব্যর্থতা

পুরো pipeline প্রথমবার চালাতেই একটি component test ফেল করল, আর fail-fast পরের সব ধাপ থামিয়ে দিল। Test-টি একটি <p role="status">স্টক শেষ</p> খুঁজছিল getByRole('status') দিয়ে। সত্যিকারের run, অংশ:

 FAIL  components/AddToCart.test.tsx > স্টকের বেশি যোগ করা যায় না
TestingLibraryElementError: Found multiple elements with the role "status"

Here are the matching elements:
<output
  aria-label="মসুর ডাল পরিমাণ"
>
  2
</output>
<p
  role="status"
>
  স্টক শেষ
</p>
…
✖ unit+component failed after 1.9s — stopping (fail-fast)

কারণটি শিক্ষণীয়। HTML-এর <output> element-এর নিজস্ব implicit ARIA role হলো status, অর্থাৎ role না লিখলেও স্ক্রিন রিডার আর Testing Library একে status হিসেবেই দেখে। তাই একই নামের দুটি element. সমাধান test-এ: getByText('স্টক শেষ'), আর E2E-তেও একই বদল, নইলে Playwright-এর strict mode একই কারণে থামত (পর্ব ৭৬)।

৫ · Database-সহ test আর build — service container, migrate deploy আর artifact

Integration test-এর জন্য আসল PostgreSQL লাগে, mock নয় (পর্ব ৭৫)। GitHub Actions-এ সবচেয়ে সহজ উপায় service container: job শুরুর আগে runner একটি container-এ database চালু করে, health check সফল হওয়া পর্যন্ত অপেক্ষা করে, আর job শেষে মুছে দেয়। প্রতিটি run তাই একটি সম্পূর্ণ খালি database পায়। নিচের YAML চলে GitHub-এর Linux runner-এ, যেখানে Docker আছে; এখানে, এই ল্যাবে, এটি চালানো হয়নি।

  integration:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    services:
      postgres:
        image: postgres:18
        env:
          POSTGRES_PASSWORD: example-secret     # শুধু এই ক্ষণস্থায়ী container-এর
          POSTGRES_DB: bazarghar_ci
        ports: ['5432:5432']
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 5s --health-timeout 5s --health-retries 10
    env:
      DATABASE_URL: postgresql://postgres:example-secret@localhost:5432/bazarghar_ci
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0
        with: { node-version: 24, cache: npm }
      - run: npm ci
      - run: npx prisma generate
      - run: npx prisma migrate deploy
      - run: npx vitest run -c vitest.integration.config.mts

এখানে password secret নয়: container-টি job-এর সাথে জন্মায় আর মরে, বাইরে থেকে পৌঁছানো যায় না। তবু স্পষ্ট নকল মান রাখা ভালো অভ্যাস। লক্ষ করুন, test-এর আগে prisma migrate deploy: খালি database-এ ঠিক সেই migration ফাইলগুলো চলে, যা production-এ চলবে। ফলে migration-এর ভুল (SQL-এর ভুল, ক্রমের ভুল) এখানেই ধরা পড়ে।

ল্যাবে Docker চালানো হয়নি। Container-এর জায়গায় embedded-postgres একটি আলাদা folder থেকে 127.0.0.1:47823-এ চলেছে, আর pipeline script প্রতিবার DROP DATABASE … WITH (FORCE) আর CREATE DATABASE দিয়ে খালি database বানিয়েছে, যেন নতুন container. কাজের আগে নিশ্চিত হওয়া গেছে যে সংযোগ নিজের server-এই: database bazarghar_ci81, port 47823, আর data_directory ল্যাবের নিজের folder. সত্যিকারের run:

▶ fresh-db

▶ migrate: npx prisma migrate deploy
Loaded Prisma config from prisma.config.ts.
Prisma schema loaded from prisma\schema.prisma.
Datasource "db": PostgreSQL database "bazarghar_ci81_run", schema "public" at "127.0.0.1:47823"

1 migration found in prisma/migrations

Applying migration `20261103112012_init`

The following migration(s) have been applied:

migrations/
  └─ 20261103112012_init/
    └─ migration.sql

All migrations have been successfully applied.

▶ integration: npx vitest run -c vitest.integration.config.mts
 Test Files  1 passed (1)
      Tests  2 passed (2)
   Duration  360ms (tests 52%, import 24%, transform 22%, worker 2%)

দুটি integration test: স্টক শূন্য পণ্য তালিকায় আসে না, আর একই sku দুবার দিলে database নিজেই Unique constraint দিয়ে আটকায়। দ্বিতীয় নিয়মটি database-এর index-এ, তাই mock তা প্রমাণ করতে পারত না।

Build — যা lint আর tsc ধরেনি

একটি অদ্ভুত সত্য: lint সবুজ, type check সবুজ, সব test সবুজ, তবু দ্বিতীয় run-এ next build ফেল করল। সত্যিকারের run:

▶ build: npx next build
▲ Next.js 16.4.4 (Turbopack)
- Cache Components enabled
- Partial Prefetching enabled

  Creating an optimized production build ...

> Build error occurred
Error: Turbopack build failed with 1 error:
./app/page.tsx:6:14
Error: Route segment config "dynamic" is not compatible with `nextConfig.cacheComponents`. Please remove it.
> 6 | export const dynamic = 'force-dynamic';
✖ build failed after 2.5s — stopping (fail-fast)

create-next-app 16.4.4-এর বানানো next.config.ts-এ cacheComponents: true চালু ছিল, আর পুরোনো অভ্যাসের export const dynamic = 'force-dynamic' তার সাথে চলে না। TypeScript-এর চোখে লাইনটি বৈধ, তাই tsc চুপ ছিল; নিয়মটি framework-এর build জানে। সমাধান: পণ্যের তালিকা একটি আলাদা async component-এ, await connection() দিয়ে চিহ্নিত যে এটি প্রতি request-এ চলবে, আর বাইরে <Suspense>. Rendering-এর এই মডেল পর্ব ৫৫-এ। সংশোধনের পরে build সফল, আর route-এর তালিকায় ◐ /: “prerendered as static HTML with dynamic server-streamed content”. শিক্ষা: CI-তে build একটি আলাদা, আবশ্যিক ধাপ; lint আর tsc সবুজ মানে build সবুজ নয়।

Build-এর ফল, অর্থাৎ .next/ folder, একটি artifact হিসেবে রাখা হয়, যাতে E2E job একই build পরীক্ষা করে, আবার বানায় না। একবার build, তারপর সেটিই পরীক্ষা ও deploy, এই নীতির তত্ত্ব আছে Cloud ও DevOps-এর artifact আর promotion পর্বে; build-এর ভেতরের কাজ পর্ব ৭৯-এ। একটি সতর্কতা: NEXT_PUBLIC_ দিয়ে শুরু variable build-এর সময় JavaScript-এ বসে যায়, তাই একই artifact ভিন্ন environment-এ নিলে সেগুলো বদলায় না (পর্ব ৭৮)।

      - run: npx next build
      - uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
        with:
          name: next-build-${{ github.sha }}
          path: .next/
          include-hidden-files: true   # নাম বিন্দু দিয়ে শুরু, নিরাপদ দিকে থাকা
          retention-days: 7

৬ · E2E — Playwright shard, blob report আর একটি HTML report

E2E সবচেয়ে ধীর স্তর। পর্ব ৭৬-এ দেখা sharding এখানে কাজে লাগে: একটি matrix দুটি job বানায়, প্রতিটি --shard=1/2 বা --shard=2/2 নিয়ে অর্ধেক test চালায়, আলাদা runner-এ, একসাথে। প্রতিটি shard তার ফল লেখে একটি blob report-এ, যা মানুষের পড়ার জন্য নয়, জোড়া দেওয়ার জন্য। শেষে একটি আলাদা job সব blob নামিয়ে merge-reports দিয়ে একটি HTML report বানায়। Playwright-এর config-এ CI-তে reporter: [['blob'], ['github']], আর নিজের কম্পিউটারে list.

  e2e:
    needs: [build, integration]
    strategy:
      fail-fast: false        # এক shard ফেল করলেও অন্যটি শেষ হোক
      matrix:
        shard: [1, 2]
    # … postgres service, npm ci, prisma generate …
    steps:
      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with: { name: 'next-build-${{ github.sha }}', path: .next/ }
      - run: npx prisma migrate deploy
      - run: node scripts/seed-e2e.mjs
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --shard=${{ matrix.shard }}/2
      - if: ${{ !cancelled() }}
        uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
        with: { name: 'blob-report-${{ matrix.shard }}', path: blob-report/, retention-days: 7 }

  e2e-report:
    needs: [e2e]
    if: ${{ !cancelled() }}
    # … download-artifact with pattern: blob-report-* and merge-multiple: true
    #     npx playwright merge-reports --reporter html ./all-blob-reports
    #     upload-artifact: playwright-report

এখানে fail-fast: false ইচ্ছাকৃত। Matrix-এর default-এ একটি job ফেল করলে বাকিগুলো বাতিল হয়; E2E-তে তা চাই না, কারণ অন্য shard-এর ফলও জানা দরকার, নইলে প্রতিবার একটি করে ব্যর্থতা দেখে সারাতে হবে। Upload-এর if: ${{ !cancelled() }} নিশ্চিত করে test ফেল করলেও report ওঠে; ব্যর্থতার সময়েই report সবচেয়ে দরকারি। CI-র runner-এ Playwright-এর নিজের Chromium বসানো হয়, আর ল্যাবে config CI না থাকলে কম্পিউটারের Microsoft Edge (channel: 'msedge') ব্যবহার করে।

ল্যাবে দুই shard পরপর চালানো হয়েছে, প্রতিটি নিজের blob folder-এ, তারপর জোড়া দেওয়া। E2E-র আগে একটি seed script তিনটি পণ্য বসায়: দুটি স্টকে, একটি স্টক শূন্য। সত্যিকারের run:

▶ seed-e2e: node scripts/seed-e2e.mjs
seeded 3 products

▶ e2e 1/2: npx playwright test --shard=1/2 --reporter=list,blob
Running 2 tests using 2 workers, shard 1 of 2
  ok 1 [chromium] › e2e\cart.spec.ts:9:5 › স্টক ফুরালে বোতাম বন্ধ (704ms)
  ok 2 [chromium] › e2e\cart.spec.ts:3:5 › ডাল কার্টে যোগ হয় (796ms)
  2 passed (2.6s)

▶ e2e 2/2: npx playwright test --shard=2/2 --reporter=list,blob
Running 2 tests using 2 workers, shard 2 of 2
  ok 1 [chromium] › e2e\home.spec.ts:9:5 › health route 200 দেয় (22ms)
  ok 2 [chromium] › e2e\home.spec.ts:3:5 › হোমপেজে শুধু স্টকে থাকা পণ্য (674ms)
  2 passed (2.4s)

$ npx playwright merge-reports --reporter list ./all-blob
Running 4 tests using 4 workers
  ok 1 [chromium] › e2e\cart.spec.ts:9:5 › স্টক ফুরালে বোতাম বন্ধ (508ms)
  ok 2 [chromium] › e2e\cart.spec.ts:3:5 › ডাল কার্টে যোগ হয় (808ms)
  ok 4 [chromium] › e2e\home.spec.ts:9:5 › health route 200 দেয় (21ms)
  ok 3 [chromium] › e2e\home.spec.ts:3:5 › হোমপেজে শুধু স্টকে থাকা পণ্য (701ms)
  4 passed (6.0s)

দুই shard-এর অংশ একটি run থেকে, আর merge-reports চালানো হয়েছে পরের run-এর blob-এর ওপর, তাই millisecond-এর সংখ্যা সামান্য আলাদা। merge-reports দুই shard-এর চারটি test এক report-এ এনেছে, যেন একটি run. প্রতিটি shard-এর মাথায় Playwright নিজে next start চালু করেছে (webServer), /api/health-এ 200 পাওয়ার পরে test শুরু, শেষে বন্ধ। এখানে প্রতিটি shard ৩.৪–৩.৫ সেকেন্ড, তার বেশির ভাগ server চালু হওয়া; এত ছোট suite-এ shard লাভজনক নয়।

৭ · Pull request — required check, branch protection আর preview

Pipeline তখনই পাহারা দেয়, যখন তার ফল merge আটকাতে পারে। GitHub-এ এটি করে branch protection-এর নিয়ম বা নতুন ধাঁচের ruleset: main-এ সরাসরি push বন্ধ, merge শুধু pull request দিয়ে, অন্তত একজনের review, আর নির্দিষ্ট কিছু required check সবুজ হতে হবে। বাজারঘরে required check: quality, integration, build, দুটি e2e job (matrix-এর job-এর নাম সাধারণত shard-এর মানসহ দেখায়)। Review আর merge-এর নিয়মের তত্ত্ব pull request পর্বে, branching-এর কৌশল branching strategy পর্বে।

Preview deployment আর preview database

Review-এ কোড পড়া এক জিনিস, পরিবর্তনটি চোখে দেখা আরেক। অনেক hosting platform-এর docs অনুযায়ী তারা repository-র সাথে যুক্ত হলে প্রতিটি pull request-এর জন্য একটি আলাদা URL-এ অ্যাপের একটি কপি চালায়, যাকে বলে preview deployment; PR বন্ধ হলে সেটি মুছে যায়। এখানে কোনো platform সুপারিশ করা হচ্ছে না, আর কোথাও সত্যিকারের deploy করা হয়নি। কোথায় অ্যাপ চালাবেন, তার তুলনা পর্ব ৮২-এ।

Full-stack অ্যাপের preview-এর কঠিন অংশ database. তিনটি সাধারণ পথ, প্রতিটির দাম আছে:

Branching ব্যবহার করলে প্রশ্নটি নিরাপত্তার: ক্রেতার নাম, ফোন নম্বর, ঠিকানা preview-র URL-এ, যা হয়তো দলের বাইরের কেউও দেখতে পান। নিরাপদ ভিত্তি হলো production-এর বদলে একটি masked বা নকল ডেটার “parent” থেকে branch. আর fork থেকে আসা PR-এর preview-তে কোনো database-এর চাবি যাবে না; কেন, তা ৯ নম্বর অংশে। এবার একটি PR-এর পুরো পথ ধাপে ধাপে।

feat/stock: "স্টক শেষ" দেখানো
commit a1b2c3d → push
PR #42  feat/stock → main
event: pull_request (synchronize)

group: ci-ci-refs/pull/42/merge
আগের commit 9f8e7d6-এর run চলছিল
→ cancelled (cancel-in-progress: true)
নতুন run শুরু: a1b2c3d

quality      ─┐
integration  ─┼→ build → e2e (1), e2e (2)
              └────────→
e2e-report   (!cancelled)

✓ quality   ✓ integration   ✓ build
✗ e2e (1)   ✓ e2e (2)   ✓ e2e-report
Merging is blocked:
required status check failed

report artifact থেকে কারণ: locator-এ দুটি status
fix → commit c4d5e6f → push
সব required check: ✓
review: 1 approval

URL: pr-42.preview.bazarghar.example
DB:  খালি DB + migrate deploy + seed
secret: শুধু preview-র নকল চাবি
reviewer হাতে চেপে “স্টক শেষ” দেখলেন

squash merge → main@7a8b9c0
event: push (main) → ci আবার চলে
preview আর তার DB মুছে ফেলা
deploy: আলাদা workflow, অনুমোদনসহ

৮ · Migration pipeline-এ — একবার, traffic-এর আগে, কখনো migrate dev নয়

পর্ব ৪০-এ Prisma-র কমান্ডগুলোর কাজ ভাগ করা হয়েছিল: migrate dev নিজের কম্পিউটারে নতুন migration বানায় আর চালায়; migrate deploy শুধু আগে থেকে commit করা migration ফাইলগুলো ক্রমে চালায়, নতুন কিছু বানায় না, কিছু মোছে না। Pipeline-এর নিয়ম তিনটি। (১) Production-এ শুধু prisma migrate deploy. (২) এটি চলে একবার, একটি আলাদা job-এ, নতুন version traffic পাওয়ার আগে; প্রতিটি app instance-এর startup-এ নয়, কারণ দশটি instance একসাথে চালু হলে দশজনই migration চালাতে চাইবে। (৩) Migration এমন হবে যাতে পুরোনো আর নতুন দুই version একসাথে চলতে পারে, অর্থাৎ expand and contract.

migrate dev pipeline-এ চালালে কী হয় — দুটি সত্যিকারের run

ল্যাবের একটি আলাদা database-এ (শুধু পরীক্ষার জন্য) ইচ্ছা করে এমন অবস্থা বানানো হলো, যেখানে database-এ title নামের একটি কলাম আছে কিন্তু schema.prisma-তে নেই, যেমনটি ঘটে যখন migration চলেছে কিন্তু schema ফাইল পুরোনো। প্রথমবার টেবিল খালি ছিল। npx prisma migrate dev --name x কোনো প্রশ্ন না করেই একটি নতুন migration বানাল আর চালিয়ে দিল। তার ভেতরের SQL, সত্যিকারের ফাইল থেকে:

/*
  Warnings:

  - You are about to drop the column `title` on the `Product` table. All the data in the column will be lost.

*/
-- AlterTable
ALTER TABLE "Product" DROP COLUMN "title";

দ্বিতীয়বার টেবিলে একটি সারি ছিল। এবার migrate dev থামল, সত্যিকারের run:

$ npx prisma migrate dev --name sync
⚠️  Warnings for the current datasource:
  • You are about to drop the column `title` on the `Product` table, which still contains 1 non-null values.
Error: Prisma Migrate has detected that the environment is non-interactive, which is not supported.
`prisma migrate dev` is an interactive command designed to create new migrations and evolve the database in development.
To apply existing migrations in deployments, use prisma migrate deploy.
$ echo $?
1

দুটি ফলই বিপদের ইঙ্গিত। প্রথমটিতে টেবিল খালি থাকায় কোনো প্রশ্নই আসেনি, আর CI নিজে একটি DROP COLUMN লিখে চালিয়ে দিয়েছে, যা কেউ review করেনি। দ্বিতীয়টিতে Prisma নিজেই বলছে: deploy-এ migrate deploy. Pipeline-এ migration-এর একমাত্র উৎস হলো PR-এ review হওয়া migration.sql ফাইল।

Expand and contract — পুরোনো version ভাঙার সত্যিকারের প্রমাণ

বাজারঘরে Product.name কলামের নাম বদলে title করতে হবে। একবারে RENAME COLUMN করলে, deploy-এর কয়েক মিনিট যখন পুরোনো আর নতুন instance একসাথে চলে (rolling deployment), পুরোনোগুলো সাথে সাথে ভাঙবে। তাই তিন ধাপ: expand (নতুন কলাম যোগ আর backfill), কোড বদল, তারপর অনেক পরে contract (পুরোনো কলাম মোছা)। তত্ত্ব আর lock-এর সতর্কতা পর্ব ৪০-এ আর deployment strategy পর্বের database অংশে। এখানে দেখা যাক pipeline-এর ক্রম ভুল হলে কী হয়। ল্যাবের script একটি খালি database-এ ধাপগুলো চালিয়েছে, আর প্রতি ধাপের পরে “পুরোনো version”, অর্থাৎ যে Prisma Client শুধু name চেনে, পণ্য পড়েছে। সত্যিকারের run:

### 1. production today: only init
Applying migration `20261103112012_init`
All migrations have been successfully applied.
old version OK: মসুর ডাল
### 2. new release, step A: migrate status, then EXPAND
2 migrations found in prisma/migrations
Following migration have not yet been applied:
20261103120000_expand_add_title
To apply migrations in development run prisma migrate dev.
To apply migrations in production run prisma migrate deploy.
Applying migration `20261103120000_expand_add_title`
All migrations have been successfully applied.
old version OK: মসুর ডাল
### 3. too early: CONTRACT while the old version still runs
Applying migration `20261110120000_contract_drop_name`
All migrations have been successfully applied.
old version FAILED: P2022 - The column `Product.name` does not exist in the current database.
### 4. running deploy again changes nothing
3 migrations found in prisma/migrations
No pending migrations to apply.

Expand-এর পরে পুরোনো version দিব্যি চলেছে: নতুন কলাম সে চেনে না, কিন্তু তাতে তার কিছু আসে যায় না। Contract আগেভাগে চালাতেই একই পুরোনো version P2022 দিয়ে ভাঙল, আর migration নিজে “successfully applied” বলেছে; অর্থাৎ migration সফল হওয়া মানে অ্যাপ নিরাপদ নয়। শেষ অংশে No pending migrations to apply: migrate deploy আবার চালালে কিছু বদলায় না, তাই retry নিরাপদ। আরেকটি মাপা তথ্য: pending migration থাকা অবস্থায় prisma migrate status-এর exit code ছিল ১, আর সব চলার পরে ০, তাই এটি একটি gate-এ ব্যবহার করা যায়।

1# Release R12job migrate: migrate deploy  (expand: ADD title, backfill)3job release: v2  (title পড়ে, name ও title লেখে)4# Release R25job release: v3  (শুধু title; migration নেই)6# Release R37job migrate: migrate deploy  (contract: DROP name)8job release: v4

Deploy gate — সব শর্ত একসাথে

Deploy-এর আগে pipeline যে প্রশ্নগুলো করে, তা একটি ছোট function-এ লেখা যায়: সব required check সবুজ কি না, deploy-এর build সেই commit কি না যা test হয়েছে, pending migration-এর ধরন কী আর migrate job সফল হয়েছে কি না, আর production-এর অনুমোদন আছে কি না। নিচে তার একটি শিক্ষণ মডেল; আসল pipeline-এ এই নিয়মগুলো ছড়িয়ে থাকে needs, environment-এর নিয়ম আর release-এর পরিকল্পনায়।

// Teaching model: may this build go to production now?
function gate(r) {
  const why = [];
  if (r.checks.some((c) => c.result !== 'success')) why.push('a required check is not green');
  if (r.buildSha !== r.testedSha) why.push('the build is not the commit that was tested');
  if (r.pendingMigrations.some((m) => m.kind === 'contract' && r.oldVersionLive))
    why.push('a contract migration while the old version still serves traffic');
  if (r.pendingMigrations.length && !r.migrateJobPassed) why.push('migrate deploy has not succeeded yet');
  if (r.env === 'production' && !r.approvedBy) why.push('production needs a reviewer approval');
  return why.length ? `BLOCK: ${why.join('; ')}` : 'DEPLOY';
}
const green = [{ name: 'quality', result: 'success' }, { name: 'e2e', result: 'success' }];
const base = { env: 'production', checks: green, buildSha: 'a1b2c3d', testedSha: 'a1b2c3d',
  pendingMigrations: [], migrateJobPassed: true, oldVersionLive: true, approvedBy: 'rina' };

const cases = {
  'all good': base,
  'e2e failed': { ...base, checks: [green[0], { name: 'e2e', result: 'failure' }] },
  'expand pending, migrate ran': { ...base, pendingMigrations: [{ kind: 'expand' }] },
  'expand pending, migrate failed': { ...base, pendingMigrations: [{ kind: 'expand' }], migrateJobPassed: false },
  'contract too early': { ...base, pendingMigrations: [{ kind: 'contract' }] },
  'contract after old is gone': { ...base, pendingMigrations: [{ kind: 'contract' }], oldVersionLive: false },
  'rebuilt from main, no approval': { ...base, buildSha: 'f9e8d7c', approvedBy: null },
};
for (const [name, r] of Object.entries(cases)) console.log(name.padEnd(31), gate(r));

৯ · Secret, fork আর supply chain — pipeline-এর নিরাপত্তা

CI-র runner production database-এর চাবি, cloud-এর অধিকার আর package প্রকাশের token ছুঁতে পারে, তাই এটি আক্রমণের আকর্ষণীয় লক্ষ্য। নিচের সব পরামর্শ রক্ষার দিক থেকে; threat model-এর পূর্ণ তত্ত্ব DevSecOps পর্বে আর Cybersecurity-র supply chain পর্বে। App-এর environment আর secret কীভাবে ভাগ করবেন, তা পর্ব ৭৮-এ।

Secret কোথায় থাকে, কে পায়

GitHub-এ secret রাখা যায় তিন স্তরে: organization, repository, আর environment. Environment secret শুধু সেই job পায়, যে environment: production ঘোষণা করে, আর সেই environment-এর সুরক্ষার নিয়ম (যেমন reviewer-এর অনুমোদন) পূরণ হওয়ার পরে। তাই production database-এর DATABASE_URL repository secret নয়, environment secret: quality বা e2e job সেটি কখনো দেখে না। Log-এ secret-এর মান GitHub মুছে *** দেখায়, কিন্তু মানটি বদলে (যেমন base64 করে) ছাপলে সেই পাহারা কাজ করে না; secret কখনো ছাপবেন না।

আরও ভালো হলো দীর্ঘস্থায়ী চাবি না রাখা। OIDC federation-এ job permissions: id-token: write নিয়ে GitHub থেকে একটি স্বাক্ষর করা, স্বল্পমেয়াদি পরিচয়পত্র নেয়, যাতে লেখা থাকে কোন repository, কোন branch বা environment থেকে job চলছে। Cloud provider আগে থেকে সেই শর্তে বিশ্বাস ঠিক করে রাখে, আর কয়েক মিনিটের অস্থায়ী অধিকার দেয়। চুরি করার মতো স্থায়ী key কোথাও থাকে না। বড় cloud provider-রা এটি সমর্থন করে বলে তাদের docs-এ লেখা; ঠিক কোন শর্ত লিখতে হয়, তা provider অনুযায়ী আলাদা, আর এখানে কোনো cloud-এ চালানো হয়নি। Protocol-এর ভিত্তি OpenID Connect, যা পর্ব ৪৭-এ এসেছিল।

Fork থেকে pull request — কেন secret দেওয়া হয় না

Open-source repository-তে যে কেউ fork করে PR খুলতে পারেন, আর সেই PR-এর কোড CI-তে চলে। কোডটি অচেনা মানুষের লেখা, তাই GitHub-এর docs অনুযায়ী fork থেকে আসা pull_request run-এ repository-র secret দেওয়া হয় না (GITHUB_TOKEN ছাড়া), আর সেই token-ও শুধু পড়ার অধিকার পায়। ফলে fork-এর PR-এ যে job secret ছাড়া চলে না (preview deploy, cloud-এ upload), সেটি ফেল বা skip হওয়াই প্রত্যাশিত, আর এটি ভালো খবর।

এখান থেকে একটি বিপজ্জনক “সমাধান” জন্মায়: pull_request_target. এই event-এ workflow চলে base repository-র প্রেক্ষাপটে, base branch-এর workflow ফাইল দিয়ে, secret আর লেখার অধিকারসহ। নকশাটি তৈরি PR-এ label দেওয়া বা মন্তব্য করার মতো কাজের জন্য, যেখানে PR-এর কোড চালানো হয় না। কেউ যদি এখানে PR-এর head checkout করে npm ci বা test চালান, তাহলে অচেনা কোড secret-সহ চলবে: PR-এর package.json-এর একটি script-ই যথেষ্ট। GitHub Security Lab ২০২১ সালের দিকে এর নাম দিয়েছিল “pwn request”. লেখার সময়ের একটি পরিবর্তন: actions/checkout-এর v7 (জুন ২০২৬) আর পরে backport হওয়া পুরোনো major version, GitHub-এর changelog অনুযায়ী, pull_request_target-এ fork-এর PR-এর head বা merge commit checkout করতে নিজে থেকেই অস্বীকার করে; ইচ্ছা করে খুলতে allow-unsafe-pr-checkout দিতে হয়। একই changelog বলে, SHA-তে পিন করা workflow এই backport নিজে থেকে পায় না, হাতে বা Dependabot দিয়ে হালনাগাদ করতে হয়। আর এটি run step-এ git দিয়ে নিজে PR-এর কোড আনা ঠেকায় না।

Supply chain — action, package আর lockfile

Workflow-এর প্রতিটি uses: অন্যের কোড, যা আপনার secret-এর পাশে চলে। @v7-এর মতো tag একটি সরানো যায় এমন নাম: action-এর মালিকের account বা repository দখল হলে tag-টি নতুন, ক্ষতিকর commit-এ সরানো যায়, আর আপনার পরের run সেটিই চালাবে। এটি তাত্ত্বিক নয়। মার্চ ২০২৫-এ একটি জনপ্রিয় action, tj-actions/changed-files, আপস হয়, আর প্রকাশিত বিবরণ অনুযায়ী তার বহু version tag একটি ক্ষতিকর commit-এ সরানো হয়, যা runner-এর memory থেকে secret পড়ে build log-এ ছাপত; ঘটনাটি CVE-2025-30066 নামে নথিভুক্ত। যাঁরা পূর্ণ commit SHA-তে পিন করেছিলেন, tag সরানো তাঁদের workflow-এ পৌঁছায়নি।

তাই SHA pinning: uses: actions/checkout@3d3c42e5…ba90b1 # v7.0.1. Git-এ commit-এর পরিচয় তার বিষয়বস্তুর hash, তাই একই SHA মানে একই কোড। এর দাম: নিরাপত্তা-সংশোধন আর নিজে থেকে আসে না (উপরের checkout-এর উদাহরণই তা দেখায়)। সমাধান Dependabot বা অনুরূপ টুল, যা নতুন version-এর SHA-সহ PR খোলে, আর মানুষ তা review করেন। নিচের ব্লক workflow-এর লেখা থেকে পিন না করা action খোঁজে; এটি একটি শিক্ষণ মডেল, আসল কাজে যাচাই করা টুল ব্যবহার করুন।

// Teaching model: flag "uses:" lines that are not pinned to a full 40-character commit SHA.
const workflow = `
jobs:
  ci:
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-node@v7
      - uses: some-org/deploy-action@main
      - uses: actions/upload-artifact@cf430e0
      - uses: ./.github/actions/seed-db
      - uses: docker://alpine:3.22
      - run: npx playwright test
`;
const FULL_SHA = /^[0-9a-f]{40}$/;
let problems = 0;
workflow.split('\n').forEach((line, i) => {
  const m = line.match(/uses:\s*([^\s#]+)/);
  if (!m) return;
  const ref = m[1];
  if (ref.startsWith('./')) return console.log(`line ${i}: local action, lives in this repo  ${ref}`);
  if (ref.startsWith('docker://')) return console.log(`line ${i}: container image, pin by @sha256 digest  ${ref}`);
  const [, version] = ref.split('@');
  if (FULL_SHA.test(version ?? '')) return console.log(`line ${i}: ok, pinned  ${ref.slice(0, 32)}…`);
  problems++;
  const why = !version ? 'no version' : /^[0-9a-f]{7,39}$/.test(version) ? 'short SHA, not a full pin' : `"${version}" is a movable tag or branch`;
  console.log(`line ${i}: NOT PINNED (${why})  ${ref}`);
});
console.log(`${problems} action(s) to pin`);

Package-এর দিকে তিনটি অভ্যাস। (১) npm ci আর commit করা lockfile: install-এ নতুন version ঢোকে না, আর প্রতিটি package-এর integrity hash মেলানো হয়। (২) npm audit একটি step হিসেবে, একটি স্পষ্ট সীমাসহ। ল্যাবে দুটি সত্যিকারের ফল পাশাপাশি:

$ npm audit --omit=dev --audit-level=high
found 0 vulnerabilities
$ echo $?
0

$ npm audit --audit-level=moderate
# npm audit report

minimatch  <11.0.1
Severity: moderate
minimatch has potential denial of service via globparts amplification - https://github.com/advisories/GHSA-g3hv-75wg-m249
fix available via `npm audit fix --force`
Will install eslint@4.0.0, which is a breaking change
…
16 moderate severity vulnerabilities
$ echo $?
1

Production-এর dependency-তে কিছু নেই; ১৬টি moderate সতর্কতা সব ESLint-এর tool chain-এর ভেতরে, যা শুধু development-এ চলে। আর npm-এর প্রস্তাবিত npm audit fix --force ESLint-কে 9 থেকে 4.0.0-এ নামিয়ে দিত, যা পুরো lint ভেঙে দিত। তাই pipeline-এ সিদ্ধান্তটি সচেতন: production dependency-তে high বা তার বেশি হলে লাল, development tool-এর moderate আলাদাভাবে, মানুষের বিচারে। Dependency-র নিরাপত্তার তালিকা পর্ব ৫০-এ। (৩) নতুন package যোগের PR-এ নাম আর প্রকাশক যাচাই, কারণ কাছাকাছি বানানের ক্ষতিকর package (typosquatting) একটি পরিচিত কৌশল।

১০ · Deploy, অনুমোদন, rollback আর দ্রুত CI

বাজারঘরের deploy একটি আলাদা workflow, হাতে চালানো (workflow_dispatch), যাতে input হিসেবে দেওয়া হয় কোন commit-এর build যাবে। দুটি job: migrate আর release, দুটোই environment: production-এ, আর release-এর needs: [migrate]. Environment-এর নিয়মে reviewer-এর অনুমোদন চালু থাকলে job শুরু হওয়ার আগে GitHub থেমে একজন নির্দিষ্ট মানুষের সম্মতি চায়; কোন plan-এ, কোন ধরনের repository-তে এই সুবিধা পাওয়া যায়, তা GitHub-এর বর্তমান docs-এ দেখে নিন। Concurrency-তে cancel-in-progress: false: অর্ধেক হওয়া deploy বাতিল করা অর্ধেক হওয়া migration-এর মতোই বিপজ্জনক, তাই নতুন deploy সারিতে অপেক্ষা করে।

on:
  workflow_dispatch:
    inputs:
      build_sha:
        description: 'Commit SHA whose build to deploy (rollback = an older SHA)'
        required: true
concurrency:
  group: deploy-production
  cancel-in-progress: false
jobs:
  migrate:
    environment: production          # অনুমোদন, তারপর environment secret
    steps:
      # checkout ${{ inputs.build_sha }}, setup-node, npm ci
      - run: npx prisma migrate deploy
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
  release:
    needs: [migrate]
    environment: production
    permissions: { contents: read, id-token: write }   # OIDC
    steps:
      - name: Deploy the stored build of this SHA
        env:
          BUILD_SHA: ${{ inputs.build_sha }}
        run: ./scripts/deploy.sh "$BUILD_SHA"     # provider-নিরপেক্ষ, এখানে চালানো হয়নি

deploy.sh ইচ্ছা করে কোনো provider-এর নয়: কোথাও এটি একটি container image বদলায়, কোথাও একটি PaaS-এর CLI চালায়, কোথাও VPS-এ ফাইল পাঠিয়ে process manager restart করে (পর্ব ৮২)। Health check-এর জন্য পর্ব ৩১-এর /health কাজে লাগে, আর deploy-এর পরে error বাড়ছে কি না দেখা পর্ব ৮৩-এর (Monitoring) বিষয়।

Rollback — আগের build আবার, database নয়

Deploy-এর পরে কিছু ভাঙলে প্রথম কাজ ক্ষতি থামানো। সবচেয়ে দ্রুত আর নিরাপদ rollback হলো আগের, জানা-ভালো commit-এর build আবার deploy করা: একই workflow, input-এ পুরোনো SHA. এখানে আবার build নয়, কারণ নতুন build মানে নতুন, পরীক্ষা না করা জিনিস। Database পেছনে নেওয়া হয় না: down migration ডেটা হারাতে পারে, আর expand-only migration-এর পরে পুরোনো কোড এমনিই চলে, ল্যাবে যেমন দেখা গেছে। যেখানে পুরোনো build চালানো সম্ভব নয় (যেমন contract-এর পরে), সেখানে পথ হলো দ্রুত সংশোধন করে নতুন release, অর্থাৎ roll forward.

build: next-build-7a8b9c0  (v41)
DB migrations: init
error rate: স্বাভাবিক

migrate (অনুমোদনের পরে):
  Applying `…_expand_add_title`   ✓
release: next-build-c4d5e6f  (v42)

POST /checkout → 500 বাড়ছে
কারণ: v42-এর একটি বাগ (DB নয়)
সিদ্ধান্ত: আগে ক্ষতি থামানো, পরে খোঁজা

migrate: No pending migrations to apply.
  (title কলাম থেকে যায়; v41 তা ছোঁয় না)
release: next-build-7a8b9c0  (নতুন build নয়)

GET /health → 200
checkout-এর error rate আগের মতো
ঘটনার নোট: কখন, কী, কে, কেন

বাগের জন্য আগে একটি ফেল করা test
সংশোধন → PR → সব check সবুজ
deploy build_sha=d7e8f90  (v43)

CI দ্রুত রাখা — মাপা সময় থেকে সিদ্ধান্ত

ল্যাবের script (scripts/ci-local.mjs) workflow-এর সব ধাপ একই ক্রমে, fail-fast-সহ, একটি কম্পিউটারে চালিয়ে প্রতিটির সময় লিখেছে। শেষ পূর্ণ run-এর সত্যিকারের সারণি, একটি স্থানীয় run, CI-র মেশিনে সংখ্যা আলাদা হবে:

$ node scripts/ci-local.mjs
…
step             seconds  result
install             20.0  ok
audit                0.8  ok
generate             1.4  ok
lint                 2.1  ok
typecheck            1.7  ok
unit+component       1.8  ok
fresh-db             0.3  ok
migrate              1.3  ok
integration          1.1  ok
build                5.1  ok
seed-e2e             0.2  ok
e2e 1/2              3.5  ok
e2e 2/2              3.4  ok
total               42.7

সংখ্যাগুলো থেকে কয়েকটি শিক্ষা। Install-ই সবচেয়ে বড়: ৪২.৭-এর ২০.০, প্রায় ৪৭%; আর খালি cache-এ সেটি ১০০ সেকেন্ড। তাই cache-ই প্রথম অগ্রাধিকার। প্রতিটি job install-এর দাম আবার দেয়: pipeline-এ পাঁচটি job মানে পাঁচবার install; ছোট project-এ সব একটি job-এ রাখলেই হয়তো দ্রুত, ২ নম্বর অংশের মডেলের মতো। সস্তা আগে: lint, typecheck, unit মিলে ৫.৬ সেকেন্ডে বেশির ভাগ সাধারণ ভুল ধরে; build আর E2E তার পরে। পুরোনো run বাতিল (concurrency) আর সময়সীমা (timeout-minutes), যাতে আটকে থাকা job ঘণ্টার পর ঘণ্টা runner না খায়। Shard তখনই, যখন E2E-র সময় প্রতি shard-এর স্থির খরচের চেয়ে অনেক বেশি।

AI-এর যুগে CI/CD

AI টুল একটি পুরো workflow কয়েক সেকেন্ডে লিখে দেয়, আর সেখানেই বিপদ। সাধারণ ভুলগুলো: পুরোনো action version (@v3, যা actionlint ল্যাবে ধরেছে), npm install, CI-তে prisma migrate dev বা db push, next lint (Next.js 16-এ নেই), সব secret repository স্তরে আর সব job-এ permissions: write-all, fork-এর PR-এ preview চালাতে pull_request_target আর তার মধ্যে PR-এর head checkout, ব্যর্থতা ঢাকতে continue-on-error: true, আর কখনো কখনো অস্তিত্বহীন action বা option. যাচাইয়ের পথ: action-এর release পাতা আর framework-এর version-মিলানো docs পড়া, actionlint চালানো, প্রতিটি step নিজের কম্পিউটারে একবার চালানো, diff লাইন ধরে পড়া, আর কখনো আসল secret prompt-এ না দেওয়া।

AI-এর লেখা pipeline মেলানোর চেকলিস্ট

• actionlint চালিয়ে শূন্য সমস্যা পেয়েছি, আর প্রতিটি action-এর version তার release পাতায় মিলিয়েছি
• সব uses: পূর্ণ SHA-তে, আর Dependabot বা অনুরূপ টুল action হালনাগাদের PR খোলে
• কোথাও migrate dev, db push, npm install, next lint বা continue-on-error নেই
• pull_request_target নেই, বা থাকলে সেখানে PR-এর কোড checkout বা চালানো হয় না
• Production-এর secret শুধু environment secret, অনুমোদনসহ; বাকি job সেগুলো দেখে না
• প্রতিটি step নিজের কম্পিউটারে একবার চালিয়েছি, আর ইচ্ছা করে একটি test ভেঙে দেখেছি pipeline সত্যিই লাল হয়