🎦 🦌 😦 विकास प्रक्रिया का समर्थन करने के लिए VSTS में एक्स्टेंसिबल पुल अनुरोध नीतियां सक्षम करना 🏴󠁧󠁢󠁥󠁮󠁧󠁿 👩🏼‍🤝‍👨🏾 🆒

अक्सर, पुल अनुरोध चेक के हिस्से के रूप में, कोड की समीक्षा के अलावा, नियमित जांच का एक सेट करने की आवश्यकता होती है। कुछ जांच पीआर के डिजाइन की चिंता कर सकती हैं। अन्य - संबंधित परिस्थितियों की जाँच करें जो परिवर्तन को अपनाने की प्रक्रिया का आधार बनती हैं।
यदि नियमित जांच स्वचालित नहीं होती है, तो कोई व्यक्ति उन्हें भूलना या रोकना शुरू कर सकता है। क्योंकि दिनचर्या उबाऊ है।

विज़ुअल स्टूडियो टीम सर्विसेज पुल रिक्वेस्ट को संभालने के लिए काफी सुविधाजनक बुनियादी ढांचा प्रदान करती है। इसमें कस्टम मर्ज नीतियां, समीक्षकों की नियुक्ति, स्वीकृत परिवर्तनों के लिए मर्ज नियम शामिल हैं। यह सब कोड पर चर्चा और टिप्पणी करने के लिए एक सुविधाजनक प्रणाली द्वारा पूरित है।

पुल अनुरोध प्रक्रिया को विस्तारित करने के लिए सबसे शक्तिशाली उपकरण बाहरी प्लग-इन नीतियां हैं।

हम उनके निर्माण और उपयोग के बारे में बात करेंगे (और कोड देखें)

विस्तार योग्य अनुरोध अनुरोध क़ानून

पीआर स्थिति संदर्भ के भीतर परिभाषित झंडे हैं। संदर्भ - संदर्भ और "शैली" के नाम का एक अनूठा संयोजन। शैली आमतौर पर प्रति एप्लिकेशन एक है जो स्थिति में हेरफेर करती है।

उदाहरण के लिए:

स्थिति 1: शैली = 'मेरी नीति', नाम = 'चेक -1'
स्थिति 2: शैली = 'मेरी नीति', नाम = 'चेक -2'

स्थिति पूर्वनिर्धारित मूल्यों में से एक लेती है। प्रक्रिया का समर्थन करने के उद्देश्य से, हम दो में दिलचस्पी लेंगे: सफल और असफल।

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

शाखा नीति के संपादन पर जाएं। विदेश नीति जोड़ें।
ब्रंच नीति

यदि स्थिति कम से कम एक बार सेट की गई है, तो यह ड्रॉप-डाउन मेनू में उपलब्ध होगा।
तल पर, आप स्थिति के लिए एक शीर्षक निर्दिष्ट कर सकते हैं कि यह पुल-अनुरोध पूरा होने वाले ब्लॉक में कैसे प्रदर्शित किया जाएगा।

आवश्यकतानुसार विदेश नीति जोड़ें

चेक स्थिति में पुल अनुरोध पृष्ठ पर जोड़े गए स्टेटस दिखाई देंगे:

यदि स्थिति को नीति के रूप में उपयोग नहीं किया जाता है, तो इसका मान स्थिति अनुभाग में पृष्ठ पर प्रदर्शित होता है। यदि स्थिति एक नीति के रूप में निर्दिष्ट की जाती है, तो यह ब्लॉक के शीर्ष पर दिखाई देगी।

कार्यक्रम की स्थिति प्रबंधन

PR स्टेटस को REST API का उपयोग करके प्रोग्रामेटिक रूप से मैनिपुलेट किया जा सकता है। इस प्रकार, अतिरिक्त पीआर चेक को लागू करना और परिवर्तन करने की प्रक्रिया में सीधे उनके परिणाम का अनुवाद करना संभव है।

नई स्थिति मान बनाएँ विधि द्वारा जोड़ा गया है। परिणाम और संदर्भ के अलावा, उस पाठ को व्यक्त करना आवश्यक है जो उपयोगकर्ता देखता है। आप वैकल्पिक रूप से एक URL पास कर सकते हैं: इस स्थिति में, पीआर फॉर्म पर स्थिति लेबल एक लिंक बन जाएगा और उपयोगकर्ता स्थिति विवरण के साथ पृष्ठ पर जा सकेगा।

नए PR स्थिति रिकॉर्ड के निर्माण में विधि कॉल परिणाम होता है। एक संदर्भ में, अंतिम जोड़ा स्थिति मान सक्रिय माना जाता है। पहले की स्थिति प्रविष्टियां UI से दिखाई नहीं देती हैं, लेकिन उन्हें सूची विधि का उपयोग करके प्राप्त किया जा सकता है।

पिछली तस्वीर में स्थिति की स्थिति के लिए, पुल अनुरोध के लिए स्थिति की वास्तविक सूची निम्नानुसार हो सकती है:

{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }

वर्तमान स्थितियों की सूची देखने के बाद, आप सूची में चयनित एक को सूचकांक द्वारा अपडेट कर सकते हैं। ऐसा करने के लिए, अद्यतन विधि का उपयोग करें।

अंत में, स्थिति रिकॉर्ड्स को डिलीट विधि का उपयोग करके हटाया जा सकता है।

पीआर स्थिति परिवर्तनों का इतिहास आगे के विश्लेषण के लिए उपयोगी हो सकता है। इसलिए, हम निम्न स्थितियों को बदलने की विधि का उपयोग करते हैं:

उसी संदर्भ के लिए नवीनतम स्थिति रिकॉर्ड ढूंढें
यदि उसके पास समान परिणाम मान, विवरण और लिंक हैं जिन्हें हम जोड़ना चाहते हैं, तो हम कुछ भी नहीं करते हैं
अन्यथा, एक नया स्टेटस रिकॉर्ड जोड़ें।
यह आपको परिवर्तनों के इतिहास को रखने की अनुमति देता है, न कि इसे बहुत बढ़ाकर।

 function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }

व्यावहारिक अनुप्रयोग

हमने एकीकरण शाखा में परिवर्तनों को स्वीकार करने के लिए एक रूढ़िवादी दृष्टिकोण अपनाया है। हम सुविधा शाखा पर अधिकतम में अधिकतम करने के लिए परिवर्तन का परीक्षण करने का प्रयास करते हैं।

कस्टम नीतियों के भाग के रूप में हम कुछ ऐसे कार्य हैं, जिन्हें हम PR स्टेटस की मदद से हल करते हैं:

सभी पीआर को एक ही शैली में सजाया जाना चाहिए। इसलिए, जो पहला नियंत्रण बनाया गया था वह पीआर हेडर का डिज़ाइन है। हम इसे नियमित अभिव्यक्ति के खिलाफ जांचते हैं।
पीआर शाखा को उस शाखा के पीछे नहीं रखना चाहिए जहां इसे डाला जाता है (एकीकरण किया जाता है)।
यदि, पीआर के ढांचे के भीतर, डेटाबेस प्रोजेक्ट फाइलें बदल जाती हैं, तो ऑटोटेस्ट फाइलें भी मौजूद होनी चाहिए।
अंतिम परिवर्तन के लिए शाखा की एक सफल विधानसभा है।
इस विधानसभा को सफलतापूर्वक परीक्षण बेंच पर भेजा गया और ऑटो टेस्ट पास किए गए।

सूचीबद्ध शर्तों को मैन्युअल रूप से जांचा जा सकता है। हमने पहले भी ऐसा किया था। लेकिन यह एक दिनचर्या है, और इसे एक स्वचालित प्रक्रिया द्वारा बदल दिया गया है। अब हम चेक के सेट को पूरक और बदल सकते हैं - इसे हमेशा प्रक्रिया में एकीकृत किया जाएगा, हमेशा निष्पादित किया जाएगा।

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

नीति प्रवर्तन का तकनीकी कार्यान्वयन

वर्तमान में, पॉलिसी लॉजिक को पॉवरशेल स्क्रिप्ट के रूप में लागू किया जाता है। उच्च-स्तरीय cmdlets और एक अच्छे ऑब्जेक्ट डेटा मॉडल के कारण, स्क्रिप्ट कोड बहुत कॉम्पैक्ट है। और स्क्रिप्ट को चरणों में अंतःक्रियात्मक रूप से चलाने और चर के साथ टिंकर करने की क्षमता - विकास और डिबगिंग प्रक्रिया को बहुत सरल बनाती है।

वैसे, पॉवरशेल कोर के रिलीज़ होने के बाद - स्क्रिप्ट्स को अन्य प्लेटफॉर्म (मैकओएस पर टेस्ट किए गए) पर चलाया जा सकता है।

हर दो घंटे में एक बार VSTS की एक विशेष रिलीज में स्क्रिप्ट चलाएँ। शायद हम शेडयूलर के माध्यम से अधिक बार चलना शुरू कर देंगे।

यह दृष्टिकोण, निश्चित रूप से, काफी धीमी प्रतिक्रिया देता है यदि आप एज़्योर फ़ंक्शन के रूप में इसे लागू करते हैं और इसे वेब हुक के माध्यम से वीएसटीएस से जोड़ते हैं। लेकिन हमारे लिए चेक लागू करना अधिक महत्वपूर्ण था और देखें कि यह प्रक्रिया (एमवीपी) में कैसे काम करेगा। जाँच की क्षमता अभी तक महत्वपूर्ण नहीं है। यह अगला कदम होगा।

VSTS REST API के साथ काम करने के लिए पुस्तकालयों का कार्यान्वयन, जो चेक में उपयोग किए जाते हैं, साथ ही एक छोटा सा उदाहरण जो इन नीतियों में से कुछ को लागू करता है GitHub पर भंडार में पाया जा सकता है । मुझे उम्मीद है कि कोई इसे उपयोगी पाएगा।

विकास प्रक्रिया का समर्थन करने के लिए VSTS में एक्स्टेंसिबल पुल अनुरोध नीतियां सक्षम करना

विस्तार योग्य अनुरोध अनुरोध क़ानून

कार्यक्रम की स्थिति प्रबंधन

व्यावहारिक अनुप्रयोग

नीति प्रवर्तन का तकनीकी कार्यान्वयन

More articles: