निरंतर एकीकरण के साथ एक बढ़ते, विविध कोडबेस को बनाए रखना


10

मुझे दर्शन और निरंतर एकीकरण सेटअप के डिजाइन के साथ कुछ मदद की आवश्यकता है।

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

मुझे एक पल के लिए विनोद करो, और मुझे समझाने दो जो मुझे विरासत में मिला है। मेरी कंपनी के लिए कोडबेस लगभग 150 अद्वितीय c ++ विंडोज अनुप्रयोग हैं, जिनमें से प्रत्येक में एक या एक दर्जन से अधिक आंतरिक पुस्तकालयों पर निर्भरता है (और साथ ही 3 पार्टी पुस्तकालयों पर कई)। इन पुस्तकालयों में से कुछ अन्योन्याश्रित हैं, और उन अनुप्रयोगों पर निर्भर करते हैं जो (जबकि उनका एक दूसरे से कोई लेना-देना नहीं है) उसी पुस्तकालय के निर्माण के साथ बनाया जाना है। इन अनुप्रयोगों और पुस्तकालयों में से आधे को "विरासत" माना जाता है और यह असंभव है, और आईबीएम संकलक के कई अलग-अलग विन्यासों के साथ बनाया जाना चाहिए (जिसके लिए मैंने अद्वितीय उपवर्ग लिखे हैं Compile), और अन्य आधे दृश्य स्टूडियो के साथ बनाए गए हैं।ShellCommandएस, जैसा कि वीएसएस के लिए कोई समर्थन नहीं है)।

हमारे मूल रात्रिकालीन बिल्डर ने सब कुछ के लिए स्रोत को नीचे ले लिया, और एक निश्चित क्रम में सामान बनाया। केवल एक ही एप्लिकेशन बनाने या संशोधन करने या समूह की चीजों को लेने का कोई तरीका नहीं था। यह कई अनुप्रयोगों के निर्माण के लिए वर्चुअल मशीन लॉन्च करेगा। यह बहुत मजबूत नहीं था, यह वितरण योग्य नहीं था। यह बहुत एक्स्टेंसिबल नहीं था। मैं बिल्डबॉट में इन सभी सीमाओं को पार करने में सक्षम होना चाहता था।

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

हालाँकि इस दृष्टिकोण की चार कमजोरियाँ हैं। एक हमारे स्रोत वृक्ष की निर्भरता का जटिल वेब है। कॉन्फ़िगर मेनटेन को सरल बनाने के लिए, सभी बिल्डरों को एक बड़े शब्दकोश से उत्पन्न किया जाता है। निर्भरता को पुनः प्राप्त किया जाता है और एक बहुत ही मजबूत तरीके से नहीं बनाया जाता है (अर्थात्, मेरे निर्माण-लक्ष्य में कुछ चीजों की कुंजी लगाना)। दूसरा यह है कि प्रत्येक बिल्ड में 15 से 21 बिल्ड चरण होते हैं, जो वेब इंटरफ़ेस में ब्राउज़ करना और देखना मुश्किल है, और चूंकि लगभग 150 कॉलम हैं, लोड करने के लिए हमेशा के लिए लेता है (30 सेकंड से कई मिनट तक सोचें)। तीसरा, हमारे पास अब बिल्ड टारगेट की ऑटोडिस्कवरी नहीं है (हालाँकि, इस बारे में मेरे सहकर्मियों में से एक ने मुझे परेशान किया है, मैं नहीं देखता कि यह हमें पहले स्थान पर क्या मिला)। आखिरकार,

अब, नए विकास के लिए आगे बढ़ते हुए, हम g ++ और तोड़फोड़ (पुराने रिपॉजिटरी को पोर्ट नहीं करते हुए, आपका - सिर्फ नए सामान के लिए) का उपयोग करना शुरू कर रहे हैं। इसके अलावा, हम और अधिक इकाई परीक्षण करना शुरू कर रहे हैं ("अधिक" गलत चित्र दे सकता है ... यह किसी भी तरह अधिक है ), और एकीकरण परीक्षण (अजगर का उपयोग करके)। मुझे पता है कि मेरे मौजूदा कॉन्फ़िगरेशन में इनको कैसे फिट किया जाए, यह एक कठिन समय है।

तो, मैं कहाँ दार्शनिक रूप से गलत हो गया हूँ? मैं सबसे अच्छी तरह से कैसे आगे बढ़ सकता हूं (बिल्डबॉट के साथ - यह पहेली का एकमात्र टुकड़ा है जिस पर मेरे पास काम करने का लाइसेंस है) ताकि मेरा कॉन्फ़िगरेशन वास्तव में संभव हो? मैं अपने डिजाइन की कुछ कमजोरियों को कैसे संबोधित करूं? वास्तव में बड़े, (संभवतः अधिक-) जटिल कोडबेस के लिए सीआई रणनीतियों के संदर्भ में क्या काम करता है?

