निरंतर एकीकरण में एकाधिक शाखाओं को संभालना

Question

मैं अपनी कंपनी में सीआई स्केल करने की समस्या से निपट रहा हूं और साथ ही यह पता लगाने की कोशिश कर रहा हूं कि सीआई और कई शाखाओं की बात कब होती है। स्टैक ओवरफ्लो, Multiple feature branches and continuous integration पर एक समान प्रश्न है। मैंने एक नया शुरू किया है क्योंकि मैं अधिक चर्चा करना चाहता हूं और प्रश्न में कुछ विश्लेषण प्रदान करना चाहता हूं।

अब तक मुझे पता चला है कि 2 मुख्य दृष्टिकोण हैं जिन्हें मैं ले सकता हूं (या शायद कुछ अन्य ???)।

• नौकरियों शाखा प्रति टूलींग
  • लिखें अतिरिक्त नौकरियों
    • बनाएं/संशोधित/बड़ी मात्रा में हटाने नौकरियां
    • कस्टम सेटिंग को प्रबंधित करने (जेनकींस/हडसन के बारे में यहाँ बात कर) के एकाधिक सेट प्रति शाखा प्रत्येक नौकरी के लिए (एससीएम यूआरएल, डीपी प्रबंधन डुप्लिकेशंस repos)
    • शैल टूल्स, चींटी स्क्रिप्ट और जेनकिंस सीएलआई के साथ इस समस्या से निपटने वाले लोगों के कुछ उदाहरण। देखें:
      1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
      2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729.html
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
      4. Configure or Create hudson job automatically
  • अपने सीआई क्लस्टर पर अधिक लोड के कारण होगा
  devs के लिए
  • प्रतिक्रिया चक्र को धीमा कर देती है (अगर बुनियादी ढांचे नए लोड को संभाल नहीं सकते)
• 2 शाखाओं (देव & स्थिर)
  • मैन्युअल दो सेट की व्यवस्था करें (यदि आप एक नौकरी की conf बदल तो दूसरी शाखा में परिवर्तित करना सुनिश्चित करें)
    प्रति नौकरियों के एकाधिक सेट
    • PITA लेकिन कम से कम इतना कुछ
  • अन्य अतिरिक्त शाखाओं का प्रबंधन करने के लिए एक पूर्ण टेस्ट स्वीट नहीं मिलेगा इससे पहले कि वे
  देव को धक्का दे दिया हो
  • असंतुष्ट देव। सीआई स्केलिंग समस्याओं के बारे में एक देव देखभाल क्यों करनी चाहिए। उसके पास एक आसान अनुरोध है, जब मैं शाखा करता हूं तो मैं अपने कोड का परीक्षण करना चाहता हूं। सरल।

तो ऐसा लगता है कि अगर मैं अपने स्वयं के कस्टम शाखाओं के लिए सीआई के साथ devs प्रदान करने के लिए मैं जेनकींस (एपीआई या shellscripts या कुछ और?) के लिए विशेष टूलींग की जरूरत चाहते हैं और स्केलिंग संभाल। या मैं उन्हें डीवी को अधिक बार विलय करने और कस्टम शाखाओं पर सीआई के बिना रहने के लिए कह सकता हूं। आप कौन से विकल्प लेते हैं या अन्य विकल्प हैं?

Answer 1

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

असली सीआई प्रदर्शन करना मतलब है कि आपके सभी डेवलपर मुख्य रूप से मुख्य रेखा पर काम कर रहे हैं। कहना आसान है, लेकिन कठिन हिस्सा आपके आवेदन को तोड़ने के बिना कर रहा है। मैं अत्यधिक अनुशंसा करता हूं कि आप Continuous Delivery देखें, खासकर अनुभाग में अनुभाग में अपना आवेदन जारी रखना अध्याय 13: घटक और निर्भरता प्रबंधन। मुख्य बिंदु इस प्रकार हैं:

• नई कार्यक्षमता छुपाएं जब तक यह (Feature Toggles A.K.A) समाप्त हो गया है।
• छोटे बदलावों की एक श्रृंखला के रूप में सभी परिवर्तनों को क्रमशः बनाएं, जिनमें से प्रत्येक रिलीज योग्य है।
• कोडबेस में बड़े पैमाने पर परिवर्तन करने के लिए सार तत्व द्वारा शाखा का उपयोग करें।
• विभिन्न दरों पर आपके एप्लिकेशन के कुछ हिस्सों को कम करने के लिए घटकों का उपयोग करें।

वे सार तत्व द्वारा शाखा को छोड़कर सुंदर आत्म व्याख्यात्मक हैं।

1. प्रणाली है कि आप को बदलने की जरूरत के किसी हिस्से पर एक अमूर्त बनाएं: इस के लिए सिर्फ एक फैंसी शब्द है।
2. अबास्ट्रक्शन परत का उपयोग करने के लिए शेष सिस्टम को रिफैक्टर करें।
3. एक नया कार्यान्वयन बनाएं, जो पूर्ण होने तक उत्पादन कोड पथ का हिस्सा नहीं है।
4. अपने नए कार्यान्वयन के लिए प्रतिनिधि बनाने के लिए अपनी अमूर्त परत अपडेट करें।
5. पुराने कार्यान्वयन को हटाएं।
6. अगर अब उचित नहीं है तो अबास्ट्रक्शन परत हटाएं।

अध्याय 14 में शाखाओं, स्ट्रीम, और सतत एकीकरण अनुभाग से निम्नलिखित पैराग्राफ: उन्नत संस्करण नियंत्रण प्रभावों का सारांश है।

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

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

Answer 2

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

यदि आप सीआई सर्वर पर लोड के बारे में चिंतित हैं, तो आप कई सर्वरों में लोड को संतुलित करने में सहायता के लिए सीआई या यहां तक ​​कि अलग दासों के अलग-अलग उदाहरण स्थापित कर सकते हैं। सुनिश्चित करें कि जिस सर्वर पर आप चल रहे हैं वह हडसन/जेनकींस पर्याप्त है। मैंने अपाचे टॉमकैट का उपयोग किया है और बस यह सुनिश्चित करना था कि बिल्ड कतार को संसाधित करने के लिए पर्याप्त स्मृति और प्रसंस्करण शक्ति हो।

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

Answer 3

मैं देव + स्थिर शाखाओं का चयन करूंगा। और यदि आप अभी भी कस्टम शाखाएं चाहते हैं और लोड से डरते हैं, तो इन कस्टम लोगों को क्लाउड पर क्यों न जाएं और डेवलपर्स को इसे स्वयं प्रबंधित करें, उदा। http://cloudbees.com/dev.cb यह वह कंपनी है जहां कोहसुक अब है। एक ग्रहण टूलिंग भी है, इसलिए यदि आप ग्रहण पर हैं, तो आप इसे dev env में कड़ाई से एकीकृत कर लेंगे।

Answer 4

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

• समर्पित दास पर
• शेयर स्थानीय खजाने प्रत्येक सुविधा शाखा के लिए गठजोड़ में अलग स्नैपशॉट खजाने बनाने
• नदी के ऊपर खजाने के साथ भंडार-server-प्लगइन का उपयोग
• एक निजी भंडार

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

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

मेरी 2 सेंट