मार्गदर्शिका

पुल रिक्वेस्ट मर्ज करने से पहले कोड गुणवत्ता (बिल्ड, टेस्ट, कवरेज) लागू करें।

→टारगेट ब्रांच पर, एक बिल्ड वैलिडेशन पॉलिसी कॉन्फ़िगर करें जो PR बनने पर एक पाइपलाइन ट्रिगर करती है। पाइपलाइन को कोड कवरेज परिणाम प्रकाशित करने होंगे। न्यूनतम कवरेज के लिए एक ब्रांच पॉलिसी सेट करें।

क्यों: यह मर्ज से पहले गुणवत्ता लागू करता है। एक मानक CI ट्रिगर मर्ज के बाद चलता है। रिलीज़ गेट परिनियोजन के लिए होते हैं, PR के लिए नहीं।

एक Git ब्रांचिंग रणनीति का चयन करें जो मर्ज विरोधों को कम करती है और प्रोडक्शन में तीव्र, निरंतर डिप्लॉयमेंट का समर्थन करती है।

→शॉर्ट-लाइव फीचर ब्रांच के साथ ट्रंक-आधारित विकास लागू करें जो अक्सर (दैनिक या अधिक) `main` में मर्ज होते हैं।

क्यों: ब्रांचों को महत्वपूर्ण रूप से अलग होने से रोकता है, मर्ज विरोधों को कम करता है और सुनिश्चित करता है कि `main` ब्रांच हमेशा रिलीज़ करने योग्य स्थिति के करीब हो।

मर्ज से पहले कोड समीक्षाओं, सफल बिल्ड और कार्य आइटम लिंकिंग को लागू करके एक महत्वपूर्ण ब्रांच (जैसे, `main`) को सुरक्षित रखें।

→Azure Repos में `main` ब्रांच पर ब्रांच पॉलिसी कॉन्फ़िगर करें। न्यूनतम समीक्षकों, बिल्ड वैलिडेशन और कार्य आइटम लिंकिंग के लिए नीतियों को सक्षम करें।

क्यों: ब्रांच पॉलिसी सर्वर-साइड प्रवर्तन प्रदान करती हैं जिन्हें डेवलपर्स द्वारा बाईपास नहीं किया जा सकता है, जिससे लगातार गुणवत्ता और प्रक्रिया अनुपालन सुनिश्चित होता है।

एक टीम के लिए एक Git ब्रांचिंग रणनीति का चयन करें जिसमें निर्धारित रिलीज़, पैरेलल फीचर डेवलपमेंट और समर्पित हॉटफिक्स ब्रांच की आवश्यकता हो।

→GitFlow ब्रांचिंग मॉडल लागू करें, जो `main`, `develop`, `feature/*`, `release/*`, और `hotfix/*` ब्रांच का उपयोग करता है।

क्यों: GitFlow जटिल रिलीज़ चक्रों को प्रबंधित करने, नए विकास को रिलीज़ स्थिरीकरण और आपातकालीन सुधारों से अलग करने के लिए एक मजबूत ढांचा प्रदान करता है।

एक रहस्य गलती से कमिट और पुश हो गया था। इसे Git हिस्ट्री से पूरी तरह से हटाना होगा।

→सबसे पहले, उजागर रहस्य को घुमाएं। फिर, इतिहास को फिर से लिखने के लिए `git-filter-repo` या BFG Repo-Cleaner जैसे टूल का उपयोग करें, फ़ाइल को हटा दें। परिवर्तनों को फोर्स-पुश करें और सभी डेवलपर्स को री-क्लोन करने के लिए सूचित करें।

क्यों: एक साधारण `git rm` या रिवर्ट इतिहास से रहस्य को नहीं हटाता है। स्थायी शुद्धिकरण के लिए इतिहास को फिर से लिखना आवश्यक है।

पैरेलल स्टेज और स्टेज के बीच निर्भरता के साथ एक जटिल वर्कफ़्लो मॉडल करें।

→YAML मल्टी-स्टेज पाइपलाइन का उपयोग करें। स्टेज निर्भरता के लिए `dependsOn` कीवर्ड का उपयोग करें और स्टेज के भीतर पैरेलल जॉब कॉन्फ़िगर करें।

क्यों: YAML जटिल ऑर्केस्ट्रेशन के लिए सबसे लचीला, कोड-आधारित दृष्टिकोण प्रदान करता है, जो क्लासिक पाइपलाइन या अलग-अलग पाइपलाइन को चेन करने से बेहतर है।

