प्रस्ताव और वैलिडेशन
ElevenAgents Architect के बदलावों को लाइव ट्रैफ़िक पर कैसे टेस्ट, रिव्यू और रोल आउट किया जाता है।
परिचय
जब ElevenAgents Architect कोई बदलाव पूरा कर लेता है, तो वह उसे आपको प्रस्ताव के रूप में देता है: एक ब्रांच जिसमें बदलाव होता है, ऐसे टेस्ट जो दिखाते हैं कि यह काम करता है, और एक मर्ज प्रस्ताव जिसमें उस ब्रांच को main में मर्ज करने का अनुरोध होता है। यह पेज बताता है कि हर भाग कैसे काम करता है, उसे कहाँ ढूँढें, और कोई प्रस्ताव बातचीत से लाइव ट्रैफ़िक तक कैसे पहुँचता है।
प्रस्ताव क्या होता है
एक प्रस्ताव मौजूदा वर्ज़निंग मॉडल पर बनाया जाता है:
मर्ज प्रस्ताव एक मानक ElevenAgents मर्ज प्रस्ताव है, ठीक वैसा ही जैसा कोई टीममेट खुद खोलता है। यह कोई अलग ऑब्जेक्ट प्रकार नहीं है।
एक मर्ज प्रस्ताव में ठीक एक सोर्स ब्रांच और एक टारगेट ब्रांच होती है, इसलिए एक प्रस्ताव में एक संभावित समाधान होता है। विकल्पों की तुलना करने के लिए, Architect से हर विकल्प को उसकी अपनी ब्रांच पर रखने के लिए कहें। फिर हर ब्रांच का अपना प्रस्ताव होगा और आप उनके बीच ट्रैफ़िक को एक्सपेरिमेंट के रूप में बाँट सकते हैं।
Architect आपकी ओर से काम करता है, इसलिए उसके द्वारा खोला गया मर्ज प्रस्ताव लेखक के रूप में आपके नाम से दर्ज होता है। ऐसा कोई फ़ील्ड नहीं होता जो दर्ज करे कि इसे Architect ने बनाया था। अगर आपकी टीम को यह जानना हो, तो इसका उल्लेख प्रस्ताव के विवरण में करें।
प्रस्ताव कैसे बनता है
जब आप Architect से किसी चीज़ को ठीक करने या बेहतर बनाने के लिए कहते हैं, या उसे कोई असफल टेस्ट, Spotlight फ़ाइंडिंग या इश्यू देते हैं, तो Architect एक प्रस्ताव बनाता है। हर चरण में Architect किन टूल्स को कॉल करता है, इसकी पूरी प्रक्रिया वर्क्ड उदाहरण में दी गई है। संक्षेप में:
- Architect जाँच करता है, एक ब्रांच बनाता है और उस ब्रांच पर आपके ड्राफ़्ट में बदलाव स्टेज करता है।
- Architect बदलाव के लिए टेस्ट और सिम्युलेशन लिखता है और आपको नतीजा दिखाने से पहले उन्हें बातचीत में चलाता है।
- Architect पब्लिश डायलॉग खोलता है। आप डिफ़ देखते हैं और प्रकाशित करें चुनते हैं, जिससे बदलाव ब्रांच पर नए वर्ज़न के रूप में कमिट हो जाता है।
- Architect
mainमें एक मर्ज प्रस्ताव खोलता है और उसका विवरण ब्रांच के वास्तविक कमिट और टेस्ट रन के आधार पर लिखता है। - प्रस्ताव की समीक्षा के दौरान Architect ब्रांच पर लाइव ट्रैफ़िक का एक छोटा हिस्सा भेजने की पेशकश करता है। इसके लिए आपकी मंज़ूरी चाहिए।
आप किसी भी चरण पर रुक सकते हैं। प्रकाशित वर्ज़न वाली लेकिन बिना मर्ज प्रस्ताव वाली ब्रांच भी उपयोगी होती है: आप उसे खुद टेस्ट कर सकते हैं या बाद में प्रस्ताव खोल सकते हैं।
बातचीत में वैलिडेशन
Architect बदलाव बनाते समय ही टेस्ट लिखता और चलाता है, न कि बाद में आपके शुरू किए जाने वाले अलग चरण के रूप में। किसी फ़िक्स के लिए, यह दिखाना उपयोगी है कि नए टेस्ट बदलाव के बिना असफल होते हैं और उसके साथ सफल होते हैं। Architect वही टेस्ट मूल ब्रांच और बदलाव वाले ड्राफ़्ट, दोनों पर चला सकता है।
Architect हर बदलाव पर यह पहले-और-बाद का जाँच अपने-आप नहीं चलाता। जब यह ज़रूरी हो, तो इसके लिए कहें, जैसे: “मुझे नया सिम्युलेशन main पर असफल और ब्रांच पर सफल दिखाएँ, फिर एक प्रस्ताव खोलें।”
टेस्ट सफल होता है जब सफलता की हर शर्त पूरी होती है। LLM टेस्ट के लिए, एजेंट का जवाब सफलता के मानदंडों को पूरा करता है। टूल-कॉल टेस्ट के लिए, अपेक्षित टूल को अपेक्षित पैरामीटर के साथ कॉल किया जाता है। सिम्युलेशन के लिए, सिम्युलेट की गई बातचीत सफलता की शर्तें पूरी करती है। अस्थिर नतीजों की जाँच के लिए Architect से टेस्ट कई बार चलाने को कहें। यह हर टेस्ट को 50 बार तक दोहरा सकता है और पास रेट रिपोर्ट कर सकता है।
हर टेस्ट प्रकार कैसे परिभाषित होता है, इसके लिए टेस्टिंग देखें।
प्रस्ताव कहाँ मिलेंगे
एजेंट खोलें, फिर वर्ज़न कंट्रोल > प्रस्ताव पर जाएँ। सूची को स्टेटस, लेखक (इनके द्वारा बनाया गया) और समीक्षक (इनसे समीक्षा की प्रतीक्षा, इनके द्वारा समीक्षा की गई) के आधार पर फ़िल्टर किया जा सकता है। आपकी बातचीत में Architect द्वारा खोला गया प्रस्ताव आपको लेखक के रूप में दिखाता है।
Architect प्रस्ताव बनाते ही बातचीत में उसका लिंक भी देता है।
प्रस्ताव की संरचना
प्रस्ताव का पेज सोर्स और टारगेट ब्रांच, उसका स्टेटस, उसे मर्ज किया जा सकता है या नहीं, और सोर्स ब्रांच टारगेट से कितना पीछे या आगे है, दिखाता है। इसमें ये टैब होते हैं:
परिचय
बदलाव
टेस्ट रन
बातचीत
विवरण, सोर्स ब्रांच पर कमिट, समीक्षाओं और टिप्पणियों की गतिविधि टाइमलाइन, और एक कमेंट बॉक्स। साइडबार में समीक्षक, सुझाए गए समीक्षक और कोई लिंक किया गया इश्यू दिखता है।
Architect द्वारा लिखे गए विवरण में हमेशा तीन सेक्शन होते हैं: सारांश (हर महत्वपूर्ण बदलाव और उसका कारण), टेस्टिंग (कौन-से टेस्ट चलाए गए और उनके नतीजे, या यह कथन कि कोई टेस्ट नहीं चलाया गया), और समीक्षा कैसे करें (किस पर ध्यान देना है, और चलाने के लिए टेस्ट या आज़माने के लिए बातचीत)।
समीक्षा और मर्ज करना
स्टेटस
मर्ज प्रस्ताव का इनमें से एक स्टेटस होता है:
जब प्रस्ताव खुला होता है, तो हर समीक्षक की नवीनतम समीक्षा स्वीकृत या बदलाव का अनुरोध होती है। अलग से “टेस्ट किया गया” या “समीक्षा के लिए तैयार” स्टेटस नहीं होते। इसके बजाय टेस्ट नतीजे टेस्ट रन टैब में दिखते हैं।
समीक्षाएँ और टिप्पणियाँ परिचय टैब की गतिविधि टाइमलाइन में सोर्स ब्रांच पर कमिट हुए हर नए वर्ज़न के साथ दिखती हैं।
कौन स्वीकृत और मर्ज कर सकता है
- एजेंट का एडिटर एक्सेस रखने वाला कोई भी व्यक्ति प्रस्ताव की समीक्षा कर सकता है, उसके लेखक को छोड़कर। Architect आपकी ओर से काम करता है, इसलिए आप अपनी बातचीत में Architect द्वारा खोले गए प्रस्ताव को स्वीकृत नहीं कर सकते। किसी टीममेट को करना होगा।
- प्रस्ताव को तब मर्ज किया जा सकता है जब उसे लेखक के अलावा किसी व्यक्ति से कम-से-कम एक स्वीकृति मिली हो और किसी भी समीक्षक की नवीनतम समीक्षा बदलाव का अनुरोध न हो। वर्कस्पेस एडमिन बिना स्वीकृति के मर्ज कर सकते हैं।
- सुरक्षित ब्रांच में मर्ज करने के लिए एडमिन अनुमतियाँ या किसी एडमिन की स्वीकृति चाहिए।
Architect मर्ज प्रस्ताव को स्वीकृत, उस पर टिप्पणी, मर्ज या बंद नहीं कर सकता। ये चरण हमेशा लोग ही करते हैं। पूरी समीक्षा नियमों के लिए मर्ज प्रस्ताव देखें।
जब आप Architect से कहते हैं और आपकी भूमिका मर्ज की अनुमति देती है, तो Architect बिना प्रस्ताव के सीधे ब्रांच मर्ज कर सकता है।
मंज़ूरी आवश्यक मोड में वह पहले पूछता है। ऑटो-अप्रूव मोड में वह नहीं पूछता। अगर हर बदलाव को समीक्षित प्रस्ताव से गुजरना चाहिए,
तो main पर ब्रांच सुरक्षा का उपयोग करें।
मर्ज होने पर क्या होता है
मर्ज के बाद अलग से प्रकाशित करने का कोई चरण नहीं होता। मर्ज करने पर टारगेट ब्रांच पर नया वर्ज़न लिखा जाता है, और वह वर्ज़न टारगेट को मिलने वाले ट्रैफ़िक के हिस्से के लिए तुरंत लाइव ट्रैफ़िक संभालता है। जब टारगेट main हो और कोई ट्रैफ़िक स्प्लिट सेट न हो, तो इसका मतलब सभी कॉलर्स होता है।
मर्ज करने पर यह भी होता है:
- सोर्स ब्रांच के लाइव ट्रैफ़िक का कोई भी हिस्सा टारगेट पर चला जाता है।
- सोर्स ब्रांच डिफ़ॉल्ट रूप से आर्काइव हो जाती है।
- उसी ब्रांच से आए अन्य खुले प्रस्ताव बंद हो जाते हैं।
- लिंक किया गया इश्यू, अगर हो, हल हो जाता है।
क्रमिक रोलआउट
प्रस्ताव के मर्ज होने से पहले, आप लाइव ट्रैफ़िक का एक हिस्सा उसकी ब्रांच पर भेज सकते हैं, ताकि वास्तविक कॉलर्स बदलाव का उपयोग करें।
स्प्लिट शुरू करें
उदाहरण के लिए Architect से कहें, “इस ब्रांच पर 5% ट्रैफ़िक भेजें।” Architect आपको main के हिस्से सहित पूरा
परिणामी स्प्लिट बताता है और उसे लागू करने से पहले मंज़ूरी माँगता है। आप इसे खुद भी सेट कर सकते हैं: वर्ज़न कंट्रोल > ब्रांचेज़ में,
ब्रांच पर डिप्लॉय चुनें।
ट्रैफ़िक हिस्सों का कुल हमेशा 100% होना चाहिए और रूटिंग हर बातचीत के लिए निश्चित होती है। सुरक्षित main से ट्रैफ़िक लेने सहित, किसी सुरक्षित ब्रांच का हिस्सा बदलने के लिए एडमिन चाहिए। ट्रैफ़िक डिप्लॉयमेंट देखें।
सक्रिय प्रस्ताव
Architect आपके कहने पर या जब आप उसे असफल टेस्ट, Spotlight फ़ाइंडिंग, अलर्ट या इश्यू देते हैं, प्रस्ताव बनाता है। यह अभी आपके एजेंट्स को तय शेड्यूल पर स्कैन नहीं करता या खुद से प्रस्ताव नहीं खोलता।
आज सक्रिय तरीका है Spotlight, जिसके बाद हैंड-ऑफ़ होता है। Spotlight आपके एजेंट की बातचीत पर लगातार नज़र रखता है। यह सुझाई गई जाँचों के साथ साप्ताहिक सारांश देता है, रीयल-टाइम अलर्ट उठाता है और कॉन्फ़िगरेशन बदलाव सुझाता है। Spotlight फ़ाइंडिंग को प्रस्ताव में बदलने के लिए:
इसे ElevenAgents Architect को सौंपें
किसी सुझाव पर Architect में खोलें, सारांश पर Architect से विश्लेषण करें, या अलर्ट पर Architect से जाँच करें चुनें। Architect को फ़ाइंडिंग मिलती है और उसे वास्तविक बातचीत के आधार पर इसकी पुष्टि करने और बदलाव सुझाने से पहले प्रभावित ब्रांच की पहचान करने का निर्देश दिया जाता है।
इश्यू भी इसी तरह काम करते हैं। आपका लाइव एजेंट बातचीत के दौरान समीक्षा के लिए इश्यू फ़्लैग कर सकता है, और किसी इश्यू पर Architect के साथ चर्चा करें चुनने से उसकी जाँच शुरू होती है।
Architect इनबॉक्स में रिपोर्ट भेजने वाले शेड्यूल्ड ऑटोमेशन विकसित किए जा रहे हैं। Architect पेज का इनबॉक्स टैब उनके लिए प्लेसहोल्डर है।