डिप्लॉयमेंट वेरिफ़िकेशन टेस्टिंग

डिप्लॉयमेंट वेरिफ़िकेशन में क्या आता है

डिप्लॉयमेंट सिर्फ़ कोड नहीं बदलता। यह container images, कॉन्फ़िगरेशन, secrets, डेटाबेस schema, इन्फ़्रास्ट्रक्चर और routing बदलता है, अक्सर एक ही क़दम में। डिप्लॉयमेंट वेरिफ़िकेशन इन सबके नतीजे को एक साथ, लक्षित एनवायरनमेंट में, इस सवाल के साथ जाँचता है: क्या नया वर्ज़न चल रहा है, सही कॉन्फ़िगर है, पहुँच में है, और कम से कम पिछले वर्ज़न जितना अच्छा व्यवहार कर रहा है?

डिप्लॉय करने और रिलीज़ करने को अलग समझना मदद करता है। डिप्लॉय करना नया कोड सर्वर पर रखना है; रिलीज़ करना नया व्यवहार यूज़र के सामने लाना है। Canary रिलीज़, blue-green switching और feature flags जैसी तकनीकें इन दोनों को अलग करने के लिए ही हैं, ताकि टीम रिलीज़ से पहले बहुत कम या बिना यूज़र एक्सपोज़र के डिप्लॉयमेंट वेरिफ़ाई कर सके। Smoke सूट वही है जो smoke, sanity और regression टेस्टिंग गाइड में बताया गया है, अब अभी-अभी डिप्लॉय हुए एनवायरनमेंट की ओर।

• वर्ज़न जाँच — एनवायरनमेंट हर instance पर वही वर्ज़न दे रहा है जो डिप्लॉय होना था।
• Health और निर्भरताएँ — सर्विसें चालू हैं और अपने डेटाबेस, queues, caches और third parties तक पहुँच सकती हैं।
• अहम रास्ते — लॉगिन, मुख्य बिज़नेस ट्रांज़ैक्शन और उसका API सही जवाब देते हैं।
• कॉन्फ़िगरेशन और सुरक्षा — सही URLs, certificates, redirects और security headers; कोई debug mode नहीं।
• असली ट्रैफ़िक में व्यवहार — errors, latency और बिज़नेस मेट्रिक्स पिछले वर्ज़न के बराबर।

डिप्लॉय से पहले सफलता और rollback मानदंड तय करें

डिप्लॉयमेंट वेरिफ़िकेशन का सबसे अहम हिस्सा डिप्लॉयमेंट से पहले होता है: यह लिखना कि "अच्छा" कैसा दिखता है और क्या rollback को ट्रिगर करेगा। इंसिडेंट के दौरान तय मानदंड दबाव में तय होते हैं, जो भी जागा हो उसके द्वारा, "पाँच मिनट और देते हैं" की ओर गहरे झुकाव के साथ। पहले से तय मानदंड rollback को बहस के बजाय एक रूटीन क़दम बना देते हैं।

प्लान एक पेज में आ जाता है। इसमें rollout के क़दम, on-call लोग, सफलता परिभाषित करने वाले सिग्नल और thresholds, वे शर्तें जिन पर टीम बिना चर्चा rollback करती है, rollback कैसे होगा और उसे कैसे वेरिफ़ाई किया जाएगा — ये सब होते हैं। नीचे का उदाहरण canary के रूप में डिप्लॉय होने वाली सर्विस का है; thresholds उदाहरण के लिए हैं, आपके अपने thresholds सर्विस की सामान्य बेसलाइन से आने चाहिए।

