Continuous delivery আর DevOps — deployment pipeline, environment আর DORA metric

১ · সবুজ build থেকে ব্যবহারকারীর হাত — continuous delivery কী

পর্ব ৫৮-এ (Continuous integration) দেখেছেন, দল সারাদিন ছোট ছোট পরিবর্তন mainline-এ মেলায় আর প্রতিটিতে স্বয়ংক্রিয় build ও test চলে। কিন্তু সবুজ build মানেই ব্যবহারকারী নতুন সুবিধা পেলেন, তা নয়। অনেক দলে সবুজ কোড সপ্তাহের পর সপ্তাহ বসে থাকে — “মাসের শেষ শুক্রবার রাতে release”, সাথে হাতে লেখা পঁচিশ ধাপের নির্দেশিকা, আর ভয়। এই মডিউলের (মডিউল ১০) প্রশ্ন এখান থেকে শুরু: কোড থেকে ব্যবহারকারী পর্যন্ত পথটি কীভাবে নিরাপদ, দ্রুত আর মাপা যায় এমন করবেন, আর তার চারপাশের পেশাদার কাজ — estimation, পরিকল্পনা, ঝুঁকি, দলগত কাজ আর নৈতিকতা — কীভাবে সামলাবেন।

শব্দগুলো কাছাকাছি, তাই একবারে পরিষ্কার করে নিই। Continuous integration (CI) মেলানো আর যাচাইয়ের অনুশীলন। Continuous delivery (CD) তার পরের ধাপ: software-কে সবসময় release-যোগ্য অবস্থায় রাখা, যাতে যেকোনো সবুজ version একটি বোতাম চেপে নিরাপদে production-এ পাঠানো যায়। Continuous deployment আরও এক ধাপ: বোতামটিও নেই — pipeline-এর সব ধাপ পার হওয়া প্রতিটি পরিবর্তন নিজে থেকেই production-এ যায়।

Continuous delivery-র কেন্দ্রীয় ফল হলো release on demand: কবে release হবে, সেটি আর প্রযুক্তিগত বাধা নয়, শুধু ব্যবসার সিদ্ধান্ত। ঈদের আগে নতুন অফার আজ বিকেলেই চালু করতে চাইলে করা যায়। এর জন্য লাগে একটি deployment pipeline (অংশ ২), একই artifact-এর environment থেকে environment-এ যাত্রা (অংশ ৩), আর deploy থেকে release আলাদা করার কৌশল (অংশ ৪); তারপর সংস্কৃতি আর মাপ — DevOps, DORA metric আর GitOps (অংশ ৫–৮)।

২ · Deployment pipeline — commit stage থেকে production

Humble ও Farley-র মূল ভাবনা: প্রতিটি commit একটি release candidate, যতক্ষণ না কোনো ধাপ প্রমাণ করে যে সেটি ভালো নয়। Pipeline একটি আস্থার সিঁড়ি। নিচের ধাপগুলো দ্রুত আর সস্তা, ওপরের ধাপগুলো ধীর কিন্তু production-এর কাছাকাছি। একটি ধাপ পার হলে আস্থা বাড়ে; ব্যর্থ হলে পরিবর্তনটি সেখানেই থামে, আর খবর ফেরে লেখকের কাছে। বইয়ে বর্ণিত সাধারণ ধাপগুলো (দলভেদে নাম আর সংখ্যা আলাদা):

• Commit stage: compile, unit test, static analysis — পর্ব ৫৮-এর CI pipeline-এর মতোই, কয়েক মিনিটে। এখানেই artifact (package, container image) একবার তৈরি হয় আর একটি artifact repository-তে জমা পড়ে।
• Acceptance stage: artifact একটি test environment-এ বসিয়ে স্বয়ংক্রিয় acceptance test — ব্যবহারকারীর চোখে কাজ ঠিক হয় কি না (পর্ব ৫১-এ test pyramid).
• Capacity আর অন্যান্য non-functional test: চাপে গতি (performance testing), নিরাপত্তা scan, কখনো দীর্ঘ সময়ের স্থিরতা।
• Manual ধাপ: staging environment-এ exploratory testing বা ব্যবহারকারীর গ্রহণযোগ্যতা যাচাই — যন্ত্র যা ধরতে পারে না, মানুষের চোখ তা দেখে।
• Release: production environment-এ deployment — continuous delivery-তে একটি বোতাম, continuous deployment-এ স্বয়ংক্রিয়।

এবার একটি পরিবর্তনের পুরো যাত্রা দেখুন। কাল্পনিক অনলাইন বাজার অ্যাপ bazar-cart-এর দলে তানভীর নতুন এক-পাতার checkout লিখেছেন, যা একটি feature flag-এর আড়ালে আছে। সময় আর সংখ্যা উদাহরণের জন্য ধরা:

৩ · Build একবার, deploy বহুবার — environment promotion আর config

