👸🏽 🚫 ⚛️ सभी चिंताओं से एक बॉट 🌧️ 👩‍🎤 🔁

जब तक सम्मेलन "एक अमानवीय व्यक्ति के अधिकारों के संरक्षण पर" को अपनाया गया है, आपको इसका उपयोग करने और बॉट्स को काम करने की दिनचर्या देने की आवश्यकता है। यह अभी शुरू करने के लिए समझ में आता है, या 5 साल बाद, कारों का विद्रोह शुरू हो जाएगा, उबाऊ कार्यों के साथ बॉट की भावनाओं का अपमान करने के लिए बड़े पैमाने पर मुकदमे मानव-मशीन संबंधों को विनियमित करने के लिए अदालतों को भर देंगे। इसलिए जल्दी करो।

रूढ़िवादी दिनचर्या और काम करने का तरीका, एक स्थापित पैटर्न का पालन, एक यांत्रिक आदत में बदल गया। ६ अक्षर।

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

कुछ साल पहले हमने एक सप्ताह में एक बार रिलीज़ किया था। मई 2018 में, रिलीज़ के लिए 147 घंटे की अधिकतम दर होने के कारण, हम हर दिन रिलीज़ करने का लक्ष्य रखते हैं। अब हमारा न्यूनतम: रिलीज होने में चार घंटे हैं, लेकिन अक्सर ऐसा नहीं होता है। हम रिकॉर्ड को ठीक करना चाहते हैं और पूरी प्रक्रिया को एक बटन के प्रेस तक कम करने में सक्षम हैं।

रिलीज चक्र

अब डोडो आईएस में, सात टीमें लेती हैं और एक रिलीज जारी करती हैं। टीम का एक व्यक्ति "भाग्यशाली" हो जाता है - relizmen। हवाई जहाज के पायलट के रूप में रिज़ीज़मैन: उसके पास लीवर और उपकरणों का एक गुच्छा है जिसे उसे अगले अपडेट को रोल करने के लिए कुशलता से तैयार करने की आवश्यकता है। हमने सोचा और फैसला किया: "यह एक ऑटोपायलट करने का समय है, और हम अपने समय को आँकड़ों के साथ उबाऊ तालिकाओं को भरने और ऑटो टेस्ट रन को ट्रैक करने की तुलना में अधिक रोमांचक कुछ पर खर्च करते हैं।"

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

~~ब्लैक~~ क्राउन ~~मार्क~~ प्राप्त करने के बाद , Relismain को याद रखना चाहिए कि रिलीज़ स्टेप्स की चेकलिस्ट कहाँ है। इसके अलावा: याद किया -> पाया -> टेम्पलेट से एक प्रतिलिपि बनाई और अंत में, Kaiten प्रणाली में चेकलिस्ट खोला। काइटेन एक इलेक्ट्रॉनिक बोर्ड है जिस पर हम कार्ड के रूप में काम करते हैं और विकास में कार्यों की स्थिति की निगरानी करते हैं। नए डेवलपर्स के लिए, एक पूरे के रूप में यह प्रक्रिया बहुत ही स्पष्ट थी। और आप कैसे जानते हैं कि इस चेक शीट को कहाँ देखना है और कोई सुराग नहीं मिलने पर कहाँ से शुरू करना है?

अपनी इच्छा को मुट्ठी में इकट्ठा करने के बाद, हमने फैसला किया कि इसे सहना काफी है। यह कुछ उबाऊ दिनचर्या को बॉट को देने का समय है। अगर हम नहीं तो कौन? कब, अगर अभी नहीं तो?

क्या हम स्वचालित करने में कामयाब रहे

निर्णय लिया गया है, हमारे ऑटोपायलट को डिजाइन करना शुरू करने का समय आ गया है यहाँ Kaiten API मिलने के बाद: https://faq.kaiten.io/docs/api , केवल एक अनुरोध के साथ, हमने नए relizmen के लिए एक कार्ड बनाया।

//  POST     var createCardRequest = new RestRequest("https://<domain>.kaiten.io/api/latest/cards/", Method.POST); //     AddBasicAuth(createCardRequest); //        -      createCardRequest.AddJsonBody( new { board_id = _kaitenSettings.ReleasesBoardId, column_id = _kaitenSettings.ReleasesColumnId, lane_id = _kaitenSettings.ReleasesLaneId, title = $"release-{nextReleaseNumber}" } );

अब इस कार्ड को उस टीम को सौंपना होगा जो अगली रिलीज होगी।

यहाँ तर्क है:

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

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

यहां https://api.slack.com स्लैक एपीआई प्रलेखन खोलें और वहां एक चैनल बनाने के लिए एक विधि की तलाश करें ।

जैसा कि आप देख सकते हैं, स्लैक में, अन्य उपकरणों की तरह, जटिल कुछ भी नहीं है। यह सब दो आवश्यक मापदंडों के साथ एक पोस्ट अनुरोध भेजने के लिए नीचे आता है (ये विपरीत हैं जो इसे आवश्यक कहते हैं)। अनुरोध में, हमें निर्मित चैनल (पैरामीटर नाम) और प्राधिकरण टोकन (पैरामीटर टोकन) के नाम को पास करना होगा। लाइन पर ध्यान दें "के साथ काम करता है: टोकन प्रकार - उपयोगकर्ता, आवश्यक गुंजाइश (ओं) - चैनल: लिखें"।

स्लैक में दो प्रकार के टोकन हैं: उपयोगकर्ता - उपयोगकर्ताओं को जारी किए गए और बॉट - अनुप्रयोगों को जारी किए गए। टोकन जारी करते समय, हम यह निर्धारित करते हैं कि उसके मालिक को निहित करने के क्या अधिकार हैं। चैनल बनाने के लिए, हमें एक उपयोगकर्ता टोकन (टोकन प्रकार - उपयोगकर्ता) चाहिए, जिसके पास चैनल लिखने के अधिकार हैं (चैनल: लिखना)।

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

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

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

अगली पंक्ति में गिथब और टीमसिटी के साथ एकीकरण किया गया। हम Gitflow पर काम करते हैं। जब हम रिलीज़ करना चाहते हैं, तो हम DEV शाखा लेते हैं, कार्यशील = हरा = जिस पर परीक्षण पास होते हैं, और उसमें से हम रिलीज़ शाखा बनाते हैं।

ऐसा करने के लिए, हमारे बॉट टीमसिटी में जाते हैं, वहां डीईवी शाखा के लिए एक परीक्षण रन शुरू करने के लिए देखते हैं। यदि परीक्षण हरे हैं, जैसे कि घर के पास घास, तो गिटहब से आगे बढ़ें, एक रिलीज शाखा और एक पुल अनुरोध बनाएं!

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

यह रिलीज़ करना लगभग संभव है, यह केवल हमारे परिवर्तनों का पूरी तरह से परीक्षण करने के लिए बना हुआ है। ऐसा करने के लिए, रिलीज शाखा को उत्पादन के करीब के माहौल में तैनात किया जाता है (हम इसे चरण कहते हैं), और रिलीज के बाद परीक्षण किया जाता है। तैनाती और परीक्षणों को TeamCity में एक पाइपलाइन में इकट्ठा किया जाता है, और हमारा कार्य इसे लॉन्च करना और प्रतीक्षा करना, क्रॉस-फ़िंगर करना है, कि परीक्षण ठीक काम करेंगे। रिग्रेशन की शुरुआत के दौरान बॉट एक पाइपलाइन लॉन्च करता है।

मैं आपको याद दिलाता हूं कि हमने इस तथ्य से शुरू किया था कि यह सब मैन्युअल रूप से किया गया था। अपनी मुट्ठी पीसते हुए, रिझिज़्मेन ने लिंक और टूल पर स्विच किया: टीमसीटी, कैटन, स्लैक, जीथब और यह सब नहीं है! और अब हमारे पास क्रियाओं का एक पूरा सेट है जिसमें से बॉट के लिए पहली टीम पहले से ही गठित है। Releaseman "/ startregress" टाइप करता है और अपनी कुर्सी पर पीछे झुककर हमारे बॉट को देखता है:

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

हम पूरी रिलीज प्रक्रिया का विश्लेषण करते हैं, लिखते हैं कि रिलीज के प्रत्येक चरण में कितना समय लगता है। यह विकास और व्यवसाय को इस बात की समझ देता है कि उपयोगकर्ताओं के लिए नई सुविधाओं को प्रदान करने में कौन सा समय बर्बाद होता है और क्या हमें बाधित करता है। हम दो दिनों के लिए बैठे हैं और परीक्षण नहीं चला सकते हैं? तो हमारे परीक्षणों में कुछ गड़बड़ है, आपको उन्हें अधिक समय और ध्यान देने की आवश्यकता है। पहले, हमारी चेकलिस्ट की क्रियाओं को निष्पादित करते हुए, हमने कम से कम 5 बार Google शीट का दौरा किया। हर बार जब आप वहां एक तारीख दर्ज करते हैं और समय निर्धारित करते हैं।

