जब एक प्रोजेक्ट को कई सबप्रोजेक्ट में अलग करना है


30

मैं जानना चाहूंगा कि क्या यह उस परियोजना को विभाजित करने के लिए समझ में आता है जिसे मैं एक के बजाय दो रिपॉजिटरी में काम कर रहा हूं।

मैं क्या कह सकता हूं:

  • Frontend को html + js में लिखा जाएगा
  • बैकएंड में .net
  • बैकएंड फ्रंटएंड पर निर्भर नहीं करता है और फ्रंटेंड बैकएंड पर निर्भर नहीं करता है
  • फ्रंटएंड बैकएंड में लागू एक आरामदायक एपि का उपयोग करेगा।
  • फ्रंटएंड को किसी भी स्थिर http सर्वर पर होस्ट किया जा सकता है।

अब तक, रिपॉजिटरी में यह संरचना है:

जड़:

  • फ़्रंट एंड/*
  • बैकएंड / *

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

मुझे बताया गया है कि यह व्यर्थ है और ऐसा करने से हमें कोई लाभ नहीं होगा।

यहाँ मेरे कुछ तर्क हैं:

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

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

जवाबों:


23

मेरी कंपनी में, हम सिस्टम के प्रत्येक घटक के लिए एक अलग SVN रिपॉजिटरी का उपयोग करते हैं। मैं आपको बता सकता हूं कि यह बेहद निराशाजनक है। हमारे निर्माण की प्रक्रिया में अमूर्तता की कई परतें हैं।

हम जावा के साथ ऐसा करते हैं, इसलिए हमारे पास javac संकलन, JibX बाध्यकारी संकलन, XML सत्यापन, आदि के साथ एक भारी निर्माण प्रक्रिया है।

आपकी साइट के लिए, यह एक बड़ी बात नहीं हो सकती है यदि आप वास्तव में "इसका निर्माण नहीं करते हैं" (जैसे वेनिला PHP)।

एक उत्पाद को कई रिपॉजिटरी में विभाजित करने के लिए डाउनसाइड करता है

  1. बिल्ड प्रबंधन - मैं सिर्फ चेकआउट कोड नहीं बना सकता, एक स्व-निर्मित बिल्ड स्क्रिप्ट चला सकता हूं और एक रनने योग्य / इंस्टॉल करने योग्य / तैनाती योग्य उत्पाद रख सकता हूं। मुझे एक बाहरी बिल्ड सिस्टम की आवश्यकता है जो कई रिपोज के लिए जाता है, कई आंतरिक बिल्ड स्क्रिप्ट चलाता है, फिर कलाकृतियों को इकट्ठा करता है।
  2. ट्रैकिंग बदलें - यह देखना कि कौन, कब और क्यों बदल गया। यदि दृश्यपटल में बग फिक्स में बैकएंड परिवर्तन की आवश्यकता होती है, तो बाद में वापस संदर्भित करने के लिए मेरे लिए अब 2 डायवर्जेंट पथ हैं।
  3. प्रशासन - क्या आप वास्तव में उपयोगकर्ता खातों, पासवर्ड नीतियों आदि की संख्या को दोगुना करना चाहते हैं जिन्हें प्रबंधित करने की आवश्यकता है?
  4. विलय - नई सुविधाओं में बहुत सारे कोड बदलने की संभावना है। अपने प्रोजेक्ट को कई रिपॉजिटरी में विभाजित करके, आप आवश्यक मर्ज की संख्या को गुणा कर रहे हैं।
  5. शाखा निर्माण - शाखा बनाने के लिए एक ही सौदा, एक शाखा बनाने के लिए, अब आपको प्रत्येक रिपॉजिटरी में एक शाखा बनाना होगा।
  6. टैगिंग - अपने कोड के सफल परीक्षण के बाद, आप रिलीज़ के लिए एक संस्करण को टैग करना चाहते हैं। अब आपके पास बनाने के लिए कई टैग हैं, प्रत्येक रिपॉजिटरी में एक।
  7. कुछ खोजने के लिए मुश्किल - शायद सामने / बैकेंड सीधा है, लेकिन यह एक फिसलन ढलान बन जाता है। यदि आप पर्याप्त मॉड्यूल में विभाजित होते हैं, तो डेवलपर्स को यह जांचना पड़ सकता है कि स्रोत नियंत्रण में कोड का कोई टुकड़ा कहाँ रहता है।

मेरा मामला थोड़ा चरम पर है क्योंकि हमारा उत्पाद 14 अलग-अलग रेपो में विभाजित है और प्रत्येक रेपो को 4-8 मॉड्यूल में विभाजित किया गया है। अगर मुझे याद है, हमारे पास लगभग 80 या कुछ "पैकेज" हैं, जिन्हें सभी को व्यक्तिगत रूप से जांचने और फिर इकट्ठा करने की आवश्यकता है।

सिर्फ बैकएंड / फ्रंटेंड के साथ आपका मामला कम जटिल हो सकता है, लेकिन मैं अभी भी इसके खिलाफ सलाह देता हूं।

चरम उदाहरण बहुत ज्यादा कुछ के लिए या उसके खिलाफ तर्क मजबूर कर सकते हैं :)

मानदंड मैं निर्णय लेने के लिए उपयोग करूंगा

मैं निम्नलिखित कारकों पर विचार करने के बाद एक उत्पाद को कई स्रोत कोड रिपॉजिटरी में विभाजित करने पर विचार करूंगा:

  1. बिल्ड - क्या प्रत्येक घटक के निर्माण के परिणाम एक साथ मिलकर एक उत्पाद बनाते हैं? जैसे .jar या .war फ़ाइलों की एक श्रृंखला में घटकों के एक समूह से .class फ़ाइलों को संयोजित करना।
  2. तैनाती - क्या आप उन घटकों के साथ समाप्त होते हैं जो एक इकाई या विभिन्न इकाइयों के रूप में एक साथ तैनात होते हैं जो विभिन्न सर्वरों पर जाते हैं? उदाहरण के लिए, डेटाबेस स्क्रिप्ट आपके DB सर्वर पर जाती हैं, जबकि जावास्क्रिप्ट आपके वेब सर्वर पर जाती है।
  3. सह-परिवर्तन - क्या वे बार-बार या एक साथ बदलते हैं? आपके मामले में, वे अलग-अलग बदल सकते हैं, लेकिन फिर भी अक्सर।
  4. ब्रांचिंग / मर्जिंग की आवृत्ति - अगर हर कोई ट्रंक और शाखाओं में जांच करता है, तो आप दुर्लभ हैं, आप इससे दूर हो सकते हैं। यदि आप अक्सर शाखा और विलय करते हैं, तो यह दुःस्वप्न में बदल सकता है।
  5. चपलता - यदि आपको एक पल की सूचना (सास के साथ होने की संभावना) पर एक परिवर्तन, परीक्षण, रिलीज और तैनाती की आवश्यकता है, तो क्या आप कीमती समय की बाजीगरी शाखाओं और रेपो को खर्च किए बिना कर सकते हैं?

आपके तर्क

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

हमारे पास दो मॉड्यूल हैं जो एक दूसरे के बीच निर्भर नहीं करते हैं।

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

लंबे समय में दोनों परियोजनाओं के स्रोत के इतिहास में चीजों को उलझाया जा सकता है (जब आप उन कमियों के आधे हिस्से के इतिहास में खोज करने का प्रयास करें जो आपके द्वारा खोजे गए बग से पूरी तरह से संबंधित नहीं हैं)

यदि आपका प्रोजेक्ट रूट फ्रंट / / और बैकएंड / में टूट गया है, तो आप उन पदानुक्रमों के इतिहास को स्वतंत्र रूप से देख सकते हैं।

संघर्ष और विलय (ऐसा नहीं होना चाहिए, लेकिन किसी को बैकएंड पर धकेलने से अन्य डेवलपर को फ्रंटएंड में बदलाव के लिए बैकएंड में बदलाव करने के लिए मजबूर किया जाएगा।) एक डेवलपर बैकएंड पर ही काम कर सकता है, लेकिन बैकएंड या दूसरे तरीके से हमेशा खींचना होगा। चारों ओर।

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

अगर चिंता यह है कि 2 रेपो का मतलब है कि एक फ्रंट डिविडेंड फ्रंटेंड कोड को मर्ज कर सकता है जबकि एक बैकएंड देव बैकएंड कोड को मर्ज करता है, तो आप अभी भी एसवीएन का उपयोग करके एकल रिपॉजिटरी के साथ कर सकते हैं। एसवीएन किसी भी स्तर पर विलय कर सकता है। हो सकता है कि यह एक परिमित या भावात्मक सीमा है (आपने दोनों को टैग किया है, इसलिए सुनिश्चित नहीं है कि आप SCM क्या उपयोग करते हैं)?

दूसरी ओर

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


सभी चीजों में संयम, जैसा कि मेरी मां कहती थी ...
विलियम पायने

मेरे लेखन के रूप में, मैं बैकएंड के बिना फ्रंटएंड लिख रहा हूं। मैं json फ़ाइलों के साथ बैकएंड का अनुकरण करता हूं, और मैं शायद ब्राउज़र में indexedDB के साथ पूरी तरह से अनुकरण भी कर सकता हूं। तो हाँ बैकएंड सिर्फ एक सर्वर है जो जसन की सेवा करता है। जब तक डेटा प्राप्त एपीआई के अनुरूप नहीं हो जाता, तब तक इसे कुछ भी बदल दिया जा सकता है। दोनों प्रोजेक्ट अलग-अलग बिल्ड सिस्टम का उपयोग करते हैं। संक्षेप में, यह एक वेबसाइट और एक मोबाइल एंड्रॉइड ऐप होने जैसा है। वेबसर्वर रिपॉजिटरी के अंदर मोबाइल एप्लिकेशन जोड़ना।
Lo --c Faure-Lacroix

अगर यह स्पष्ट नहीं था, तो बैकएंड और फ्रंटेंड उपयोगकर्ता / व्यवस्थापक इंटरफेस नहीं हैं। लेकिन फ्रंटएंड सिर्फ एक अजाक्स इंटरफेस है और बैकेंड जसन का काम करता है। उपयोगकर्ताओं और भूमिकाओं को अलग-अलग रूप से नियंत्रित किया जाता है और व्यवस्थापक इंटरफ़ेस फ्रंटएंड में होगा। यह विचार है कि दोनों भागों को अलग-अलग रखा जाए और जावास्क्रिप्ट जनरेट किए गए html को सर्वर जनरेट किए गए html को लोड करने से रोका जाए। सर्वर को केवल json या xml की सेवा देनी चाहिए।
Locc Faure-Lacroix

1
तब आपके पास कोई निर्माण या परिनियोजन समस्याएँ नहीं हैं, इसलिए यह ठीक हो सकता है। लेकिन फिर से, यदि आप एक बड़ा बदलाव करते हैं, तो आपको एपीआई को बदलने की आवश्यकता हो सकती है, जो कि फ्रंटएंड और बैकएंड दोनों को प्रभावित करता है और इस तरह आप दो बार ब्रांचिंग करेंगे, दो बार विलय करेंगे, दो बार टैगिंग करेंगे, आदि लेकिन जब तक यह केवल दो बार रहता है और doesn टी 3 में बदल ... 4 ... 12 ... 20, शायद एक बुरा विचार नहीं है।
ब्रैंडन

यहां तक ​​कि अगर एपीआई बदलता है, तो उचित संस्करण के साथ, एपीआई के समर्थन वाले प्रत्येक फ्रंटेंड के लिए शाखा संस्करण बनाना संभव हो सकता है। बैकएंड में कुछ "पिछड़े" संगतता होनी चाहिए और पुराने एपीआई को यथासंभव लंबे समय तक काम करते रहना चाहिए।
लोकेक फ्योर-लैक्रोसिक्स

3

आपके कुछ तर्क मान्य हैं और कुछ नहीं हैं।

हमारे पास दो मॉड्यूल हैं जो एक दूसरे के बीच निर्भर नहीं करते हैं।

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

लंबे समय में दोनों परियोजनाओं के स्रोत के इतिहास में चीजों को उलझाया जा सकता है (जब आप उन कमियों के आधे हिस्से के इतिहास में खोज करने का प्रयास करें जो आपके द्वारा खोजे गए बग से पूरी तरह से संबंधित नहीं हैं)

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

संघर्ष और विलय (यह नहीं होना चाहिए, लेकिन किसी को बैकएंड पर धकेलने से अन्य डेवलपर को फ्रंटएंड परिवर्तनों को आगे बढ़ाने के लिए बैकएंड परिवर्तन खींचने के लिए मजबूर होगा।)

यह एक संगीन तर्क है। मुझे किसी भी (आधे सभ्य) वीसीएस के बारे में पता नहीं है जहां आपको अपने परिवर्तनों को करने / धक्का देने से पहले संपूर्ण रिपॉजिटरी को सिंक्रनाइज़ करने की आवश्यकता है। अधिकांश पर आपको उन फ़ोल्डरों को सिंक्रनाइज़ करने की आवश्यकता होती है जिनमें परिवर्तित फाइलें होती हैं (और अक्सर केवल फाइलें स्वयं)।

एक डेवलपर केवल बैकएंड पर काम कर सकता है, लेकिन हमेशा बैकएंड या दूसरे तरीके से उसे खींचना होगा।

यह पहले की तरह ही संगीन तर्क है।

लंबे समय में, जब यह तैनात करने का समय होगा। किसी तरह, बैकएंड सर्वर होने पर, फ्रंटेंड को कई स्थिर सर्वर पर तैनात किया जा सकता है। हर मामले में, लोगों को या तो इसके साथ पूरे बैकएंड को क्लोन करने के लिए मजबूर किया जाएगा या कस्टम स्क्रिप्ट बनाने के लिए सभी सर्वरों को आगे बढ़ाने के लिए या बैकएंड को हटाने के लिए धक्का दिया जाएगा। अगर केवल एक की जरूरत है तो केवल फ्रंट या बैकेंड को आगे बढ़ाने / खींचने में आसान है।

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

काउंटर तर्क (एक व्यक्ति दोनों परियोजनाओं पर काम कर सकता है), सबमॉड्यूल के साथ तीसरा रेपो बनाएं और इसके साथ विकसित करें। इतिहास को अलग-अलग मॉड्यूल में अलग रखा जाता है और आप हमेशा ऐसे टैग बना सकते हैं जहां बैकएंड / फ्रंटेंड का संस्करण वास्तव में सिंक में एक साथ काम करता है। दोनों रेपो / बैकएंड एक साथ एक रेपो में होने का मतलब यह नहीं है कि वे एक साथ काम करेंगे। यह सिर्फ दोनों इतिहास को एक बड़े रेपो में विलय कर रहा है।

यह एक मान्य तर्क है, लेकिन यह उतना मजबूत नहीं है।

यदि आप प्रोजेक्ट में एक फ्रीलांसर जोड़ना चाहते हैं, तो सबमॉड्यूल के रूप में फ्रंटएंड / बैकएंड होने से चीजें आसान हो जाएंगी। कुछ मामलों में, आप वास्तव में कोडबेस की पूरी पहुँच नहीं देना चाहते हैं। यदि आप "बाहरी लोगों" को देख / संपादित कर सकते हैं, तो एक बड़ा मॉड्यूल रखने से चीजें कठिन हो जाएंगी।

यह एक मान्य तर्क है।

बग परिचय और फिक्सिंग बग, मैंने फ्रंटेंड में एक नया बग डाला। फिर कोई बैकएंड में बग को ठीक करता है। एक रिपॉजिटरी के साथ, नए बग से पहले वापस रोल करने से बैकएंड भी रोलबैक हो जाएगा जिससे इसे ठीक करना मुश्किल हो सकता है।

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

मैं एक अलग फ़ोल्डर में बैकएंड को क्लोन करना चाहता हूं, बैकएंड को बग में फिक्सिंग के दौरान काम करना है ... फिर चीजों को फिर से जोड़ने की कोशिश कर रहा है ... दो रिपॉजिटरी होने के बाद दर्द रहित होगा क्योंकि एक रेपो के सिर को जीतना 'दूसरे को मत बदलो। और बैकएंड के विभिन्न संस्करण के खिलाफ परीक्षण दर्द रहित होगा।

यह वास्तव में काफी अच्छा तर्क है। दो रिपॉजिटरी होने से उन परिदृश्यों का परीक्षण करना आसान हो जाता है, जहां तैनात फ्रंट- और बैक-एंड सिंक से बाहर (थोड़ा) हो सकते हैं।


ईमानदार होने के लिए, अधिकांश फर्जी दलीलों को शाखाओं के साथ हल किया जा सकता है। बैकएंड के लिए शाखा और बैकएंड के लिए शाखा। सिंक के लिए मास्टर। लेकिन किसी तरह, इस तरह से शाखा को संभालना दो रिपोज होने की तुलना में चीजों को और अधिक जटिल बना रहा है।
लोकेक फ्योर-लैक्रोइक्स

1
@ संयम: वास्तव में, वे फर्जी तर्क हैं, क्योंकि वे एक समस्या को उजागर नहीं करते हैं जो एकल रिपॉजिटरी का उपयोग करने के साथ मौजूद हो सकती है, भले ही सभी परिवर्तन केवल ट्रंक / मुख्य करने के लिए किए गए हों।
बार्ट वैन इनगेन शानौ

मुझे लगता है कि आपके आलोचक मान्य हैं। मुझे नहीं लगता कि यह प्रश्न का बिंदु था।
सिल्वानार

2

यह पोस्ट थोड़ी पुरानी है लेकिन मैं इसमें योगदान देना चाहूंगा। जबकि आपके बैक-एंड को वास्तव में फ्रंट-एंड के बारे में नहीं पता है कि बैक-एंड के एपीआई से मेल खाते अनुरोधों की आवश्यकता है। यदि आप अपने बैक-एंड को REST API मानते हैं, तो आप एक इंटरफ़ेस फ़ाइल जैसे कि स्वैगर YAML इंटरफ़ेस को परिभाषित कर सकते हैं। अब वास्तव में 3 परियोजनाएं हैं, जिन्हें आप व्यक्तिगत रूप से अलग-अलग रिपोज में विभाजित कर सकते हैं जैसे कि आप फिट देखते हैं:

  • एपीआई परिभाषा
  • बैक-एंड
  • फ़्रंट एंड

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

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

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

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