GitLab CI बनाम जेनकिन्स [बंद]


129

जेनकिन्स और अन्य CI के बीच क्या अंतर है जैसे GitLab CI, drone.io जो Git वितरण के साथ आता है। कुछ शोधों पर मैं केवल यह बता पाया कि GitLab समुदाय संस्करण जेनकींस को जोड़ने की अनुमति नहीं देता है, लेकिन GitLab एंटरप्राइज़ संस्करण करता है। क्या कोई अन्य महत्वपूर्ण अंतर हैं?


5
: GitLab भी अब एक साथ GitLab सीआई बनाम जेनकींस की तुलना डाल दिया about.gitlab.com/comparison/gitlab-vs-jenkins.html
bbodenmiller

जवाबों:


122

यह मेरा अनुभव है:

मेरे काम पर हम GitLab EE के साथ अपनी रिपॉजिटरी का प्रबंधन करते हैं और हमारे पास जेनकिंस सर्वर (1.6) चल रहा है।

आधार में वे बहुत अधिक एक ही करते हैं। वे एक सर्वर / डॉकर छवि पर कुछ स्क्रिप्ट चलाएंगे।

टी एल; डॉ;

  • जेनकिंस का उपयोग / सीखना आसान है, लेकिन इसमें प्लगइन नरक बनने का जोखिम है
  • जेनकिंस में एक जीयूआई है (इसे अन्य लोगों द्वारा सुलभ / बनाए रखने योग्य होने पर प्राथमिकता दी जा सकती है)
  • GitLab के साथ एकीकरण GitLab CI से कम है
  • जेनकिन्स को आपके भंडार से अलग किया जा सकता है

अधिकांश सीआई सर्वर सुंदर सीधे आगे (हैं concourse.ci ), gitlab-ci , वृत्त-ci , ट्रैविस-ci , drone.io , gocd और और क्या है)। वे आपको एक YAML फ़ाइल परिभाषा से शेल / बैट स्क्रिप्ट निष्पादित करने की अनुमति देते हैं। जेनकिंस बहुत अधिक प्लगेबल है, और UI के साथ आता है। यह या तो आपकी आवश्यकताओं के आधार पर एक फायदा या नुकसान हो सकता है।

सभी प्लगइन्स उपलब्ध होने के कारण जेनकिंस बहुत विन्यास योग्य है। इसका नकारात्मक पक्ष यह है कि आपका CI सर्वर प्लगइन्स का एक स्पैगेटी बन सकता है।

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

आजकल ( जेनकींस 2 भी अधिक के साथ "उचित ci" का समर्थन करता है Jenkinsfileऔर pipline जो जेनकींस 2 से के रूप में डिफ़ॉल्ट आता प्लगइन), लेकिन कम यानी GitLab सीआई से भंडार के लिए युग्मित किया जाता था।

अपनी बिल्ड पाइपलाइन को परिभाषित करने के लिए YAML फ़ाइलों का उपयोग करना (और अंत में शुद्ध शेल / बैट चलाने के लिए) क्लीनर है।

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

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

  • उनका दस्तावेज़ीकरण आपको कुछ ही समय में मिलना चाहिए।
  • आरंभ करने की दहलीज बहुत कम है।
  • रखरखाव आसान है (कोई प्लगइन्स नहीं)।
  • स्केलिंग धावक सरल है।
  • CI पूरी तरह से आपके भंडार का हिस्सा है।
  • जेनकिंस की नौकरी / विचार गड़बड़ हो सकते हैं।

लेखन के समय कुछ भत्ते:


13
जेनकिंस को अब ब्लू महासागर के
Ayoub Kaanich

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

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

जेनकिंस गीतालाब की तुलना में बहुत अधिक उपकरण प्रदान करते हैं। gitlab / jenkins एक साथ एकीकरण संभव है और उपयोगकर्ता के लिए वास्तव में पारदर्शी है अगर अच्छी तरह से व्यवस्थित हो जाए। जेनकींस में दो piplelines को बदलना आपके रिपॉजिटरी में जेनकिंसफाइल के साथ आसान है .... आपको gitlab और gitlab स्रोत शाखा प्लगइन्स की आवश्यकता होगी
sancelot

