यदि आप एक आईटी कंपनी में काम करते हैं, तो सबसे अधिक संभावना है कि आपकी प्रक्रियाएं प्रसिद्ध एटलसियन उत्पाद - जीरा के आसपास बनाई गई हैं। समान समस्याओं को हल करने के लिए बाजार पर कई कार्य ट्रैकर्स हैं, जिनमें ओपन-सोर्स समाधान (Trac, Redmine, Bugzilla) शामिल हैं, लेकिन शायद जीरा आज सबसे व्यापक रूप से उपयोग किया जाता है।

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

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

जीरा की अतिरिक्त विशेषताएं

निम्नलिखित पाठ को और अधिक समझने के लिए, आइए जानें कि जीरा गैर-मानक विशलिस्ट के कार्यान्वयन के लिए हमें कौन से उपकरण प्रदान करता है - जो मानक जीरा कार्यक्षमता से परे हैं।

अन्य एपीआई

सामान्य तौर पर, एक एपीआई कमांड कॉल एक एपीआई यूआरएल है जो विधि (GET, PUT, POST और DELETE), कमांड, और अनुरोध बॉडी को दर्शाता है। अनुरोध निकाय, साथ ही API प्रतिक्रिया, JSON प्रारूप में है। एक अनुरोध का एक उदाहरण जो एक टिकट के JSON प्रतिनिधित्व को लौटाता है:

GET /rest/api/latest/issue/{ticket_number}

एपीआई का उपयोग करना, आप किसी भी प्रोग्रामिंग भाषा में स्क्रिप्ट का उपयोग कर सकते हैं:

टिकट बनाएँ;
टिकट के किसी भी गुण को संशोधित करें (अंतर्निहित और कस्टम);
टिप्पणियाँ लिखें;
किसी भी टिकट सूची प्राप्त करने के लिए JQL (अंतर्निहित क्वेरी भाषा) का उपयोग करना;
और भी बहुत कुछ।

विस्तृत एपीआई प्रलेखन यहाँ उपलब्ध है ।

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

 public function addComment($issue_key, $comment) {  return $this->_post("issue/{$issue_key}/comment", ['body' => $comment]); } public function updateComment($issue_key, $comment_id, $new_text) {  return $this->_put("issue/{$issue_key}/comment/{$comment_id}", ['body' => $new_text]); } public function deleteComment($issue_key, $comment_id) {  return $this->_delete("issue/{$issue_key}/comment/{$comment_id}"); }

Webhooks

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

परिणामस्वरूप, आप इस तरह के नियम बना सकते हैं:

नाम : "एसआरवी - नया फीचर बनाया / अपडेट किया गया"
URL : www.myremoteapp.com/webhookreceiver
स्कोप : प्रोजेक्ट = एसआरवी और टाइप ('नई सुविधा')
घटनाक्रम : मुद्दा अद्यतन, मुद्दा बनाया गया

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

यह समझना महत्वपूर्ण है कि जीरा यह गारंटी नहीं देता है कि आपका ईवेंट वितरित किया जाएगा। यदि बाहरी URL ने किसी त्रुटि के साथ प्रतिक्रिया या उत्तर नहीं दिया, तो यह कहीं भी दिखाई नहीं देगा (लॉग को छोड़कर, शायद)। इसलिए, webhook घटना हैंडलर जितना संभव हो उतना विश्वसनीय होना चाहिए। उदाहरण के लिए, आप ईवेंट को कतारबद्ध कर सकते हैं और उन्हें तब तक संसाधित करने का प्रयास कर सकते हैं जब तक कि वह सफल न हो जाए। यह अस्थायी रूप से अनुपलब्ध सेवाओं के साथ समस्याओं को हल करने में मदद करेगा, उदाहरण के लिए, घटना के सही प्रसंस्करण के लिए आवश्यक कोई भी बाहरी डेटाबेस।

वेबहूक पर विस्तृत प्रलेखन यहाँ उपलब्ध है ।

