TypeScript के साथ Canary Deployments: प्रोडक्शन को तोड़ने के डर के बिना निर्बाध रिलीज़

परिचय: आप अब भी "Deploy" बटन दबाने से क्यों डरते हैं?

आपने कोड लिखा। लोकल मशीन पर जाँच की। टेस्ट पास हो गए। सब कुछ परफेक्ट है। आप मनचाहा Deploy बटन दबाते हैं... और 5 मिनट बाद देखते हैं कि 500 एरर आ रही है, और उपयोगकर्ता घबराकर सपोर्ट में लिख रहे हैं। परिचित लगता है?

पारंपरिक डिप्लॉय रणनीतियाँ (blue-green, rolling update) अच्छी हैं, लेकिन उनमें एक कमी है: वे या तो सारा नया कोड एक साथ शामिल करती हैं, या बिल्कुल नहीं। क्या होगा अगर आप केवल 1% उपयोगकर्ताओं को एक नई सुविधा भेज सकें, मेट्रिक्स देख सकें, और फिर स्थिरता सुनिश्चित करने के बाद ही इसे 100% तक बढ़ा सकें?

ठीक इसी तरह canary deployments (कैनरी रिलीज़) काम करते हैं। यह नाम पुरानी खनिक प्रथा से आया है - खदान में गैस रिसाव का पता लगाने के लिए अपने साथ कैनरी पक्षी ले जाना। अगर पक्षी चुप हो जाता था - खनिक जान जाते थे: ऊपर भागने का समय आ गया है। IT की दुनिया में "कैनरी" उपयोगकर्ताओं का एक छोटा समूह है, जिस पर नए कोड का परीक्षण किया जाता है। अगर सब कुछ ठीक है - रिलीज़ आगे बढ़ती है। अगर नहीं - आप "hotfix" कहने से भी तेज़ी से रोलबैक करते हैं।

इस लेख में हम TypeScript पर एक पूर्ण canary deployment सिस्टम लिखेंगे। आप सीखेंगे कि ट्रैफ़िक बैलेंसिंग कैसे सेट करें, CI/CD के माध्यम से प्रक्रिया को कैसे स्वचालित करें, और अपनी कैनरी के "स्वास्थ्य" की निगरानी कैसे करें। चलिए शुरू करते हैं!

Canary Deployment क्या है और इसकी आवश्यकता क्यों है?

Canary deployment नए कोड को रोल आउट करने की एक रणनीति है, जिसमें एप्लिकेशन का अपडेटेड वर्जन पहले उपयोगकर्ताओं के एक छोटे प्रतिशत (आमतौर पर 1-10%) को भेजा जाता है। बाकी लोग पुराने, स्थिर वर्जन पर काम करते रहते हैं। अगर नए वर्जन में कोई समस्या नहीं आती (एरर, प्रदर्शन में गिरावट, latency में वृद्धि), तो आप धीरे-धीरे उस पर ट्रैफ़िक का प्रतिशत बढ़ाते हैं, जब तक कि वह पुराने वर्जन को पूरी तरह से बदल नहीं देता।

मुख्य लाभ:

\n
• जोखिमों को कम करना — बग केवल दर्शकों के एक छोटे हिस्से को प्रभावित करते हैं।
\n
• त्वरित रोलबैक — ट्रैफ़िक को वापस स्थिर वर्जन पर रीडायरेक्ट करना पर्याप्त है।
\n
• वास्तविक परिस्थितियों में A/B परीक्षण — पुराने और नए वर्जन के मेट्रिक्स की तुलना कर सकते हैं।
• सुचारू रोलआउट — आप अचानक लोड बढ़ने से सर्वर को नहीं मारते।

अब सिद्धांत से व्यवहार की ओर बढ़ते हैं। हम एक ऐसी प्रणाली बनाएंगे जो तीन भागों से मिलकर बनी है:

\n
1. TypeScript (Express.js) पर बैकएंड।
2. Nginx पर ट्रैफ़िक बैलेंसर।
3. GitHub Actions के माध्यम से ऑटोमेशन।

चरण 1. वर्जनिंग सपोर्ट के साथ TypeScript में एप्लिकेशन लिखना

शुरुआत में एक सरल Express एप्लिकेशन बनाते हैं जो दो मोड में काम कर सके: stable और canary। अंतर केवल रूट एंडपॉइंट के रिस्पॉन्स में होगा, लेकिन वास्तविक प्रोजेक्ट में यह कोई भी नई सुविधा हो सकती है।

// src/app.ts\nimport express, { Request, Response } from 'express';\nimport dotenv from 'dotenv';\n\ndotenv.config();\n\nconst app = express();\nconst PORT = process.env.PORT || 3000;\nconst VERSION = process.env.VERSION || 'stable'; // 'stable' या 'canary'\n\napp.get('/', (req: Request, res: Response) => {\n  res.json({\n    message: 'Hello from API!',\n    version: VERSION,\n    timestamp: new Date().toISOString(),\n  });\n});\n\n// health check के लिए एंडपॉइंट\napp.get('/health', (req: Request, res: Response) => {\n  res.status(200).send('OK');\n});\n\napp.listen(PORT, () => {\n  console.log(`Server running on port ${PORT} in ${VERSION} mode`);\n});\n

अब एप्लिकेशन को कंटेनर में पैकेज करने के लिए Dockerfile बनाते हैं। इससे डिप्लॉय और बैलेंसिंग सरल हो जाएगी।

# Dockerfile\nFROM node:18-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci\nCOPY . .\nRUN npm run build\n\nFROM node:18-alpine AS runner\nWORK