एसवीएन में टैग सस्ते हैं। क्या वे हमारे सीआई बॉक्स (टीमसिटी, अगर इससे कोई फर्क पड़ता है) से बाहर निकलने वाले हर सफल निर्माण को टैग करने में सक्षम होने के लिए पर्याप्त सस्ते हैं?क्या हमें हर सफल सीआई निर्माण के बाद हमारे एसवीएन रेपो को टैग करना चाहिए?
मेरा उत्तर नहीं है। यह एसवीएन विशिष्ट नहीं है, यह सिर्फ अच्छा अभ्यास विशिष्ट है।
सीआई बनाता निर्माण या संस्करण संख्या को नहीं बढ़ाया जाना चाहिए - वे सिर्फ एक मानसिक स्वास्थ्य की जांच है कि सब कुछ बनाता हैं (हे, यह हो सकता है नहीं रन है)। सीआई बिल्डिंग टैगिंग में बिल्कुल कोई बात नहीं है।
संपादित करें:
हमारे क्यूए विभाग सीआई बॉक्स के अगले उपलब्ध निर्माण लेने
आपका क्यूए विभाग, एक सीआई का निर्माण नहीं छू जाना चाहिए बजाय वे के साथ काम किया जाना चाहिए रिलीज गुणवत्ता बनाता है, जो अक्सर सीआई बिल्डों की तुलना में उनके साथ अधिक किया जाता है (यानी संस्करण संख्याएं जहां उचित हो गई हैं, डीबग के बजाए रिलीज मोड में संकलन किया गया है)। याद रखें कि सीआई बिल्ड संकलित कर सकते हैं, लेकिन स्रोत भंडार में क्या चेक किया गया है, इस पर निर्भर करता है कि वे जंक का ढेर हो सकते हैं।
ऐसा लगता है कि आप सीआई बिल्ड के रूप में संदर्भित करते हैं, इसे केवल बनाएं, क्योंकि यह केवल एक ही है जिसे आप कर रहे हैं। यह निर्माण का एक अच्छा सेट एक साथ रखने के लिए थोड़ा सा काम है, लेकिन यह प्रयास के लायक है, इसके बारे में कई ट्यूटोरियल और श्वेत पत्र हैं, कुछ समय निवेश करें और इसे पढ़ें, फिर अपना क्यूए विभाग दें हर बार जब वे "सीआई बिल्ड" शब्दों को बोलते हैं (जैसे कि बिल्डर्स केवल डेवलपर्स के उपयोग के लिए होना चाहिए)।
आगे संपादित करें:
लोगों के एक जोड़े टिप्पणी की है "क्यों एक सीआई निर्माण रिहाई गुणवत्ता नहीं किया जा सकता?"। मैं एसओ के लिए अनुपयुक्त चर्चा में इसे बिना किसी संक्षिप्त तरीके से इसका उत्तर देने का प्रयास करूंगा। मुझे पहले कहना है कि निश्चित रूप से एक सीआई निर्माण गुणवत्ता जारी किया जा सकता है। यदि आप इसे प्राप्त कर सकते हैं तो आपके लिए अधिक शक्ति, खुद को एक पदक दें। यदि आप इस श्रेणी में हैं तो मुझे लगता है कि आप धीरे-धीरे बदलते कोडबेस के साथ एक छोटी टीम पर हैं।
Wikipedia के शब्दों में:
सामान्य अभ्यास इन बनाता है हर, भंडार के लिए प्रतिबद्ध द्वारा नहीं बल्कि एक समय-समय पर अनुसूचित निर्माण की तुलना में गति प्रदान करने के लिए है। तेजी से काम करने के एक बहु-डेवलपर वातावरण में ऐसा करने की व्यावहारिकताएं ऐसी होती हैं कि प्रत्येक प्रतिबद्धता के बाद एक छोटा टाइमर ट्रिगर करना सामान्य होता है, फिर जब कोई टाइमर समाप्त हो जाता है, या आखिरी बिल्ड के बाद से अधिक अंतराल के बाद निर्माण शुरू होता है।
और Martin Fowler उद्धृत करने के लिए:
सतत एकीकरण एक सॉफ्टवेयर विकास अभ्यास जहां एक टीम के सदस्य अक्सर अपने काम को एकीकृत है, आम तौर पर प्रत्येक व्यक्ति को कम से कम दैनिक एकीकृत - प्रति दिन कई एकीकरण के लिए अग्रणी । जितनी जल्दी हो सके एकीकरण त्रुटियों का पता लगाने के लिए प्रत्येक एकीकरण को स्वचालित निर्माण (परीक्षण सहित) द्वारा सत्यापित किया जाता है।
उन में से न तो कहते हैं कि एक सीआई निर्माण रिहाई गुणवत्ता नहीं चाहिए। लेकिन न ही उनमें से कोई भी कहता है कि यह होना चाहिए।
एक उचित आकार की टीम में काम करते समय, जो एक ही शाखा से काम कर रहे हैं, यह प्रत्येक सीआई निर्माण के साथ रिलीज गुणवत्ता प्राप्त करने के लिए जल्दी ही अव्यवहारिक हो जाता है। सीआई बिल्डों को चेक-इन के बाद हमेशा एक छोटी अवधि शुरू कर दी जाती है, इस बात की कोई गारंटी नहीं है कि एक टीम के सदस्य ने वास्तव में अपना चेक-इन समाप्त कर दिया है, या कोई और व्यक्ति शुरू नहीं हुआ है जब उस टाइमर खत्म हो जाता है और निर्माण शुरू होता है।
एक और विचार यह ध्यान में रखना है कि एक बड़ी टीम पर काम करते समय सीआईआई विकास शाखा पर निर्माण करता है, जबकि रिलीज/क्यूए गुणवत्ता निर्माण रिलीज या क्यूए शाखा से किया जाता है। यह देव टीम को निर्माण के प्रदूषण के बिना सुविधाओं को कार्यान्वित करने में सक्षम बनाता है कि क्यूए परीक्षण करेगा - जब सुविधाएं पूरी होंगी तो वे उस शाखा में विलय हो जाएंगे जहां क्यूए टीम अपना निर्माण करती है।
मुझे उम्मीद है कि यह सीए बिल्डों के साथ काम नहीं कर रहे क्यूए टीमों के बारे में मेरी टिप्पणी बताता है। कोई और चर्चा वास्तव में programmers.stackexchange.com या अन्य जगहों पर होनी चाहिए।
सीआई बिल्ड रिलीज गुणवत्ता का क्यों नहीं हो सकता है? –
प्रत्येक बिल्ड रिलीज गुणवत्ता होना चाहिए - संभावित रूप से शिप करने योग्य। लेकिन हर निर्माण को टैग करने का कोई अच्छा कारण नहीं है। –
@ इवो, @ रारस, मैंने यह समझाने के लिए एक और संपादन जोड़ा है कि मेरा क्या मतलब है। संक्षेप में, यह सब व्यावहारिक और क्या नहीं है के नीचे आता है। – slugster
चूंकि सबवर्सन अनिवार्य रूप से प्रत्येक संशोधन के लिए वैश्विक संशोधन संख्या में अंतर्निहित टैग है, यह आवश्यक नहीं है।
आप आमतौर पर एक महत्वपूर्ण कदम को चिह्नित करने के लिए टैग करते हैं, न कि निरंतर प्रक्रिया को ट्रैक रखने के लिए।
प्रत्येक बिल्ड टैगिंग के लिए भुगतान क्या होगा? टैग आमतौर पर आपके प्रोजेक्ट के इतिहास में "विशेष"/"महत्वपूर्ण" बिंदुओं को हाइलाइट करने के लिए उपयोग किए जाते हैं - और आमतौर पर स्थिर/केवल-पढ़ने वाले होते हैं। कई टैग्स आपके लिए – Gishu
के लिए जो खोज रहे हैं उसे ढूंढना आपके लिए मुश्किल हो रहा है, जब हम एक बिल्ड करते हैं, तो हमारे क्यूए विभाग सीआई बॉक्स से अगले उपलब्ध निर्माण को चुनते हैं। फिर वे इसे मैन्युअल रूप से परीक्षण करने में कुछ समय बिताते हैं और भविष्य में किसी बिंदु पर कहते हैं, "हां, 1.2.3.4 का निर्माण उत्पादन के लिए ठीक है"। हमें स्रोत नियंत्रण में संस्करण 1.2.3.4 की पहचान करने का एक तरीका चाहिए। –
आप निर्माण के सटीक संशोधन को जानते हैं। आपको टैग की आवश्यकता क्यों है? –