Pipeline-এর সবচেয়ে গুরুত্বপূর্ণ নিয়মগুলোর একটি: build একবার, deploy বহুবার। Commit stage যে artifact বানায়, সেই হুবহু artifact test, perf, staging আর prod-এ যায় — একে বলে environment promotion. কেন এত জোর? কারণ staging-এ যা test হলো, prod-এ যদি অন্য কিছু চলে, তাহলে test-এর প্রমাণ prod-এর জন্য খাটে না।

আবার build করলে কী বদলাতে পারে? Dependency-র version range (^2.1) আজ ২.১.৩ আর তিন দিন পরে ২.২.০ ধরতে পারে; compiler-এর version বা build-এর তারিখ বদলাতে পারে। Lockfile আর reproducible build ঝুঁকি কমায়, কিন্তু সবচেয়ে সরল প্রতিরক্ষা আবার build-ই না করা। Artifact চেনা হয় তার digest দিয়ে — artifact-এর সব byte-এর hash (container image-এ সাধারণত sha256:…)। দুই environment-এ একই digest মানে হুবহু একই artifact; পর্ব ৫২-এ (Git-এর ভেতরে) Git-এর content-addressed storage-এও এই ধারণাই দেখেছেন।

Config থাকে artifact-এর বাইরে

একই artifact সব environment-এ চললে test আর prod-এর database আলাদা হবে কীভাবে? উত্তর: config artifact-এর অংশ নয়। Database-এর ঠিকানা, flag-এর মান, বাইরের URL আর secret deploy-এর সময় environment থেকে আসে, সাধারণত environment variable বা একটি config service দিয়ে। Heroku-র প্রকৌশলীদের (Adam Wiggins-এর নাম প্রায়ই উল্লেখ হয়) মোটামুটি ২০১১ সালে প্রকাশিত The Twelve-Factor App নির্দেশিকার তৃতীয় নীতি এটিই — config environment-এ রাখুন; আর পঞ্চম নীতি বলে build, release আর run তিনটি ধাপ আলাদা রাখতে। এটি একটি প্রভাবশালী নির্দেশিকা, কোনো আনুষ্ঠানিক মান নয়; সব নীতি সব ধরনের software-এ সমান খাটে না।

একটি সহজ পরীক্ষা: আপনার repository কি এখনই open source করে দেওয়া যায়, কোনো password ফাঁস না করে? উত্তর “না” হলে config বা secret কোডের ভেতরে ঢুকে আছে (secret রাখার নিয়ম পর্ব ৫৭-এ, Git-এ নিরাপত্তা)। Secret-এর মান কখনো Git-এ নয় — একটি secret manager-এ, আর deploy-এর সময় শুধু সেই environment-এর জন্য।

নিচের মডেলে দুটি pipeline. Pipeline A artifact একবার বানিয়ে চারটি environment-এ এগিয়ে দেয়। Pipeline B প্রতিটি environment-এ আবার build করে, আর prod-এর build তিন দিন পরে হওয়ায় একটি library-র নতুন minor version ধরে ফেলে। Hash হিসেবে FNV-1a 32-bit ব্যবহার করা হয়েছে — আসল artifact repository-র SHA-256 digest-এর জায়গায় একটি ছোট বিকল্প:

// Build once, deploy many: the SAME artifact moves dev -> test -> staging -> prod;
// only the config differs. FNV-1a 32-bit stands in for a real SHA-256 digest.
const fnv1a = s => { let h = 0x811c9dc5; for (const ch of s) { h ^= ch.charCodeAt(0);
  h = Math.imul(h, 0x01000193) >>> 0; } return h.toString(16).padStart(8, "0"); };
// A "build" = source + the dependency versions resolved at build time.
const build = (src, resolved) => fnv1a(src + JSON.stringify(resolved));
const SRC = "bazar-cart@a1c9e40";
const CONFIG = {
  dev:     { DB_URL: "db.dev.internal",  NEW_CHECKOUT: "on"  },
  test:    { DB_URL: "db.test.internal", NEW_CHECKOUT: "on"  },
  staging: { DB_URL: "db.stg.internal",  NEW_CHECKOUT: "on"  },
  prod:    { DB_URL: "db.prod.internal", NEW_CHECKOUT: "off" },
};
// Pipeline A: build once, promote the digest.  Pipeline B: rebuild in every environment;
// "^2.1" resolved again on day 4 picks a newer minor release of a library.
const once = build(SRC, { pay: "2.1.3" });
const A = { dev: once, test: once, staging: once, prod: once };
const B = { dev: build(SRC, { pay: "2.1.3" }), test: build(SRC, { pay: "2.1.3" }),
            staging: build(SRC, { pay: "2.1.3" }), prod: build(SRC, { pay: "2.2.0" }) };
function check(name, deployed) {
  const envs = Object.keys(deployed), digests = new Set(Object.values(deployed));
  console.log(`${name}: ` + envs.map(e => `${e}=${deployed[e]}`).join(" "));
  if (digests.size === 1) console.log("  OK: one artifact everywhere; what prod runs was tested");
  else envs.slice(1).forEach((e, i) => { if (deployed[e] !== deployed[envs[i]])
    console.log(`  ANTI-PATTERN: ${e} runs ${deployed[e]}, but ${envs[i]} tested ${deployed[envs[i]]}`); });
  const diff = Object.keys(CONFIG.prod).filter(k => CONFIG.staging[k] !== CONFIG.prod[k]);
  console.log(`  config keys that differ staging->prod: ${diff.join(", ")}`);
}
check("Pipeline A", A);
check("Pipeline B", B);

Pipeline A: dev=611809b3 test=611809b3 staging=611809b3 prod=611809b3
  OK: one artifact everywhere; what prod runs was tested
  config keys that differ staging->prod: DB_URL, NEW_CHECKOUT
Pipeline B: dev=611809b3 test=611809b3 staging=611809b3 prod=460181f7
  ANTI-PATTERN: prod runs 460181f7, but staging tested 611809b3
  config keys that differ staging->prod: DB_URL, NEW_CHECKOUT

৪ · Deploy বনাম release — rollback, roll forward আর release management

অংশ ২-এর stepper-এ সোমবার দুপুরে deploy হলো, কিন্তু release হলো মঙ্গল থেকে বৃহস্পতিবারে। দুটি শব্দ প্রায়ই একসাথে বলা হয়, কিন্তু আলাদা ঘটনা:

• Deploy: নতুন version production-এর যন্ত্রে বসানো আর চালানো — একটি প্রযুক্তিগত ঘটনা।
• Release: ব্যবহারকারীকে নতুন আচরণ দেখানো — একটি ব্যবসার ঘটনা।

দুটি আলাদা করলে deploy নিরাপদ আর একঘেয়ে হয়ে যায়: দিনে পাঁচবার deploy হলেও ব্যবহারকারী কিছুই টের পান না, আর release হয় flag ঘুরিয়ে, ঠিক যখন ব্যবসা চায়। এর প্রধান হাতিয়ার feature flag — trunk-based development-এর সাথে তার ব্যবহার, flag-এর ধরন আর flag-এর debt পর্ব ১৭-এ (Branching strategy) দেখেছেন। আরেকটি কৌশল dark launch: নতুন কোড prod-এ আসল অনুরোধের ওপর চালানো, কিন্তু ফল ব্যবহারকারীকে না দেখানো — শুধু আচরণ আর চাপ মাপা।

Deploy-এর নিজস্ব কৌশলগুলো — blue-green, canary, rolling update, Kubernetes-এর rollout, graceful shutdown, আর database migration-এর expand/contract — System Design কোর্সের Deployment আর release পর্বে বিস্তারিত আছে; এখানে আর পুনরাবৃত্তি করছি না। এই কোর্সের জন্য মূল কথা: কৌশল যা-ই হোক, সবই একই artifact আর একই pipeline-এর ওপর দাঁড়ায়।

সমস্যা হলে — rollback না roll forward?

Production-এ নতুন version-এর পরে error বাড়ল। দুটি পথ:

প্রচলিত পরামর্শ: আগে ব্যবহারকারীর ক্ষতি থামান, তারপর কারণ খুঁজুন — অর্থাৎ নিশ্চিত না হলে rollback বা flag বন্ধ। এটি পর্ব ৫৮-এর “লাল main-এ আগে revert” নিয়মেরই production-রূপ। Git-এর দিক থেকে rollback সাধারণত git revert (পর্ব ১১-এ ভুল শোধরানো) — ইতিহাস না মুছে নতুন commit, যা pipeline দিয়েই prod-এ যায়। আর rollback কাজ করবে কি না, তা আগের প্রস্তুতির ওপর নির্ভর করে: ফেরা যায় এমন migration, হাতের কাছে আগের artifact, আর নিয়মিত মহড়া।

Release management — continuous delivery-তেও দরকার

Release management মানে কোন পরিবর্তন কবে, কাদের কাছে, কোন ঝুঁকি আর ফেরার পরিকল্পনাসহ যাবে, তার সমন্বয়। Continuous delivery এই কাজকে বাদ দেয় না, ছোট করে: পঁচিশ ধাপের হাতের নির্দেশিকার বদলে pipeline-এ লেখা ধাপ, মাসিক release meeting-এর বদলে প্রতিটি পরিবর্তনের ছোট ঝুঁকি-যাচাই। তবু কিছু প্রশ্ন সবসময় থাকে: database migration আছে কি? কোনো public API ভাঙছে কি (তাহলে SemVer-এ MAJOR — পর্ব ১৮-এ ভালো commit, tag আর release)? Release notes কে লিখবেন? ঈদের আগের ভিড়ের সপ্তাহে deploy কমাবেন কি না? যেখানে app store-এর অনুমোদন বা আইনি নিয়ন্ত্রণ আছে, সেখানে continuous deployment সম্ভব না-ও হতে পারে — কিন্তু continuous delivery তখনো সম্ভব।

৫ · DevOps — দেয়াল ভাঙার সংস্কৃতি

