संस्करण नियंत्रण के तहत आप कैसे जारी बायनेरिज़ को जारी रखते हैं?

Question

संस्करण नियंत्रण के तहत आप कैसे जारी बायनेरिज़ को जारी रखते हैं? यह ट्रैक करने की अनुमति देता है कि प्रत्येक रिलीज़ के बीच कौन से सामान बदले जाते हैं। मेरा मतलब है कि रिलीज हुए बायनेरिज़ को सोर्स रिपॉजिटरी से अलग करना। जारी किए गए बायनेरिज़ या तो कॉन्टीन्यूअस इंटीग्रेशन सॉफ़्टवेयर से बनाए गए हैं या मैन्युअल रूप से संकलित किए गए हैं।

Comments

"ट्रैक क्या सामान बदल गया है" से आपका क्या मतलब है? रिलीज़ बायनेरिज़ की क्या विशेषताएँ हैं (या आप चाहते हैं) ट्रैकिंग? यह सिर्फ अजीब लगता है, इसलिए मैं उत्सुक हूं।

— जेरेमी हीलर

v1.0.0 और v1.0.1 के बीच उदाहरण के लिए, केवल ABC.exe को बदल दिया गया है, जबकि निर्भरता DEF.dll अपरिवर्तित बनी हुई है

— linquize

आप इसे बायनेरिज़ को देखकर कैसे निर्धारित करते हैं?

— जेरेमी हीलर

एक ही फ़ाइल के पुराने और नए संस्करण को अलग करें

— पंक्तिबद्ध करें

Answer 1

दो विकल्प:

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

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

किसी भी तरह से, बायनेरिज़ और अन्य बिल्ड आउटपुट कई कारणों से स्रोत नियंत्रण में नहीं हैं।

Comments

a) अक्सर संभव नहीं है

— ।

@jk: अच्छा लिंक। मुझे लगता है कि स्रोत कोड और निर्माण नियंत्रण के लिए पूरी तरह से स्रोत नियंत्रण (और सही संकलक संस्करण स्थापित) के लिए सभी इनपुट फाइलें होने से वास्तविक दुनिया के बहुत सारे परिदृश्यों में "निर्धारक पर्याप्त" हो सकता है (और दूसरों में पर्याप्त नहीं है, बिल्कुल) )। यह निर्भर करता है कि प्रजनन योग्य बायनेरिज़ का बिट-बाय-बिट होना कितना महत्वपूर्ण है।

— डॉक ब्राउन

Answer 2

बायनेरिज़ के लिए एक विरूपण साक्ष्य भंडार का उपयोग करें, न कि एक संस्करण नियंत्रण प्रणाली। रिलीज़ किए गए बाइनरी का एक विशिष्ट संस्करण समय के साथ बदलने वाला नहीं है, इसलिए संस्करण नियंत्रण का कोई मतलब नहीं है क्योंकि फ़ाइल (s) नहीं बदलेगी।

उदाहरण के लिए मावेन रिपॉजिटरी को संग्रह / प्रकाशन / रिलीज और अन्य बायनेरिज़ (जैसे दस्तावेज़ीकरण) के भंडार के रूप में देखें

Comments

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

— gbjbaanb

gbjbaanb, SCM का अर्थ "सोर्स कंट्रोल मैनेजमेंट" है। यह किसी को भी संकेत देना चाहिए कि इन प्रणालियों को बायनेरी लेकिन स्रोत को स्टोर करने के लिए डिज़ाइन नहीं किया गया है। यदि आप अभी भी बायनेरिज़ को स्टोर करना चाहते हैं, तो आगे बढ़ें। मैं नहीं करूंगा

— mhaller

SCM का अर्थ है "सॉफ़्टवेयर नियंत्रण प्रबंधन" लेकिन अच्छी कोशिश। "स्रोत कोड" अक्सर केवल पाठ फ़ाइलें नहीं होती हैं, बल्कि चित्र, दस्तावेज़, चित्र आदि

— gbjbaanb

आम तौर पर, "सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन।" मैंने कभी "सॉफ्टवेयर नियंत्रण प्रबंधन" के बारे में नहीं सुना है।

— जेम्स मैक्लियोड

Answer 3

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

अधिकांश SCMs डेल्टा बायनेरिज़ काफी अच्छी तरह से, हम अपने SVN में 2Mb संसाधन dll डालते थे और यह हर बार कुछ kb डेल्टा देता था।

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

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

Comments

@ MarnenLaibow-Koser आपने स्पष्ट रूप से लंबे समय तक उद्योग में काम नहीं किया है। समय के साथ वातावरण में बदलाव होता है, इसलिए जब आप एक पुराने को फिर से बना सकते हैं, तो संभावना है कि आपको सही पुराने टूल और एसडीके के साथ एनव को फिर से बनाने में दिन बिताने होंगे। मुझे आशा है कि आपने संस्करण दिया है ....

— gbjbaanb

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

— gbjbaanb

@gjbaanb मैं यह भी स्वीकार करूंगा कि आप मुझसे दूसरी तरह से अलग स्थिति में हैं: मेरी सभी बाहरी निर्भरताएँ ओएसएस हैं, इसलिए वे सिर्फ इसलिए नहीं जा सकते क्योंकि कुछ कंपनी अब उन्हें जारी करने के लिए फिट नहीं दिखती।

— मार्नेन लाईबो-कोसर

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

— gbjbaanb

@gjbaanb और मेरी बात यह है कि आप इसके बारे में गलत हैं। :) यकीन है, VCSs सब कुछ स्टोर कर सकते हैं, लेकिन वे अच्छी तरह से केवल एक कमिट के लिए रहने वाली फ़ाइलों को संग्रहीत करने के लिए सेट नहीं होते हैं (आखिरकार, आप r550 में अपने r500 के निर्माण को r550 पर नहीं चाहते हैं; यह सिर्फ भ्रामक होगा) । रेपो में निर्माण कलाकृतियों के भंडारण की मूलभूत समस्या यह नहीं है कि वे द्विआधारी हैं , बल्कि यह कि वे व्युत्पन्न डेटा हैं और समान रेपो में अपने स्रोत के साथ सिंक से बाहर निकल जाएंगे। मैं जिन तर्क का उपयोग कर रहा हूं, वे उत्पन्न पाठ फ़ाइलों पर लागू होंगे।

— मार्नेन लाईबो-कोसर

Answer 4

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

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

Answer 5

सबसे अच्छा समाधान सभी संगठनात्मक रूप से महत्वपूर्ण बिल्ड (रिलीज़, रिलीज उम्मीदवारों आदि ...) के लिए अपने CI सिस्टम का अनन्य उपयोग करना है।

यह व्यवस्थित रूप से जारी किए गए बायनेरिज़ को रिपॉजिटरी सामग्री में बाँधता है, क्योंकि वे वास्तव में रिपॉजिटरी में बायनेरिज़ को स्टोर करने के लिए नहीं हैं।

उदाहरण के लिए, यदि आप एसवीएन का उपयोग कर रहे हैं, तो शाखा-प्रमुख संगठनात्मक योजना का उपयोग करें; / ट्रंक में सभी दिन-प्रतिदिन का विकास करें, और एक बार तैयार होने के बाद प्रत्येक रिलीज़ के लिए टैग बनाएं।

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

• / बनाता / ट्रंक / [राजस्व] [तारीख] [build_id] /
• / बनाता / टैग / release_0_1_3beta4 / [राजस्व] [तारीख] [build_id] /

बिल्ड सिस्टम को एक सर्कुलर बफर की तरह / बिल्ड / ट्रंक / डायरेक्ट्री का इलाज करने की आवश्यकता होगी , पिछले एन बिल्ड्स को स्टोर करते हुए, पुराने बिल्ड को हटाते हुए इसे चला जाता है।

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

• [राजस्व] [तारीख] [build_id]

जहां [Rev] एसवीएन संशोधन आईडी है, [दिनांक] YYYYMMDD प्रारूप में तारीख है, और [build_id] एक 3-अंकीय अद्वितीय काउंटर है, जो पहले बिल्ड से आगे बढ़ता है, प्रत्येक बिल्ड को विशिष्ट बनाता है।

ऊपर दी गई प्रक्रिया आपको निम्नलिखित लाभ प्रदान करती है:

1. बिल्ड कलाकृतियों को व्यवस्थित रूप से उस स्रोत से बांधा जाता है जो उन्हें उत्पन्न करता है, इसलिए आप किसी विशेष बिल्ड विरूपण साक्ष्य के लिए स्रोत बहुत आसानी से पा सकते हैं, (और इसके विपरीत)।

2. यह आगे जारी स्वचालन के लिए आधार बनाता है। उदाहरण के लिए, रिलीज दस्तावेजों आदि की स्वचालित पीढ़ी ...