प्रस्ताव और सत्यापन

परिचय

जब Architect कोई बदलाव पूरा करता है, तो वह उसे आपको एक प्रस्ताव के रूप में देता है: एक ब्रांच जिसमें बदलाव होता है, यह दिखाने वाले टेस्ट होते हैं कि यह काम करता है, और उस ब्रांच को main में मर्ज करने का अनुरोध करने वाला एक मर्ज प्रस्ताव होता है। यह पेज बताता है कि हर हिस्सा कैसे काम करता है, उसे कहाँ ढूँढें, और कोई प्रस्ताव बातचीत से लाइव ट्रैफ़िक तक कैसे पहुँचता है।

प्रस्ताव क्या है

प्रस्ताव मौजूदा वर्ज़निंग मॉडल पर बनाया जाता है:

मर्ज प्रस्ताव एक सामान्य ElevenAgents मर्ज प्रस्ताव है, वैसा ही जैसा कोई टीममेट खुद खोलता है। यह कोई अलग ऑब्जेक्ट टाइप नहीं है।

एक मर्ज प्रस्ताव में ठीक एक स्रोत ब्रांच और एक लक्ष्य ब्रांच होती है, इसलिए एक प्रस्ताव में एक उम्मीदवार समाधान होता है। विकल्पों की तुलना करने के लिए Architect से हर विकल्प को अपनी अलग ब्रांच पर रखने को कहें। फिर हर ब्रांच का अपना प्रस्ताव होगा, और आप उनके बीच ट्रैफ़िक को एक्सपेरिमेंट के रूप में बाँट सकते हैं।

प्रस्ताव कैसे बनाया जाता है

जब आप Architect से कुछ ठीक करने या बेहतर बनाने को कहते हैं, या उसे कोई असफल टेस्ट, Spotlight की खोज, या ट्रायेज टिकट देते हैं, तो Architect एक प्रस्ताव बनाता है। हर चरण में Architect किन टूल्स को कॉल करता है, इसके साथ पूरा क्रम उदाहरण में दिया गया है। संक्षेप में:

1. Architect जाँच करता है, एक ब्रांच बनाता है, और उस ब्रांच पर आपके ड्राफ़्ट में बदलाव स्टेज करता है।
2. Architect बदलाव के लिए टेस्ट और सिम्युलेशन लिखता है और परिणाम दिखाने से पहले उन्हें बातचीत में चलाता है।
3. Architect पब्लिश डायलॉग खोलता है। आप डिफ़ देखते हैं और प्रकाशित करें चुनते हैं, जिससे बदलाव ब्रांच पर नए वर्ज़न के रूप में कमिट हो जाता है।
4. Architect main में एक मर्ज प्रस्ताव खोलता है और उसका विवरण ब्रांच के वास्तविक कमिट और टेस्ट रन से लिखता है।
5. प्रस्ताव की समीक्षा के दौरान Architect ब्रांच को लाइव ट्रैफ़िक का एक छोटा हिस्सा भेजने की पेशकश करता है। इसके लिए आपकी मंज़ूरी चाहिए।

आप किसी भी चरण पर रुक सकते हैं। प्रकाशित वर्ज़न वाली लेकिन बिना मर्ज प्रस्ताव वाली ब्रांच भी उपयोगी है: आप इसे खुद टेस्ट कर सकते हैं या बाद में प्रस्ताव खोल सकते हैं।

बातचीत के भीतर वैलिडेशन

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

Architect हर बदलाव पर यह पहले-और-बाद की जाँच अपने-आप नहीं चलाता। जहाँ यह ज़रूरी हो, वहाँ इसके लिए कहें, उदाहरण के लिए: “मुझे नया सिम्युलेशन main पर असफल और ब्रांच पर पास होते हुए दिखाएं, फिर एक प्रस्ताव खोलें।”

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

हर टेस्ट प्रकार कैसे परिभाषित है, इसके लिए टेस्टिंग देखें।

प्रस्ताव कहाँ मिलेंगे

एजेंट खोलें, फिर वर्ज़न कंट्रोल > प्रस्ताव पर जाएँ। सूची को स्टेटस, लेखक (Created by), और समीक्षक (Awaiting review from, Reviewed by) के आधार पर फ़िल्टर किया जा सकता है। आपकी बातचीत में Architect द्वारा खोला गया प्रस्ताव आपको लेखक के रूप में दिखाता है।

Architect प्रस्ताव बनाते ही बातचीत में उसका लिंक भी देता है।

प्रस्ताव की संरचना

प्रस्ताव के पेज पर स्रोत और लक्ष्य ब्रांच, उसका स्टेटस, उसे मर्ज किया जा सकता है या नहीं, और स्रोत ब्रांच लक्ष्य से कितना पीछे या आगे है, दिखता है। इसमें ये टैब होते हैं:

समीक्षा और मर्ज करना

स्टेटस

मर्ज प्रस्ताव का इनमें से एक स्टेटस होता है:

प्रस्ताव खुला होने पर, हर समीक्षक की नवीनतम समीक्षा स्वीकृत या बदलाव का अनुरोध होती है। अलग से “tested” या “ready for review” स्टेटस नहीं होते। टेस्ट के परिणाम इसके बजाय टेस्ट रन टैब में दिखते हैं।

समीक्षाएँ और टिप्पणियाँ परिचय टैब की गतिविधि टाइमलाइन में दिखाई देती हैं, साथ ही स्रोत ब्रांच पर कमिट किए गए हर नए वर्ज़न के साथ।

कौन मंज़ूरी दे और मर्ज कर सकता है

• एजेंट का एडिटर एक्सेस रखने वाला कोई भी व्यक्ति प्रस्ताव की समीक्षा कर सकता है, लेखक को छोड़कर। क्योंकि Architect आपकी ओर से काम करता है, आप अपनी बातचीत में Architect द्वारा खोले गए प्रस्ताव को मंज़ूरी नहीं दे सकते। इसके लिए कोई टीममेट चाहिए।
• प्रस्ताव को तब मर्ज किया जा सकता है जब उसे लेखक के अलावा किसी व्यक्ति से कम से कम एक मंज़ूरी मिली हो और किसी समीक्षक की नवीनतम समीक्षा बदलाव का अनुरोध न हो। वर्कस्पेस एडमिन मंज़ूरी के बिना मर्ज कर सकते हैं।
• किसी सुरक्षित ब्रांच में मर्ज करने के लिए एडमिन अनुमति या किसी एडमिन की मंज़ूरी चाहिए।

Architect किसी मर्ज प्रस्ताव को मंज़ूरी नहीं दे सकता, उस पर टिप्पणी नहीं कर सकता, उसे मर्ज या बंद नहीं कर सकता। ये चरण हमेशा लोग करते हैं। पूरे समीक्षा नियमों के लिए मर्ज प्रस्ताव देखें।

मर्ज होने पर क्या होता है

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

मर्ज करने पर ये भी होता है:

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

धीरे-धीरे रोलआउट

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

ट्रैफ़िक हिस्सों का कुल योग हमेशा 100% होना चाहिए और रूटिंग हर बातचीत के लिए निश्चित होती है। किसी सुरक्षित ब्रांच का हिस्सा बदलने के लिए, जिसमें सुरक्षित main से ट्रैफ़िक लेना भी शामिल है, एडमिन की ज़रूरत होती है। ट्रैफ़िक डिप्लॉयमेंट देखें।

सक्रिय प्रस्ताव

आज सक्रिय मार्ग Spotlight से शुरू होकर हैंड-ऑफ़ तक जाता है। Spotlight आपके एजेंट की बातचीत को लगातार देखता है। यह सुझाई गई जाँचों के साथ साप्ताहिक सारांश बनाता है, रीयल-टाइम अलर्ट देता है और कॉन्फ़िगरेशन बदलाव सुझाता है। Spotlight की किसी खोज को प्रस्ताव में बदलने के लिए:

ट्रायेज टिकट भी इसी तरह काम करते हैं। आपका लाइव एजेंट बातचीत के दौरान समीक्षा के लिए समस्याओं को फ़्लैग कर सकता है, और टिकट पर Architect के साथ चर्चा करें चुनने से उसकी जाँच शुरू होती है।

Architect इनबॉक्स में डिलीवर होने वाली रिपोर्ट के साथ शेड्यूल्ड ऑटोमेशन विकसित किए जा रहे हैं। Architect पेज पर इनबॉक्स टैब उनके लिए प्लेसहोल्डर है।