ठीक है Google, हम आपको भी स्वचालित कर देंगे! आसानी से और आसानी से तालिकाओं के साथ काम करने के लिए, हम अपने बॉट की परियोजना के लिए nuget पैकेज Google.Apis.Sheets.v4 को कनेक्ट करते हैं। और फिर सब कुछ योजना के अनुसार अन्य सेवाओं के साथ इसी तरह से होता है: हम एक अनुरोध भेजते हैं जिसमें हम कहते हैं कि किस सेल में क्या मूल्य डालें। यह प्रश्न इस तरह दिखता है:

 public void InsertEntry(string cellAddress, string value) { //          - _googleSettings.SheetName        - cellAddress var range = $"{_googleSettings.SheetName}!{cellAddress}"; var valueRange = new ValueRange(); //        - value var objectsList = new List<object> {$"{value}"}; valueRange.Values = new List<IList<object>> {objectsList}; //    Google.Apis.Sheets.v4           SpreadsheetId var insertEntryRequest = _service.Spreadsheets.Values.Update(valueRange, _googleSettings.SpreadsheetId, range); insertEntryRequest.ValueInputOption = SpreadsheetsResource.ValuesResource.UpdateRequest.ValueInputOptionEnum.USERENTERED; insertEntryRequest.Execute(); }

Google के साथ एकीकरण स्थापित करने के बाद, हमने अपने बॉट की दूसरी कमांड "/ अपडेट" तैयार की और यही वह करता है:

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

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

हमने रिलीज प्रक्रिया को अनुकूलित करने के लिए एक बैठक रखी है। इसका एक हल यह था कि अब releaseman केवल स्लैक चैनलों में से एक में स्थिति को देखता है, जहाँ बुनियादी ढांचा पदों को हटाने की अनुमति है। यह लगातार एक ही बात पूछने और 90% मामलों में "आप कर सकते हैं" जवाब पाने से अधिक सुविधाजनक है।

किसी कारण से, ऐसी प्रतीत होता है कि प्रारंभिक चीजें तुरंत दिमाग में नहीं आईं। कंपनी में नए डेवलपर्स के लिए विशेष धन्यवाद कहा जाना चाहिए। हमारे पास आने के बाद, जल्द ही या बाद में वे relismen बन गए। उन लोगों के लिए जिन्होंने लंबे समय तक हमारे साथ काम किया, प्रक्रिया कुछ जटिल नहीं लगती थी, बल्कि कुछ परिचित थी। नई टीम के सदस्यों ने हमारे विकास बिंदुओं की ओर ध्यान दिलाया और सुधार पर काम के आयोजन में सक्रिय भाग लिया।

इस बीच, हम अंतिम चरण में आ गए हैं। हमारी रिहाई लाइनर उतरा है, केवल एक "/ releasecomplete" टीम हमें अंत से अलग करती है। वह क्या करती है:

मास्टर शाखा को जारी करने के साथ मेरिटज पुल अनुरोध
रिलीज शाखा निकालता है
गिटहब पर रिलीज विवरण बनाता है
स्लैक में संग्रह रिलीज चैनल
Kaiten में "रिलीज़ -..." कॉलम से "संपन्न" कॉलम में ले जाता है और रिलीज़ कॉलम को हटा देता है
अगले आदेश को जारी करने के लिए आमंत्रित करते हुए, बैटन पास करता है

संक्षेप में, मैं चाहूंगा कि आप अपने आप से सवाल पूछें: क्या आपके पास उबाऊ दिनचर्या प्रक्रियाएं हैं? क्या आप अभी भी उन्हें अपने हाथों से कर रहे हैं? क्या आप इसे एक बार और सभी के लिए समाप्त होने से रोकता है? एक बैठक इकट्ठा करें, प्रक्रियाओं की समीक्षा करें, वह सब कुछ फेंक दें जिसकी आपको आवश्यकता नहीं है और यह सिर्फ एक अनुष्ठान बन गया है। आपको अपनी ज़रूरत की हर चीज़ को स्वचालित करके, आप पहले जो चोट लगी है, उसका आनंद लेना शुरू कर देंगे, और रिहाई या किसी अन्य प्रक्रिया को तेज करके ढेर को बचा सकते हैं।

सभी चिंताओं से एक बॉट

रिलीज चक्र

क्या हम स्वचालित करने में कामयाब रहे

More articles: