CI/CD pipeline-এর নকশা — stage, cache, parallel আর গতি

১ · Pipeline একটি কারখানার লাইন: stage, job আর step

Continuous integration মানে সবার কাজ ঘন ঘন মূল branch-এ মেলানো আর প্রতিবার স্বয়ংক্রিয় যাচাই। Continuous delivery মানে প্রতিটি সবুজ build যেকোনো সময় release করার মতো রাখা। এই সংজ্ঞা আর তাদের ইতিহাস Software Engineering কোর্সের Continuous integration আর Continuous delivery ও DevOps পর্বে আছে। এই পর্ব তার পরের ধাপ: একটি pipeline-কে প্রকৌশলের চোখে নকশা করা। সে কত দ্রুত, কত সস্তা, কত নির্ভরযোগ্য, আর কতটা নিরাপদ?

Job আলাদা যন্ত্রে চলে, তাই build-এর তৈরি file পরের job নিজে থেকে পায় না। সেটি artifact হিসেবে পাঠাতে হয়। Artifact-এর পুরো গল্প পরের পর্ব ৫৮-তে (Artifact আর promotion). GitLab-এর ভাবনার কেন্দ্রে stage, আর GitHub Actions-এ stage বলে আলাদা কিছু নেই, সেখানে শুধু job আর তাদের নির্ভরতা। শব্দ আলাদা, নকশার নীতি একই।

২ · DAG, needs আর critical path

“Build-এর পরে test” বলার সবচেয়ে সরল উপায় stage. কিন্তু stage-এ একটি লুকানো খরচ আছে: stage-এর সব job শেষ না হলে পরের stage শুরু হয় না, এমনকি পরের job যার ওপর নির্ভর করে না তার জন্যও। প্রতিটি job যদি নিজে বলে সে কার জন্য অপেক্ষা করবে, তাহলে pipeline একটি DAG হয়ে যায়, মানে দিক আছে কিন্তু বৃত্ত নেই এমন গ্রাফ। GitHub Actions আর GitLab CI দুটিতেই এর জন্য শব্দটি needs.

নিচে একটি কাল্পনিক অনলাইন বাজার অ্যাপ bazar-app-এর pipeline. প্রতিটি সংখ্যা ধরে নেওয়া সময়, মিনিটে। সব job-এর যোগফল ৪৫ মিনিট। লাল পথটি লক্ষ করুন।

Critical path হলো শুরু থেকে শেষ পর্যন্ত সবচেয়ে লম্বা নির্ভরতার পথ। অসীম runner থাকলেও pipeline এর চেয়ে দ্রুত শেষ হতে পারে না। দুটি নিচের সীমা মনে রাখুন, যেখানে R মানে runner-এর সংখ্যা:

এখানে R = ২ হলে দ্বিতীয় সীমা ৪৫ ÷ ২ = ২২.৫ মিনিট, প্রথমটি ২৬ মিনিট, তাই ২৬-এর নিচে যাওয়া অসম্ভব। নিচের simulator একটি সত্যিকারের list scheduler চালায়: যে job-এর সব নির্ভরতা শেষ, তাদের মধ্যে লম্বাটি আগে খালি runner পায়। এখানে JOBS-এর সময় বদলে দেখুন, আর শেষ অংশের “যদি” পরীক্ষাগুলো নিজে যোগ করুন।

// Pipeline DAG with limited runners. Durations (minutes) are ASSUMED.
const JOBS = { lint: [2], typecheck: [3], unit: [6],
  build: [5, "lint", "typecheck"], image: [4, "build"], scan: [3, "image"],
  integ: [8, "image"], e2e: [12, "image"], publish: [2, "unit", "scan", "integ", "e2e"] };