संपादित करें:

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


मैं भी इसका उत्तर जानना चाहूंगा। हमारा पर्यावरण आपके लिए उतना जटिल नहीं है, लेकिन हमें निर्भरता की निर्भरता मिली है (सेटअप प्रोजेक्ट के मामले में, इसमें निर्भरता चार परतें हैं)। मुझे नहीं पता कि क्या प्रत्येक प्रोजेक्ट एक CI प्रोजेक्ट होना चाहिए, या अगर मुझे सिर्फ मेरे लिए इसकी देखभाल के लिए Visual Studio .sn फाइल का उपयोग करना चाहिए, ताकि मुझे प्रत्येक प्रोजेक्ट के लिए निर्भरता ट्री को फिर से बनाना न पड़े। (और भविष्य की परियोजना)।
मोसवाल्ड

अपने स्थानीय मशीन पर निर्माण करने में सक्षम नहीं होना आपके सीआई सर्वर मिशन को आपके व्यवसाय के लिए महत्वपूर्ण बनाता है । आप इस पर पुनर्विचार करना चाह सकते हैं।
थोरबजोरन रावन एंडरसन

जवाबों:


3

हालाँकि, मैंने एक ऐसी स्थिति का सामना नहीं किया है जैसा कि आप वर्णन करते हैं, मैं दसियों घटकों के साथ एक सीआई कॉन्फ़िगरेशन को बनाए हुए हूं, जिसके बीच कुछ 'सरल' निर्भरताएं हैं। मुझे उम्मीद है कि मेरा दृष्टिकोण आपको कुछ संकेत दे सकता है जिसके साथ आगे बढ़ना है। समस्या निश्चित रूप से केवल सीआई सर्वर की पसंद से संबंधित नहीं है, बल्कि समग्र निर्माण प्रक्रिया और परियोजना संरचना से भी संबंधित है।

मैं समस्या को 2 भागों में तोड़ूंगा: भवन और सीआई।

इमारत

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

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

उदाहरण के लिए, मैंने उससे पहले कुछ जावा प्रोजेक्ट्स को देखा था, हालांकि पूरी बिल्ड प्रक्रिया के बाद कई JAR (आप इसे जावा में लिब / डीएल के रूप में मान सकते हैं) निर्मित हैं, वे वास्तव में इंटर-डिपेंडेंट हैं। जैसे, ए.जर, बीजर में चीजों का उपयोग कर रहा है, और इसके विपरीत। इस तरह का 'मॉडर्नाइजेशन' पूरी तरह से निरर्थक है। एजर और बीजर को हमेशा एक साथ तैनात और उपयोग करने की आवश्यकता होती है। निहितार्थ, बाद में यदि आप उन्हें अलग-अलग परियोजनाओं (उदाहरण के लिए अन्य परियोजनाओं में पुन: उपयोग) के लिए अलग करना चाहते हैं, तो यू ऐसा करने में सक्षम नहीं होगा, coz आप यह निर्धारित नहीं कर सकते कि कौन सी परियोजना, ए या बी, पहले बनाने के लिए।

हां, इसे आपके सॉफ़्टवेयर के डिज़ाइन में कैटर किए जाने की आवश्यकता है, लेकिन मेरा हमेशा मानना ​​है कि, एक गंदे प्रोजेक्ट में जटिल बिल्डिंग टूल्स / मॉडल काम करने के लिए समय देने के बजाय, मैं डिज़ाइन का उपयोग करने के लिए डिज़ाइन को पुनर्गठित करने के लिए समय बिताऊंगा सरल निर्माण मॉडल।

2) निर्भरताएं घोषणात्मक होनी चाहिए। बहुत सारी बिल्ड प्रक्रिया है जो मैंने पहले देखी थी, जिसमें वे सभी लिबास शामिल हैं जिनकी परियोजना में स्थानीय स्तर पर आवश्यकता है। यह निर्माण प्रक्रिया को बेहद तकलीफदेह बना देगा अगर कुछ लिबास वास्तव में अन्य कलाकृतियों के हैं जिन्हें आपको बनाने की जरूरत है।

3) निर्भरता प्राप्त करने के लिए कलाकृतियों के लिए "केंद्रीकृत" भंडारण, या इसे संकलित करने के बाद कलाकृतियों को तैनात करना। यह पूरे कार्यालय के लिए "केंद्रीकृत" होने की आवश्यकता नहीं है (यह बहुत अच्छा होगा अगर यह है), बस एक स्थानीय निर्देशिका पहले से ही ठीक हो जाएगी।