1
इसका मतलब "सामुदायिक संस्करण में किसी एकल फ़ाइल के लिए केवल समर्थन है। एंटरप्राइज़ संस्करण में फ़ाइलें गुणा करें।" ? खेद है कि मैंने संलग्न मुद्दे को पढ़ने की कोशिश की लेकिन संबंधित नहीं हो सका।
लेस्टर

62

मैं रिक के अधिकांश नोट्स से सहमत हूं, लेकिन मेरी राय जिसके बारे में सरल है वह विपरीत है : गिटलैब के साथ काम करने के लिए एक बढ़िया उपकरण साबित हो रहा है।

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

मैं अभी इसका उपयोग स्वचालित रूप से करने और परीक्षण करने के लिए कर रहा हूं कि कैसे एक एप्लिकेशन विभिन्न लिनक्स वितरणों पर स्थापित होता है, और यह कॉन्फ़िगर करने के लिए तेजी से धधक रहा है (फ़ायरफ़ॉक्स में एक जटिल जेनकींस नौकरी कॉन्फ़िगरेशन को खोलने का प्रयास करें और गैर-उत्तरदायी स्क्रिप्ट के लिए प्रतीक्षा करें बनाम। (कैसे हल्के संपादित करने के लिए है .gitlab-ci.yml)।

गुलामों को कॉन्फ़िगर / स्केल करने में लगने वाला समय धावक बायनेरिज़ की तुलना में काफी कम है ; प्लस तथ्य यह है कि GitLab.com में आपको काफी सभ्य और मुफ्त साझा धावक मिलते हैं।

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

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


5
मैं पूरी तरह से Gitlab के बारे में आप पर सहमत हूँ। गीतालाब लिखने के समय उतना पूर्ण नहीं था जितना आजकल है। मुझे गीतालाब एक उपकरण के रूप में बहुत पसंद है, और वास्तव में उन सभी कार्यों की सराहना करते हैं जो लोग इसमें डाल रहे हैं।
रिक

1
@alfageme: मैं वैसे भी उल्लेखित साइट पर अपनी रिपोर्ट की जाँच करूँगा: आपके सभी स्पष्टीकरणों के लिए धन्यवाद। अगर हम अपने CI -Stuff के लिए gitlabCI या जेनकिंस का उपयोग करते हैं तो यह तय करने वाला क्षण है।
मैक्स शिंडलर

3
@ रिक मैं गीतालाब सीआई को पसंद करता हूं, हालांकि मैं दूसरी तरफ से दलीलें सुनता हूं, जिसमें कहा गया है कि यमल फाइल को बनाए रखना मुश्किल है क्योंकि इसमें कोई रियूजेबिलिटी नहीं है, क्योंकि एक पाइपलाइन में कई यम फाइल एक ही स्ट्रक्चर को फॉलो करते हैं और टेंपलेटिंग को एक बेहतर ऑप्शन के रूप में नहीं देखा जाता है। jenkinsfile क्योंकि jenkinsfile groovy का उपयोग करता है। इसलिए यह पुन: प्रयोज्य के लिए कोड बनाम कॉन्फ़िगरेशन के बारे में है। क्या आप इस पर अपने विचार साझा कर सकते हैं?
user1870400

1
@ user1870400 मुझे पूरी तरह से यकीन नहीं है कि आप टेम्प्लेटिंग के साथ क्या मतलब रखते हैं। क्योंकि जहां तक ​​मैं इसे देख सकता हूं, यह आपकी रिपॉजिटरी में सिर्फ एक फाइल है। और वह आपकी तुलना में अलग नहीं है Jenkinsfile। आप सही हैं कि आपके Jenkinsfileपास कोड चलाने के लिए ग्रूवी (+ अतिरिक्त जावा लिब) उपलब्ध हैं, जहां .gitlab-ci.yamlफ़ाइल मुख्य रूप से शेल का समर्थन करेगी, लेकिन (धावक के स्थान के आधार पर)। दूसरी ओर आप शेल स्क्रिप्ट से भी यह सब कह सकते हैं, लेकिन नकारात्मक पक्ष यह है कि आप मशीन पर निर्भरता पैदा कर रहे हैं (जो मेरी राय में बहुत पारदर्शी नहीं हैं)।
रिक

1
@Alfageme - मैंने गिटलैब सीआई का उपयोग करना शुरू कर दिया और जेनकिंस से दूर चला गया। मैं इसे ऑटो-बिल्ड के लिए पल में उपयोग करता हूं, नेक्सस पर अपलोड करता हूं, DEV env पर तैनात करता हूं और यूनिट टेस्ट चलाता हूं। इस तरह के अनुक्रम को परियोजना स्तर (मानक) पर निष्पादित किया जाता है। DEV के बाद मुझे मल्टी-प्रोजेक्ट (Gitlab group) परिनियोजन का प्रबंधन करने की भी आवश्यकता है। मैंने GUI बनाया जो Gitlab, Nexus API इत्यादि का उपयोग करता है, जहाँ आप परिनियोजित करने के लिए प्रोजेक्ट के नवीनतम TAG का चयन करते हैं और समूह-प्रोजेक्ट नवीनतम टैग के रूप में अच्छी तरह से (naive) परिनियोजित होते हैं। मैं संस्करण मैट्रिक्स की परिभाषा का समर्थन करने के लिए विस्तार पर काम करता हूं (projec1v1.1 Project2v3.2 के साथ संगत है), मैं इसके लिए गिटलैब में एक फीचर अनुरोध करूंगा।
केन्सई

22

सबसे पहले, आज की तरह, जिंकलैब कम्युनिटी एडिशन जेनकिंस के साथ पूरी तरह से इंटरऑपरेबल हो सकता है। कोई प्रश्न नहीं।

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

मुझे उम्मीद है कि यह आपको अपने स्वयं के प्रोजेक्ट पर गुणवत्ता की जानकारी देगा।

GitLab CI और जेनकिन्स ताकत

गिटलब सी.आई.

GitLab CI स्वाभाविक रूप से GitLab SCM में एकीकृत है। आप gitlab-ci.ymlफ़ाइलों का उपयोग करके पाइपलाइन बना सकते हैं और उन्हें ग्राफिकल इंटरफ़ेस के माध्यम से जोड़ सकते हैं ।

कोड के रूप में इन पाइपलाइनों को स्पष्ट रूप से कोड बेस में संग्रहीत किया जा सकता है, "कोड के रूप में सब कुछ" अभ्यास (पहुंच, संस्करण, प्रतिलिपि प्रस्तुत करने योग्यता, पुन: प्रयोज्य, आदि)।

GitLab CI एक बेहतरीन विजुअल मैनेजमेंट टूल है:

  • टीमों के सभी सदस्यों (गैर-तकनीकी वाले सहित) के पास जीवन चक्र की स्थिति के लिए त्वरित और आसान पहुंच है।
  • इसलिए इसे रिलीज प्रबंधन के लिए एक इंटरैक्टिव और ऑपरेशनल डैशबोर्ड के रूप में इस्तेमाल किया जा सकता है ।

जेनकींस

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

groovyस्क्रिप्ट के उपयोग से कोड के रूप में पाइपलाइन भी उपलब्ध है ।

GitLab CI और जेनकिन्स का एक साथ उपयोग करना

यह पहली बार में थोड़ा बेमानी लग सकता है, लेकिन GitLab CI और जेनकिंस का संयोजन काफी शक्तिशाली है।

  • GitLab CI ऑर्केस्ट्रा (चेन, रन, मॉनीटर ...) पाइपलाइनों और एक GitMabab के लिए एकीकृत अपने ग्राफिकल इंटरफ़ेस का लाभ उठा सकते हैं
  • जेनकिंस नौकरी चलाता है और तीसरे पक्ष के उपकरण के साथ संवाद की सुविधा देता है।

इस डिजाइन का एक और लाभ यह है कि उपकरण के बीच ढीली युग्मन है:

  • हम संपूर्ण CI / CD प्रक्रिया को फिर से बनाने के बिना किसी भी निर्माण कारखाने के घटकों को बदल सकते हैं
  • हमारे पास एक व्यापक निर्माण वातावरण हो सकता है, संयोजन (संभवतः कई) जेनकिंस, टीमसिटी, आप इसे नाम देते हैं, और अभी भी एक एकल निगरानी उपकरण है।

अदला - बदली

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

इस कारण से, जब तक मैं इस तरह के सेट-अप की सिफारिश नहीं करता

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

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

अगर मुझे एक चुनना था

GitLab CI और जेनकिंस दोनों के पेशेवरों और विपक्ष हैं। दोनों ही शक्तिशाली उपकरण हैं। तो कौन सा चुनना है?

उत्तर 1

अपनी टीम (या कोई करीबी) को पहले से ही एक निश्चित स्तर की विशेषज्ञता का चयन करें।

उत्तर २

यदि आप CI प्रौद्योगिकियों में सभी नए हैं, तो बस एक चुनें और जायें।

  • यदि आप GitLab का उपयोग कर रहे हैं और कोड के रूप में सब कुछ के लिए एक आदत है, यह GitLab CI को चुनने के लिए कुल समझ में आता है।
  • यदि आपको कई अन्य CI / CD टूल के साथ संवाद करना है या अपनी नौकरी बनाने के लिए GUI की आवश्यकता है, तो जेनकिंस के लिए जाएं।

आप में से जो GitLab का उपयोग कर रहे हैं और सुनिश्चित नहीं हैं कि वे ऐसा करते रहेंगे फिर भी यह ध्यान रखना होगा कि, GitLab CI को चुने जाने से आपके सभी CI / CD पाइपलाइनों को नष्ट कर दिया जाएगा।

अंतिम शब्द है: बैलेंस अपने कई प्लगइन्स के कारण जेनकिंस की ओर थोड़ा सा झुकता है , लेकिन संभावना है कि गिटलैब सीआई जल्दी से अंतराल को भर देगा।


@ पेटर मोर्टेनसेन: THX!
avi.elkharrat

6

मैं GitLab CI के साथ अपने हालिया प्रयोग से कुछ निष्कर्ष जोड़ना चाहूंगा। 11.6 और 11.7 के साथ आए फीचर्स सिर्फ कमाल के हैं!

विशेष रूप से मुझे onlyऐसी परिस्थितियां पसंद हैं, जो मूल रूप से आपको ( merge_requestया pushपूरी सूची यहां है ) अलग पाइपलाइन बनाने की अनुमति देती है

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

यदि आप DRY के बारे में सोच रहे हैं , तो यह आजकल पूरी तरह से संभव है! आप अपने "टेम्पलेट" लिख सकते हैं

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

उन्हें कुछ सार्वजनिक भंडार में रखें, उन्हें मुख्य पाइपलाइन में शामिल करें:

include:
  - remote: https://....

और कुछ नौकरी का विस्तार करने के लिए उनका उपयोग करें:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

मैं GitLab CI को बहुत प्यार करता हूँ! हाँ, यह (अब तक) कवरेज और इतने पर के साथ अच्छा रेखांकन नहीं बना सकता है, लेकिन कुल मिलाकर यह एक बहुत ही साफ उपकरण है!

संपादित करें (2019-02-23): यहाँ मैं GitLab CI में प्यार करने वाली चीजों के बारे में अपनी पोस्ट लिख रहा हूँ। यह 11.7 "युग" में लिखा गया था, इसलिए जब आप इस उत्तर को पढ़ रहे हैं, तो GitLab CI में संभवतः कई और विशेषताएं हैं।

संपादित करें (2019/07/10): Gitlab सीआई अब कई का समर्थन करता है extendsजैसे

extends:
 - .pieceA
 - .pieceB

एकाधिक विस्तार के बारे में अधिक जानकारी प्राप्त करने के लिए आधिकारिक दस्तावेज देखें


0

यदि आपकी बिल्ड / पब्लिश / पोस्ट / जॉब और टेस्ट जॉब्स बहुत अधिक जटिल नहीं हैं तो gitlab ci का उपयोग करने के प्राकृतिक फायदे हैं।

चूँकि gitlab-ci.yml हर शाखा में आपके कोड के साथ मौजूद है, आप अपने ci / cd चरणों को विशेष रूप से परीक्षण (जो पूरे वातावरण में भिन्न होते हैं) को और अधिक प्रभावी ढंग से संशोधित कर सकते हैं।

एक उदाहरण के लिए, आप देव शाखा के लिए किसी भी चेकइन के लिए इकाई परीक्षण करना चाहते हैं, जबकि आप QA शाखा पर पूर्ण विकसित परीक्षण करना चाहते हैं और एक सीमित केवल उत्पादन पर परीक्षण के प्रकार प्राप्त कर सकते हैं यह आसानी से gitlab ci का उपयोग करके प्राप्त किया जा सकता है।

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

इसके अलावा gitlab ci स्वचालित रूप से आपके लिए जाँच करेगा और आपको अलग से जेनकिंस मास्टर का प्रबंधन करने की आवश्यकता नहीं है

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