प्रस्ताव और वैलिडेशन
ElevenAgents Architect के बदलावों को कैसे टेस्ट, रिव्यू और लाइव ट्रैफ़िक पर रोल आउट किया जाता है।
अवलोकन
जब ElevenAgents Architect कोई बदलाव पूरा करता है, तो वह उसे आपको एक प्रस्ताव के रूप में देता है: एक ब्रांच जिसमें बदलाव होता है, ऐसे टेस्ट जो दिखाते हैं कि यह काम करता है, और एक मर्ज प्रस्ताव जिसमें उस ब्रांच को main में मर्ज करने का अनुरोध होता है। यह पेज बताता है कि हर हिस्सा कैसे काम करता है, उसे कहाँ ढूंढें, और कोई प्रस्ताव बातचीत से लाइव ट्रैफ़िक तक कैसे पहुँचता है।
प्रस्ताव क्या है
एक प्रस्ताव मौजूदा वर्शनिंग मॉडल पर बनाया जाता है:
मर्ज प्रस्ताव एक मानक ElevenAgents मर्ज प्रस्ताव होता है, ठीक उसी तरह का जिसे कोई टीममेट मैन्युअली खोलता है। यह अलग ऑब्जेक्ट टाइप नहीं है।
एक मर्ज प्रस्ताव में ठीक एक सोर्स ब्रांच और एक टारगेट ब्रांच होती है, इसलिए एक प्रस्ताव में एक संभावित समाधान होता है। विकल्पों की तुलना करने के लिए Architect से कहें कि हर विकल्प को अपनी अलग ब्रांच पर रखे। फिर हर ब्रांच का अपना प्रस्ताव होगा, और आप उनके बीच ट्रैफ़िक को एक एक्सपेरिमेंट के रूप में बाँट सकते हैं।
Architect आपकी ओर से काम करता है, इसलिए उसके द्वारा खोला गया मर्ज प्रस्ताव लेखक के रूप में आपके नाम से दर्ज होता है। यह रिकॉर्ड करने के लिए कोई फ़ील्ड नहीं है कि इसे Architect ने बनाया था। अगर आपकी टीम को जानना हो, तो इसका उल्लेख प्रस्ताव के विवरण में करें।
प्रस्ताव कैसे बनाया जाता है
Architect तब प्रस्ताव बनाता है जब आप उससे किसी चीज़ को ठीक करने या बेहतर करने के लिए कहते हैं, या जब आप उसे कोई विफल टेस्ट, Spotlight की खोज या ट्रायेज टिकट देते हैं। हर चरण में Architect द्वारा कॉल किए गए टूल्स के साथ पूरी प्रक्रिया उदाहरण में दी गई है। संक्षेप में:
- Architect जाँच करता है, ब्रांच बनाता है और उस ब्रांच पर आपके ड्राफ़्ट में बदलाव स्टेज करता है।
- Architect बदलाव के लिए टेस्ट और सिमुलेशन लिखता है और आपको नतीजा दिखाने से पहले उन्हें बातचीत में चलाता है।
- Architect पब्लिश डायलॉग खोलता है। आप डिफ़ देखते हैं और Publish चुनते हैं, जिससे बदलाव ब्रांच पर नए वर्शन के रूप में कमिट हो जाता है।
- Architect
mainमें मर्ज प्रस्ताव खोलता है और उसका विवरण ब्रांच के वास्तविक कमिट्स और टेस्ट रन से लिखता है। - प्रस्ताव की समीक्षा के दौरान Architect ब्रांच पर लाइव ट्रैफ़िक का छोटा हिस्सा भेजने की पेशकश करता है। इसके लिए आपकी मंज़ूरी चाहिए।
आप किसी भी चरण पर रुक सकते हैं। प्रकाशित वर्शन वाली लेकिन बिना मर्ज प्रस्ताव वाली ब्रांच भी उपयोगी है: आप उसे खुद टेस्ट कर सकते हैं या बाद में प्रस्ताव खोल सकते हैं।
बातचीत के भीतर वैलिडेशन
Architect बदलाव बनाते समय ही टेस्ट लिखता और चलाता है, न कि बाद में आपके द्वारा शुरू किए जाने वाले अलग चरण के रूप में। किसी फ़िक्स के लिए, एक उपयोगी तरीका यह दिखाना है कि नए टेस्ट बदलाव के बिना विफल होते हैं और उसके साथ पास होते हैं। Architect वही टेस्ट मूल ब्रांच और बदलाव वाले ड्राफ़्ट, दोनों पर चला सकता है।
Architect हर बदलाव के लिए अपने-आप यह पहले-और-बाद की जाँच नहीं चलाता। जब यह महत्वपूर्ण हो, तो कहें, जैसे: “मुझे नया सिमुलेशन main पर विफल और ब्रांच पर पास होता दिखाएँ, फिर प्रस्ताव खोलें।”
जब हर सफलता शर्त पूरी होती है, तो टेस्ट पास होता है। LLM टेस्ट में, एजेंट का जवाब सफलता मानदंडों को पूरा करता है। टूल-कॉल टेस्ट में, अपेक्षित टूल को अपेक्षित पैरामीटर्स के साथ कॉल किया जाता है। सिमुलेशन में, सिमुलेट की गई बातचीत अपनी सफलता शर्तों को पूरा करती है। अस्थिर नतीजों की जाँच के लिए Architect से टेस्ट कई बार चलाने को कहें। यह हर टेस्ट को अधिकतम 50 बार दोहरा सकता है और पास रेट बता सकता है।
हर टेस्ट टाइप की परिभाषा के लिए टेस्टिंग देखें।
प्रस्ताव कहाँ ढूंढें
एजेंट खोलें, फिर Version Control > Proposals पर जाएँ। सूची को स्टेटस, लेखक (Created by) और समीक्षक (Awaiting review from, Reviewed by) के आधार पर फ़िल्टर किया जा सकता है। आपकी बातचीत में Architect द्वारा खोला गया प्रस्ताव आपको लेखक के रूप में दिखाता है।
Architect भी प्रस्ताव बनाते ही बातचीत में उसका लिंक देता है।
प्रस्ताव की संरचना
प्रस्ताव का पेज सोर्स और टारगेट ब्रांच, उसका स्टेटस, क्या उसे मर्ज किया जा सकता है, और सोर्स ब्रांच टारगेट से कितना पीछे या आगे है, दिखाता है। इसमें ये टैब होते हैं:
अवलोकन
बदलाव
टेस्ट रन
बातचीत
विवरण, सोर्स ब्रांच पर कमिट्स, समीक्षाओं और टिप्पणियों की गतिविधि टाइमलाइन, और एक कमेंट बॉक्स। साइडबार में समीक्षक, सुझाए गए समीक्षक और लिंक किया गया कोई भी ट्रायेज टिकट दिखता है।
Architect द्वारा लिखे गए विवरण में हमेशा तीन सेक्शन होते हैं: सारांश (हर महत्वपूर्ण बदलाव और उसका कारण), टेस्टिंग (कौन-से टेस्ट चलाए गए और उनके नतीजे, या यह कथन कि कोई टेस्ट नहीं चलाया गया), और समीक्षा कैसे करें (किस पर ध्यान दें, और चलाने के लिए कोई टेस्ट या आज़माने के लिए बातचीत)।
समीक्षा और मर्ज करना
स्टेटस
मर्ज प्रस्ताव में इनमें से एक स्टेटस होता है:
जब प्रस्ताव खुला होता है, तो हर समीक्षक की नवीनतम समीक्षा Approved या Changes requested होती है। अलग से “tested” या “ready for review” स्टेटस नहीं होते। टेस्ट नतीजे इसके बजाय Test runs टैब पर दिखते हैं।
समीक्षाएँ और टिप्पणियाँ Overview टैब की गतिविधि टाइमलाइन में, सोर्स ब्रांच पर कमिट किए गए हर नए वर्शन के साथ दिखती हैं।
कौन मंज़ूरी दे और मर्ज कर सकता है
- लेखक को छोड़कर, एजेंट का एडिटर ऐक्सेस रखने वाला कोई भी व्यक्ति प्रस्ताव की समीक्षा कर सकता है। Architect आपकी ओर से काम करता है, इसलिए आप अपनी बातचीत में Architect द्वारा खोले गए प्रस्ताव को मंज़ूरी नहीं दे सकते। किसी टीममेट को देनी होगी।
- प्रस्ताव को तब मर्ज किया जा सकता है जब लेखक के अलावा किसी अन्य व्यक्ति से कम-से-कम एक मंज़ूरी हो और किसी भी समीक्षक की नवीनतम समीक्षा Changes requested न हो। वर्कस्पेस एडमिन मंज़ूरी के बिना मर्ज कर सकते हैं।
- किसी सुरक्षित ब्रांच में मर्ज करने के लिए एडमिन अनुमतियाँ या एडमिन की मंज़ूरी चाहिए।
Architect मर्ज प्रस्ताव को मंज़ूरी नहीं दे सकता, उस पर टिप्पणी नहीं कर सकता, उसे मर्ज या बंद नहीं कर सकता। ये चरण हमेशा लोग करते हैं। समीक्षा के पूरे नियमों के लिए मर्ज प्रस्ताव देखें।
जब आप Architect से ऐसा करने को कहते हैं और आपकी भूमिका मर्ज की अनुमति देती है, तो वह प्रस्ताव के बिना सीधे ब्रांच मर्ज कर सकता है।
Approval required मोड में वह पहले पूछता है। Auto-approve मोड में नहीं। अगर हर बदलाव को समीक्षा किए गए प्रस्ताव से गुजरना चाहिए, तो
main पर ब्रांच प्रोटेक्शन इस्तेमाल करें।
मर्ज होने पर क्या होता है
मर्ज के बाद अलग से पब्लिश करने का चरण नहीं है। मर्ज करने से टारगेट ब्रांच पर नया वर्शन लिखा जाता है, और वह वर्शन टारगेट को मिलने वाले ट्रैफ़िक के हिस्से के लिए तुरंत लाइव ट्रैफ़िक संभालता है। जब टारगेट main हो और कोई ट्रैफ़िक स्प्लिट सेट न हो, तो इसका मतलब सभी कॉलर होते हैं।
मर्ज करने पर यह भी होता है:
- सोर्स ब्रांच के लाइव ट्रैफ़िक का कोई भी हिस्सा टारगेट पर चला जाता है।
- डिफ़ॉल्ट रूप से सोर्स ब्रांच आर्काइव हो जाती है।
- उसी ब्रांच के अन्य सभी खुले प्रस्ताव बंद हो जाते हैं।
- अगर कोई लिंक किया हुआ ट्रायेज टिकट है, तो उसका समाधान हो जाता है।
क्रमिक रोलआउट
प्रस्ताव मर्ज होने से पहले, आप लाइव ट्रैफ़िक का एक हिस्सा उसकी ब्रांच पर भेज सकते हैं, ताकि वास्तविक कॉलर बदलाव का उपयोग करें।
स्प्लिट शुरू करें
Architect से कहें, उदाहरण के लिए “इस ब्रांच पर 5% ट्रैफ़िक भेजें।” Architect आपको main के हिस्से सहित
पूरा परिणामी स्प्लिट बताता है और उसे लागू करने से पहले मंज़ूरी माँगता है। आप इसे खुद भी सेट कर सकते हैं: Version Control > Branches में,
ब्रांच पर Deploy चुनें।
ट्रैफ़िक हिस्सों का कुल हमेशा 100% होना चाहिए और रूटिंग हर बातचीत के लिए निर्धारित होती है। सुरक्षित main से ट्रैफ़िक लेना समेत, किसी सुरक्षित ब्रांच का हिस्सा बदलने के लिए एडमिन चाहिए। ट्रैफ़िक डिप्लॉयमेंट देखें।
सक्रिय प्रस्ताव
Architect आपके कहने पर, या जब आप उसे कोई विफल टेस्ट, Spotlight की खोज, अलर्ट या ट्रायेज टिकट देते हैं, तब प्रस्ताव बनाता है। वह अभी आपके एजेंट्स को किसी तय शेड्यूल पर स्कैन नहीं करता और न ही खुद प्रस्ताव खोलता है।
आज सक्रिय प्रक्रिया Spotlight से शुरू होकर हैंड-ऑफ़ तक जाती है। Spotlight आपके एजेंट की बातचीत को लगातार मॉनिटर करता है। यह सुझाई गई जाँचों के साथ साप्ताहिक सारांश बनाता है, रियल-टाइम अलर्ट देता है और कॉन्फ़िगरेशन बदलाव सुझाता है। Spotlight की खोज को प्रस्ताव में बदलने के लिए:
इसे ElevenAgents Architect को सौंपें
किसी सुझाव पर Open in Architect, सारांश पर Analyze with Architect, या किसी अलर्ट पर Investigate with Architect चुनें। Architect को खोज मिलती है और उसे बदलाव सुझाने से पहले वास्तविक बातचीत के विरुद्ध उसे सत्यापित करने और प्रभावित ब्रांच की पहचान करने का निर्देश दिया जाता है।
ट्रायेज टिकट भी इसी तरह काम करते हैं। आपका लाइव एजेंट बातचीत के दौरान समीक्षा के लिए समस्याएँ फ़्लैग कर सकता है, और टिकट पर Discuss with Architect उसे जाँचने की प्रक्रिया शुरू करता है।
Architect इनबॉक्स में भेजी जाने वाली रिपोर्ट के साथ शेड्यूल्ड ऑटोमेशन विकासाधीन हैं। Architect पेज पर Inbox टैब उनके लिए प्लेसहोल्डर है।