जेनकींस: एक गिट भंडार से कई शीर्ष-स्तरीय परियोजनाओं का निर्माण कैसे करें?

Question

मेरे पास एक गिट भंडार है जिसमें शीर्ष-स्तरीय मेवेन प्रोजेक्ट्स का एक गुच्छा शामिल है (प्रत्येक अपनी उप-निर्देशिका में एक pom.xml के साथ बैठता है)। यहां शीर्ष-स्तर का अर्थ है कि ये प्रोजेक्ट सीधे रेपॉजिटरी रूट के नीचे उपनिर्देशिका में बैठते हैं। इन सभी परियोजनाओं को एक ही गिट भंडार में रहना चाहिए।

repo 
+--- projectA 
    +--- pom.xml 

+--- projectB 
    +--- pom.xml 

वे स्वतंत्र जेनकिंस नौकरियों द्वारा बनाया/बनाया जाना चाहिए। इसलिए हमारे पास प्रोजेक्ट ए के लिए एक नौकरी है और प्रोजेक्ट बी के लिए एक है।

पूर्व में सबवर्सन के साथ मैं एक जेनकिन्स जॉब (प्रत्येक प्रोजेक्ट के लिए) स्थापित करने में सक्षम था जो केवल प्रोजेक्ट स्रोत की जांच करेगा और pom.xml से मेवेन बिल्ड चलाएगा।

गिट मॉडल (शायद सभी डीवीसीएस के साथ समान) के साथ यह परिवर्तन और मुझे यकीन नहीं है कि सबसे अच्छा अभ्यास क्या है। वहाँ कुछ ही विकल्प है कि मैं देख रहा हूँ और जो कोई भी से मैं वास्तव में पसंद कर रहे हैं:

1. प्रत्येक जेनकींस काम configured क्लोन करने के लिए है/पूर्ण Git रेपो खींच और Maven निर्माण के लिए /pom.xml को दर्शाता है। तो नौकरी में सभी कोड हैं लेकिन यह केवल एक टुकड़ा बनाता है।
2. Git (http://book.git-scm.com/5_submodules.html) जो लगते थोड़ा संभाल करने मुश्किल हो (और आसानी से तोड़ सकते हैं)
3. एक Maven माता पिता बनाएँ (एग्रीगेटर कि परियोजनाओं के सभी शामिल हैं) परियोजना है कि चलाता है प्रत्येक परियोजनाओं का निर्माण (होने submodules प्रदान करता है एक जेनकिंस नौकरी)। इस pom.xml में ProjectA और ProjectB के तत्व शामिल हैं।

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

Answer 1

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

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

आमतौर पर, आप एक आर्टिफैक्ट का उत्पादन करने के लिए दिए गए पोम चाहते हैं। एग्रीगेटर पोम्स submodules में एक बड़े आर्टिफैक्ट के हिस्सों को तोड़ने के लिए उपयोगी होते हैं, लेकिन केवल तभी अगर उन submodules खुद को जारी नहीं किया जाता है।

Answer 2

वैसे खुद को दोहराने का सबसे अच्छा अभ्यास नहीं है। तो एक सुपर पीओएम होने से उस स्टैंड प्वाइंट से अच्छा होगा।

आईडी शायद विकल्प 1 के साथ जाता है। डिस्क स्थान आमतौर पर सस्ता होता है।

लेकिन 3 जेनकिन्स को फिर से स्थापित किए बिना, नए सिस्टम पर तैनाती करना आसान बना देगा।

Answer 3

@recampbell, मुझे एक ही समस्या है। हमारे पास एक एचजी भंडार में कई पारस्परिक परियोजनाएं हैं।

इस तरह हम वास्तव में जानते हैं कि कौन सा संस्करण (एचजी संस्करण संख्या), एक-दूसरे संकलन। जब मैं बिल्कुल कहता हूं, मेरा मतलब है कि मैं सत्यापित कर सकता हूं कि यह बाइनरी समान है।

रिलीज संख्याओं का उपयोग करना बहुत मोटे अनाज है। उदाहरण के लिए आज मुझे एक बग मिला जो केवल एचजी संस्करण 3367 के तहत पुन: उत्पन्न किया गया था, लेकिन एचजी संस्करण 3368 में नहीं। कई एचजी रिपोज़ का उपयोग करना जो पुन: उत्पादित नहीं होता था, क्योंकि प्रत्येक परियोजना में हर दिन कई काम करते हैं, और इसलिए यह है यह निर्धारित करना असंभव है कि प्रत्येक व्यक्तिगत प्रोजेक्ट का कौन सा संस्करण उपयोग किया गया था, केवल एचजी संस्करण उपयोग करने के लिए सही है (बग खोजने के लिए bisect का उपयोग करके)।

यह पता चला कि हमने क्लाइंट डेटाबेस ड्राइवर संस्करण को उपप्रोजेक्ट्स में से एक में बदल दिया है और जिसने हमारी स्वचालित दाओ-पीढ़ी को एनपीई के साथ विफल कर दिया है। निश्चित रूप से चालक यदि एक रिलीज संस्करण जिसे हम नहीं लिखते हैं, तो हम विक्रेता द्वारा प्रदान किए गए एक का उपयोग करते हैं। यह हमें कई दिनों में डीबग करने में ले जाता, लेकिन चूंकि हम हर घंटे बनाने के लिए जेनकींस का उपयोग करते हैं, हम जानते थे कि खोज करने के लिए 10 से 20 काम करने के बीच थे, और केवल 3 या 4 दाओ जनरेटर को छुआ, इसलिए यह एक आसान काम था।

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