जेनकींस वर्कफ़्लो

Question

के साथ एकाधिक पाइपलाइनों के साथ जटिल मूल्य स्ट्रीम कैसे बनाएं जेनकिन्स वर्कफ़्लो में एकाधिक पाइपलाइनों के साथ जटिल मूल्य स्ट्रीम कैसे कार्यान्वित करें? जैसा कि आप गो सीडी के साथ कर सकते हैं: How do I do CD with Go?: Part 2: Pipelines and Value Streams।

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

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

यदि प्रत्येक डिलीवरी पाइपलाइन अपनी जेनकींस जॉब में है। मैं पूरी पाइपलाइन को कैसे देख सकता हूं और आखिरी सफल कलाकृतियों या अन्य पाइपलाइनों से संस्करण को खींचने का सबसे अच्छा तरीका क्या है?

Answer 1

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

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

¹ एक मामला जहां आपको निश्चित रूप से अलग नौकरियों की आवश्यकता है, सुरक्षा कारणों से विभिन्न परियोजनाओं में योगदान करने वाली टीमों को एक दूसरे के स्रोत या लॉग बनाने में सक्षम नहीं होना चाहिए।

Answer 2

यह मानते हुए कि अपने देव टीमों में से प्रत्येक अपनी परियोजना का एक अलग मॉड्यूल पर काम करता है और "एक परिवर्तन एकमात्र टीम है जो परिवर्तन बनाया पाइपलाइन को गति प्रदान करने की जरूरत है" मैं Git Submodules का उपयोग करेंगे:

सबमोड्यूल आपको एक गिट भंडार को अन्य गिट भंडार की उपनिर्देशिका के रूप में रखने की अनुमति देता है।

एक रेपो के साथ

, कि एक मुख्य मॉड्यूल रेपो के एक submodule, प्रत्येक टीम के लिए हो जाता है। यह टीमों के लिए पारदर्शी होगा क्योंकि वे केवल उनके नामित रिपो पर ही काम करते हैं।

मुख्य मॉड्यूल बिल्ड टूल के संदर्भ में आपकी मॉड्यूल परियोजनाओं के लिए एग्रीगेटर प्रोजेक्ट भी है। तो, आप विकल्प हैं:

• प्रत्येक रेपो/पाइपलाइन को व्यक्तिगत रूप से निर्माण करने के लिए या
• ही बार में पूरा (मुख्य) परियोजना का निर्माण।

एक बिल्ड पाइपलाइन जिसमें एक या अधिक बिल्ड नौकरियां शामिल हैं, प्रत्येक टीम/रेपो/मॉड्यूल से जुड़ी है।

मुख्य पाइपलाइन केवल डाउनस्ट्रीम नौकरियों का एक संग्रह है जो टीम/रेपो/मॉड्यूल पाइपलाइनों के प्रारंभिक बिंदुओं का प्रतिनिधित्व करता है।

बिल्ड ट्रिगर्स मैन्युअल रूप से, समय या स्रोत परिवर्तनों में से कोई भी हो सकता है।

का निर्णय भी किए जाने के लिए है: अपने मॉड्यूल

• आप चाहे संस्करण को व्यक्तिगत रूप से, ऐसी अन्य मॉड्यूल रिलीज संस्करण केवल पर निर्भर हैं।
  • लाभ:
    • अन्य, अधिक स्थिर संस्करण जारी पर भरोसा करते हैं आम तौर पर।
    • मॉड्यूल तय कर सकते हैं कि वे किस निर्भरता का उपयोग करना चाहते हैं।
  • नुकसान:
    • विज्ञप्ति प्रत्येक मॉड्यूल के लिए तैयार किया जाना है।
    • इसमें अधिक समय लग सकता है जब तक कि नवीनतम परिवर्तन दूसरों के लिए उपलब्ध न हो जाएं।
    • मॉड्यूल को यह तय करना है कि वे किस निर्भरता का उपयोग करना चाहते हैं। और उन्हें हर बार अनुकूलित करना होगा जब उन्हें किसी नए संस्करण में कार्यक्षमता की आवश्यकता होती है।

• या आप पूरी परियोजना (जो तब मॉड्यूल द्वारा विरासत में मिली है) के लिए एक संस्करण का उपयोग करें: विकास चक्र, एक रिलीज़ संस्करण के दौरान ...-SNAPSHOT जब प्रोजेक्ट रिलीज़।

  इस मामले में, यदि ऐसे मॉड्यूल हैं जो दूसरों के लिए आवश्यक हैं, उदा। कोर मॉड्यूल, इसका एक सफल निर्माण निर्भर मॉड्यूल के निर्माण को भी ट्रिगर करना चाहिए, ताकि असंगतताएं जितनी जल्दी हो सके पहचान सकें।

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

---

रे "मैं पूरा पाइपलाइन कैसे कल्पना कर सकते हैं"

मैं उस पल में वर्कफ़्लो के साथ ऐसा कर सकते हैं किसी भी प्लगइन के बारे में पता नहीं कर रहा हूँ।

Build Graph View Plugin मूल रूप से प्रवाह बिल्ड के लिए बनाया गया है जो नहीं है, लेकिन यह अब दो से अधिक वर्ष है:

डाउनस्ट्रीम बनाता DownStreamRunDeclarer विस्तार बिंदु से पहचाने जाते हैं।

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

(तुम्हें पता है, और "बाद में" अक्सर बन "हो सकता है" नहीं होगा और कभी नहीं में विकास;।)

Build Pipeline Plugin नहीं है, लेकिन यह जाहिरा तौर पर भी उपयुक्त नहीं है वर्कफ़्लोज़ के लिए:

यह प्लगइन अपस्ट्रीम और डाउनस्ट्रीम कनेक्ट नौकरियों का एक बिल्ड पाइपलाइन दृश्य प्रदान करता है [...]

---

रे "तरह से पिछले सफल कलाकृतियों में खींचने के लिए"

जाहिर है यह नहीं है कि चिकनी Gradle साथ है:

डिफ़ॉल्ट रूप से, Gradle किसी भी खजाने को परिभाषित नहीं करता।

मैं Maven उपयोग कर रहा हूँ और वहाँ local and remote repositories मौजूद है जहाँ बाद भी हो सकता है:

[...] आंतरिक एक फ़ाइल या HTTP सर्वर आपकी कंपनी के भीतर पर स्थापित खजाने का इस्तेमाल किया साझा करने के लिए विकास टीमों और रिलीज के बीच निजी कलाकृतियों।

क्या आपने Artifactory या Nexus जैसे बाइनरी रिपोजिटरी मैनेजर का उपयोग करने पर विचार किया है?

Answer 3

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

1. एक भी पाइप लाइन (कार्यप्रवाह लिपि) है कि दोनों रेपोस से कोड बाहर की जाँच करता है और साथ ही साथ एक ही पाइप लाइन के माध्यम से उन्हें कहते हैं:

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

2. दो पाइपलाइन हैं और इससे प्रत्येक व्यक्ति अपनी गति से आगे बढ़ने की अनुमति देता है जो दूसरे करता है। यह बुनियादी ढांचे कोड के लिए कोई समस्या नहीं है, लेकिन यह ऐप कोड के लिए बहुत अच्छा हो सकता है। यदि आपने पहले से होने वाले बुनियादी ढांचे अद्यतन के बिना अपने ऐप कोड को उत्पादन में धक्का दिया है, तो परिणाम सुखद नहीं हो सकते हैं।

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

import hudson.EnvVars 
import hudson.model.* 

int indepdentBuildNum = 16 

waitUntil{ 
    verifyDependentPipelineCompletion("FLDR_CM/WorkflowDepedencyTester2", indepdentBuildNum) 
} 

boolean verifyDependentPipelineCompletion(String jobName, int buildNum){ 
    def hi = jenkins.model.Jenkins.instance 
    Item dep2 = hi.getItemByFullName(jobName) 
    hi = null 
    def jobs = dep2.getAllJobs().toArray() 
    def onlyJob = jobs[0] //always 1 job...I think? 
    def targetedBuild = onlyJob.getLastSuccessfulBuild() 
    EnvVars me = targetedBuild.getCharacteristicEnvVars() 
    def es = me.entrySet() 
    int targetBuildNum = 0; 
    def vars = es.iterator() 
    while(vars.hasNext()){ 
     def envVar = vars.next() 
     if(envVar.getKey().equals("BUILD_ID")){ 
      targetBuildNum = Integer.parseInt(envVar.getValue()) 
     } 
    } 
    if (buildNum > targetBuildNum) { 
     return false 
    } 
    return true 

} 

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