रिलीज प्रबंधन - सर्वोत्तम अभ्यास

Question

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

Answer 1

हम सबवर्सन का उपयोग करते हैं, जहां टैग और शाखाएं बनाने के लिए सस्ते होती हैं।

जहाँ तक रिलीज का सवाल है, हम इस परिपाटी निम्न हैं:

(मेजर रिलीज) (माइनर रिलीज) (पैच रिलीज) (SVN संशोधन)

• पैच रिलीज = बग फिक्स
।।।
• मामूली रिलीज = बाइनरी संगत/ इंटरफेस संगत
• प्रमुख रिलीज = परिवर्तन तोड़ना शामिल है।

क्या यह समझ में आता है? अगर आपको अधिक जानकारी चाहिए, तो एक टिप्पणी जोड़ें और मैं अपनी पोस्ट को स्पष्टीकरण के लिए संपादित कर दूंगा।

Answer 2

मेरी कंपनी में, जब एक रिलीज तैयार होता है, तो हम प्रमुख/मामूली रिलीज संख्याओं के लिए एक शाखा बनाते हैं, जिसे R_2_1 जैसे कुछ कहा जाता है। प्रारंभिक रिलीज स्नैपशॉट शाखा या तुरंत लेबल करके किया जाता है, जिसे R_2_1_0 कहा जाता है। जब क्यूए एक रिलीज के खिलाफ बग फाइल करता है, तो R_X_Y शाखा पर कोड परिवर्तन किए जाते हैं, और फिर उस रिलीज को चिह्नित करने के लिए R_2_1_1 शाखा बनाई जाती है। तो पेड़ इस तरह दिखता है:

Mainline 
| 
|- R_2_1 
| | 
| |-R_2_1_0 (locked) 
| | 
| | 
| |-R_2_1_1 (locked) 
| | 
. . 
. . 
. . 

Answer 3

मैं एक कस्टम सॉफ्टवेयर प्रदाता है कि अंततः एक समाधान प्रदाता में बदल गया जब ग्राहकों फैसला किया है कि वे अपने स्वयं के callcenters और वेबसाइटों को लागू नहीं करना चाहता था के लिए काम किया।

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

यह ठीक काम करता है, जब तक व्यवसाय बढ़ता नहीं है और शाखाओं की संख्या का विस्तार होता है, अक्सर वास्तव में लंगर परिवर्तनों को समायोजित करने के लिए। एक बिंदु पर मुझे लगता है कि उनके पास एक ही कोडबेस के 15 अलग-अलग सक्रिय संस्करणों की तरह कुछ था ... जिसने चीजों को वास्तव में लचीला और समर्थन करना मुश्किल बना दिया।

हमारे द्वारा किए गए कार्यों को न करें - अपनी रिलीज स्केल करें!

Answer 4

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

रिलीज स्रोत शाखा से कॉपी की गई शाखाओं में छोटे पैच बनाए जाते हैं, और ट्रंक में विलय हो जाते हैं। रिलीज स्रोत शाखा को एक नई शाखा में कॉपी करके और जो भी पैच की आवश्यकता होती है, में विलय करके आसानी से एक मामूली रिलीज किया जा सकता है।

ट्रंक से कॉपी की गई शाखाओं में प्रमुख काम किया जाता है, और पूर्ण होने पर ट्रंक में वापस विलय कर दिया जाता है। तब प्रमुख रिलीज ट्रंक से किए जा सकते हैं।

Answer 5

आईटीआईएल ढांचे पर आधारित एक उत्तर (जो कि अन्य लोगों के बराबर या कम है)।

आईटीआईएल 3 समूहों में रिलीज वर्गीकृत करता है: प्रमुख सॉफ्टवेयर रिलीज, मामूली सॉफ्टवेयर रिलीज और आपातकालीन सॉफ्टवेयर फिक्स।

आईटीआईएल पुस्तकों से

:

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

तो निम्नलिखित इस आप होना चाहिए:

मेजर: V1, V2, v3, आदि
माइनर: v1 .1, वी 2.1, आदि
आपातकाल: v1.1.1, वी 2.1.1, आदि ..

Answer 6

जैसा कि अन्य ने कहा, पुनर्विक्रय प्रबंधन के साथ निपटने का सबसे अच्छा तरीका शाखाकरण द्वारा है। मैं अत्यधिक टीएफएस ब्रांचिंग गाइड (http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785) पर एक नज़र डालने की सलाह देता हूं जो आपकी परियोजनाओं के आकार और अंतिम सॉफ्टवेयर (प्रमुख रिलीज, सर्विस पैक, हॉटफिक्सेस) को आपके सॉफ़्टवेयर प्रदान करने के विभिन्न तरीकों के आधार पर शाखा संरचना बनाने के कई दृष्टिकोण बताता है।)। अधिकांश टीएफएस के लिए विशिष्ट नहीं है, इसलिए आप इसे अन्य स्रोत नियंत्रण प्रणालियों पर लागू कर सकते हैं।

Answer 7

I created a similar question, लेकिन मैं इसे जोड़ना चाहता था: मैं रिलीज चक्र का प्रबंधन करने के लिए Jira जैसे कुछ का उपयोग करने की दृढ़ता से अनुशंसा करता हूं। आप अनुरोध/मुद्दों/बग के साथ काम को जोड़ सकते हैं, और फिर रिलीज के हिस्से के रूप में उन्हें ध्वजांकित कर सकते हैं।

विशेष रूप से, यदि आप एक अच्छा रिलीज चक्र प्रबंधित करने के बारे में जानना चाहते हैं, तो देखें कि अपाचे नींव यह कैसे करती है, क्योंकि उनके पास यह विज्ञान है। उदाहरण के लिए, यहां roadmap for releases in the Mahout project है।

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

Answer 8

टीएफएस के संबंध में सह-बिल्ली के उत्तर का पालन-पोषण। कम से कम, Git वैसे भी उपयोग कर लेने के बाद नहीं और VS2010 के लिए कुछ अद्यतन के साथ एक नया URL VS11

http://vsarbranchingguide.codeplex.com/releases