ScriptRunner

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

जो इच्छुक हैं वे दस्तावेज पढ़ सकते हैं।

प्रवाह: हुड के नीचे क्या छिपा है

और अब इस बारे में कि हम अपनी परियोजनाओं में जीरा की अतिरिक्त विशेषताओं को कैसे लागू करते हैं। निर्माण से समापन तक हमारे विशिष्ट प्रवाह टिकट के माध्यम से जाने के संदर्भ में इस पर विचार करें। उसी समय मैं आपको स्वयं प्रवाह के बारे में बताऊंगा।

खुला / बैकलॉग

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

Project = SRV AND assignee is EMPTY AND status in (Open)

प्रगति में है

गिट के साथ काम करने की तकनीकी बारीकियां

यह ध्यान दिया जाना चाहिए कि हम प्रत्येक कार्य पर एक अलग गिट शाखा में काम करते हैं। इसके लिए, हमारा एक अनुबंध है कि शुरुआत में शाखा का नाम टिकट नंबर होना चाहिए। उदाहरण के लिए, SRV-123_new_super_feature । साथ ही, शाखा में प्रत्येक कमेंट के लिए प्रारूप [SRV-123]: {टिप्पणी} में टिकट नंबर होना चाहिए। हमें इस तरह के प्रारूप की आवश्यकता है, उदाहरण के लिए, एक बिल्ड से "खराब" कार्य को सही तरीके से हटाने के लिए। यह कैसे किया जाता है लेख में विस्तार से वर्णित किया गया है।

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

 #!/bin/bash b=`git symbolic-ref HEAD| sed -e 's|^refs/heads/||' | sed -e 's|_.*||'` c=`cat $1` if [ -n "$b" ] && [[ "$c" != "[$b]:"* ]] then echo "[$b]: $c" > $1 fi

यदि आप एक "गलत" टिप्पणी के साथ एक कमिट पुश करने की कोशिश करते हैं, तो इस तरह के एक पुश को अस्वीकार कर दिया जाएगा। शुरुआत में बिना टिकट नंबर के शाखा शुरू करने का प्रयास भी अस्वीकार कर दिया जाएगा।

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

हमारे लिए प्रथागत स्थिति में स्थानांतरित होने पर नियत दिनांक को कार्य को निर्धारित करने की प्रथा है। यदि डेवलपर ने ऐसा नहीं किया, तो वह हिपचैट कॉर्पोरेट मैसेंजर में एक अनुस्मारक प्राप्त करेगा। हर दो घंटे में एक विशेष स्क्रिप्ट:

Jira REST API का उपयोग करने से खाली स्थिति वाले क्षेत्र ( प्रोजेक्ट = SRV और स्थिति = 'प्रगति में' और diedate EMPTY ) के साथ प्रगति की स्थिति में टिकट का चयन करता है;
वर्तमान तिथि ( परियोजना = SRV और स्थिति = 'प्रगति में) की तुलना में पुरानी तारीख के साथ अधूरे टिकट का चयन करता है और डीपीईट EMPTY और duedate नहीं है <(अब );
टिकट में संबंधित क्षेत्र को पढ़ने के साथ-साथ डेवलपर की अगुवाई के लिए प्रत्येक टिकट के लिए डेवलपर को पहचानता है;
डेवलपर्स और लीड द्वारा टिकट टिकट और इसके एपीआई का उपयोग करके हिपचैट को अनुस्मारक भेजता है।

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

हमारे नियमों का अनुपालन करने के लिए, गिट शाखा का नाम, साथ ही साथ कमेंट पर टिप्पणी की जाँच की जाती है;
यह जाँच की जाती है कि जिस टिकट के साथ शाखा जुड़ी है वह बंद नहीं है (आप नए कोड को बंद टिकटों में नहीं धकेल सकते हैं);
संशोधित PHP फ़ाइलों के सिंटैक्स की जाँच की जाती है (PHP -l file_name.php );
स्वरूपण की जाँच की जाती है;
यदि टिकट जिस शाखा में धकेल दिया जाता है, वह खुली स्थिति में है, तो यह स्वतः ही प्रगति की स्थिति में स्थानांतरित हो जाएगा;
टिकट शाखा से जुड़ा हुआ है, इसी प्रविष्टि को जीरा एपीआई का उपयोग करके कमिट टिकट के कस्टम क्षेत्र में बनाया गया है। यह इस तरह दिखता है:

( ब्रांचडिफ़ उस शाखा के सिर के साथ अंतर करने के लिए एक लिंक है जिसमें से वर्तमान शाखा हमारे कोडिसोक कोड समीक्षा टूल में उत्पन्न हुई है);

इस पुश में सभी कमिट के साथ टिकट में एक टिप्पणी बनाई गई है।

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

समीक्षा करने पर

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

समीक्षक कुछ इस तरह देखता है:

समीक्षा समाप्त होने के बाद, समीक्षक समाप्त बटन दबाता है, और, अन्य बातों के अलावा, इस समय निम्न होता है:

JIra API का उपयोग करते हुए, कोड के संदर्भ में समीक्षक की टिप्पणियों के साथ टिकट में एक टिप्पणी बनाई जाती है। यह कुछ इस तरह दिखता है:

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

हल

इसके अलावा, यदि समीक्षा सफल रही, तो टिकट को क्यूए इंजीनियरों के बैकलॉग में भेज दिया जाता है। लेकिन एक ही समय में, सुलझी हुई घटना के लिए webhook का उपयोग करते हुए, शाखा कोड पर स्वचालित परीक्षण पृष्ठभूमि में लॉन्च किए जाते हैं। कुछ मिनटों के बाद, टिकट में एक नई टिप्पणी दिखाई देगी, जो आपको परीक्षा परिणामों की सूचना देगी।

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

वास्तव में, यह बटन जीरा वर्कफ़्लो में अतिरिक्त कार्य स्थितियों में से एक है, एक अनुवाद जिसमें ScriptRunner प्लगइन के लिए एक ग्रूवी स्क्रिप्ट को ट्रिगर किया गया है। स्क्रिप्ट एक बाहरी URL कहती है, जो टेस्ट रन शुरू करती है, और यदि URL ने सफलतापूर्वक जवाब दिया, तो टिकट अपनी पिछली स्थिति (हमारे मामले में, हल किए गए ) पर वापस आ जाता है।

शॉट में / शॉट में - ठीक है

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

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

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

यदि शॉट में परीक्षण सफल रहा, तो टिकट को स्टेटस इन शॉट - ओके में स्थानांतरित कर दिया जाता है ।

बिल्ड / इन बिल्ड - ओके

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

बिल्ड शाखा के निर्माण के समय, JQL क्वेरी का उपयोग करने वाली एक विशेष स्क्रिप्ट को इन शॉट में टिकटों की एक सूची प्राप्त होती है - ठीक स्थिति और निम्न सभी शर्तों के पूरा होने पर बिल्ड शाखा में उन्हें फ्रीज करने की कोशिश करता है:

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

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

यदि सब कुछ ठीक है और टिकट शाखा बिल्ड में जमी हुई है, तो टिकट स्वचालित रूप से इन बिल्ड स्थिति में स्थानांतरित हो जाता है, और बिल्ड का नाम बिल्ड_Name टिकट के कस्टम फ़ील्ड में लिखा जाता है।

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

अगले चरण में, क्यूए इंजीनियर अतिरिक्त जाँच करते हैं कि क्या कार्य कोड बिल्ड में अन्य कार्यों के साथ संयोजन में सही ढंग से काम करता है या नहीं। यदि सब कुछ ठीक है, तो टिकट मैन्युअल रूप से इन बिल्ड - ओके पर सेट हो जाता है ।

उत्पादन पर / उत्पादन पर - ठीक / बंद

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

इसके अलावा, डेवलपर (या ग्राहक) यह सुनिश्चित करता है कि सुविधा उत्पादन पर सही ढंग से काम करती है, और टिकट की स्थिति को उत्पादन पर सेट करती है - ठीक है।

दो सप्ताह के बाद, ऑन-प्रोडक्शन में टिकट - ओके स्थिति स्वचालित रूप से बंद स्थिति में स्थानांतरित हो जाती है, अगर किसी ने पहले मैन्युअल रूप से ऐसा नहीं किया है।

यह उन अतिरिक्त स्थितियों का भी उल्लेख करने योग्य है जिसमें टिकट स्थित हो सकता है:

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

परिणामस्वरूप, हमारे वर्कफ़्लो का एक सरलीकृत आरेख इस तरह दिखता है:

टिकट - कार्य के लिए संचार केंद्र

प्रवाह के माध्यम से टिकट पास करने के परिणामस्वरूप, इसका हेडर लगभग निम्नलिखित फॉर्म प्राप्त करता है:

यहाँ और क्या दिलचस्प है जिसे हमने अपने लिए अनुकूलित किया है और जिसका मैंने अभी तक उल्लेख नहीं किया है?

घटक - एक बड़े विभाग के भीतर एक टिकट क्लस्टर करने के लिए उपयोग किया जाता है। विभिन्न उपसमूह विभिन्न घटकों के लिए जिम्मेदार हैं और, तदनुसार, अपने डैशबोर्ड पर वे अपने घटकों के लिए केवल कार्य देखते हैं। उदाहरण के लिए, मैं इस प्रश्न के साथ अपनी टीम के घटकों के लिए सभी खुले बगों को सूचीबद्ध कर सकता हूं:
```
 Project = SRV AND type = Bug AND status = Open AND component in componentsLeadByUser(d.semenihin) 
```
समीक्षा - क्या कोड समीक्षा की आवश्यकता है। डिफ़ॉल्ट की जरूरत है। यदि फ़ील्ड मान नहीं पर सेट है , तो टिकट तुरंत हल की स्थिति प्राप्त कर लेगा ।

QA - क्या परीक्षक को सत्यापन की आवश्यकता है। डिफ़ॉल्ट की जरूरत है। यदि फ़ील्ड मान नहीं पर सेट है , तो टिकट तुरंत इन शॉट - ओके स्थिति में जाएगा ।

स्प्रिंट - हमारे मामले में, यह केवल नए फ़ीचर प्रकार के कार्यों के लिए प्रासंगिक है, एक योजना जिसके लिए हम एक सप्ताह के लिए अग्रिम में तैयार करते हैं।
नियत तिथि - डेवलपर उस तिथि को निर्धारित करता है जब टिकट उत्पादन पर होगा। कार्य शुरू करने से पहले प्रदर्शित किया जाता है।
स्थिति - वास्तव में, कार्य की वर्तमान स्थिति के संक्षिप्त विवरण के साथ एक लघु लॉग। उदाहरण के लिए, "20/08 मैं अनुवाद के लिए इंतजार कर रहा हूँ" , "21/08 समस्या एक्स पर ग्राहक से स्पष्टीकरण की आवश्यकता है" । यह अन्य कार्यों की सूची में कार्य का एक संक्षिप्त सारांश देखने में मदद करता है।
Msg4QA - क्यूए इंजीनियरों के लिए जानकारी, जो डेवलपर परीक्षण प्रक्रिया को सरल बनाने के लिए साझा करता है

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

"मानव" ग्रंथों के अलावा, जैसा कि मैंने ऊपर उल्लेख किया है, एपीआई का उपयोग करके बहुत सी चीजें स्वचालित रूप से एक टिप्पणी में लिखी जाती हैं:

करता;
परिणामों की समीक्षा करें;
परीक्षण चलाने के परिणाम।

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

उस स्क्रिप्ट का जेएस कोड जिसे हम टिकट टेम्पलेट में एम्बेड करते हैं

 window.addEventListener('load', () => {   const $ = window.jQuery;   const botsAttrMatch = [       'aida',       'itops.api'   ].map(bot => `[rel="${bot}"]`).join(',');   if (!$) {       return;   }   const AIDA_COLLAPSE_KEY = 'aida-collapsed';   const COMMENT_SELECTOR = '.issue-data-block.activity-comment.twixi-block';   const JiraImprovements = {       init() {           this.addButtons();           this.handleAidaCollapsing();           this.handleCommentExpansion();           // Handle toggle button and aida collapsing and put it on a loop           // to handle unexpected JIRA behaviour           const self = this;           setInterval(function () {               self.addButtons();               self.handleAidaCollapsing();           }, 2000);           addCss(`               #badoo-toggle-bots {                   background: #fff2c9;                   color: #594300;                   border-radius: 0 3px 0 0;                   margin-top: 3px;                   display: inline-block;               }           `);       },       addButtons() {           // Do we already have the button?           if ($('#badoo-toggle-bots').length > 0) {               return;           }           // const headerOps = $('ul#opsbar-opsbar-operations');           const jiraHeader = $('#issue-tabs');           // Only add it in ticket state           if (jiraHeader.length > 0) {               const li = $('<a id="badoo-toggle-bots" class="aui-button aui-button-primary aui-style" href="/">Collapse Bots</a>');               li.on('click', this.toggleAidaCollapsing.bind(this));               jiraHeader.append(li);           }       },       toggleAidaCollapsing(e) {           e.preventDefault();           const isCollapsed = localStorage.getItem(AIDA_COLLAPSE_KEY) === 'true';           localStorage.setItem(AIDA_COLLAPSE_KEY, !isCollapsed);           this.handleAidaCollapsing();       },       handleAidaCollapsing() {           const isCollapsed = localStorage.getItem(AIDA_COLLAPSE_KEY) === 'true';           const aidaComments = $(COMMENT_SELECTOR).has(botsAttrMatch).not('.manual-toggle');           if (isCollapsed) {               aidaComments.removeClass('expanded').addClass('collapsed');               $('#badoo-toggle-bots').text('Show Bots');           }           else {               aidaComments.removeClass('collapsed').addClass('expanded');               $('#badoo-toggle-bots').text('Collapse Bots');           }       },       handleCommentExpansion() {           $(document.body).delegate('a.collapsed-comments', 'click', function () {               const self = this; // eslint-disable-line no-invalid-this               let triesLeft = 100;               const interval = setInterval(() => {                   if (--triesLeft < 0 || self.offsetHeight === 0) {                       clearInterval(interval);                   }                   // Element has been removed from DOM. ie new jira comments have been added                   if (self.offsetHeight === 0) {                       JiraImprovements.handleAidaCollapsing();                   }               }, 100);           });           $(document.body).delegate(COMMENT_SELECTOR, 'click', function () {               $(this).addClass('manual-toggle');// eslint-disable-line no-invalid-this           });       }   };   JiraImprovements.init();   function addCss(cssText) {       const style = document.createElement('style');       style.type = 'text/css';       if (style.styleSheet) {           style.styleSheet.cssText = cssText;       }       else {           style.appendChild(document.createTextNode(cssText));       }       document.head.appendChild(style);   } });

और क्या?

API webhooks Jira :

HipChat, - ( );
HipChat ( , );
( ) ( ; );
; , ;
In progress ;
, «» (, On Review), ;
, Jira (, «d.semenihin (Day off)»). .

परिणाम

Jira — , , . , , . Jira , .

— . Jira , Jira. , - .

आपका ध्यान के लिए धन्यवाद!

जीरा को अपनी आवश्यकताओं के अनुरूप बनाना। सही प्रवाह और सही टिकट