• Rollout और तैयारी: canary 5%, फिर 25%, फिर 100%, हर क़दम 15 मिनट; डिप्लॉय के समय flag new_checkout बंद; release engineer और on-call टेस्टर के नाम release ticket में; डिप्लॉय से पहले backup की पुष्टि और migration 0042 सिर्फ़ additive (expand क़दम)। Post-deploy smoke पहले canary पर, फिर production URL पर चलता है।
• सफलता के सिग्नल, हर क़दम पर बेसलाइन की तुलना में: HTTP 5xx rate बेसलाइन से 0.5 percentage points से ज़्यादा नहीं; p95 latency बेसलाइन के 1.2 गुने से ज़्यादा नहीं; checkout conversion उसी समय-खिड़की की बेसलाइन के 10% के भीतर; लॉग में कोई नया error signature नहीं।
• Rollback मानदंड — इनमें से कोई एक भी हो तो बिना बहस rollback: canary या production पर smoke फ़ेलियर; लगातार 5 मिनट तक 5xx rate 2% से ऊपर; payment failures बेसलाइन के दोगुने से ज़्यादा; data integrity alert (duplicate या ग़ायब ऑर्डर)।
• Rollback और पूर्णता: image 5.8.3 फिर से डिप्लॉय, new_checkout बंद ही रहे, और migration 0042 रखी जाए क्योंकि वह additive है; rollback तब वेरिफ़ाई माना जाए जब smoke.sh पास हो और /version हर instance पर 5.8.3 बताए। Rollout तभी पूरा है जब 100% ट्रैफ़िक पर एक घंटे तक सभी सिग्नल हरे रहें।

Release verification plan: orders-service 5.9.0 (example)
Deployment:   canary 5% -> 25% -> 100%, 15 min per step; flag new_checkout OFF at deploy
People:       release engineer + tester on call (named in the release ticket)
Before:       backup confirmed; migration 0042 is additive only (expand step)

Post-deploy smoke:  smoke.sh against the canary, then against the production URL

Success signals, canary compared with baseline, at every step:
  - HTTP 5xx rate           <= baseline + 0.5 percentage points
  - p95 latency             <= baseline x 1.2
  - checkout conversion     within 10% of baseline (same window)
  - no new error signatures in the logs

Rollback criteria (any one => roll back, no debate):
  - smoke failure on canary or production
  - 5xx rate above 2% for 5 consecutive minutes
  - payment failures above baseline x 2
  - data integrity alert (duplicate or missing orders)

Rollback method:    redeploy image 5.8.3; new_checkout stays OFF; migration 0042 is kept (additive)
Rollback verified:  smoke.sh passes and /version reports 5.8.3 on every instance
Done when:          100% of traffic for 1 hour with all signals green

Post-deployment smoke टेस्ट

Smoke सूट को डिप्लॉयमेंट job के आख़िरी क़दम के रूप में, अभी-अभी डिप्लॉय हुए एनवायरनमेंट पर चलाएँ, और उसके फ़ेल होने पर pipeline फ़ेल करें। इसे छोटा (कुछ मिनट), ऐसे टेस्ट डेटा से स्वतंत्र जो प्रोडक्शन में शायद न हो, और प्रोडक्शन पर चलाने के लिए सुरक्षित रखें: read-only calls, या ऐसे समर्पित test account से writes जिसका डेटा रिपोर्ट और billing से बाहर रखा जाता हो। नकारात्मक व्यवहार भी जाँचें — जो protected endpoint अचानक token के बिना 200 लौटाए, वह डिप्लॉयमेंट दोष है।

नीचे की स्क्रिप्ट सबसे सरल उपयोगी रूप का उदाहरण है: स्पष्ट अपेक्षित status codes के साथ HTTP जाँचें और एक वर्ज़न जाँच। ज़्यादातर टीमें बाद में यही जाँचें अपने API या UI टेस्ट framework में ले जाती हैं ताकि नतीजे बाक़ी टेस्ट के समान रिपोर्ट फ़ॉर्मेट में प्रकाशित हों।

• हो सके तो हर instance या region को hit करें, सिर्फ़ load balancer को नहीं — एक पुराना instance partial-deployment का क्लासिक दोष है।
• कम से कम एक जाँच में caches को bypass करें; CDN स्वस्थ दिखने वाला cached पेज दे सकता है जबकि origin errors लौटा रहा हो।
• Health endpoint को अर्थपूर्ण बनाएँ: यह निर्भरताओं की स्थिति बताए, सिर्फ़ इसलिए 200 न लौटाए कि process ज़िंदा है।
• इन्फ़्रास्ट्रक्चर बदलावों के बाद security headers, TLS और redirects जाँचें; ये कोड के बाहर कॉन्फ़िगर होते हैं और आसानी से छूट जाते हैं।

#!/usr/bin/env bash
# Example post-deployment smoke script. Usage: ./smoke.sh https://staging.example.com
set -euo pipefail
BASE_URL="$1"
EXPECTED_VERSION="${EXPECTED_VERSION:-}"

check() {  # name, path, expected HTTP status
  local name="$1" path="$2" expected="$3" status
  status=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$BASE_URL$path" || true)
  if [ "$status" != "$expected" ]; then
    echo "FAIL $name: $path returned $status, expected $expected"
    exit 1
  fi
  echo "ok   $name ($status)"
}

check "health"            "/health"                200
check "home page"         "/"                      200
check "product API"       "/api/v1/products/1001"  200
check "auth still needed" "/api/v1/orders"         401

# Only if the service exposes its version
if [ -n "$EXPECTED_VERSION" ]; then
  deployed=$(curl -s --max-time 10 "$BASE_URL/version" || true)
  if [ "$deployed" != "$EXPECTED_VERSION" ]; then
    echo "FAIL version: got $deployed, expected $EXPECTED_VERSION"
    exit 1
  fi
  echo "ok   version ($deployed)"
fi

आज़माएँ: API हेल्थ चेकर आज़माएँ: API एंडपॉइंट टेस्टर आज़माएँ: सिक्योरिटी हेडर एनालाइज़र आज़माएँ: रीडायरेक्ट चेकर

डिप्लॉयमेंट के बाद synthetic checks

Smoke टेस्ट एक बार चलता है; synthetic monitoring चलती रहती है। Synthetic checks scripted ट्रांज़ैक्शन हैं — होम पेज लोड करना, monitoring account से लॉगिन, सर्च, कार्ट में जोड़ना, कोई मुख्य API कॉल करना — जो सिस्टम के बाहर से शेड्यूल पर, हर कुछ मिनट में चलते हैं, और फ़ेलियर या धीमेपन पर alert देते हैं। ये वे समस्याएँ पकड़ते हैं जो डिप्लॉयमेंट के कुछ समय बाद दिखती हैं: memory leak, expire होता certificate, cache तोड़ने वाला scheduled job, या अपना व्यवहार बदल चुका third party।

Synthetic checks को टेस्ट की तरह मानें: उन्हें version control में रखें, हर फ़ीचर बदलाव के साथ उनकी समीक्षा करें, उन्हें समर्पित test accounts और डेटा दें, और सुनिश्चित करें कि फ़ेलियर किसी व्यक्ति तक पहुँचे। हफ़्ते भर से चुपचाप फ़ेल होता synthetic check न होने से बुरा है, क्योंकि यह कवरेज का भ्रम पैदा करता है। शेड्यूल को cron expression में लिखें तो उस पर भरोसा करने से पहले उसे और उसके अगले run times को जाँच लें।

आज़माएँ: Cron एक्सप्रेशन जनरेटर आज़माएँ: Cron एक्सप्रेशन एक्सप्लेनर आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

Canary रिलीज़, blue-green और feature flags

Progressive delivery बदलाव को ट्रैफ़िक के बढ़ते हिस्से के सामने लाती है, हर क़दम पर एक जाँच के साथ। Canary रिलीज़ में नया वर्ज़न पहले ट्रैफ़िक का छोटा हिस्सा पाता है — कुछ प्रतिशत, या आंतरिक यूज़र — और हिस्सा बढ़ाने से पहले उसके व्यवहार की तुलना पुराना वर्ज़न चला रही बेसलाइन से की जाती है। Google की SRE workbook canarying को canary आबादी की control आबादी से तुलना के रूप में बताती है, और टेस्टर के लिए यही मुख्य बात है: समान की तुलना समान से करें, उसी समय-खिड़की में, canary की तुलना कल के पूरे fleet से नहीं।

Blue-green डिप्लॉयमेंट दो एक जैसे एनवायरनमेंट रखता है; नया वर्ज़न ख़ाली वाले में डिप्लॉय होता है, वहाँ smoke सूट से वेरिफ़ाई होता है, और ट्रैफ़िक उस पर switch किया जाता है, जबकि पुराना एनवायरनमेंट तुरंत वापस switch के लिए तैयार रहता है। Feature flags कोड के भीतर रिलीज़ को डिप्लॉयमेंट से अलग करते हैं: नया व्यवहार बंद अवस्था में ship होता है, आंतरिक यूज़र के लिए चालू होता है, फिर ग्राहकों के एक प्रतिशत के लिए, और बिना redeploy के बंद किया जा सकता है।

