सी ++ निरंतर एकीकरण के लिए बिल्डबॉट बनाम हडसन/जेनकींस

Question

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

• पुन: कॉन्फ़िगर है कि क्या करने के लिए, एक साफ निर्माण करते हैं, या का उपयोग एक ताजा चेकआउट
• वैकल्पिक रूप से बनाता है के लिए विकल्पों के साथ सब कुछ बनाता है और सभी परीक्षण
• वैकल्पिक रूप से चलाता है का उपयोग करते हुए सभी परीक्षणों चलाता वेलग्रिंड की: सी ++ परियोजनाओं निम्न कार्य करें Memcheck
• रन cppcheck
• उत्पन्न Doxygen प्रलेखन
• रिपोर्ट प्रकाशित: इकाई परीक्षण, valgrind, cppcheck, संकलक चेतावनी, SLOC, खुले कार्य और कोड कवरेज (gcov का उपयोग कर, GCO vr, और Cobertura प्लगइन)
• पर मांग बनाता है के लिए हर रात को या एक परीक्षण पर्यावरण के लिए मांग और एक पैकेज भंडार

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

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

मैंने अन्य समाधानों को देखा है और ऐसा लगता है कि यह एक प्रतिस्थापन हो सकता है buildbot। क्या इस स्थिति के लिए बिल्डबॉट बेहतर होगा? क्या निवेश इसके लायक है क्योंकि हम पहले ही हडसन का उपयोग कर रहे हैं? क्यूं कर?

EDIT: किसी ने पूछा कि मुझे हडसन/जेनकींस आदर्श क्यों नहीं मिला है। संक्षिप्त जवाब यह है कि सब कुछ बेहतर किया जा सकता है। मैं बस सोच रहा हूं कि जेनकिंस मेरे उपयोग के मामले के लिए सबसे अच्छा वर्तमान समाधान है या क्या कुछ बेहतर है (buildbot?) जो लंबे समय तक बनाए रखना आसान होगा, भले ही नई आवश्यकताएं आती हैं।

Answer 1

दोनों ओपन सोर्स प्रोजेक्ट्स हैं, लेकिन आपको बिल्डबॉट कोड को "विस्तारित" करने के लिए बदलने की आवश्यकता नहीं है, वास्तव में अपने कॉन्फ़िगरेशन में अपने स्वयं के पैकेज आयात करना बहुत आसान है जिसमें आप उप-श्रेणी के साथ अधिकांश सुविधाएं कर सकते हैं अपने स्वयं के जोड़ उदाहरण: आपका स्वयं का संकलन या परीक्षण कोड, अगली चरणों में आउटपुट/त्रुटियों के कुछ विश्लेषण, आपके स्वयं के अलर्ट ईमेल आदि का निर्माण करना बहुत संभावनाएं हैं।

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

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

आशा है कि इससे मदद मिलेगी।

Answer 2

'परिणाम एकीकरण' जेनकींस/हडसन में भी है, और आप 'कहीं और उन्हें कॉपी' किए बिना अपेक्षाकृत आसानी से निर्माण उत्पादों को कैप्चर कर सकते हैं।

हमारे उदाहरण के लिए, जावा कोड के लिए कवरेज रिपोर्ट और इकाई परीक्षण मेट्रिक्स और जावाडोक सभी एकीकृत हैं। हमारे सी ++ कोड के लिए, प्लगइन की कमी कम है, लेकिन आप अभी भी इसे अधिकतर प्राप्त कर सकते हैं।

हम प्री 0.7 के बाद से बिल्डबॉट चला रहे हैं, और अब 0.8 चल रहे हैं और अब स्विच करने के लिए कोई वास्तविक कारण देख रहे हैं, क्योंकि buildbot 0.8 एक विस्तारित अवधि के लिए विंडोज गुलामों के बारे में भूल गया था और समर्थन बहुत खराब था।

Answer 3

वहाँ कई अन्य समाधान है, वहाँ बाहर हैं जेनकींस/हडसन/BuildBot के अलावा: JetBrains द्वारा

• TeamCity
• Atlassian
द्वारा बांस
• जाओ ThoughtWorks
• क्रूज नियंत्रण
• OpenMake Meister द्वारा

के बारे में विशिष्टताएं आप जो कर रहे हैं वह वास्तव में महत्वपूर्ण नहीं है, वास्तव में, जब तक एजेंट (उर्फ नोड्स) कि आप उन्हें उन कार्यों के समर्थन पर कर रहे हैं।

एक सीआई सर्वर की सुंदरता एक नई बिल्ड (और परीक्षण) को ट्रिगर करने, कलाकृतियों को प्रकाशित करने और परीक्षण परिणामों को प्रकाशित करने के लिए बदलती समय देख रही है।

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

मेरा निजी पसंदीदा बांस है, लेकिन यह लाइसेंस शुल्क के साथ आता है।