तत्काल रोलबैक क्षमता के साथ एक वेब ऐप के लिए शून्य-डाउनटाइम, कम-जोखिम वाला परिनियोजन लागू करें।

→Azure App Service डिप्लॉयमेंट स्लॉट का उपयोग करें। एक स्टेजिंग (ग्रीन) स्लॉट में डिप्लॉय करें, वैलिडेट करें, फिर प्रोडक्शन (ब्लू) के साथ स्लॉट स्वैप करें।

क्यों: एक स्लॉट स्वैप एक एटॉमिक, लगभग-तत्काल ऑपरेशन है जो ट्रैफ़िक को रीडायरेक्ट करता है। रोलबैक उतना ही सरल है जितना वापस स्वैप करना।

संदर्भ↗

कई माइक्रोसर्विस के लिए पाइपलाइन डुप्लिकेशन को कम करें जो सामान्य बिल्ड/डिप्लॉय चरणों को साझा करते हैं लेकिन विशिष्ट अनुकूलन की आवश्यकता होती है।

→एक केंद्रीय रिपॉजिटरी में YAML टेम्पलेट बनाएं। प्रत्येक सेवा-विशिष्ट पाइपलाइन में, `extends` कीवर्ड का उपयोग करें और अनुकूलन के लिए पैरामीटर पास करें।

क्यों: `extends` DRY सिद्धांतों को बढ़ावा देता है और मानकों को लागू करता है जबकि पैरामीटर के माध्यम से लचीलापन की अनुमति देता है। पूरी पाइपलाइन संरचनाओं के लिए टास्क ग्रुप से अधिक शक्तिशाली।

एक पाइपलाइन स्टेज (जैसे, प्रोडक्शन डिप्लॉयमेंट) को केवल एक विशिष्ट ब्रांच (जैसे, main) में मर्ज होने पर ही चलने के लिए प्रतिबंधित करें।

→स्टेज या जॉब पर एक `condition` का उपयोग करें। जैसे, `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`।

क्यों: PR वैलिडेशन बिल्ड एक अलग स्रोत ब्रांच संदर्भ (जैसे, `refs/pull/...`) का उपयोग करते हैं, इसलिए यह शर्त PR जीवनचक्र के दौरान डिप्लॉयमेंट को सही ढंग से रोकती है।

कॉर्पोरेट फ़ायरवॉल के पीछे Azure DevOps से ऑन-प्रिमाइसेस सर्वर पर एप्लिकेशन डिप्लॉय करें।

→ऑन-प्रिमाइसेस सर्वर पर self-hosted agents इंस्टॉल करें। उन्हें Azure DevOps में एक एजेंट पूल में रजिस्टर करें।

क्यों: Self-hosted agents Azure DevOps के लिए आउटबाउंड संचार शुरू करते हैं, इसलिए किसी इनबाउंड फ़ायरवॉल नियमों की आवश्यकता नहीं होती है। वे डिप्लॉयमेंट के लिए स्थानीय नेटवर्क संसाधनों तक पहुंच सकते हैं।

प्रोडक्शन डिप्लॉयमेंट के लिए कई व्यक्तियों की स्वीकृति की आवश्यकता होती है और उन्हें विशिष्ट रखरखाव विंडो तक सीमित करें।

→प्रोडक्शन के लिए एक Azure DevOps Environment परिभाषित करें। आवश्यक अनुमोदकों के साथ अनुमोदन कॉन्फ़िगर करें। समय विंडो लागू करने के लिए एक गेट के रूप में "Business Hours" चेक जोड़ें।

क्यों: एन्वायरनमेंट डिप्लॉयमेंट नियंत्रणों को केंद्रीकृत करते हैं। अनुमोदन और गेट एक स्टेज के चलने से पहले मजबूत, स्वचालित नीति प्रवर्तन प्रदान करते हैं।

एप्लिकेशन को रीडिप्लॉय किए बिना उपयोगकर्ताओं के लिए फीचर एक्सपोजर को नियंत्रित करें, जिसमें लगभग-वास्तविक-समय अपडेट हों।

→फीचर प्रबंधन के लिए Azure App Configuration का उपयोग करें। फ़्लैग्स को पढ़ने और इसकी डायनामिक रिफ्रेश क्षमताओं को सक्षम करने के लिए एप्लिकेशन को इंस्ट्रूमेंट करें।

क्यों: फ़ीचर रिलीज़ को डिप्लॉयमेंट से अलग करता है। App Configuration डायनामिक अपडेट के लिए एक केंद्रीकृत UI और SDK प्रदान करता है, जिससे एप्लिकेशन रीस्टार्ट से बचा जा सकता है।

