मुझे समझाइए कि जो सर्विस दिन में कई बार डिप्लॉय होती है, उसके लिए आप CI/CD पाइपलाइन कैसे डिज़ाइन करेंगे।

हर commit एक ही पाइपलाइन चलाता है जो एक immutable artifact बनाती है, उसे टेस्ट करती है, और वही artifact एक के बाद एक एनवायरनमेंट में प्रमोट होता है; हर एनवायरनमेंट के लिए दोबारा build नहीं होता। तेज़ फीडबैक वाले stages पहले रखें, यानी lint, unit tests और build, ताकि गड़बड़ी मिनटों में सामने आ जाए, integration और security scans समानांतर चलाएं, फिर staging पर अपने आप डिप्लॉय करें और प्रोडक्शन पर progressive rollout के पीछे, जिसमें ऑटोमैटिक rollback लगा हो।

मूल सिद्धांत यही है कि एक बार build करो और वही artifact प्रमोट करो। commit होते ही पाइपलाइन commit sha से टैग की गई container image बनाती है, और आखिर में प्रोडक्शन में वही digest चलता है, तो रास्ते के बीच अलग dependencies के साथ कुछ दोबारा build नहीं होता। stage का क्रम फीडबैक टाइम से तय होता है: पहले lint और unit tests, ताकि खराब बदलाव लगभग दो मिनट में फेल हो जाए, फिर image build, फिर integration tests, contract tests और security scanning समानांतर, क्योंकि इनमें से कोई किसी पर निर्भर नहीं है। main में merge होते ही staging पर अपने आप डिप्लॉय होता है और smoke tests चलते हैं। प्रोडक्शन वही पाइपलाइन है, बस progressive rollout के साथ, यानी पहले दस प्रतिशत ट्रैफिक, और उतनी देर हम error rate और latency को baseline से तोलते हैं, और सीमा टूटी तो ऑटोमैटिक rollback। पाइपलाइन की परिभाषा मैं कोड वाली रिपॉज़िटरी में ही रखता हूं ताकि उसका रिव्यू बाकी चीज़ों जैसा हो, और खुद पाइपलाइन पर दो नंबर ट्रैक करता हूं: एक बदलाव को प्रोडक्शन तक पहुंचने में कितना समय लगता है, और main के कितने प्रतिशत builds हरे रहते हैं।