वेब विकास के लिए जीआईटी वर्कफ़्लो

Question

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

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

दोस्तों हाल के एक सुझाव पर मैंने GitHub Flow को देखना शुरू किया है । स्कॉट चाकोन की पोस्ट को पढ़ना यहाँ दर्द बिंदु को पूरी तरह से प्रभावित करता है:

तो, हम GitHub पर git-flow का उपयोग क्यों नहीं करते हैं? खैर, मुख्य मुद्दा यह है कि हम हर समय तैनात हैं। गिट-फ्लो प्रक्रिया को बड़े पैमाने पर "रिलीज" के आसपास तैयार किया गया है। हमारे पास वास्तव में "रिलीज़" नहीं है क्योंकि हम हर दिन उत्पादन के लिए तैनात करते हैं - अक्सर एक दिन में कई बार।

FWIW, मैंने एटलसियन की साइट पर वर्कफ़्लोज़ के इस अच्छे दौर को भी देखा है: https://www.atlassian.com/git/workflows# -workflow-feature-branch!

हालांकि, वे सभी एक छोटी सी टीम में वेब विकास के लिए खराब विकल्पों की तरह दिखते हैं और फिर से प्रमुख एप्लिकेशन रिलीज की ओर अग्रसर होते हैं जो अक्सर / दैनिक रिलीज नहीं होते हैं।

एसई पर एक सवाल है जो गिट-फ्लो की तुलना जीथब-फ्लो /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github पर करने के लिए कह रहा है। -बहे

यह सामान्य रूप से एक अच्छा उत्तर है, लेकिन जैसा कि मैंने मेटा.प्रोग्रामर्स के नीचे अपनी टिप्पणी में उल्लेख किया है। मुझे लगता है कि सामान्य सर्वश्रेष्ठ वर्कफ़्लो प्रथाओं के बारे में प्रश्न यहाँ दिए गए हैं और मैं सिर्फ git-flow और github की तुलना में संभावित उत्तर की एक विस्तृत सूची की उम्मीद कर रहा था -फ्लो होना, जबकि वेब डेवलपमेंट के लिए विशिष्ट होना। इसलिए मुझे लगता है कि यह यहाँ एक नया प्रश्न है।

इसके साथ, आपको क्या लगता है कि एक छोटी वेब विकास टीम के लिए सबसे अच्छा / पसंद किया जाने वाला git आधारित वर्कफ़्लो है जो काफी निरंतर तैनाती वाली परियोजनाओं पर काम कर रहा है? क्या यह गितुब-प्रवाह या कुछ और है?

Comments

BTW, मैं यहाँ पर इस सवाल को Programmers.SE पर आधारित कर रहा हूँ: meta.programmers.stackexchange.com/posts/6312/revisions

— jb510

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

— gnat

@gnat मुझे यकीन नहीं है कि मैं उस संबंध में और क्या साझा कर सकता हूं? gitflow हो रहा है तो रिलीज उन्मुख बोझिल है। GitHub- फ़्लो पर्पस दैनिक तैनाती के लिए अच्छा है, लेकिन दर्जनों शाखाओं में विलय होने का इंतजार भी अराजकता की तरह दिखता है। उम्मीद कर रहा था कि कोई व्यक्ति "एक्स वेब देव के लिए महान है क्योंकि वाई" के साथ जवाब देगा। यह मेरे द्वारा प्रदान किए गए लिंक में अच्छी तरह से शामिल है, मुझे लगता है कि मैं इसके उद्धरण उद्धृत कर सकता हूं?

— jb510

@gnat - मैं पूरी तरह से अधिक शोध दिखाने के लिए प्रश्न को फिर से लिखता हूं और जिस उत्तर की तलाश कर रहा हूं उसके बारे में बहुत विशिष्ट होना चाहिए।

— jb510

Answer 1

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

• केंद्रीकृत ( स्रोत ): SVN वर्कफ़्लो की तरह बहुत सुंदर लेकिन अब एक वितरित वातावरण पर। प्रत्येक डेवलपर अपनी व्यक्तिगत प्रति पर काम करता है masterऔर परिवर्तनों को origin/masterसीधे या पुल अनुरोध के माध्यम से धक्का देता है ।

• फ़ीचर शाखा ( स्रोत ): ठीक है, कि। किसी विशेष सुविधा पर काम करने वाले प्रत्येक डेवलपर को केवल उस सुविधा के लिए समर्पित एक विशिष्ट शाखा पर काम करना चाहिए। यह सुविधा शाखा masterकिसी अन्य सुविधा शाखा से या उससे निर्मित होनी चाहिए । अंततः सब कुछ वापस विलय हो जाता है master।

• Gitflow ( स्रोत ): दो मुख्य शाखाएँ प्रोजेक्ट इतिहास को ट्रैक करती हैं, developऔर master। एक और 3 शाखाओं बुलाया hotfix, releaseऔर featureपकड़ परिवर्तन करने के लिए सीधे किए गए masterमहत्वपूर्ण उत्पादन कीड़े, परिवर्तन संस्करण संख्या और अन्य विवरण एक रिलीज या बस की तरह एक विशेष सुविधा पर काम करने से पहले ठीक करने के लिए फ़ीचर शाखा , क्रमशः।

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

आपके प्रश्न के विकास भाग के लिए, उत्तर आपकी टीम की पृष्ठभूमि पर निर्भर करता है। क्या वे एक SVN वातावरण से आते हैं? तब आपको केंद्रीयकृत दृष्टिकोण के साथ जाना चाहिए क्योंकि यह वह है जो एसवीएन सबसे मिलता जुलता है। क्या वे Git के साथ काम करने में सहज महसूस करते हैं? तब शायद आपको अपनी टीम के वर्कफ़्लो को उनमें से किसी एक में भी ढालने की कोशिश नहीं करनी चाहिए, लेकिन अपनी ज़रूरतों को पूरा करने के लिए खुद को तैयार करना चाहिए, जो अगर मुझे अच्छी तरह समझ में आ जाए, तो वह है विकास का लचीलापन और तेज़ परिनियोजन।

मुझे भी लगता है कि आपको बाद में सुधार करने पर ध्यान देना चाहिए। आपकी तैनाती पाइपलाइन किस प्रकार से बनी है? " सतत वितरण: विश्वसनीय सॉफ्टवेयर बिल्ड, टेस्ट, और परिनियोजन स्वचालन के माध्यम से जारी करता है " लेखक असीम तैनाती के संभावित कारणों की पहचान करते हैं, जिनमें से कुछ हैं:

• तैनाती की प्रक्रिया स्वचालित नहीं है।
• परीक्षण में लंबा समय लगता है।
• लोग निर्माण / परीक्षण / तैनाती प्रक्रिया को नहीं समझते हैं।
• डेवलपर्स को छोटे, वृद्धिशील परिवर्तन करके आवेदन को चालू रखने के बारे में अनुशासित नहीं किया जा रहा है, और इसलिए अक्सर मौजूदा कार्यक्षमता को तोड़ते हैं

क्या आप जो कुछ भी सुधार कर सकते हैं, उनमें से कोई भी ध्वनि है? शायद आप हमें इस बारे में थोड़ा और बता सकते हैं कि आप और आपकी टीम परियोजना के इस हिस्से को कैसे संभालती है।

Comments

+1, cd की कुंजी git या आपके gitflow नहीं बल्कि CI और डिलीवरी वर्कफ़्लो है।

— व्याट बार्नेट

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

— jb510

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

— व्याट बार्नेट

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

— Kzqai

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

— jb510