ধরুন একটি প্রতিষ্ঠানে দুটি দল। Development-এর লক্ষ্য দ্রুত নতুন feature; operations-এর দায় system চালু রাখা, তাই তাদের লক্ষ্য কম পরিবর্তন। মাঝে একটি দেয়াল: development কোড “দেয়ালের ওপারে ছুড়ে দেয়”, operations রাত তিনটায় ফোন পায়। দুই দলই নিজের লক্ষ্যে ঠিক, কিন্তু প্রতিষ্ঠান মিলে ধীর আর ঝুঁকিপূর্ণ। DevOps এই দেয়াল ভাঙার আন্দোলন।

CALMS — DevOps মাপার পাঁচটি দিক

DevOps-এর কোনো আনুষ্ঠানিক সংজ্ঞা বা মান নেই; একটি প্রচলিত কাঠামো CALMS. প্রচলিত বর্ণনা অনুযায়ী John Willis আর Damon Edwards প্রথমে CAMS বলেন (মোটামুটি ২০১০), পরে Jez Humble Lean-এর L যোগ করেন:

“You build it, you run it”

২০০৬ সালে ACM Queue-এর একটি সাক্ষাৎকারে Amazon-এর CTO Werner Vogels যে কথাটি বলেছিলেন বলে বহুল-উদ্ধৃত, তার সারকথা: you build it, you run it — যে দল service বানায়, সেই দলই production-এ সেটি চালায়। এতে ডেভেলপার নিজের কোডের রাতের আচরণ দেখেন, তাই log আর monitoring-এর দিকে মনোযোগ আপনা-আপনি বাড়ে। খরচও আছে: on-call-এর চাপ আর সব দলে ops-এর দক্ষতার দরকার। তাই অনেক প্রতিষ্ঠান একটি platform দল রাখে, যারা pipeline আর পরিকাঠামো “স্ব-সেবা” হিসেবে দেয়; আর SRE reliability-কে আলাদা প্রকৌশল হিসেবে দেখে। SLO আর error budget দিয়ে গতি আর স্থিতির ভারসাম্য রাখার পদ্ধতি System Design-এর Observability পর্বে।

তিন পথ — The Three Ways

Gene Kim, Kevin Behr ও George Spafford-এর উপন্যাস The Phoenix Project (২০১৩) আর পরে Kim, Humble, Debois ও Willis-এর The DevOps Handbook (২০১৬; দ্বিতীয় সংস্করণ ২০২১) DevOps-কে তিনটি পথে সাজায়:

1. প্রথম পথ — flow: development থেকে production পর্যন্ত কাজ বাঁ থেকে ডানে দ্রুত আর মসৃণ চলুক। ছোট batch, কম WIP, ধাপে ধাপে অপেক্ষা কমানো (পর্ব ৬-এ Kanban আর lean-এর flow আর Little-এর সূত্র)।
2. দ্বিতীয় পথ — feedback: ডান থেকে বাঁয়ে দ্রুত খবর ফিরুক — pipeline-এর লাল, production-এর alert, ব্যবহারকারীর অভিযোগ — যাতে সমস্যা ছোট থাকতেই ধরা পড়ে।
3. তৃতীয় পথ — ধারাবাহিক শেখা আর পরীক্ষা: ব্যর্থতা থেকে দোষারোপহীনভাবে শেখা, ছোট পরীক্ষা চালানো, আর দৈনন্দিন কাজের উন্নতির জন্য সময় রাখা।

৬ · DORA-র চারটি metric — সংজ্ঞা আর হিসাব

“আমাদের delivery কি ভালো হচ্ছে?” — এই প্রশ্নের উত্তর অনুভূতিতে দিলে তর্ক শেষ হয় না। DORA (DevOps Research and Assessment) দল বছরের পর বছর হাজারো পেশাজীবীর জরিপ থেকে চারটি মাপ বেছে নেয়, যেগুলো একসাথে delivery-র গতি আর স্থিতি দেখায়। ফলাফল সংকলিত হয় Nicole Forsgren, Jez Humble ও Gene Kim-এর বই Accelerate (২০১৮)-এ; DORA ২০১৮ সালের শেষে Google-এর অংশ হয়। এই চারটিকে একসাথে বলে DORA metric:

খেয়াল করুন, DORA-র lead time পর্ব ৬-এর Kanban-এর lead time-এর চেয়ে সরু: অনুরোধ আসা থেকে নয়, commit থেকে production পর্যন্ত — অর্থাৎ শুধু delivery-র পথ। শেষ metric-টিকে পুরোনো লেখায় প্রায়ই MTTR বলা হয়। পরের report-গুলোতে নাম আর সংখ্যা কিছু বদলেছে: ২০২১ নাগাদ operational performance-এর জন্য reliability নামে একটি পঞ্চম মাপ যোগ হয়; আর ২০২৩ নাগাদ “time to restore service”-এর বদলে আসে failed deployment recovery time — শুধু deploy-এর কারণে ঘটা ব্যর্থতা থেকে ফেরার সময়। পরে rework rate-এর মতো আরও মাপের কথাও এসেছে বলে আমরা জানি। Performance-এর band (elite, high, medium, low)-এর সীমাও বছরভেদে বদলেছে, আর এগুলো জরিপের গুচ্ছ (cluster) থেকে আসে, আইনি মান নয়। সর্বশেষ সংজ্ঞা DORA-র নিজের প্রকাশনায় দেখে নিন।