Kubernetes क्लस्टर स्थिति को घोषणात्मक रूप से प्रबंधित करें, जहां Git सत्य का एकमात्र स्रोत है और परिवर्तन स्वचालित रूप से लागू होते हैं।

→AKS क्लस्टर में Flux या ArgoCD जैसे GitOps एजेंट को डिप्लॉय करें। एजेंट को Kubernetes मैनिफेस्ट वाली एक Git रिपॉजिटरी की निगरानी करने और क्लस्टर स्थिति को स्वचालित रूप से सिंक्रनाइज़ करने के लिए कॉन्फ़िगर करें।

क्यों: यह पुल-आधारित मॉडल निरंतर समाधान और ड्रिफ्ट डिटेक्शन को सक्षम बनाता है, जो GitOps का मूल है। यह पुश-आधारित `kubectl` पाइपलाइन की तुलना में अधिक मजबूत है।

टीम सहयोग के लिए Terraform स्टेट को प्रबंधित करें, सुरक्षा सुनिश्चित करें और समवर्ती संशोधनों को रोकें।

→Terraform बैकएंड को Azure Storage Account का उपयोग करने के लिए कॉन्फ़िगर करें। यह रिमोट स्टेट स्टोरेज प्रदान करता है, जिसमें Azure Blob lease के माध्यम से स्टेट लॉकिंग को हैंडल किया जाता है।

क्यों: समवर्ती `apply` ऑपरेशनों से स्टेट फ़ाइल करप्शन को रोकता है और संवेदनशील स्टेट डेटा को सोर्स कंट्रोल से बाहर रखता है।

संदर्भ↗

एक मोनोरेपो में, किसी एप्लिकेशन की CI पाइपलाइन को तभी ट्रिगर करें जब उसकी विशिष्ट डायरेक्टरी (या एक साझा डायरेक्टरी) में फाइलें बदल दी जाएं।

→पाइपलाइन के YAML में, संबंधित डायरेक्टरी निर्दिष्ट करने के लिए `trigger.paths.include` फ़िल्टर का उपयोग करें, जैसे, `include: ['/apps/frontend/**', '/apps/shared/**']`।

क्यों: यह असंबंधित कोड परिवर्तनों के लिए अनावश्यक बिल्ड से बचाता है, CI समय और कंप्यूट संसाधनों की बचत करता है।

तेज़ प्रतिक्रिया के लिए तेज़ (यूनिट) और धीमी (एकीकरण) दोनों परीक्षणों के साथ एक परीक्षण स्टेज को ऑप्टिमाइज़ करें।

→एक ही स्टेज के भीतर पैरेलल जॉब में यूनिट टेस्ट और इंटीग्रेशन टेस्ट चलाएं।

क्यों: पैरेलल निष्पादन यूनिट टेस्ट परिणाम बहुत तेज़ी से प्रदान करता है जबकि धीमी परीक्षण समवर्ती रूप से चलते हैं। कुल स्टेज की अवधि सबसे लंबी जॉब द्वारा निर्धारित होती है, योग से नहीं।

परिवर्तनों (ब्रेकिंग, फीचर, फिक्स) के प्रभाव को स्पष्ट रूप से संवाद करने के लिए कमिट हिस्ट्री के आधार पर एक लाइब्रेरी पैकेज को स्वचालित रूप से संस्करणित करें।

→CI पाइपलाइन में GitVersion जैसे टूल को एकीकृत करें। यह कमिट संदेशों, ब्रांचों और टैग्स का विश्लेषण करके स्वचालित रूप से एक SemVer (Major.Minor.Patch) संस्करण की गणना करता है।

क्यों: SemVer सार्थक संस्करण प्रदान करता है जिस पर उपभोक्ता निर्भरता प्रबंधन के लिए भरोसा कर सकते हैं, बिल्ड नंबर या कमिट हैश के विपरीत।

एक एप्लिकेशन को एक-एक करके कई भौगोलिक क्षेत्रों में डिप्लॉय करें, प्रत्येक क्षेत्रीय डिप्लॉयमेंट के बाद सत्यापन के साथ।

→क्रम को लागू करने के लिए `dependsOn` का उपयोग करके अनुक्रमिक चरणों के साथ एक मल्टी-स्टेज YAML पाइपलाइन का उपयोग करें, प्रत्येक क्षेत्र के लिए एक। सत्यापन के लिए चरणों के बीच पर्यावरण गेट्स का उपयोग करें।

क्यों: यह रिंग-आधारित डिप्लॉयमेंट मॉडल एक खराब डिप्लॉयमेंट के विस्फोट त्रिज्या को एक ही क्षेत्र तक सीमित करता है, जिससे सभी उपयोगकर्ताओं को प्रभावित करने से पहले रोलबैक की अनुमति मिलती है।

एक पाइपलाइन को ट्रंक-आधारित विकास मॉडल का समर्थन करने के लिए कॉन्फ़िगर करें, यह सुनिश्चित करते हुए कि मुख्य ब्रांच हमेशा डिप्लॉय करने योग्य हो।

→`main` ब्रांच पर एक CI ट्रिगर कॉन्फ़िगर करें। एक बिल्ड वैलिडेशन पॉलिसी के साथ PR लागू करें जो तेज़, व्यापक परीक्षण चलाता है। बिल्ड ब्रेक के लिए त्वरित नोटिफिकेशन (जैसे, Teams/Slack पर) को एकीकृत करें।

क्यों: ट्रंक-आधारित विकास में तत्काल प्रतिक्रिया महत्वपूर्ण है। यह संयोजन टूटे हुए कोड को मर्ज होने से रोकता है और मुद्दों के होने पर त्वरित समाधान सुनिश्चित करता है।

पाइपलाइन चरणों के बीच बड़ी कलाकृतियों (जैसे, ML मॉडल, >5GB) को कुशलता से पास करें।

→उत्पादक स्टेज में Azure Blob Storage पर बड़ी कलाकृति अपलोड करें। उपभोक्ता स्टेज को आउटपुट वेरिएबल के रूप में Blob URI पास करें।

क्यों: Azure Blob Storage मल्टी-गीगाबाइट फ़ाइलों के लिए अंतर्निहित पाइपलाइन कलाकृतियों की तुलना में अधिक लागत प्रभावी और प्रदर्शनकारी है।

प्रत्येक रन पर निर्भरता (जैसे, NuGet, npm) को फिर से डाउनलोड करने से बचकर बिल्ड समय कम करें।

→`Cache@2` टास्क का उपयोग करें। पैकेज लॉक फ़ाइल (जैसे, `packages.lock.json`) के आधार पर एक कुंजी परिभाषित करें। टास्क निर्भरता फ़ोल्डर को स्टोर और पुनर्स्थापित करेगा।

क्यों: बाहरी रिपॉजिटरी से लाने के बजाय एक तेज़, स्थानीय कैश से पुनर्स्थापित करके प्रति बिल्ड कई मिनट बचा सकता है।

एक ही कोड को समानांतर में कई लक्ष्यों (जैसे, विभिन्न OS, क्षेत्रों) के खिलाफ बनाएं या डिप्लॉय करें।

→YAML पाइपलाइन जॉब में `strategy: matrix` का उपयोग करें। प्रत्येक संयोजन के लिए वेरिएबल परिभाषित करें, जो प्रत्येक मैट्रिक्स एंट्री के लिए एक जॉब उत्पन्न करेगा।

क्यों: एक मैट्रिक्स रणनीति पाइपलाइन परिभाषा को DRY रखती है, एक ही परिभाषा से कई जॉब भिन्नताएं बनाती है और उन्हें समानांतर में चलाती है।

AKS पर एक कैनरी डिप्लॉयमेंट लागू करें जो स्वचालित रूप से ट्रैफ़िक को शिफ्ट करता है और वास्तविक समय के मेट्रिक्स के आधार पर बढ़ावा देता है या रोलबैक करता है।

→एक सर्विस मेश (जैसे, Istio) और एक मेट्रिक्स प्रोवाइडर (जैसे, Prometheus) के साथ एकीकृत Flagger जैसे प्रगतिशील डिलीवरी कंट्रोलर का उपयोग करें।

क्यों: Flagger पूरी कैनरी विश्लेषण प्रक्रिया को स्वचालित करता है, मैनुअल स्क्रिप्ट की तुलना में सुरक्षित और अधिक विश्वसनीय प्रगतिशील डिलीवरी प्रदान करता है।

एक एप्लिकेशन पाइपलाइन को तब ट्रिगर करने की आवश्यकता होती है जब उसके अपने रिपॉजिटरी में या एक अलग, साझा लाइब्रेरी रिपॉजिटरी में कोड बदलता है।

→एप्लिकेशन के YAML में, `resources.repositories` के तहत साझा लाइब्रेरी को परिभाषित करें और उस संसाधन पर एक `trigger` ब्लॉक कॉन्फ़िगर करें।

क्यों: रिपॉजिटरी के बीच एक घोषणात्मक निर्भरता बनाता है, यह सुनिश्चित करता है कि एप्लिकेशन हमेशा नवीनतम साझा घटकों के साथ फिर से बनाया गया है।