2 और 3 पर अधिक विस्तार। बस एक उदाहरण देने के लिए, मैं एक परियोजना पर आया हूं जिसमें 3 स्वतंत्र परियोजनाएं शामिल हैं। प्रत्येक परियोजना को स्रोत पर आधार बनाया जाता है, साथ ही स्रोत निर्देशिका में लिब / डायरेक्टरी के तहत काम करता है। प्रोजेक्ट ए कई लिबास का निर्माण करेगा, जो परियोजना बी और सी द्वारा उपयोग किया जाता है। इसमें कुछ कमियां हैं: निर्माण प्रक्रिया जटिल और स्वचालित करने के लिए कठिन है; स्रोत नियंत्रण अनावश्यक डुप्लिकेट JARs के साथ अलग-अलग प्रोजेक्ट में पुन: उपयोग किया जा रहा है

मावेन की दुनिया में, यह क्या किया जाता है, प्रोजेक्ट बी और सी में वास्तव में एएजर नहीं है (और अन्य निर्भरताएं, अन्य 3 पार्टी के काम की तरह) प्रोजेक्ट स्रोत में। यह घोषणात्मक है। उदाहरण के लिए, प्रोजेक्ट B के बिल्ड कॉन्फ़िगरेशन में, यह बस यह घोषित करता है कि इसकी आवश्यकता है: A.lib v1.0, xyz.lib v2.1 इत्यादि, और बिल्ड स्क्रिप्ट /A / 1.0/A से लिब को देखेगा। जार और /xyz/2.1/xyz.lib

गैर-मावेन दुनिया के लिए, इस कलाकृतियों को केवल एक या दो निर्देशिकाओं के लिए सहमत निर्देशिका संरचना की आवश्यकता है। आप सभी 3 पार्टी के काम को एक शेयर स्थान पर रख सकते हैं और डेवलपर्स को अपने स्थानीय मशीनों को सिंक या कॉपी करने दे सकते हैं। मेरे C ++ प्रोजेक्ट्स में मैंने कई साल पहले किया था, जो मैं कर रहा हूं वह $ {कलाकृतियों के लिए लिबर और हेडर सेट कर रहा है।

जब प्रोजेक्ट A का निर्माण किया जाता है, तो उसके उस परिणाम की एक प्रति उस विरूपण साक्ष्य_dir में होगी, ताकि जब हम प्रोजेक्ट B का निर्माण करें, तो B मैन्युअल रूप से कॉपी किए बिना A का परिणाम स्वचालित रूप से प्राप्त कर सके।

4) गैर उत्परिवर्ती रिलीज। एक बार जब आप ए.लिब 1.0 जारी करते हैं, तो यह है, आप ए.लिब 1.0 की सामग्री में बदलाव की उम्मीद नहीं करेंगे 1 महीने बाद बस कुछ बग फिक्स होंगे। ऐसे मामले में, यह ए। एलिब 1.1 होना चाहिए। बदलते कोड आधार की कलाकृतियों को एक विशेष "संस्करण" पर विचार करना चाहिए, जिसके लिए मावेन में हम इसे स्नैपशॉट कहते हैं।

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


ये सभी सुनिश्चित करते हैं कि आपकी परियोजनाएं स्वतंत्र रूप से निर्माण कर सकती हैं, जैसे बहुत अधिक मैनुअल ट्रिक्स के बिना, प्रोजेक्ट ए का निर्माण, ए। एलिब की प्रतिलिपि बी को प्रोजेक्ट करें, और फिर प्रोजेक्ट बी का निर्माण करें ...

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


सीआई

एक आसान बिल्ड सिस्टम के साथ, स्पष्ट निर्भरता के साथ, CI बहुत आसान हो जाएगा। मुझे उम्मीद है कि आपका CI सर्वर निम्नलिखित आवश्यकता को पूरा करेगा:

1) स्रोत नियंत्रण की निगरानी करें, स्रोत में परिवर्तन होने पर केवल चेकआउट + बिल्ड करें

2) परियोजनाओं के बीच निर्भरता को स्थापित करने में सक्षम

परियोजनाओं के लिए एक स्पष्ट निर्भरता के साथ, आपको बस अपनी वास्तविक परियोजनाओं के अनुसार CI में परियोजनाओं को स्थापित करने की आवश्यकता है, अपनी परियोजनाओं की निर्भरता के अनुसार CI परियोजना निर्भरता की स्थापना करें। किसी भी परियोजना के निर्माण से पहले आपके सीआई सर्वर को आश्रित परियोजनाओं के निर्माण के लिए सेट किया जाना चाहिए (और निश्चित रूप से, केवल तभी होता है जब परियोजना स्रोत वास्तव में परिवर्तन हो)।