Git আর deploy log থেকে কীভাবে মাপবেন

চারটি metric-এর কাঁচামাল দুটি জায়গায়: Git জানে প্রতিটি commit-এর সময়, আর deploy-এর tool জানে কোন commit কখন production-এ গেল। অনেক দল প্রতিটি prod deploy-এ একটি annotated tag বসায় (tag পর্ব ১৮-এ) — তাহলে Git থেকেই দুটি deploy-এর মাঝের commit-গুলো পাওয়া যায়। নিচের transcript একটি scratch repository-তে Git ২.৫৩-এ তৈরি; কাল্পনিক দল, সময় নির্দিষ্ট করে দেওয়া:

$ git tag --list "deploy-*" --format="%(refname:short) %(taggerdate:iso-strict)"
deploy-0041 2026-03-02T17:00:00+06:00
deploy-0042 2026-03-03T16:00:00+06:00
$ git log --reverse --format="%h %cI %s" deploy-0041..deploy-0042
96c783e 2026-03-03T09:10:00+06:00 feat(pay): add cash on delivery
4ec747c 2026-03-03T11:45:00+06:00 test(pay): cover COD limit
97b188e 2026-03-03T14:20:00+06:00 fix(cart): empty cart crash

Change failure rate-এর জন্য দরকার deploy-এর সাথে incident বা rollback-এর যোগসূত্র — incident-এর রেকর্ডে “কোন deploy-এর পরে” লেখা থাকলে সহজ। ফেরার সময়ের জন্য incident খোলা আর বন্ধের সময়। এবার একটি ছোট সপ্তাহের log থেকে হাতে হিসাব করি। কাল্পনিক bazar-cart-এর সাত দিনে ছয়টি deploy:

এবার বড় একটি log — ২৮ দিনের, seeded PRNG দিয়ে তৈরি, যাতে প্রত্যেক পাঠক একই সংখ্যা দেখেন। প্রতিদিন ০ থেকে ৩টি deploy, প্রতিটিতে ১–৩টি commit, যা deploy-এর ১ থেকে ৩১ ঘণ্টা আগে লেখা; প্রতিটি deploy-এর প্রায় ১৫% সম্ভাবনায় সমস্যা, আর ফিরতে ১০ থেকে ১৮০ মিনিট। Band-এর সীমা এখানে দেওয়া মান — মোটামুটি ২০১৯ সালের দিকের report-এর ধাঁচে সরল করা; আসল report-এর সীমা বছরভেদে আলাদা:

// DORA's four key metrics from a SIMULATED 28-day deploy + incident log.
// mulberry32 = small seeded PRNG, so every reader sees the same log.
function mulberry32(a) { return function () { 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(59), H = 3600e3, MIN = 60e3, DAYS = 28;
const deploys = [], incidents = [];
for (let d = 0; d < DAYS; d++) {
  const n = Math.floor(rnd() * 4);                    // 0..3 deploys that day
  for (let k = 0; k < n; k++) {
    const at = d * 24 * H + (10 + 3 * k) * H;         // 10:00, 13:00, 16:00
    const commits = Array.from({ length: 1 + Math.floor(rnd() * 3) },
                               () => at - (1 + rnd() * 30) * H);   // committed 1-31 h earlier
    const failed = rnd() < 0.15;                      // caused a user-facing problem?
    deploys.push({ at, commits, failed });
    if (failed) incidents.push({ minutes: Math.round(10 + rnd() * 170) }); // detect -> restored
  }
}
const median = xs => { const s = [...xs].sort((a, b) => a - b);
  return s[Math.ceil(0.5 * s.length) - 1]; };          // nearest-rank median
const perDay = deploys.length / DAYS;
const leadH = median(deploys.flatMap(dp => dp.commits.map(c => dp.at - c))) / H;
const cfr = deploys.filter(dp => dp.failed).length / deploys.length;
const restoreMin = median(incidents.map(i => i.minutes));
// STATED, simplified bands (roughly the 2019-era report style; reports change them).
const band = (v, cuts, up, other = "low") =>   // up: bigger is better
  (cuts.find(([lim]) => up ? v >= lim : v <= lim) || [0, other])[1];
console.log(`deploys: ${deploys.length} in ${DAYS} days, commits: ${deploys.reduce((a, d) => a + d.commits.length, 0)}`);
console.log(`deployment frequency: ${perDay.toFixed(2)}/day -> ${band(perDay, [[1, "elite"], [1 / 7, "high"], [1 / 30, "medium"]], true)}`);
console.log(`lead time for changes (median): ${leadH.toFixed(1)} h -> ${band(leadH, [[24, "elite"], [168, "high"], [720, "medium"]])}`);
console.log(`change failure rate: ${(100 * cfr).toFixed(1)}% -> ${band(cfr, [[0.15, "0-15% band"]], false, "above 15%")}`);
console.log(`time to restore (median): ${restoreMin} min over ${incidents.length} incidents -> ${band(restoreMin, [[60, "elite"], [1440, "high"], [10080, "medium"]])}`);

deploys: 35 in 28 days, commits: 68
deployment frequency: 1.25/day -> elite
lead time for changes (median): 15.9 h -> elite
change failure rate: 25.7% -> above 15%
time to restore (median): 63 min over 9 incidents -> high

৭ · ছোট batch, কম অপেক্ষা — আর metric-এর অপব্যবহার

DORA-র একটি প্রধান দাবি — Accelerate-এর ভাষায় — গতি আর স্থিতি পরস্পরবিরোধী নয়: জরিপে যে দলগুলো বেশি ঘন ঘন deploy করে, তাদের change failure rate-ও গড়ে কম। কেন হতে পারে? একটি বড় কারণ batch-এর আকার। সপ্তাহে একবার deploy মানে প্রতিটি deploy-এ এক সপ্তাহের সব পরিবর্তন — ভাঙলে কোনটির জন্য, খুঁজতে সময় লাগে, আর rollback-এ ভালো পরিবর্তনগুলোও ফিরে যায়। আর অপেক্ষা: সোমবারের commit বৃহস্পতিবারের deploy-এর জন্য বসে থাকে। ঈদের আগে বাসের টিকিটের কাউন্টারের কথা ভাবুন — সপ্তাহে একদিন কাউন্টার খুললে সবাই সেদিন লাইনে, আর কেউ রবিবারে এলেও বৃহস্পতিবার পর্যন্ত অপেক্ষা।

নিচের Python program একই ৪০টি commit (দুই সপ্তাহ, রবি থেকে বৃহস্পতি, প্রতিদিন ১০, ১২, ২ আর ৪টায়) তিনটি নিয়মে deploy করে: সপ্তাহে একবার বৃহস্পতিবার বিকেল ৫টায়, প্রতিদিন বিকেল ৫টায়, আর প্রতিটি commit-এর পরে (৪০ মিনিটের pipeline). প্রতিটি commit-এর lead time = তার পরের প্রথম deploy − commit:

# Lead time for changes under three deploy policies, same commits.
# Commits: 4 per working day (Sun-Thu) at 10:00, 12:00, 14:00, 16:00 for 2 weeks.
from datetime import datetime, timedelta
from math import ceil

start = datetime(2026, 3, 1)                       # a Sunday
commits = [start + timedelta(days=d, hours=h)
           for d in range(14) if (start + timedelta(days=d)).weekday() not in (4, 5)
           for h in (10, 12, 14, 16)]              # Friday(4), Saturday(5) off

def deploy_times(policy):
    if policy == "weekly (Thu 17:00)":
        return [start + timedelta(days=d, hours=17) for d in (4, 11)]
    if policy == "daily (17:00)":
        return sorted({c.replace(hour=17) for c in commits})
    return [c + timedelta(minutes=40) for c in commits]   # every commit, 40-min pipeline

def pct(xs, p):                                    # nearest-rank percentile
    s = sorted(xs)
    return s[ceil(p / 100 * len(s)) - 1]

print(f"{len(commits)} commits")
for policy in ("weekly (Thu 17:00)", "daily (17:00)", "every change (+40 min)"):
    deps = deploy_times(policy)
    lead = [(min(t for t in deps if t >= c) - c).total_seconds() / 3600 for c in commits]
    batch = len(commits) / len(deps)
    print(f"{policy:24} deploys={len(deps):2} batch={batch:4.1f} "
          f"median={pct(lead, 50):6.1f} h  p90={pct(lead, 90):6.1f} h  max={max(lead):6.1f} h")

40 commits
weekly (Thu 17:00)       deploys= 2 batch=20.0 median=  51.0 h  p90=  99.0 h  max= 103.0 h
daily (17:00)            deploys=10 batch= 4.0 median=   3.0 h  p90=   7.0 h  max=   7.0 h
every change (+40 min)   deploys=40 batch= 1.0 median=   0.7 h  p90=   0.7 h  max=   0.7 h

যখন metric লক্ষ্য হয়ে যায়

পর্ব ৬-এ Goodhart-এর সূত্র দেখেছেন: কোনো মাপ লক্ষ্য হলে মানুষ মাপটিকেই সাজায়, ব্যবস্থাকে নয়। DORA metric এর ব্যতিক্রম নয়। কয়েকটি পরিচিত বিকৃতি:

• ফাঁপা deploy: deploy frequency-র লক্ষ্য পূরণে খালি বা শুধু comment-বদলের deploy. সংখ্যা বাড়ে, ব্যবহারকারী কিছু পান না।
• Failure-এর সংজ্ঞা সরু করা: “এটি config-এর ভুল, deploy-এর নয়” বা “মাত্র দশ মিনিট, incident নয়” — change failure rate কমে কাগজে।
• ঘড়ি দেরিতে চালু: lead time-এর শুরু commit থেকে নয়, PR approve থেকে — অপেক্ষার সবচেয়ে বড় অংশ চোখের আড়ালে।
• Incident তাড়াতাড়ি বন্ধ: দ্রুত “resolved” চিহ্ন দিয়ে পরে নতুন ticket — ফেরার সময় সুন্দর দেখায়।
• দল বা ব্যক্তির তুলনা আর পুরস্কার: ভিন্ন ঝুঁকির দলকে এক মাপে সাজানো, ব্যক্তির deploy গোনা। DORA-র নিজের নির্দেশনাও metric-কে দলের নিজের উন্নতির জন্য ব্যবহারের কথা বলে, র‍্যাংকিংয়ের জন্য নয়।

প্রতিরক্ষা: চারটি metric জোড়ায় দেখুন (গতির পাশে স্থিতি), সংজ্ঞা লিখে স্থির রাখুন, নিজের প্রবণতার সাথে তুলনা করুন, আর সংখ্যার পাশে গল্প রাখুন — postmortem, ব্যবহারকারীর অভিযোগ, দলের ক্লান্তি। আর মনে রাখুন, DORA-র ফলাফল জরিপভিত্তিক সম্পর্ক (correlation); প্রতিটি দলে কারণ-ফল নিশ্চিত নয়।

৮ · Infrastructure as code আর GitOps — কাঙ্ক্ষিত অবস্থা Git-এ

Artifact একই, config আলাদা — কিন্তু যে server, network আর database-এ সেগুলো চলে, সেগুলো কে বানায়? পুরোনো পথে একজন admin হাতে server সাজান। ছয় মাস পরে কেউ জানেন না staging আর prod ঠিক কোথায় আলাদা; কেউ হাতে একটি setting বদলেছিলেন, যা কোথাও লেখা নেই — একে বলে configuration drift.

Infrastructure as code (IaC) এর উত্তর: পরিকাঠামোর বর্ণনা file-এ লিখুন, file রাখুন Git-এ, আর tool সেই বর্ণনা থেকে পরিকাঠামো বানাক। তাহলে পরিকাঠামোর পরিবর্তনও PR-এ review হয়, history থাকে, আর একই file থেকে নতুন environment মিনিটে তৈরি হয়। Tool-এর উদাহরণ (লেখার সময়ে প্রচলিত): Terraform বা OpenTofu, Ansible, Puppet, Chef. বেশিরভাগ tool declarative: আপনি লেখেন কী চাই (“এই image-এর ৩টি copy”), tool ঠিক করে কীভাবে — রান্নার ধাপ নয়, প্লেটে কী থাকবে তার ছবি।

GitOps এই ভাবনাকে আরেক ধাপ নেয়। শব্দটি ২০১৭ সালে Weaveworks প্রতিষ্ঠানের (Alexis Richardson-এর লেখায়) জনপ্রিয় হয় বলে প্রচলিত; পরে CNCF-এর OpenGitOps প্রকল্প চারটি নীতি লেখে (মোটামুটি এই অর্থে): system-এর desired state declarative ভাবে বর্ণিত; সেই বর্ণনা version-সহ অপরিবর্তনীয় ভাবে রাখা (সাধারণত Git); একটি agent নিজে থেকে সেটি টেনে নেয় (pull); আর agent অবিরাম আসল অবস্থাকে বর্ণনার সাথে মিলিয়ে রাখে। শেষ নীতিটির নাম reconciliation loop — ঘরের থার্মোস্ট্যাটের মতো: আপনি তাপমাত্রা ঠিক করে দেন, যন্ত্র বারবার মাপে আর পার্থক্য দেখলে চালু-বন্ধ করে। Kubernetes-এর মতো system-এ Argo CD বা Flux-এর মতো tool এই agent-এর কাজ করে (Kubernetes-এর মূল ধারণা System Design-এর Deployment আর release পর্বে)।

নিচের খেলনা reconciler একটি loop-এ desired আর actual মেলায়: যা Git-এ আছে কিন্তু চলছে না, তা create; যা আলাদা, তা update; আর যা চলছে কিন্তু Git-এ নেই — prune বন্ধ থাকলে শুধু সতর্কবার্তা, চালু থাকলে delete. শুরুতে দুটি drift আছে: কেউ হাতে worker-কে ৫টি copy-তে বাড়িয়েছেন, আর একটি debug service হাতে বানিয়েছেন:

// A toy GitOps reconciler: desired state (read from Git) vs actual state (the cluster).
// Each loop: diff -> actions -> apply. Running it again must change nothing (converged).
const desired = {                                   // what the main branch of the config repo says
  web:    { image: "bazar-cart:1.8.0", replicas: 3 },
  worker: { image: "bazar-jobs:2.4.1", replicas: 2 },
  redis:  { image: "redis:7.4",        replicas: 1 },
};
const actual = {                                    // what is really running
  web:    { image: "bazar-cart:1.7.2", replicas: 3 },
  worker: { image: "bazar-jobs:2.4.1", replicas: 5 },   // someone scaled it by hand
  debug:  { image: "busybox:1.36",     replicas: 1 },   // created by hand, not in Git
};
function diff(want, have, prune) {
  const acts = [];
  for (const [n, spec] of Object.entries(want)) {
    if (!(n in have)) { acts.push(["create", n, spec]); continue; }
    const changed = Object.keys(spec).filter(k => spec[k] !== have[n][k]);
    if (changed.length) acts.push(["update", n, spec,
      changed.map(k => `${k} ${have[n][k]} -> ${spec[k]}`).join(", ")]);
  }
  for (const n of Object.keys(have))
    if (!(n in want)) acts.push(prune ? ["delete", n] : ["warn-extra", n]);
  return acts;
}
function reconcile(loop, prune) {
  const acts = diff(desired, actual, prune);
  console.log(`loop ${loop}: ${acts.length ? acts.length + " action(s)" : "in sync, nothing to do"}`);
  for (const [op, n, spec, why] of acts) {
    console.log(`  ${op.padEnd(10)} ${n}${why ? "  (" + why + ")" : ""}`);
    if (op === "create" || op === "update") actual[n] = { ...spec };
    if (op === "delete") delete actual[n];
  }
}
reconcile(1, false);   // prune off: extra objects are only reported
reconcile(2, true); reconcile(3, true);   // prune on: not-in-Git is removed; then converged

loop 1: 4 action(s)
  update     web  (image bazar-cart:1.7.2 -> bazar-cart:1.8.0)
  update     worker  (replicas 5 -> 2)
  create     redis
  warn-extra debug
loop 2: 1 action(s)
  delete     debug
loop 3: in sync, nothing to do

৯ · DevSecOps — নিরাপত্তা শুরু থেকেই

পুরোনো ধারায় নিরাপত্তা-পর্যালোচনা হতো release-এর ঠিক আগে, একটি আলাদা দলের হাতে — তখন বড় সমস্যা পেলে হয় release পেছায়, নয় ঝুঁকি নিয়ে যায়। DevSecOps নিরাপত্তাকে pipeline-এর প্রতিটি ধাপে আর দলের সবার দায়িত্বে আনে — shift left-এর ভাবনা, যা testing-এর ক্ষেত্রে পর্ব ৪৫-৫১-এ দেখেছেন। মূল চর্চাগুলো এই কোর্সে ইতিমধ্যে এসেছে, আর এখানে শুধু জায়গামতো বসাই:

• Commit-এর আগে আর commit stage-এ: secret scanning, signed commit (পর্ব ৫৭-এ Git-এ নিরাপত্তা), static analysis আর dependency-র দুর্বলতার scan (পর্ব ৫৮-এ Continuous integration).
• Artifact-এ: artifact কোন source আর কোন build থেকে এল তার প্রমাণ (provenance), dependency-র তালিকা (SBOM), আর digest-এ সই — software supply chain-এর প্রতিরক্ষা। SLSA-র মতো কাঠামো এই স্তরগুলো সাজায়; বিস্তারিত দ্রুত বদলাচ্ছে, তাই লেখার সময়ের documentation দেখুন।
• Deploy-এ: ন্যূনতম অনুমতি — deploy-এর credential শুধু pipeline বা GitOps agent-এর কাছে, ডেভেলপারের ল্যাপটপে নয়; prod-এ পরিবর্তন শুধু pipeline দিয়ে।
• Production-এ: নিরাপত্তার ঘটনার log আর alert, আর ঘটনা ঘটলে incident response-এর আগে থেকে ঠিক করা ধাপ।

নিরাপত্তা দল এখানে “না” বলার দরজা নয়, সহজ নিরাপদ পথ বানিয়ে দেওয়া সহকর্মী। বিপর্যয়ের প্রস্তুতি — backup, RPO-RTO, failover — System Design-এর Failover আর disaster recovery পর্বে।

১০ · AI-এর যুগে — delivery-র পরামর্শে AI-কে যাচাই

AI কয়েক সেকেন্ডে pipeline, deploy script আর Terraform file দেয়; কিন্তু এখানকার ভুল ধরা পড়ে production-এ — সবচেয়ে দামি জায়গায়। চেনা ভুলগুলো:

AI-এর পরামর্শ — চেকলিস্ট

• প্রতিটি command আর flag tool-এর official documentation বা git help <command>-এ মিলিয়েছি
• Prod-এ যাওয়া artifact-এর digest আর staging-এ test হওয়া digest একই
• কোনো secret কোডে, config repository-তে বা prompt-এ নেই
• Rollback-এর ধাপ লেখা আছে, আর একবার মহড়া দিয়ে দেখেছি; migration-এর কথা ভাবা হয়েছে
• Destructive command (reset --hard, push --force, -auto-approve) আগে একটি throwaway clone বা test environment-এ চালিয়েছি
• উদ্ধৃত প্রতিটি DORA সংখ্যার report আর বছর খুঁজে পেয়েছি
• কপি করা script-এর উৎস আর licence দেখেছি