• Flag की दोनों अवस्थाएँ टेस्ट करें, और किसी flow के बीच में मौजूद यूज़र के लिए उनके बीच का बदलाव भी (flag बंद रहते बना कार्ट, flag चालू होने पर checkout)।
• Targeting वेरिफ़ाई करें: flag ठीक उन्हीं यूज़र, regions या प्रतिशत के लिए चालू है जिनके लिए इरादा था, और बाक़ी सबके लिए बंद।
• कोई असली ट्रैफ़िक पहुँचने से पहले smoke सूट सीधे canary या ख़ाली एनवायरनमेंट पर चलाएँ।
• Rollout के दौरान दोनों वर्ज़न compatible रखें: APIs, message formats और डेटाबेस schema को पुराने और नए कोड दोनों के साथ एक साथ काम करना चाहिए।
• पूरी रिलीज़ के बाद flags हटाएँ; लंबे समय तक रहने वाले flags टेस्ट करने लायक combinations को कई गुना कर देते हैं।

आज़माएँ: API रिस्पॉन्स कम्पेरेटर

देखने लायक monitoring सिग्नल

Rollout के दौरान और बाद में वेरिफ़िकेशन टेस्ट नतीजों के बजाय प्रोडक्शन सिग्नलों पर टिकता है। Google SRE book के चार golden signals एक समझदार न्यूनतम हैं: latency, traffic, errors और saturation। बिज़नेस सिग्नल भी जोड़ें, क्योंकि कई डिप्लॉयमेंट दोष कोई error पैदा ही नहीं करते — ऑर्डर बस रुक जाते हैं, या totals ग़लत होते हैं। हर सिग्नल की तुलना उसी अवधि की बेसलाइन से करें और डिप्लॉयमेंट के समय से मेल खाते अचानक बदलाव खोजें।

• Errors — HTTP 5xx rate, फ़ेल jobs, client-side JavaScript errors, ऐसे नए error messages जो डिप्लॉयमेंट से पहले नहीं थे।
• Latency — मुख्य endpoints का p95 और p99, सिर्फ़ औसत नहीं; धीमे सफल requests भी regression हैं।
• Traffic — अचानक गिरावट का मतलब हो सकता है कि यूज़र किसी फ़ीचर तक नहीं पहुँच पा रहे; अचानक उछाल retry storms का संकेत हो सकता है।
• Saturation — CPU, memory, connection pools, queue depth; धीमा leak साफ़ smoke टेस्ट के घंटों बाद यहीं दिखता है।
• बिज़नेस — sign-ups, logins, checkouts, payments, भेजे गए messages, पिछले दिनों के उसी घंटे की तुलना में।
• समय के साथ delivery की सेहत — change fail rate और failed deployment recovery time, जो DORA मेट्रिक्स में से दो हैं, दिखाते हैं कि कई रिलीज़ में डिप्लॉयमेंट वेरिफ़िकेशन और rollback काम कर रहे हैं या नहीं।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

Rollback और रिलीज़ वैलिडेशन

Rollback ख़ुद एक डिप्लॉयमेंट है और उसे भी उसी तरह वेरिफ़ाई करना चाहिए: smoke सूट फिर चलाएँ और पुष्टि करें कि version endpoint हर instance पर पिछला वर्ज़न बता रहा है। इन्फ़्रास्ट्रक्चर या डेटा बदलने वाली किसी भी रिलीज़ के लिए staging पर rollback का अभ्यास करें, और उसका समय मापें — एक घंटे का rollback उस दोष के लिए सुरक्षा-जाल नहीं है जो हर मिनट पैसे का नुक़सान करता है। कभी-कभी forward fix rollback से तेज़ और सुरक्षित होता है; कौन-सा लागू होगा यह प्लान में तय करें, इंसिडेंट के दौरान नहीं।

