जिरा परियोजनाओं में घटकों का उपयोग करने का सर्वोत्तम अभ्यास

Question

हम अपने दिन के विकास में जिरा का भारी उपयोग कर रहे हैं। मैं देखना चाहता हूं कि जिरा में परियोजना घटकों को बनाने में कोई सर्वोत्तम प्रथा है या नहीं?

उदाहरण के लिए, आपकी राय में, क्या जिरा में प्रत्येक विकास मॉड्यूल के लिए एक घटक बनाना बेहतर है या शायद आपकी टीम द्वारा बेहतर अनाज वाले घटक पसंद किए जाते हैं?

Answer 1

मैं आपके मॉड्यूल/कलाकृतियों/जारों के साथ घटकों का मिलान करूंगा, इसलिए प्रत्येक समस्या का एक विशेष मॉड्यूल स्वामित्व हो सकता है (हालांकि इसमें अन्य लोगों के साथ निर्भरता/संबंध भी हो सकते हैं)।

यदि आप मॉड्यूल स्तर की तुलना में बेहतर अनाज वाले मुद्दे प्रबंधन के लिए एक मजबूत मामला बना सकते हैं, तो विचार करें कि आप संबंधित मॉड्यूल को अलग क्यों नहीं करेंगे।

यह 1-1 मैपिंग होने से आपके रिलीज शेड्यूल को स्पष्ट करने में मदद मिलती है, आप आसानी से अपने प्रोजेक्ट के संस्करण एक्स को क्या समस्याएं दे सकते हैं, और कौन से मॉड्यूल पर ध्यान केंद्रित करने के लिए मॉड्यूल हैं। यह जिरा, बिल्ड सिस्टम और एससीएम के बीच एसोसिएशन को सरल बनाने में भी मदद करता है, उदाहरण के लिए यदि आप बांस का उपयोग कर रहे हैं तो आपके पास प्रति मॉड्यूल एक बिल्ड प्रोजेक्ट होगा, ताकि आप बस एसोसिएशन जोड़ सकें।

Answer 2

घटक छोटी उप-परियोजनाओं की तरह हैं। परियोजनाएं सबसे उपयोगी प्रतीत होती हैं जब वे लोगों को एक साथ समूहित करते हैं। मैं अपने ग्राहकों को सलाह देता हूं कि जेआईआरए परियोजनाएं कुछ हद तक सामाजिक संगठन को प्रतिबिंबित करती हैं, कम से कम परियोजनाओं की संख्या बहुत बड़ी हो जाती है।

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

Answer 3

प्रत्येक प्रमुख मॉड्यूल, या यहां तक ​​कि सिस्टम स्तरीय (उदाहरण के लिए बैकएंड, फ्रंटएंड) के लिए एक घटक बनाएं। मैं नीचे-मॉड्यूल-स्तर ग्रैन्युलरिटी नहीं जाऊंगा। आप इस तरह के बीए के रूप में समर्थन गतिविधियों के लिए घटकों को जोड़ सकते हैं, परीक्षण (mdoar साथ सहमत हो) ... अवयव संस्करण के लिए ओर्थोगोनल/विज्ञप्ति

Answer 4

घटकों के बारे में सबसे महत्वपूर्ण है स्पष्ट और भी कई नहीं हो रहा है। शीर्ष स्तर पर आप बीए घटकों जो कुछ और टीम (बुनियादी, बैकएंड, जीयूआई) द्वारा पृथक किए गए हैं पर

• - यह मदद करता है: अब हमारी टीम में, हम (GreenHopper अर्थ में) 3 स्तर पदानुक्रम की ओर पलायन कर रहे हैं बीए लोग घटक लीड के रूप में असाइन किए गए सही DEV-Team प्रबंधक को अनुरोध को रूट करते हैं।
• दूसरा स्तर वास्तविक प्रक्रिया है (यूनिक्स अर्थ में)। यह बहुत स्पष्ट परिभाषा है। यदि किसी समस्या को कई प्रक्रियाओं में मैप किया जाता है, तो हम इसे उनमें से एक को सौंप देते हैं (बीटीडब्ल्यू, ग्रीनहोपर कई पत्ते के घटकों की अनुमति नहीं देता है, लेकिन सादा जिरा करता है)। यह DEV प्रबंधक द्वारा किया जाता है।
• तीसरा स्तर वैकल्पिक है और शायद ही कभी उपयोग किया जाता है, प्रक्रिया के भीतर उपप्रणाली को दर्शाता है। हम इसका उपयोग करते हैं जब मुद्दों का एक बड़ा हिस्सा कोड के एक अच्छी तरह से परिभाषित हिस्से से संबंधित होता है और हम उन्हें अलग से ट्रैक करना चाहते हैं। यह आमतौर पर इस मुद्दे पर काम कर रहे डेवलपर द्वारा किया जाता है।

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

Answer 5

हम उपयोग करते हैं एक 2 लेवल घटक पदानुक्रम (हरे रंग की दुकान के लिए धन्यवाद ...) - थीम्स और महाकाव्य। ग्रीनहोपर थीम्स और एपिक्स में निर्माण हमें जिस तरह से हम चाहते हैं उसे समेकित करने और रिपोर्ट करने की अनुमति नहीं देते हैं, और यह चाल बहुत अच्छी तरह से करता है।

Answer 6

4.2.4 के रूप में संस्करण घटकों, केवल परियोजनाओं के लिए संभव नहीं है। यदि आप सड़क मानचित्र सुविधा का उपयोग करना चाहते हैं तो इसे ध्यान में रखें।

एक लंबे समय से (7+ वर्ष) घटकों के लिए संस्करण जोड़ने के लिए अनुरोध नहीं है:

http://jira.atlassian.com/browse/JRA-3501

Answer 7

मुझे मिल गया है एक और अब घटकों पर ले लो।
ग्राहकों के साथ मैं के रूप में घटक क्षेत्र का संदर्भ लें:

A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.

और फिर मैं कहता हूँ:

If you don't care about automatic assignment, just treat the components field as a convenient system field.

तो फिर से मूल सवाल का जवाब देने, अपने आप से पूछना अगर तुम से मुद्दों आवंटित टीम या आपके द्वारा संदर्भित ठीक स्तर से?
शायद पूर्व।

Answer 8

जेआईआरए प्रोजेक्ट के प्रत्येक घटक को संस्करण संख्याओं के समान सेट रखने के लिए डिज़ाइन किया गया है, इसलिए यदि आप चाहते हैं कि घटक आपके पास स्वतंत्र संस्करण संख्याएं हों तो आपको या तो प्रत्येक घटक के लिए एक अलग परियोजना स्थापित करने या मेरे द्वारा विकसित प्लगइन का उपयोग करने की आवश्यकता है जो घटक विशिष्ट संस्करण संख्याओं की अनुमति देता है और साथ ही घटकों के समूह को बंडल में अनुमति देता है। प्लगइन "Component/Subcomponents/Bundle Versions for JIRA" है और एटलसियन बाज़ार में उपलब्ध है। अधिक जानकारी atlassian plugins help page पर उपलब्ध है। एक और विकल्प टीम के प्रत्येक घटक को संस्करण संख्याओं का एक ही सेट रखने के लिए मजबूर करना है। अन्यथा घटकों के लिए सही संस्करण संख्याओं का चयन करना बहुत मुश्किल है।