Azure devops में Pipeline और Release Pipeline के बीच क्या अंतर है?

Question

जब आप नीचे दिखाए गए इस विकल्प को चुनते हैं तो एक यमल फ़ाइल बनती है:

इस yaml फ़ाइल में, आप शुरू होने वाले संपूर्ण परिनियोजन चक्र को परिभाषित कर सकते हैं restore -> build -> run tests -> publish and -> deploy to azure app service web app।

उसके बाद, रिलीज़ विकल्प क्यों है? यदि मैं Pipelines -> Pipelinesविकल्प के माध्यम से संपूर्ण जीवनचक्र को परिभाषित कर सकता हूं , तो विकल्प का उद्देश्य क्या है Pipelines -> Releases?

Comments

क्या नीचे दिया गया उत्तर आपको वह हासिल करने में मदद कर सकता है जो आप चाहते हैं? यदि हाँ, तो आप उत्तर को स्वीकार कर सकते हैं इस प्रकार अन्य SO उपयोगकर्ता यह देख पाएंगे कि समाधान काम करता है या नहीं। यदि आप अभी भी कुछ मुद्दों का सामना कर रहे हैं, तो बेझिझक टिप्पणी यहां छोड़ें :-)

— फ्रैंक वांग-एमएसएफटी

Answer 1

पाइपलाइनों के लिए नवीनतम DevOps उपयोगकर्ता इंटरफ़ेस में एक नाम है। पुराने UI में यह इस प्रकार है:

यह कहा जा सकता है कि Pipeline(या बिल्ड, या बिल्ड पाइपलाइन) Azure DevOps में CI (निरंतर एकीकरण) का प्रतिनिधित्व करता है। ReleaseAzure DevOps में CD (निरंतर वितरण) का प्रतिनिधित्व करता है। पाइपलाइन आमतौर पर कोड लेता है, इसे बनाता है, परीक्षण करता है और एक कलाकृति बनाता है। रिलीज कलाकृतियों को लेती है और रिलीज / इसे दर्शाती है।

उपयोग आपके प्रोजेक्ट पर निर्भर करता है।

यदि आपके पास एक छोटी परियोजना है और रिलीज़ सुविधाओं (जैसे पूर्व-परिनियोजन की स्थिति और अनुमोदन) restore -> build -> tests -> deployमें कोई आवश्यकता नहीं है , तो आपके पास पाइपलाइन का उल्लेख हो सकता है: जैसा कि आपने उल्लेख किया है: और रिलीज़ में कोई आवश्यकता नहीं है।

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

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

Comments

यह बिल्कुल सटीक नहीं है, क्योंकि पाइपलाइन (जब YAML फ़ाइलों के रूप में निर्दिष्ट होती है) भी रिलीज परिदृश्य का समर्थन करती है।

— डैनियल मान

@DanielMann ने इसके विपरीत नहीं कहा, वह ऑप की भटकन का जवाब दे रही है, दोनों के बीच के अंतर को समझाकर

— AymenDaoudi

Answer 2

जैसा कि Microsoft डॉक्स में बताया गया है, "रिलीव्स" खंड उनका "क्लासिक एडिटर" समाधान है: लिंक

"पाइपलाइन" अनुभाग दो तरीकों से पाइपलाइन बनाने की पेशकश करता है:

1. YAML कोड
2. क्लासिक यूआई संपादक

उनके द्वारा मूल रूप से क्लासिक का मतलब क्या है, मूल तरीका एज़्योर देव ऑप्स पाइपलाइन बनाया जाता है। आप एक इंटरैक्टिव तरीके से जीयूआई संपादक का उपयोग करके एक पाइपलाइन का निर्माण करते हैं। सहायक की मदद से YAML से बनाई गई पाइपलाइन नया तरीका है ।

क्या "पाइपलाइन" खंड मुख्य रूप से है "विज्ञप्ति" कि YAML कोड लिख कर यह आप कोड है, जहां, पाइपलाइन परिभाषा जीवन के साथ-साथ और एक साथ अपने कोड के साथ के रूप में अपने सीआई / सीडी रणनीति कॉन्फ़िगर करने देता है नहीं है है।

उनके नवीनतम सीखने के संसाधन भी एक ही पाइपलाइन में YAML का उपयोग करने और निर्माण और तैनाती चरणों का निर्माण करने के लिए संकेत देते हैं, Azure Devotps के साथ एप्लिकेशन का उपयोग करें

मेरा सुझाव है:

• यदि आप क्लासिक UI एडिटर का उपयोग बिल्ड के लिए "पाइपलाइन" अनुभाग और तैनाती के लिए "रिलीज" अनुभाग का उपयोग करना पसंद करते हैं ;
• यदि आप YAML का उपयोग करना पसंद करते हैं, तो बस बिल्ड और परिनियोजन के लिए "पाइपलाइन" अनुभाग का उपयोग करें और एक मल्टीस्टेज पाइपलाइन बनाएं।

कई चरणों के साथ पाइपलाइन

Comments

यह वास्तव में भ्रामक है कि वे चीजों का नामकरण कैसे कर रहे हैं।

— ओमेनदौड़ी