एक पाइपलाइन को परीक्षण के लिए अस्थायी इन्फ्रास्ट्रक्चर बनाने और यह सुनिश्चित करने की आवश्यकता है कि परीक्षण विफल होने पर भी इसे बाद में नष्ट कर दिया जाए।

→IaC (Terraform/Bicep) के लिए अलग-अलग अप्लाई और डिस्ट्रॉय स्टेज के साथ एक मल्टी-स्टेज पाइपलाइन का उपयोग करें। `condition: always()` के साथ डिस्ट्रॉय स्टेज को कॉन्फ़िगर करें।

क्यों: `always()` कंडीशन यह गारंटी देती है कि पिछली स्टेज की सफलता या विफलता की परवाह किए बिना क्लीनअप स्टेज चलता है, जिससे अनाथ संसाधनों को रोका जा सके।

किसी ITSM टूल जैसे ServiceNow में अनुमोदित परिवर्तन अनुरोध के बिना प्रोडक्शन डिप्लॉयमेंट को आगे बढ़ने से रोकें।

→"Query ServiceNow" गेट को इनवोक करने के लिए एक पर्यावरण गेट कॉन्फ़िगर करें ताकि परिवर्तन अनुरोध की स्थिति की जांच की जा सके।

क्यों: एंटरप्राइज़ परिवर्तन प्रबंधन प्रक्रियाओं के साथ एकीकरण को स्वचालित करता है, मैन्युअल हैंड-ऑफ के बिना अनुपालन सुनिश्चित करता है।

सेल्फ-होस्टेड बिल्ड एजेंटों का एक पूल प्रदान करें जो कतार समय को कम करने और लागतों को नियंत्रित करने के लिए मांग के साथ गतिशील रूप से स्केल करता है।

→Azure Virtual Machine Scale Set (VMSS) का उपयोग करके एक Azure DevOps एजेंट पूल कॉन्फ़िगर करें, जिसे लंबित जॉब की संख्या के आधार पर स्वचालित रूप से स्केल करने के लिए सेट किया गया है।

क्यों: VMSS एजेंट सेल्फ-होस्टेड एजेंटों के अनुकूलन को क्लाउड-होस्टेड एजेंटों की लोच के साथ जोड़ते हैं, प्रदर्शन और लागत को अनुकूलित करते हैं।

डेटाबेस स्कीमा परिवर्तनों को इस तरह से डिप्लॉय करें जो डेटा हानि को रोकता है और रोलबैक का समर्थन करता है।

→एक माइग्रेशन टूल (जैसे, Flyway, DbUp) का उपयोग करें। बैकवर्ड कम्पैटिबिलिटी बनाए रखने के लिए स्कीमा परिवर्तनों के लिए एक्सपैंड/कॉन्ट्रैक्ट पैटर्न लागू करें।

क्यों: माइग्रेशन टूल संस्करण और नियंत्रण प्रदान करते हैं। एक्सपैंड/कॉन्ट्रैक्ट पैटर्न एप्लिकेशन और डेटाबेस रोलबैक को अलग करता है, जिससे सुरक्षित डिप्लॉयमेंट सक्षम होते हैं।

सेल्फ-होस्टेड एजेंट संचित बिल्ड कलाकृतियों से डिस्क स्थान से बाहर चल रहे हैं।

→पाइपलाइन YAML में, जॉब स्तर पर, `workspace: clean: all` कॉन्फ़िगर करें।

क्यों: यह निवारक पाइपलाइन कॉन्फ़िगरेशन मैन्युअल हस्तक्षेप या निरंतर इन्फ्रास्ट्रक्चर परिवर्तनों की आवश्यकता के बिना मूल कारण को हल करता है।

इंटीग्रेशन परीक्षणों के लिए प्रत्येक पाइपलाइन रन के लिए एक पृथक डेटाबेस इंस्टेंस की आवश्यकता होती है।

→पाइपलाइन YAML में एक कंटेनर संसाधन (जैसे, SQL Server, Postgres) को एक सेवा के रूप में परिभाषित करें। परीक्षण जॉब तब इस अल्पकालिक सेवा से कनेक्ट हो सकता है।

क्यों: परीक्षणों के लिए तेज़, पृथक, और स्वचालित रूप से साफ की गई निर्भरताएँ प्रदान करता है, जिससे परीक्षण हस्तक्षेप को रोका जा सकता है और सेटअप को सरल बनाया जा सकता है।