डेटाबेस migrations ही सबसे ज़्यादा rollback को कठिन बनाती हैं। जैसे ही कोई migration कॉलम हटाती है, टेबल का नाम बदलती है या डेटा दोबारा लिखती है, कोड का पिछला वर्ज़न नए schema पर शायद चल न सके, और migration उलटने से डिप्लॉयमेंट के बाद लिखा डेटा खो सकता है। आम बचाव expand-and-contract तरीक़ा है: पहले नई संरचनाएँ backward-compatible ढंग से जोड़ें, ऐसा कोड डिप्लॉय करें जो दोनों के साथ काम करे, डेटा migrate करें, और पुरानी संरचनाएँ सिर्फ़ किसी बाद की रिलीज़ में हटाएँ। Migrations की टेस्टिंग — प्रोडक्शन आकार की कॉपी पर, नए schema पर पुराने कोड के साथ, locks और अवधि मापते हुए — डेटाबेस transactions और migrations टेस्टिंग गाइड में कवर है।

• डिप्लॉयमेंट से पहले लिखे rollback मानदंड, संख्यात्मक thresholds और नामित निर्णय-मालिक के साथ।
• Rollback प्रक्रिया का अभ्यास और समय-माप; पिछले वर्ज़न का artifact अब भी उपलब्ध।
• रिलीज़ के साथ migration जाने पर हर बार नए schema पर पुराना कोड टेस्ट।
• विनाशकारी migration क़दम (drop, rename, type change) उस कोड के बाद की रिलीज़ में ship हों जिसने उनका इस्तेमाल बंद किया।
• Rollback को उसी smoke सूट और version जाँच से वेरिफ़ाई करें जो डिप्लॉयमेंट के लिए थी।

आम डिप्लॉयमेंट दोष

• 5.9.0 डिप्लॉय करने के बाद छह में से दो instances पर प्रोडक्शन 5.8.3 लौटाता है (partial rollout)।
• डेटाबेस connection pool ख़त्म होने पर भी health endpoint 200 लौटाता है।
• Origin के 502 लौटाते हुए भी smoke टेस्ट cached CDN पेज पर पास हो जाता है।
• Gateway कॉन्फ़िगरेशन बदलाव के बाद GET /api/v1/orders बिना token के 200 लौटाता है।
• नए load balancer पर Strict-Transport-Security header ग़ायब है।
• Saved cards वाले यूज़र के लिए POST /orders पर canary बेसलाइन से तीन गुना 5xx rate दिखाता है।
• 5% के लिए चालू flag new_checkout लॉग-आउट विज़िटर्स को भी नया flow दिखाता है।
• 5.8.3 पर rollback फ़ेल: पुराना कोड नए status PENDING_REVIEW वाले ऑर्डर नहीं पढ़ पाता।
• Synthetic login check छह दिन से फ़ेल क्योंकि उसके test account का पासवर्ड expire हो गया।

डिप्लॉयमेंट वेरिफ़िकेशन चेकलिस्ट

• वेरिफ़िकेशन प्लान लिखा हुआ: rollout क़दम, सफलता सिग्नल, rollback मानदंड, owners।
• Migrations की backward compatibility के लिए समीक्षा; नए schema पर पुराना कोड टेस्ट।
• Post-deployment smoke सूट अपने-आप चलता है और फ़ेल होने पर pipeline फ़ेल करता है।
• हर instance या region पर वर्ज़न की पुष्टि।
• इन्फ़्रास्ट्रक्चर बदलावों के बाद security headers, TLS और redirects की जाँच।
• असली ट्रैफ़िक से पहले canary या ख़ाली एनवायरनमेंट वेरिफ़ाई; हर क़दम पर बेसलाइन से तुलना।
• Feature flags दोनों अवस्थाओं में और सही targeting के लिए टेस्ट।
• Golden signals और बिज़नेस सिग्नल तय अवधि तक देखे गए।
• Rollback का अभ्यास, समय-माप और उसी smoke सूट से वेरिफ़िकेशन।
• Synthetic checks नए व्यवहार के लिए अपडेट और किसी असली व्यक्ति को alert करते हुए।

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly Mediaबदलाव को पहले ट्रैफ़िक के छोटे हिस्से पर रिलीज़ करना और पूरी तरह फैलाने से पहले baseline से तुलना करना — SRE में deployment verification।
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
• DORA's software delivery performance metricsDORA (Google Cloud)DORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
• Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।
• Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।