यदि सब कुछ सही हो जाता है, तो आपके पास एक विशाल, जटिल, लेकिन फिर भी प्रबंधनीय सीआई होना चाहिए (और इससे भी महत्वपूर्ण, एक प्रबंधनीय परियोजना संरचनाएं)


मुझे पसंद है कि यह उत्तर कहां जा रहा है, लेकिन क्या आप 'बिल्डिंग' सेक्शन में अधिक विस्तार से जा सकते हैं? यही है, कुछ उदाहरण दें, कुछ अवधारणाओं को अधिक पूरी तरह से समझाएं, विस्तृत करें।
नैट

हम्म ... किस हिस्से की तरह? मैं प्रत्येक भाग के अधिक विवरण देने के लिए पोस्ट को संपादित करने का प्रयास करता हूं। यह बेहतर होगा यदि आप मुझे बता सकते हैं कि किस भाग को महसूस करने की आवश्यकता है। वैसे, यदि आप भी जावा का उपयोग कर रहे हैं, तो maven.apache.org पर एक नज़र डालें। मावेन को अपनाने के लिए सबसे आसान बात नहीं हो सकती है, लेकिन यह आपको अपनी चीजों को साफ और व्यवस्थित करने के लिए मजबूर करता है।
एड्रियन शुम

1

मेरे लिए समान परिस्थितियों में क्या काम किया है:

  • एप्लिकेशन के स्तर के निर्माण के कुछ हिस्सों को समर्पित बिल्ड ऐप्स में शंट करके (हमारे मामले में ये PHP स्क्रिप्ट मुख्य बिल्ड से कहे जाते हैं)। यह बिल्ड चरणों की कुछ दर्जन लाइनों को एक बिल्ड चरण में कम कर सकता है।
  • बिल्ड-लेवल एब्स्ट्रक्शन को मुख्य बिल्ड स्क्रिप्ट से लॉन्च करने वाली सब-बिल्ड-स्क्रिप्ट बनाते हैं। कोई विचार नहीं है कि यह बिल्डबोट के लिए प्रासंगिक है (उस उत्पाद के साथ कोई अनुभव नहीं है)।

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


0

मैं जेनकिन्स को सीआई सर्वर के रूप में मानूंगा, आप यहां की विशेषताओं को देख सकते हैं:

https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

क्यों? इसे स्थापित करना आसान है, इसमें एक अद्भुत इंटरफ़ेस है, इसे कॉन्फ़िगर करना और विस्तार करना आसान है और लगभग हर चीज के लिए तैयार प्लगइन्स के बहुत सारे हैं:

https://wiki.jenkins-ci.org/display/JENKINS/Plugins

कोशिश करो :)


2
मुझे लगता है कि आपने मेरे प्रश्न का शीर्षक पढ़ा है, लेकिन शरीर को नहीं पढ़ा है ... मैं उत्पाद सुझाव की तलाश में नहीं हूं। मैंने एक उत्पाद चुना है। मैं देख रहा हूँ कि एक जटिल CI सेटअप कैसे व्यवस्थित किया जाए।
नट

नैट, मैंने आपकी सभी पोस्ट पढ़ी और मुझे लगता है कि आपने गलत उत्पाद चुना है, इसीलिए मैंने जेनकिंस का सुझाव दिया। मैं कई मशीनों पर क्लस्टरिंग के साथ C ++ उत्पादों (यहां तक ​​कि कई भाषाओं में लिखे गए परीक्षण) के विभिन्न प्रकार के परीक्षण के लिए जेनकिंस का उपयोग करता हूं। इसे प्रबंधित और कॉन्फ़िगर करना बहुत आसान है। वास्तव में, इसे आजमाएँ :)
पेट्रीज़ियो रुलो

इस ब्लॉग पोस्ट को भी देखें: vperic.blogspot.com/2011/05/…
Patrizio Rullo

0

अब हम इससे पहले Go by ThoughtWorks का उपयोग करते हैं, हम CruiseControl.Net का उपयोग कर रहे थे । यह उपयोगी रहा है कि हम दो टीमों को एक-दूसरे से आधी दुनिया से दूर रखें और हमारे बीच एक बड़ा समय क्षेत्र अंतर हो।

हम कई परियोजनाओं का प्रबंधन कर रहे हैं और अधिकांश कार्यों में दुनिया के दोनों पक्षों में दो डेवलपर्स के बीच ओवरलैप शामिल हैं, इसलिए हमें यह ध्यान रखना होगा कि सभी फाइलें किसी और के निर्माण को नहीं तोड़ना चाहिए।

गो के साथ प्रबंधन भी आसान है और एक एजाइल प्रोसेस डेडहार्ड होने के कारण, हमने इसे स्थापित करने के बाद हमें कम सिरदर्द दिया है। परीक्षण को गो के साथ एकीकृत भी किया गया है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.