सार्वजनिक रिपॉजिटरी (जैसे, npmjs, nuget.org) से पैकेज पुनर्स्थापना की विश्वसनीयता और प्रदर्शन में सुधार करें।

→Azure Artifacts में, एक फ़ीड बनाएं और सार्वजनिक रिपॉजिटरी की ओर इशारा करते हुए अपस्ट्रीम स्रोत कॉन्फ़िगर करें। ग्राहकों को Azure Artifacts फ़ीड से पैकेज का उपभोग करने दें।

क्यों: फ़ीड अपस्ट्रीम स्रोतों से पैकेज को कैश करता है, सार्वजनिक रिपॉजिटरी आउटेज से बचाता है और अक्सर उपयोग किए जाने वाले पैकेजों के लिए पुनर्स्थापना में तेजी लाता है।

विभिन्न कॉन्फ़िगरेशन मानों के साथ कई एन्वायरनमेंट (देव, प्रॉड) में एक Helm चार्ट डिप्लॉय करें।

→प्रत्येक एन्वायरनमेंट के लिए अलग-अलग `values-<env>.yaml` फ़ाइलों का उपयोग करें। `HelmDeploy` टास्क में, उपयुक्त फ़ाइल निर्दिष्ट करने के लिए `valueFile` इनपुट का उपयोग करें और इमेज टैग जैसे डायनामिक मानों को इंजेक्ट करने के लिए `overrideValues` का उपयोग करें।

क्यों: यह पैटर्न स्थिर पर्यावरण कॉन्फ़िगरेशन को डायनामिक पाइपलाइन वेरिएबल से अलग करता है, जिससे डिप्लॉयमेंट साफ और रखरखाव योग्य रहते हैं।

पाइपलाइन में बिना हार्डकोडिंग के सुरक्षित रूप से रहस्य (जैसे, कनेक्शन स्ट्रिंग) का प्रबंधन और उपभोग करें।

→Azure Key Vault में रहस्य स्टोर करें। Azure DevOps में, Key Vault से जुड़ा एक Variable Group बनाएं। पाइपलाइन में वेरिएबल ग्रुप से रहस्यों का संदर्भ लें।

क्यों: रहस्य प्रबंधन को केंद्रीकृत करता है, पाइपलाइन परिवर्तनों के बिना रोटेशन को सक्षम बनाता है, और Key Vault के माध्यम से मजबूत एक्सेस कंट्रोल और ऑडिटिंग प्रदान करता है।

एप्लिकेशन कोड (SAST) और थर्ड-पार्टी डिपेंडेंसी (SCA) में कमजोरियों का पता लगाने के लिए CI पाइपलाइन में सुरक्षा स्कैनिंग लागू करें।

→Microsoft Security DevOps एक्सटेंशन को एकीकृत करें, जिसमें कई स्कैनर शामिल हैं। एक देशी, व्यापक सूट के लिए Azure DevOps के लिए GitHub Advanced Security पर भी विचार करें।

क्यों: यह "शिफ्ट-लेफ्ट" दृष्टिकोण विकास जीवनचक्र में शुरुआती कमजोरियों की पहचान करता है, जिससे लागत और जोखिम कम होता है।

प्रत्यक्ष परिवर्तनों को रोकने के लिए प्रोडक्शन एन्वायरनमेंट तक डेवलपर पहुंच को प्रतिबंधित करें, जबकि अभी भी ऑडिटेड आपातकालीन पहुंच की अनुमति हो।

→स्थायी योगदानकर्ता/मालिक भूमिकाओं को हटा दें। डिप्लॉयमेंट के लिए पाइपलाइन सर्विस कनेक्शन का उपयोग करें। आपात स्थितियों के लिए, Just-In-Time (JIT) एलिवेटेड एक्सेस के लिए Azure AD Privileged Identity Management (PIM) का उपयोग करें।

क्यों: PIM समय-बाध्य, अनुमोदन-गेटेड, और पूरी तरह से ऑडिटेड एलिवेटेड एक्सेस प्रदान करता है, जो कम से कम विशेषाधिकार के सिद्धांत का पालन करता है।

AKS में माइक्रोसर्विस को सुरक्षित रूप से रहस्य प्रदान करें, स्वचालित रोटेशन और वर्कलोड-विशिष्ट पहुंच के साथ।

→AKS के लिए Secrets Store CSI Driver के साथ एकीकृत Azure Key Vault का उपयोग करें। Key Vault को प्रमाणित करने के लिए पॉड के लिए वर्कलोड आइडेंटिटी का उपयोग करें।