const dur = (J, n) => J[n][0], needs = (J, n) => J[n].slice(1);
function criticalPath(J) {               // longest path through the DAG
  const memo = {};
  const best = n => memo[n] ??= (() => {
    const p = needs(J, n).map(best).sort((a, b) => b.len - a.len)[0];
    return { len: (p ? p.len : 0) + dur(J, n), path: [...(p ? p.path : []), n] };
  })();
  return Object.keys(J).map(best).sort((a, b) => b.len - a.len)[0];
}
function schedule(J, runners) {          // list scheduling: longest ready job first
  const end = {}, left = new Set(Object.keys(J)); let t = 0, busy = [];
  while (left.size || busy.length) {
    const ready = [...left].filter(n => needs(J, n).every(d => end[d] <= t))
      .sort((a, b) => dur(J, b) - dur(J, a));
    for (const n of ready.slice(0, runners - busy.length)) {
      left.delete(n); busy.push(n); end[n] = t + dur(J, n);
    }
    t = Math.min(...busy.map(n => end[n]));
    busy = busy.filter(n => end[n] > t);
  }
  return t;
}
const cp = criticalPath(JOBS);
const work = Object.keys(JOBS).reduce((a, n) => a + dur(JOBS, n), 0);
console.log(`total work ${work} min, critical path ${cp.len} min`);
console.log(cp.path.join(" -> "));
for (const r of [1, 2, 3, 4]) console.log(`runners=${r}  wall=${schedule(JOBS, r)} min`);
for (const [job, m] of [["unit", 3], ["e2e", 6], ["build", 3]]) {
  const what = { ...JOBS, [job]: [m, ...needs(JOBS, job)] };
  console.log(`if ${job}=${m} min: critical path ${criticalPath(what).len} min`);
}

total work 45 min, critical path 26 min
typecheck -> build -> image -> e2e -> publish
runners=1  wall=45 min
runners=2  wall=28 min
runners=3  wall=26 min
runners=4  wall=26 min
if unit=3 min: critical path 26 min
if e2e=6 min: critical path 22 min
if build=3 min: critical path 24 min

৩ · Runner: hosted বনাম self-hosted

Runner হলো সেই যন্ত্র, যেখানে job চলে। Hosted runner platform-এর দেওয়া: প্রতিটি job-এ নতুন virtual machine, কাজ শেষে মুছে যায়। Self-hosted runner আপনার নিজের VM, server বা Kubernetes cluster-এ চলে। পার্থক্যটি CNG ভাড়া আর নিজের গাড়ির মতো: ভাড়ায় যত্নের ঝামেলা নেই, প্রতিবার গুনে টাকা; নিজের গাড়িতে পথ আর গ্যারেজ আপনার পছন্দের, কিন্তু চুরি আর মেরামতের দায়ও আপনার।

Self-hosted runner-এর নিরাপত্তা

শেষ সারিটিই সবচেয়ে বিপজ্জনক। একটি CI job-এর কাজই repository-র কোড চালানো। Pull request-এর কোডও কোড। একটি স্থায়ী runner-এ এক job যদি ক্ষতিকর কিছু রেখে যায়, পরের job, হয়তো release-এর job, সেই একই যন্ত্রে চলবে। আর runner যদি আপনার VPC-র ভেতরে থাকে, ঝুঁকি শুধু build-এ থেমে থাকে না। তাই নিয়মগুলো:

• Ephemeral runner: একটি job, তারপর যন্ত্র মুছে ফেলা। Docker socket বা host-এর folder job-কে না দেওয়া।
• Public repository-তে self-hosted নয়: GitHub-এর documentation লেখার সময়ে ঠিক এই সতর্কতাই দেয়, কারণ যে কেউ fork থেকে pull request পাঠাতে পারেন।
• বিশ্বাসের স্তর আলাদা: Pull request-এর runner আর deploy-এর runner আলাদা group-এ। GitLab-এ “protected runner” শুধু protected branch-এর job নেয়।
• Network আর পরিচয় সীমিত: runner-এর subnet থেকে শুধু দরকারি জায়গায় egress, আর instance-এর IAM role-এ শুধু ন্যূনতম অনুমতি (least privilege). Metadata service-এর পথ বন্ধ বা সীমিত।

৪ · Fail fast: দ্রুত আর সস্তা check আগে

লঞ্চঘাটে টিকিট দেখা হয় ঘাটেই, মাঝনদীতে নয়। Pipeline-এও একই নিয়ম: যে check সবচেয়ে দ্রুত আর সবচেয়ে বেশি ভুল ধরে, সে সবার আগে। একটি typo ধরা পড়ার জন্য ১২ মিনিটের end-to-end test-এর অপেক্ষা করা চলে না। ক্রম ঠিক করার হিসাবটি সহজ: প্রতিটি check-এর “ভুল ধরার সম্ভাবনা ÷ সময়” বের করুন, বেশি যার সে আগে। সাধারণত ক্রমটি হয় lint ও format, type check, unit test, build, integration test, শেষে e2e.

