तय करें कि Taiga निर्णय के लिए कहाँ रुके
पूरा हुआPlan approval, build execution, merge permission और deployment अलग रखें। संगठन के पास रहने वाले निर्णयों के अनुसार autonomy configure करें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंOrganization autonomous merge की अनुमति देती है, लेकिन factory उसे बंद करती है। क्या उसके नीचे का product इसे enable कर सकता है?अभ्यास करें
आप क्या सीखेंगे
- Automatic build और autonomous merge का अंतर समझें।
- Merge की ऊपरी सीमाएँ, product defaults और initiative overrides समझाएँ।
- Automation enable करने से पहले branch rules और deployment परिणाम जाँचें।
चार निर्णय अलग रखें
काल्पनिक equipment service में चार अलग निर्णय हैं: plan स्वीकार करना, build execute करना, बदलाव merge करना और deploy करना। एक switch को चारों की अनुमति न मानें।
Autonomy बदलने से पहले देखें कि repository pipeline merge के बाद क्या करती है। Working branch में merge से deployment शुरू हो, तो automated merge उस मौजूदा workflow को भी शुरू कर सकता है।
तय करें कि plan रुके या नहीं
Product की Build on its own by default setting तय करती है कि पूरा plan build में जाए या approval की प्रतीक्षा करे। Plans को पहले human decision चाहिए तो इसे बंद करें।
Initiative की Build on its own setting उस initiative के लिए व्यवहार बदल सकती है। काम queue में रखने से पहले default और विशेष choice, दोनों देखें।
Approve मंजूर करने वाले व्यक्ति की वर्तमान permissions के अनुसार उसी के रूप में build शुरू करता है। Failed plan कोई build शुरू नहीं करता। Build automation अपने आप बनी pull request merge करने की अनुमति नहीं देता।
Merge की hierarchy समझें
Autonomous merge का अलग control है और enable होने तक बंद रहता है। Documented integration GitHub और GitHub Enterprise support करता है।
| स्तर | अर्थ |
|---|---|
| Organization | Autonomous merge की अनुमति की ऊपरी सीमा |
| Factory | उस factory के नीचे हर चीज की ऊपरी सीमा |
| Product | अपनी choice न रखने वाली initiatives की default setting |
| Initiative | सीमाओं के भीतर अपनी Merge on its own choice |
बंद organization या factory सीमा नीचे से override नहीं हो सकती। Product का default off अलग है: ऊपरी सीमाएँ अनुमति दें तो initiative अपना merge enable कर सकती है।
Equipment service में शुरुआती दायरा स्पष्ट रखें। कम असर वाली initiative की choice employee access controls बदलने वाली initiative से अलग हो सकती है, स्वीकार्य सीमाओं के भीतर।
जरूरी reviews लागू होने योग्य बनाएँ
Taiga source-control provider से पूछता है कि pull request merge हो सकती है या नहीं। Branch protection जरूरी checks, reviews और दूसरी शर्तें तय करता है। Autonomous merge उन नियमों को bypass नहीं करता।
Automated review को merge रोकना हो, तो repository के supported configuration से उसके result को required status check बनाएँ। आपकी अपेक्षा से advisory result अनिवार्य नहीं बन जाता।
Required human approvals भी जाँचें। हरी check उस approval की जगह नहीं है जिसे policy माँगती है। वास्तविक target branch के rules की पुष्टि करें।
रुके merge का अर्थ समझें
Initiative पर कारण पढ़ें। Pending check, missing approval, conflict और incomplete plan के लिए अलग प्रतिक्रियाएँ चाहिए। जब fixes उन criteria को बदलते हैं जिनसे failed checks pass हुईं, तब भी Taiga autonomous merge रोकता है। उस बदलाव का सीधे review करें।
केवल प्रगति रुकने के कारण required check न हटाएँ। Check कभी report न करे तो configuration सुधारें या अधिकृत policy प्रक्रिया अपनाएँ। हर fix के बाद current commit देखें।
Deployment की अनुमति अलग रखें
Taiga GitHub App autonomous merge करता है और merger के रूप में दर्ज होता है। Repository pipeline का मौजूदा deployment behavior बना रहता है।
इस scenario में merge से staging deploy होता है। Production को संगठन का production decision और प्रमाण अब भी चाहिए। पुष्टि करें कि pipeline यह अलगाव लागू करती है। आगे delivery review पढ़ें।
अभ्यास करें
काल्पनिक equipment service में plans और pull requests का human review जरूरी है। Main branch staging में deploy होती है। Build setting, जरूरी branch rules, merge setting और अलग production approval लिखें।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।