हम कई टीमों के साथ एक छोटी-ईश फर्म हैं जो अपने स्वयं के गिट रिपॉजिटरी का प्रबंधन करते हैं। यह एक वेब प्लेटफॉर्म है और प्रत्येक टीम की कलाकृतियों को रात के परीक्षणों के लिए दिन के अंत में तैनात किया जाता है। हम संस्करण और पैकेजिंग के आसपास की प्रक्रिया को औपचारिक बनाने की कोशिश कर रहे हैं।
प्रत्येक टीम की एक मास्टर शाखा होती है जहाँ वे दिन-प्रतिदिन विकास करते हैं। प्रत्येक टीम के गुणवत्ता आश्वासन सदस्य चाहते हैं कि उनकी टीम के बदलावों से कलाकृतियों को एक परीक्षण बिस्तर में तैनात किया जाए जहां सभी घटकों को शेफ द्वारा संयोजित किया जाता है। कलाकृतियाँ टारबॉल हैं लेकिन मैं उन्हें RPM में बदलना चाहता हूँ ताकि हम सोच सकें और संस्करणों के बारे में सही तरीके से जान सकें।
रिलीज की प्रक्रिया में प्रत्येक गिट रिपॉजिटरी के विकास शाखा (ज्यादातर मामलों में मास्टर) से एक रिलीज शाखा को काटना शामिल है। इसके बाद गुणवत्ता आश्वासन दिया जाता है जो कलाकृतियों के सेट पर परीक्षण और साइन-ऑफ चलाते हैं।
उदाहरण के लिए, यह संबंधित रिलीज़ शाखाओं के साथ एक विशिष्ट गिट रिपॉजिटरी है:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
मैं विकास शाखाओं से आने वाले पैकेजों के संस्करण का प्रदर्शन करने के लिए एक योजना का पता लगाने की कोशिश कर रहा हूं। हम प्रत्येक रेपो की मास्टर शाखा को अत्यधिक टैग नहीं करना चाहते हैं और केवल टैग जारी करने के लिए टैग को प्रतिबंधित करते हैं। लेकिन हमें मानक यम / आरपीएम शब्दार्थ का उपयोग करके परीक्षण मशीनों में तैनात पैकेजों को क्वेरी करने में सक्षम होना चाहिए। जब मास्टर शाखा के पास कोई टैग नहीं है तो विकास संस्करण क्या दिखेंगे? मैं समझता हूं कि git describeमुझे बिल्ड वर्जन का एक उपयोगी प्रतिनिधित्व प्रदान किया जा सकता है लेकिन यह तब अच्छा काम करता है जब ब्रांच पर विभिन्न रिलीज़ पॉइंट्स टैग किए जाते हैं।
EDIT1: @ Urban48 के जवाब के जवाब में
मुझे लगा कि मुझे अपनी रिलीज़ प्रक्रिया को थोड़ा और स्पष्ट करना चाहिए। इस चर्चा के प्रयोजनों के लिए मान लें कि हमारे पास masterसभी रिपॉजिटरी में शाखा है। masterशाखा विकास शाखा माना जाता है और एक स्वचालित सीआई-सीडी के लिए तैनात किया गया है क्यूए वातावरण सक्षम होना चाहिए। यह वह जगह है जहाँ रात के परीक्षणों का एक सबसेट मास्टर की स्थिरता सुनिश्चित करने के लिए चलता है। हम रिलीज शाखा को काटने से पहले नौकरियों की इस पाइपलाइन को देखते हैं। हमारी रिलीज़ शाखाएँ अल्पकालिक हैं। कहते हैं, एक रिलीज शाखा (एक स्थिर मास्टर से) काटने के बाद, एक पूर्ण प्रतिगमन चलाया जाता है, फ़िक्स को बनाया जाता है और उत्पादन के लिए तैनात किया जाता है। ऐसा करने में लगभग एक सप्ताह का समय लगता है। हम उत्पादन के लिए लगभग हर दो सप्ताह में रिलीज करते हैं।
हमारी सुविधा शाखाओं को हमेशा मास्टर से काट दिया जाता है और मास्टर के साथ विलय से पहले डेवलपर परीक्षण की कुछ मात्रा से गुजरना होता है, जिस पर वे CI-CD स्थिरता जांच से गुजरते हैं।
हॉटफ़िक्स को हॉटफ़िक्स शाखाओं (रिलीज़ शाखाओं से कट) पर बनाया जाता है और उत्पादन में न्यूनतम प्रभाव परीक्षण के साथ तैनात किया जाता है।
रिलीज़ और हॉटफ़िक्स शाखाओं के लिए हमारी संस्करण रणनीति सेवर का अनुसरण करती है। क्यूए चक्र के दौरान रिलीज शाखाएं जैसे संस्करणों के माध्यम से जाती हैं v2.0.0-rc1, v2.0.0-rc2और आखिरकार क्यूए साइन-ऑफ बनने के बाद v2.0.0।
हम कभी-कभी छोटे फीचर्स के लिए रिलीज़ डेटेड करते हैं जो कि रिलीज़ होने वाली शाखाओं (और फिर मास्टर) में विलय हो जाते हैं जहाँ संस्करण बन जाते हैं v2.1.0। और हॉटफिक्सेस v2.1.1पैटर्न ग्रहण करते हैं ।
हालाँकि, यह सवाल इन शाखाओं के संस्करण के बारे में नहीं है। मैं इस संस्करण योजना को पूरी तरह से नहीं बदलना पसंद करूंगा। एकमात्र परिवर्तन विकास शाखा के बारे में आता है। गुरुजी। मैं CI-CD वातावरण में मज़बूती से कैसे संकेत दे सकता हूं कि कौन सा संस्करण मौजूद है जो उत्पादन में पिछली रिलीज़ को प्रदर्शित करता है। यह आदर्श रूप से स्मार्ट गिट टैगिंग के माध्यम से किया जाएगा, लेकिन ऐसा कुछ जो मास्टर शाखा को अत्यधिक टैग नहीं करता है।
rcप्रत्यय से पहले क्या होगा ? यह major.minorविकास संस्करण तय करेगा । rcऔर बिल्ड नंबर केवल उसी के आधार पर प्राप्त किया जा सकता है। इसके अलावा rc, गुरु से कोई मतलब नहीं है क्योंकि हम कभी भी गुरु से मुक्त नहीं होते हैं। हम अपनी रिहाई के उम्मीदवारों को आज रिलीज चक्र के कुछ हिस्सों के रूप में रिलीज शाखाओं पर टैग करते हैं
rcप्रत्यय होगा।