নিচের stepper-এ একটি commit ওপরের DAG ধরে এগোয়। Runner তিনটি, আর শুরুতে ১ মিনিট লাইনে অপেক্ষা ধরা হয়েছে।

GitHub Actions-এর matrix-এ fail-fast নামে একটি আলাদা সেটিং আছে, যা ডিফল্টে চালু থাকে: এক matrix job ব্যর্থ হলে বাকিগুলো বাতিল। Test shard-এ অনেক দল এটি বন্ধ রাখেন, যাতে একবারেই সব ব্যর্থ test দেখা যায়। “দ্রুত থামা” আর “সব খবর পাওয়া”, এই দুটির মধ্যে বেছে নিতে হয়।

৫ · Cache: dependency, Docker layer আর poisoning

Hosted runner প্রতিবার খালি যন্ত্র, তাই সব dependency প্রতিবার নামাতে হয়। Cache মানে আগের কাজের ফল জমিয়ে রাখা। Cache আর artifact-এর পার্থক্য Continuous integration পর্বে আছে। মূল নিয়মটি একটি বাক্যে: cache মুছে গেলেও pipeline-এর ফল একই হতে হবে, শুধু সময় বেশি লাগবে। Pipeline-এ cache থাকে মূলত দুই রূপে:

Cache key কীভাবে বদলায়

নিচের stepper-এর hash আসল: একটি ১২ লাইনের requirements.txt-এর SHA-256 আর তাতে একটি লাইন যোগ করার পরের SHA-256, প্রথম ১২ অক্ষর। Package-এর সংখ্যাগুলোও আসল pip run থেকে নেওয়া।

ভালো key-তে থাকে OS, CPU-র ধরন, ভাষার version আর lockfile-এর hash. Key-তে OS না থাকলে Linux-এর compiled package Windows-এ ফিরে আসতে পারে। Key-তে তারিখ বা commit SHA রাখলে প্রায় সবসময় miss, মানে cache hit ratio শূন্যের কাছে।

আসল Docker build: কত সময় বাঁচে

একটি ছোট Python app (Flask, requests আর তাদের dependency মিলিয়ে ১২টি pin, image ৯৯.৫ MB) নিয়ে Docker Engine 29 আর BuildKit-এ আসল build চালানো হয়েছে। সময় মাপা হয়েছে build-এর বাইরের stopwatch দিয়ে। আপনার ক্ষেত্রে id, digest, আকার আর সময় আলাদা হবে; এই run-এ network দ্রুত ছিল, আর package-গুলো ছোট।

FROM python:3.12-alpine
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --disable-pip-version-check --root-user-action=ignore -r requirements.txt
COPY app.py .
CMD ["python", "app.py"]

শুধু app.py বদলে দুই Dockerfile-এর আসল আউটপুট, ছোট করে:

$ docker build --progress=plain -f Dockerfile.plain -t abcl-pd-app:plain .
…
#6 [2/5] WORKDIR /app
#6 CACHED

#7 [3/5] COPY requirements.txt .
#7 CACHED

#8 [4/5] RUN pip install --no-cache-dir --disable-pip-version-check --root-user-action=ignore -r requirements.txt
#8 CACHED

#9 [5/5] COPY app.py .
#9 DONE 0.1s
…

$ docker build --progress=plain -f Dockerfile.bad -t abcl-pd-app:bad .
…
#6 [2/4] WORKDIR /app
#6 CACHED

#7 [3/4] COPY . .
#7 DONE 0.0s

#8 [4/4] RUN pip install --no-cache-dir --disable-pip-version-check --root-user-action=ignore -r requirements.txt
…
#8 DONE 4.1s
…

এই টেবিল থেকে তিনটি সৎ শিক্ষা:

• ক্রমের লাভই সবচেয়ে বড়। এক লাইন সরিয়ে প্রায় ৫ সেকেন্ড বাঁচে, প্রতি commit-এ, এক পয়সা খরচ ছাড়া।
• Cache mount এখানে সামান্যই বাঁচিয়েছে, গড়ে ০.৪ সেকেন্ডের মতো। Network দ্রুত, wheel ছোট, আর install-এর সময় ঠিকই লাগে। তবে আগের একটি run-এ cache ছাড়া একই ধরনের build ১৭.৮৩ সেকেন্ড নিয়েছিল, আর cache mount-সহ ৪.৪১ সেকেন্ড; কারণ এখানে যাচাই করা হয়নি, সম্ভবত network-এর ওঠানামা। ধীর network-এ বা বড় package-এ এর লাভ বাড়ার কথা। অনুমান নয়, নিজের pipeline-এ মেপে দেখুন।
• নতুন builder-ই hosted runner-এর আসল ছবি। এই সারিগুলোর প্রতিটি run একটি একেবারে নতুন builder-এ চলেছে, ঠিক খালি runner-এর মতো। --cache-from সময় অর্ধেকের কম করেছে: ১৭.৫ থেকে ৭.৫ সেকেন্ড।

$ docker buildx build --builder abcl-pd-builder --progress=plain -f Dockerfile.plain \
    --cache-from type=local,src=../ccache -t abcl-pd-app:fresh --load .
…
#4 importing cache manifest from local:15948370437373171322
#4 inferred cache manifest type: application/vnd.oci.image.manifest.v1+json done
#4 DONE 0.0s
…
#7 [2/5] WORKDIR /app
#7 CACHED

#8 [3/5] COPY requirements.txt .
#8 CACHED

#9 [4/5] RUN pip install --no-cache-dir --disable-pip-version-check --root-user-action=ignore -r requirements.txt
…
#9 CACHED
…

Cache hit ratio বনাম খরচ

Cache কি সবসময় লাভ? না। Cache ফেরাতে আর জমাতেও সময় লাগে। নিচের মডেলে সব দাম ধরে নেওয়া: ধরে নিই runner-মিনিট $০.০০৮, মাসে ৩,০০০ run, প্রতি run-এ ৬টি job. আপনার provider-এর আসল দাম তার pricing পাতায় দেখুন।

// Cache hit ratio vs runner minutes and monthly bill. All prices ASSUMED.
const RUNS = 3000, JOBS = 6;              // per month, per run
const WORK = 5, INSTALL = 4;              // minutes per job
const RESTORE_HIT = 0.5;                  // download and unpack the cache
const MISS_EXTRA = 0.5;                   // failed lookup + saving a new cache
const PRICE = 0.008;                      // $ per runner-minute (assumed)
const row = m => ({ m, total: m * JOBS * RUNS, bill: m * JOBS * RUNS * PRICE });
const none = row(WORK + INSTALL);
console.log(`no cache: ${none.m.toFixed(2)} min/job, ` +
  `${none.total} min/month, $${none.bill.toFixed(0)}`);
for (const h of [0, 0.25, 0.5, 0.75, 0.9, 0.95, 1]) {
  const m = WORK + h * RESTORE_HIT + (1 - h) * (INSTALL + MISS_EXTRA);
  const r = row(m);
  console.log(`hit ${String(h * 100).padStart(3)}%: ${m.toFixed(2)} min/job  ` +
    `${String(Math.round(r.total)).padStart(6)} min/month  ` +
    `$${r.bill.toFixed(0).padStart(4)}  saves $${(none.bill - r.bill).toFixed(0)}`);
}
const be = MISS_EXTRA / (INSTALL + MISS_EXTRA - RESTORE_HIT);
console.log(`break-even hit ratio: ${(be * 100).toFixed(1)}%`);

no cache: 9.00 min/job, 162000 min/month, $1296
hit   0%: 9.50 min/job  171000 min/month  $1368  saves $-72
hit  25%: 8.50 min/job  153000 min/month  $1224  saves $72
hit  50%: 7.50 min/job  135000 min/month  $1080  saves $216
hit  75%: 6.50 min/job  117000 min/month  $ 936  saves $360
hit  90%: 5.90 min/job  106200 min/month  $ 850  saves $446
hit  95%: 5.70 min/job  102600 min/month  $ 821  saves $475
hit 100%: 5.50 min/job   99000 min/month  $ 792  saves $504
break-even hit ratio: 12.5%

Cache poisoning: গতির বদলে বিশ্বাস হারানো

Cache হলো এক run-এর লেখা file, যা পরের run বিনা প্রশ্নে চালায় বা ব্যবহার করে। অবিশ্বস্ত কোড যদি সেই cache-এ লিখতে পারে, আর বিশ্বস্ত release job তা পড়ে, তাহলে ক্ষতিকর জিনিস সবুজ pipeline-এর ভেতর দিয়ে production-এ পৌঁছায়। এটিই cache poisoning. গুদামঘরের উদাহরণে: মাল ফেরত নেওয়ার তাক আর বিক্রির তাক এক হলে একটি নকল প্যাকেট আসল মালের সারিতে ঢুকে যায়। প্রতিরক্ষার সিদ্ধান্তটি ধাপে ধাপে দেখুন।

৬ · Parallel, matrix, sharding আর Amdahl-এর সীমা

দুই ধরনের parallel আলাদা করে চিনুন। Matrix build একই test ভিন্ন পরিবেশে চালায়, যেমন Python 3.11, 3.12, 3.13 × Linux, Windows = ৬টি job. এটি বাড়তি আত্মবিশ্বাস কেনে, সময় নয়। Test sharding একই পরিবেশে একটি বড় suite ভেঙে কয়েকটি runner-এ চালায়। এটি সময় কেনে।

হাতে হিসাব। Suite ২০ মিনিট, প্রতিটি runner-এর setup ২ মিনিট, ৪টি shard, ভাগ নিখুঁত। সময় = ২ + ২০ ÷ ৪ = ৭ মিনিট। Runner-মিনিট = ৪ × ২ + ২০ = ২৮, যেখানে এক runner-এ ছিল ২২। অর্থাৎ সময় ৬৮% কমল, বিল ২৭% বাড়ল. নিখুঁত ভাগ কিন্তু সহজ নয়। ধরা যাক ৪০টি test file, যার প্রথম ৮টি database-এর ধীর test. শুধু সংখ্যা সমান করে ভাগ করলে সব ধীর test এক shard-এ পড়ে।

// Split 40 test files into 4 shards: naive chunks vs balanced by time.
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 rnd = mulberry32(57), SHARDS = 4, SETUP = 60;       // seconds
const tests = [];                                         // folder order
for (let i = 0; i < 8; i++)  tests.push(40 + Math.floor(rnd() * 50));  // db: slow
for (let i = 0; i < 32; i++) tests.push(5 + Math.floor(rnd() * 16));   // unit
const load = s => s.reduce((a, b) => a + b, 0), total = load(tests);
const empty = k => Array.from({ length: k }, () => []);
function naive(t, k) {                       // equal COUNT, in folder order
  const s = empty(k), n = Math.ceil(t.length / k);
  t.forEach((d, i) => s[Math.floor(i / n)].push(d));
  return s;
}
function balanced(t, k) {                    // longest first, to the lightest shard
  const s = empty(k);
  [...t].sort((a, b) => b - a).forEach(d =>
    s.reduce((m, x) => load(x) < load(m) ? x : m).push(d));
  return s;
}
function report(name, shards) {
  const loads = shards.map(load), wall = SETUP + Math.max(...loads);
  console.log(`${name.padEnd(9)} loads ${loads.join(" ")}  wall ${wall}s` +
    `  runner-sec ${loads.length * SETUP + total}`);
  return wall;
}
console.log(`40 files, ${total}s of tests, one runner: ${SETUP + total}s`);
const a = report("naive", naive(tests, SHARDS)), b = report("balanced", balanced(tests, SHARDS));
console.log(`speedup: naive ${((SETUP + total) / a).toFixed(2)}x, balanced ${((SETUP + total) / b).toFixed(2)}x`);
const p = total / (SETUP + total);                       // Amdahl's limit
for (const n of [2, 4, 8, 16, 1000])
  console.log(`n=${String(n).padEnd(5)} Amdahl limit ${(1 / ((1 - p) + p / n)).toFixed(2)}x`);

40 files, 880s of tests, one runner: 940s
naive     loads 516 131 118 115  wall 576s  runner-sec 1120
balanced  loads 220 221 219 220  wall 281s  runner-sec 1120
speedup: naive 1.63x, balanced 3.35x
n=2     Amdahl limit 1.88x
n=4     Amdahl limit 3.36x
n=8     Amdahl limit 5.53x
n=16    Amdahl limit 8.17x
n=1000  Amdahl limit 15.44x

এবার শেষ পাঁচ লাইন। ১৯৬৭ সালে Gene Amdahl দেখান: কাজের যে অংশ ভাগ করা যায় না, সে-ই গতির ছাদ ঠিক করে। ভাগ করা যায় এমন অংশ p, runner n হলে:

এখানে p = ৮৮০ ÷ ৯৪০ ≈ ০.৯৩৬, তাই ছাদ ৯৪০ ÷ ৬০ ≈ ১৫.৭ গুণ। ১,০০০ runner-এও ১৫.৪৪ গুণ, অথচ ১৬ runner-ই দেয় ৮.১৭ গুণ। এই সরল মডেলে setup-কে ভাগ-না-হওয়া অংশ ধরা হয়েছে, কারণ প্রতিটি shard-কে পুরো setup-টাই করতে হয়। আরেকটি সীমা: একটি test file ভাঙা না গেলে shard তার চেয়ে ছোট হতে পারে না। এখানে সবচেয়ে ধীর file ৭৬ সেকেন্ডের, তাই n যত বড়ই হোক, সময় ৬০ + ৭৬ = ১৩৬ সেকেন্ডের নিচে যাবে না। এটিও critical path-এর আরেক রূপ।

৭ · Flaky test, monorepo আর পুরোনো run বাতিল

Flaky test: যে test মিথ্যা বলে

Flaky test একই কোডে কখনো পাস, কখনো ফেল। একটি test-এর ফেলের সম্ভাবনা সামান্য হলেও suite-এ তা জমে যায়। ধরুন ২,০০০টি test, প্রতিটি ০.১% সময় মিথ্যা ফেল করে। সব পাস হওয়ার সম্ভাবনা ০.৯৯৯^২০০০ ≈ ০.১৩৫, মানে প্রায় ৮৬.৫% run অকারণে লাল. একবার retry দিলে একটি test-এর দুবার ফেল ০.০০১² = ১০⁻⁶, তখন মিথ্যা লাল প্রায় ০.২%. Retry তাই গণিতে দারুণ, কিন্তু ঝুঁকি হলো আসল race condition-ও ঢাকা পড়ে।

ভালো পথের চারটি ধাপ: চিহ্নিত করুন (retry-তে পাস করা প্রতিটি test log-এ তুলে রাখুন), quarantine করুন (আলাদা non-blocking দলে সরান, যাতে অন্যদের আটকে না রাখে), মালিক ঠিক করুন আর সময়সীমা দিন, আর কারণ সরান: বেশিরভাগ ক্ষেত্রে async অপেক্ষা, ভাগ করা অবস্থা, সময় বা ক্রমের ওপর নির্ভরতা। Retry-র সীমা থাকুক, আর সেই সংখ্যাটি মেট্রিক হোক। Test নকশার গভীর আলোচনা Test pyramid আর integration test পর্বে।

Monorepo-র path filter

একটি monorepo-তে অনেক service এক repository-তে। Docs-এর একটি শব্দ বদলালে সব service-এর ৪০ মিনিটের test চালানো অপচয়। Path filter বলে দেয় কোন file বদলালে কোন কাজ চলবে: GitHub Actions-এ on.pull_request.paths, GitLab-এ rules:changes. Trade-off আর graph-ভিত্তিক tool Monorepo পর্বে আছে।

• ভাগ করা কোড: libs/payment/ বদলালে যে সব service তা ব্যবহার করে, তাদেরও চলতে হবে। শুধু path দেখলে সেটি ধরা পড়ে না। কে কাকে ব্যবহার করে, তা জানতে dependency graph লাগে, যেমন Bazel, Nx বা Turborepo-র.
• Required check-এর ফাঁদ: GitHub Actions-এ path filter-এ পুরো workflow বাদ পড়লে তার check, documentation অনুযায়ী, “Pending” থেকে যায়, আর সেটি required check হলে merge আটকে থাকে। প্রচলিত সমাধান: workflow সবসময় চলে, ভেতরের job শর্তে চলে, আর শেষে একটি “gate” job if: always() দিয়ে সবার ফল মিলিয়ে দেখে।
• নিরাপত্তার জাল: মিস হওয়া নির্ভরতা ধরতে main-এ বা রাতে মাঝে মাঝে পুরো suite চালান।

Concurrency: পুরোনো run বাতিল

ধরুন আপনি ২৫ মিনিটের pipeline চলার মাঝে একই branch-এ নতুন commit পাঠালেন। পুরোনো run-এর ফল আর কারও কাজে লাগবে না, তবু সে runner দখল করে আছে। GitHub Actions-এ concurrency-র cancel-in-progress, GitLab-এ interruptible: true আর auto-cancel তাকে থামায়। ঈদের আগে বাসের টিকিটের লাইনে একই মানুষের দুটি পুরোনো আবেদন বাতিল করে নতুনটি রাখার মতো।

কিন্তু deploy কখনো মাঝপথে বাতিল করা ঠিক নয়। অর্ধেক হওয়া deploy আধখানা migration রেখে যেতে পারে। Deploy-এ উল্টো নিয়ম: একই environment-এ একবারে একটি, পরেরটি লাইনে অপেক্ষা করে। GitHub-এ cancel-in-progress: false, GitLab-এ resource_group.

৮ · Pipeline as code: secret, fork আর দুটি YAML

Secret আর fork-এর pull request

Secret-এর মূল নিয়ম পর্ব ৩৩-এ আছে। Pipeline-এর জন্য চারটি অভ্যাস যথেষ্ট:

• Secret আসে platform-এর store থেকে, শুধু যে job-এর দরকার তাকে, সবচেয়ে ছোট পরিসরে (environment). Log-এ masking থাকলেও echo নয়, কারণ রূপ বদলালে ঢাকা পড়ে না।
• স্থায়ী cloud key-এর বদলে OIDC দিয়ে স্বল্পমেয়াদি পরিচয়; বিস্তারিত পর্ব ৬১-তে (DevSecOps).
• স্বয়ংক্রিয় token-এর ডিফল্ট অনুমতি contents: read, বাড়তি শুধু দরকারি job-এ।
• Fork থেকে আসা pull request-এর সাধারণ event-এ secret দেওয়া হয় না (GitHub Actions, লেখার সময়ে)। বিপদ pull_request_target-এ, যা base repository-র অধিকারে চলে। সেখানে PR-এর কোড checkout করে চালানো যাবে না। আরও পড়ুন CI পর্বের নিরাপত্তা অংশে।

GitHub Actions-এ পুরো নকশা

নিচের YAML কাল্পনিক bazar-app-এর। এটি চালানো হয়নি, শুধু গঠন দেখানোর জন্য; parser দিয়ে যাচাই করা হয়েছে। Action-এর major version লেখার সময়ের (অক্টোবর ২০২৬) tag দেখে লেখা, ব্যবহারের আগে মিলিয়ে নিন; পেশাদার ব্যবহারে পুরো commit SHA দিয়ে pin করুন।

# .github/workflows/ci.yml  (fictional bazar-app; illustration, not run here)
name: ci
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read                     # least privilege by default
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
  lint:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v7
      - run: pipx run ruff check .

  unit:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    strategy:
      fail-fast: false               # show every failing shard
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/cache@v6
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
          restore-keys: |
            ${{ runner.os }}-pip-
      - run: pip install -r requirements.txt pytest pytest-split
      - run: pytest --splits 4 --group ${{ matrix.shard }}

  image:
    needs: [lint, unit]              # DAG edge
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
      - uses: docker/setup-buildx-action@v4
      - uses: docker/build-push-action@v7
        with:
          context: .
          push: false
          tags: bazar-app:${{ github.sha }}
          cache-from: type=gha
          # Only main may write the shared layer cache.
          cache-to: ${{ github.ref == 'refs/heads/main' && 'type=gha,mode=max' || '' }}

GitLab CI-তে একই নকশা

# .gitlab-ci.yml  (the same fictional design; illustration, not run here)
stages: [check, package]

workflow:
  auto_cancel:
    on_new_commit: interruptible     # cancel older pipelines of this ref
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

default:
  image: python:3.12-alpine
  interruptible: true

lint:
  stage: check
  script:
    - pip install ruff
    - ruff check .

unit:
  stage: check
  parallel: 4                        # CI_NODE_INDEX and CI_NODE_TOTAL per job
  variables:
    PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"
  cache:
    key:
      files: [requirements.txt]
      prefix: pip
    paths: [.pip-cache/]
  script:
    - pip install -r requirements.txt pytest pytest-split
    - pytest --splits "$CI_NODE_TOTAL" --group "$CI_NODE_INDEX"

build-image:
  stage: package
  needs: [lint, unit]
  rules:
    - changes: [Dockerfile, requirements.txt, "app/**/*"]
  script:
    - echo "build the image here (runner-specific, see the docs)"

Reusable workflow আর template

৫০টি repository-তে একই YAML কপি থাকলে একটি নিরাপত্তা-সংশোধন ৫০ জায়গায় করতে হয়। এই কপির সমস্যা মেটায় reusable workflow: GitHub Actions-এ on: workflow_call, GitLab-এ include, extends আর CI/CD component. রান্নাঘরের একটি রেসিপি খাতা থাকলে সবাই একই বিরিয়ানি রাঁধেন।

# A service repository calls the shared workflow (fictional organisation).
name: service-ci
on:
  pull_request:
jobs:
  python-ci:
    uses: example-org/ci-templates/.github/workflows/python-ci.yml@v2
    with:
      python-version: "3.12"
    permissions:
      contents: read

৯ · মাপা: queue time, duration, success rate আর খরচ

গড় সময় মিথ্যা বলে, কারণ pipeline-এর সময় একদিকে হেলানো। তাই p50 আর p90 দেখুন। চারটি মেট্রিক সবচেয়ে কাজের:

নিচের Bash block একটি নমুনা CSV থেকে এই চারটি বের করে। সংখ্যাগুলো বানানো উদাহরণ, আর দাম ধরে নেওয়া।

#!/bin/bash
# Pipeline health from a sample run log. Price per runner-minute is ASSUMED.
set -euo pipefail
cat > runs.csv <<'CSV'
id,queue_s,duration_s,result,runner_min
101,20,1590,success,45
102,35,1640,success,46
103,15,240,failure,8
104,410,1610,success,45
105,30,1980,failure,52
106,25,300,cancelled,9
107,620,1600,success,45
108,40,1655,success,46
109,20,1625,success,45
110,55,2400,success,70
CSV
pct() {  # pct COLUMN PERCENT : nearest-rank percentile
  tail -n +2 runs.csv | cut -d, -f"$1" | sort -n |
    awk -v p="$2" '{ v[NR] = $1 }
      END { r = p * NR / 100; i = int(r); if (i < r) i++; print v[i] }'
}
echo "queue    p50 $(pct 2 50)s  p90 $(pct 2 90)s"
echo "duration p50 $(pct 3 50)s  p90 $(pct 3 90)s"
awk -F, -v price=0.008 'NR > 1 { c[$4]++; m += $5; n++ }
  END {
    done = c["success"] + c["failure"]
    printf "runs %d, cancelled %d\n", n, c["cancelled"]
    printf "success rate %.1f%%\n", 100 * c["success"] / done
    printf "runner minutes %d, cost $%.2f\n", m, m * price
    printf "cost per run $%.3f, per green run $%.3f\n", m * price / n, m * price / c["success"]
  }' runs.csv

queue    p50 30s  p90 410s
duration p50 1610s  p90 1980s
runs 10, cancelled 1
success rate 77.8%
runner minutes 411, cost $3.29
cost per run $0.329, per green run $0.470

এখানে একটি খরচ বিলে দেখা যায় না: মানুষের অপেক্ষা। আট জনের দলে দিনে ২০টি run, প্রতি run-এ ১০ মিনিট কমলে দিনে ২০০ মিনিট মনোযোগ ফেরে। DORA-র মেট্রিকের সাথে এর সম্পর্ক Continuous delivery ও DevOps পর্বে আছে, আর বিলের দিক পর্ব ৭৩-এ (FinOps).

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

AI কয়েক সেকেন্ডে পুরো YAML লিখে দেয়, আর দেখতে একদম ঠিক লাগে। কিন্তু pipeline-এর হাতে secret আর production-এর পথ থাকে, তাই ভুলের দাম বেশি। AI যেসব ভুল প্রায়ই করে:

AI-এর লেখা pipeline চালানোর আগে

• YAML parser বা actionlint-এর মতো linter পার হয়েছে, আর প্রতিটি action ও input documentation-এ পেয়েছি
• Token-এর অনুমতি ন্যূনতম, আর কোনো secret YAML-এ বা log-এ নেই
• Fork-এর pull request পরীক্ষা করে দেখেছি, কোনো secret পৌঁছায় না
• আলাদা throwaway repository-তে চালিয়ে দেখেছি, মূল repository-তে নয়
• Cache hit ratio আর মোট runner-মিনিট আগের সাথে তুলনা করেছি, আর budget alert চালু
• Deploy বা ধ্বংসাত্মক step-এ মানুষের অনুমোদন আর dry-run আছে