क्यों: Kubernetes Secrets से बचते हुए Key Vault से सीधे पॉड में रहस्य माउंट करता है। पॉड-स्तरीय पहचान और सहज रहस्य रोटेशन को सक्षम बनाता है।

संदर्भ↗

यह लागू करें कि केवल स्कैन की गई और हस्ताक्षरित कंटेनर छवियों को ही एक प्रोडक्शन Kubernetes क्लस्टर में डिप्लॉय किया जा सकता है।

→इमेज साइनिंग के लिए Azure Container Registry (ACR) कंटेंट ट्रस्ट का उपयोग करें। स्कैनिंग के लिए Microsoft Defender for Containers का उपयोग करें। AKS पर नीतियों को लागू करने के लिए Kubernetes के लिए Azure Policy का उपयोग करें।

क्यों: बिल्ड से रनटाइम तक कंटेनर इमेज सुरक्षा के लिए एक व्यापक, नीति-संचालित, डीप-डिफेंस रणनीति प्रदान करता है।

क्लाइंट रहस्य या प्रमाणपत्रों का उपयोग किए बिना Azure Pipelines को Azure संसाधनों से कनेक्ट करें।

→"Workload Identity Federation" का उपयोग करके एक Azure Resource Manager सर्विस कनेक्शन बनाएं।

क्यों: रहस्यों को प्रबंधित और घुमाने की आवश्यकता को समाप्त करता है, जिससे CI/CD सिस्टम की सुरक्षा स्थिति में सुधार होता है।

ग्राहकों के Azure सदस्यता में अपने Azure DevOps संगठन से बिना रहस्य का आदान-प्रदान किए डिप्लॉय करें।

→ग्राहक के Azure एन्वायरनमेंट के भीतर एक सेल्फ-होस्टेड एजेंट डिप्लॉय करें। एजेंट के VM/VMSS को एक Managed Identity असाइन करें और उसे आवश्यक RBAC भूमिकाएं प्रदान करें।

क्यों: सभी प्रमाणीकरण सिद्धांतों को ग्राहक के टेनेंट के भीतर रखता है, एक शून्य-ट्रस्ट मॉडल का पालन करता है। कोई रहस्य टेनेंट सीमाओं को पार नहीं करते हैं।

एक बड़े उत्पाद पर कई टीमों के लिए काम का प्रबंधन करें, टीम स्वायत्तता की अनुमति देते हुए नेतृत्व के लिए क्रॉस-टीम दृश्यता प्रदान करें।

→प्रत्येक टीम को फ़िल्टर किए गए बैकलॉग देने के लिए एरिया पाथ के साथ एक सिंगल प्रोजेक्ट का उपयोग करें। टीमों में प्रगति और निर्भरता को विज़ुअलाइज़ करने के लिए डिलीवरी प्लान का उपयोग करें।

क्यों: यह रोलअप रिपोर्टिंग और निर्भरता ट्रैकिंग को सक्षम बनाता है जबकि प्रत्येक टीम को अपने स्वयं के स्प्रिंट और कार्य आइटम को स्वतंत्र रूप से प्रबंधित करने की अनुमति देता है।

कमिट/PR को कार्य आइटम से स्वचालित रूप से लिंक करें और PR मर्ज होने पर कार्य आइटम की स्थिति (जैसे, "Resolved" पर) को ट्रांजिशन करें।

→प्रोजेक्ट सेटिंग्स में, "Automatically complete work items with pull requests" सक्षम करें। डेवलपर्स को कमिट संदेशों में `#<ID>` का उपयोग करना चाहिए या PR को लिंक करना चाहिए।

क्यों: डेवलपर्स के लिए मैन्युअल ओवरहेड कम करता है, कार्य आइटम स्थिति को अप-टू-डेट रखता है, और कोड और आवश्यकताओं के बीच ट्रेसिबिलिटी में सुधार करता है।

मूल्य स्ट्रीम विश्लेषण के लिए साइकिल टाइम, लीड टाइम और DORA मेट्रिक्स जैसे प्रमुख प्रक्रिया मेट्रिक्स को मापें।

→Azure DevOps Analytics सेवा और इसके OData फ़ीड का उपयोग करें। इन मेट्रिक्स को विज़ुअलाइज़ करने के लिए Power BI को कनेक्ट करें या अंतर्निहित डैशबोर्ड विजेट्स का उपयोग करें।

क्यों: एनालिटिक्स सेवा प्रमुख प्रवाह और SRE मेट्रिक्स के लिए अंतर्निहित डेटा प्रदान करती है, जिससे डेटा-संचालित प्रक्रिया सुधार सक्षम होता है।

