मोनोरेपो की मल्टीरेपो

सामग्री:

• सारांश
  • समस्या
  • निर्णय
  • स्थिती
• तपशील
  • गृहीतके
  • मर्यादा
  • मते
  • युक्तिवाद
  • परिणाम
• संबंधित
  • संबंधित निर्णय
  • संबंधित आवश्यकता
  • संबंधित आर्टिफॅक्ट्स
  • संबंधित तत्त्वे
• टिपा

सारांश

समस्या

आमच्या प्रकल्पात सॉफ्टवेअरच्या तीन प्रमुख वर्गांचा विकास समाविष्ट आहे:

• फ्रंट-एंड GUI
• मिडलवेअर सेवा
• बॅक-एंड सर्व्हर

आम्ही विकास करतो तेव्हा आमची स्रोत कोड व्यवस्थापन (SCM) आवृत्ती नियंत्रण प्रणाली (VCS) git आहे.

आमचा कोड व्यवस्थित करण्यासाठी git कसे वापरायचे ते आम्हाला निवडायचे आहे.

सर्वोच्च-स्तरीय निवड म्हणजे "मोनोरेपो" किंवा "पॉलीरेपो" किंवा "हायब्रिड" म्हणून व्यवस्थित करणे:

• मोनोरेपो म्हणजे आम्ही सर्व भाग एका मोठ्या रेपोमध्ये ठेवतो
• पॉलीरेपो म्हणजे आम्ही प्रत्येक भाग त्याच्या स्वतःच्या रेपोमध्ये ठेवतो
• हायब्रिड म्हणजे मोनोरेपो आणि पॉलीरेपोचे काही मिश्रण

अधिक माहितीसाठी कृपया https://github.com/joelparkerhenderson/monorepo-vs-polyrepo पहा

निर्णय

जेव्हा संस्था/संघ/प्रकल्प तुलनेने लहान असतो, आणि स्थिरता टिकवण्यापेक्षा जलद पुनरावृत्तीला उच्च प्राधान्य असते तेव्हा मोनोरेपो.

जेव्हा संस्था/संघ/प्रकल्प तुलनेने मोठा असतो, आणि जलद पुनरावृत्तीपेक्षा स्थिरता टिकवण्याला उच्च प्राधान्य असते तेव्हा पॉलीरेपो.

स्थिती

ठरले. मोनोरेपो आणि/किंवा पॉलीरेपो व्यवस्थापित करण्यासाठी नवीन साधने उपलब्ध झाल्यास/जेव्हा होतील तेव्हा पुन्हा विचार करण्यासाठी खुले.

तपशील

गृहीतके

आम्ही विकसित करत असलेला सर्व कोड एका संस्थेच्या उत्पादनांसाठी आहे, सामान्य जनतेसाठी नाही. म्हणजे ब्रोकर-डीलरचे सामान्य जनतेच्या स्वयंसेवी विकासकांसारखे काहीही असण्याचे उद्दिष्ट नाही.

मर्यादा

मर्यादा https://github.com/joelparkerhenderson/monorepo-vs-polyrepo येथे चांगल्या प्रकारे दस्तऐवजीकृत आहेत

मते

आम्ही Google, Facebook इत्यादींच्या शैलीतील मोनोरेपोंचा विचार केला. आम्हाला वाटते की मोनोरेपोच्या प्रमाण वाढवण्याच्या कोणत्याही समस्या इतक्या भविष्यात आहेत की त्यांची आवश्यकता पडेपर्यंत आम्ही Google आणि Facebook च्याच प्रथांचा लाभ घेऊ शकू.

आम्ही Google Android, Facebook React इत्यादी सामान्य Git ओपन सोर्स प्रकल्पांच्या शैलीतील पॉलीरेपोंचा विचार केला. आम्हाला वाटते की सामान्य जनतेच्या सहभागासाठी (उदा. जगातील कोणीही कोडवर काम करू शकते) आणि वैयक्तिक उपलब्धतेसाठी (उदा. प्रकल्प कोणत्याही इतर भागांशिवाय स्वतःच वापरला जातो) हीच सर्वोत्तम निवड आहे.

युक्तिवाद

जेव्हा संस्था/संघ/प्रकल्प तुलनेने लहान असतो, तेव्हा आम्ही मोनोरेपो निवडतो, कारण स्थिरता टिकवण्यापेक्षा जलद पुनरावृत्तीला लक्षणीयरीत्या उच्च प्राधान्य असते

जेव्हा संस्था/संघ/प्रकल्प तुलनेने मोठा असतो, तेव्हा आम्ही पॉलीरेपो निवडतो, कारण जलद पुनरावृत्तीपेक्षा स्थिरता टिकवण्याला लक्षणीयरीत्या उच्च प्राधान्य असते.

परिणाम

CI+CD साठी विद्यमान पाइपलाइन असल्यास, एका रेपोमधील अनेक प्रकल्पांची चाचणी घेण्यासाठी आम्हाला ती जुळवून घ्यावी लागू शकते.

मोनोरेपोसाठी पूर्ण बिल्डला CI+CD मध्ये जास्त वेळ लागू शकतो, कारण CI+CD मोनोरेपोमधील सर्व प्रकल्प बिल्ड करू शकते.

संस्था/संघ/प्रकल्प वाढल्यास, मोनोरेपोला प्रमाण वाढवण्याच्या समस्या येतील.

मोनोरेपोच्या प्रमाण वाढवण्याच्या समस्यांमुळे पॉलीरेपोकडे संक्रमण करणे अधिकाधिक मौल्यवान होऊ शकते.

मोनोरेपोकडून पॉलीरेपोकडे संक्रमण हे महत्त्वपूर्ण devops काम आहे, आणि त्याचे नियोजन, व्यवस्थापन आणि प्रोग्रामिंग करावे लागेल.

संबंधित

संबंधित निर्णय

आम्ही मोनोरेपो (उदा. Google Bazel) आणि पॉलीरेपो (उदा. Lyft Refactorator) व्यवस्थापित करण्यासाठी संबंधित साधनांसाठी निर्णय तयार करू.

संबंधित आवश्यकता

आम्हाला CI+CD पाइपलाइन git सह चांगले काम करेल अशी विकसित करावी लागेल.

संबंधित आर्टिफॅक्ट्स

रेपो संघटनेसोबत प्रोव्हिजनिंग, कॉन्फिगरेशन व्यवस्थापन, चाचणी आणि तत्सम devops क्षेत्रांसाठी संबंधित आर्टिफॅक्ट्स असतील अशी आमची अपेक्षा आहे.

संबंधित तत्त्वे

सहज पलटवता येण्याजोगे. मोनोरेपो व्यवहारात काम करत नसेल, किंवा नेतृत्वाला नको असेल, तर पॉलीरेपोमध्ये बदलणे सोपे आहे.

ग्राहकाचे वेड. प्रकल्प ग्राहकांच्या हातात देण्याला आम्ही महत्त्व देतो, आणि आमचा विश्वास आहे की मोनोरेपो आम्हाला तिथे पॉलीरेपोपेक्षा जलद पोहोचवू शकतो, आणि जलद पुनरावृत्ती करण्यासही मदत करू शकतो.

मोठा विचार करा. Google आणि Facebook हे पॉलीरेपोपेक्षा मोनोरेपोचे अतिशय जोरदार पुरस्कर्ते आहेत, कारण सर्व मुख्य उत्पादने एकत्रितपणे विकसित/चाचणी/डिप्लॉय करता येतात.

टिपा

येथे कोणत्याही टिपा जोडा.