औसत प्रदर्शन मेट्रिक्स द्वारा छिपे हुए रुक-रुक कर धीमी प्रतिक्रिया समय की जांच करें।

→Application Insights में, प्रतिशत विश्लेषण (P95, P99) और विशिष्ट धीमी रिक्वेस्ट सैंपल में ड्रिल करने के लिए ट्रांजैक्शन सर्च के साथ प्रदर्शन ब्लेड का उपयोग करें।

क्यों: औसत भ्रामक हो सकते हैं। प्रतिशत प्रदर्शन मुद्दों की "लंबी पूंछ" को प्रकट करते हैं, जो अक्सर सबसे निराश उपयोगकर्ताओं का प्रतिनिधित्व करते हैं।

एक एकल उपयोगकर्ता रिक्वेस्ट को ट्रेस करें क्योंकि यह कई माइक्रोसर्विस में यात्रा करता है ताकि बॉटलनेक या विफलता बिंदुओं की पहचान की जा सके।

→सभी सेवाओं को Application Insights SDK के साथ इंस्ट्रूमेंट करें। यह सेवा कॉल में स्वचालित रूप से एक W3C Trace Context कोरिलेशन ID को फैलाता है।

क्यों: एप्लिकेशन मैप में एक वितरित लेनदेन का एक एकीकृत दृश्य प्रदान करता है, जिससे जटिल इंटरैक्शन को डीबग करना संभव हो जाता है।

किसी एप्लिकेशन के सर्विस लेवल ऑब्जेक्टिव (SLO) की सक्रिय रूप से निगरानी करें और SLO के उल्लंघन से *पहले* अलर्ट प्राप्त करें।

→Azure Monitor में KQL प्रश्नों का उपयोग करके SLI परिभाषित करें। एक अलर्ट नियम बनाएं जो एरर बजट बर्न रेट (बजट कितनी तेज़ी से खपत हो रहा है) के आधार पर ट्रिगर होता है।

क्यों: बर्न रेट अलर्ट अनुमानित होते हैं, SLO के उल्लंघन और उपयोगकर्ताओं के महत्वपूर्ण रूप से प्रभावित होने से पहले प्रतिक्रिया करने का समय प्रदान करते हैं।

सत्यापित करें कि एक डिप्लॉयमेंट उपयोगकर्ता के परिप्रेक्ष्य से कार्यात्मक रूप से सफल रहा था, न कि केवल पाइपलाइन कार्य पूरे हुए थे।

→डिप्लॉयमेंट के बाद के चरण या रिलीज़ गेट के रूप में, Application Insights उपलब्धता परीक्षण (सिंथेटिक मॉनिटरिंग) चलाएं जो प्रमुख उपयोगकर्ता प्रवाह का अनुकरण करते हैं।

क्यों: पाइपलाइन की सफलता केवल यह इंगित करती है कि बिट्स को स्थानांतरित किया गया था। सिंथेटिक परीक्षण पुष्टि करते हैं कि एप्लिकेशन वास्तव में काम कर रहा है, गलत कॉन्फ़िगरेशन या निर्भरता विफलताओं को पकड़ रहा है।

एप्लिकेशन प्रदर्शन और त्रुटि दर मेट्रिक्स में परिवर्तनों के साथ डिप्लॉयमेंट घटनाओं को दृष्टिगत रूप से सहसंबंधित करें।

→Application Insights में "रिलीज़ एनोटेशन" बनाने के लिए Azure Pipelines टास्क का उपयोग करें, जो मेट्रिक चार्ट पर एक मार्कर रखता है।

क्यों: यह तुरंत दृश्य प्रतिक्रिया प्रदान करता है ताकि यह जल्दी से पहचाना जा सके कि हाल ही में डिप्लॉयमेंट ने प्रदर्शन प्रतिगमन या बग पेश किया है या नहीं।

नियंत्रित तरीके से विफलताओं के प्रति एप्लिकेशन और इन्फ्रास्ट्रक्चर लचीलेपन का सक्रिय रूप से परीक्षण करें।

→रिलीज़ पाइपलाइन में Azure Chaos Studio को एकीकृत करें। ऐसे प्रयोग बनाएं जो दोषों को इंजेक्ट करते हैं (जैसे, VM शटडाउन, नेटवर्क लेटेंसी) और सिस्टम व्यवहार को मान्य करते हैं।

क्यों: अप्रत्याशित विफलताओं के लिए परीक्षण करने के लिए अपेक्षित व्यवहार के परीक्षण से आगे बढ़ता है, जिससे सिस्टम लचीलेपन में विश्वास पैदा होता है।