आप अपने प्रोजेक्ट फ़ोल्डर को कैसे व्यवस्थित करते हैं? [बन्द है]

Question

नमस्कार

मैं जानना चाहूंगा कि आप लोग अपने प्रोजेक्ट फ़ोल्डर को कैसे व्यवस्थित करते हैं?

मेरे पास एक बार एक बॉस था जो मुझे ग्राहकों द्वारा व्यवस्थित करने का सुझाव देता था।

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

मेरे एक मित्र ने मुझे टेक्नोलॉजी द्वारा मंदिर का आयोजन करने के लिए कहा

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

और आप? क्या आपके पास अपने प्रोजेक्ट फ़ोल्डर को व्यवस्थित करने का एक चतुर तरीका है?

Comments

# 2 बेहतर है ...

— Yousha Aleayoub

नमस्ते, 2018 यहाँ। आपने क्या चुना?

— डेनियल आयटेकिन

Answer 1

यह वही है जो हम उपयोग कर रहे हैं:

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

हम इस संरचना का उपयोग कई अलग-अलग ग्राहकों के साथ कई वर्षों से कर रहे हैं और यह बहुत अच्छी तरह से काम करता है।

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

हर कोई अपनी (विंडोज़) देव मशीन पर अपनी कार्यशील प्रतियों की जाँच करता है और उस स्थान पर एक ड्राइव अक्षर को मैप करने के लिए SUBST कमांड का उपयोग करता है। इस तरह हम फ़ाइलों, आदि के निर्माण में कठिन-कोडित सापेक्ष पथ हो सकते हैं, जो हर किसी के सेटअप में काम करते हैं। इसलिए, उदाहरण के लिए, यदि हम चाहें, तो हमारे पास साझा पुस्तकालयों के लिंक हो सकते हैं। हम इस थो को प्राप्त करने के लिए आमतौर पर संस्करण नियंत्रण लिंक / उपनाम का उपयोग करते हैं।

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

आपका दूसरा सुझाव इतनी जटिल परियोजना के साथ काम नहीं करेगा जो एक से अधिक तकनीकों का उपयोग करती है।

Comments

बहुत ही उचित, लेकिन -1 हार्डकोडेड पूर्ण पथ की आवश्यकता के लिए। हार्डकॉस्ट किए गए रिश्तेदार पथ 99.9% चीजों के लिए काम करना चाहिए।

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

एर, मैं वहाँ में पूर्ण पथ डाल दिया?

— JBRWilkinson

Answer 2

मैं बहुत सपाट हूँ:

/ परियोजनाओं

बॉक्स के आधार पर कुछ संस्करण प्राप्त हो रहे हैं, लेकिन इसके पीछे परियोजनाओं के लिए बहुत सारे व्यक्तिगत फ़ोल्डर हैं। असली सौदा किसी भी तरह से स्रोत नियंत्रण में रहता है, इसलिए यह सिर्फ अस्थायी स्थानीय घर है।

Answer 3

मेरे पास एक संरचना है जो शिथिल निम्नलिखित की तरह दिखती है:

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archivesपुरानी परियोजनाएँ हैं जिनमें अब मैं काम नहीं कर रहा हूँ। Workइसमें काम से जुड़ी परियोजनाएं शामिल हैं। Currentसभी वर्तमान विकास है। फिर, अपनी होम निर्देशिका में, मैं सिमलिंक Projectsके लिए ~/Developer/Projects/Current। ~/Projectsइसमें कुछ कार्य परियोजनाओं के लिए सीमलिंक भी शामिल हैं।

Comments

करंट से वर्क से लेकर आर्काइव तक के प्रोजेक्ट्स को चालू करना सोर्स वर्जन कंट्रोल टूल्स का इस्तेमाल नहीं करता। इस मामले में फ़ोल्डर के संदर्भ / लिंक (वर्किंग कॉपी के बाहर) होना बेहतर है। हो सकता है कि आप 'अभिलेखागार', 'वर्तमान' और 'कार्य' के अंदर काम की प्रतियाँ ले जा रहे हों?

— Fil

@ फ़ील: मैं गिट का उपयोग करता हूं। प्रत्येक परियोजना का अपना स्व-निहित रेपो है, इसलिए इससे कोई फर्क नहीं पड़ता कि वह कहां चली गई है।

— मिपादी

Answer 4

मेरे पास एक सपाट संरचना भी है।

/ परियोजनाओं

वायट बार्नेट के साथ सहमत, असली सौदा वैसे भी स्रोत नियंत्रण में रहता है।

बस यह जोड़ना चाहते हैं कि वैसे भी फ़ोल्डर संरचना के बारे में कुछ विशेष नहीं होना चाहिए, क्योंकि कई आईडीई वैसे भी हाल की परियोजनाओं / फाइलों को शॉर्टकट प्रदान करते हैं। और कितने प्रोजेक्ट किसी पर भी काम करते हैं? सच में, केवल परिभाषा से, हाल ही में।

इसके अलावा, मैं हाल की परियोजनाओं को वैसे भी शीर्ष स्तर के फ़ोल्डर में जोड़ता हूं। मैं सभी पुराने और पूर्ण किए गए सामानों को संग्रहीत करता हूं:

/ परियोजनाएं / Old_stuff

या कुछ इस तरह का। मैं संग्रह करता हूं जो मैं आमतौर पर फिर से काम नहीं करूंगा।

Comments

आप आश्चर्यचकित होंगे - मुझे आमतौर पर एक दर्जन या तो प्रोजेक्ट की जरूरत होती है, चालू और मेरे "गो" लैपटॉप पर चलने के लिए तैयार और एक सामान्य दिन के दौरान आसानी से आधा दर्जन खोल सकते हैं।

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

Answer 5

मेरे पास, अतीत में, मेरे स्रोत दस्तावेजों को संग्रहीत करने के लिए सबवर्सन रिपॉजिटरी का इस्तेमाल किया, और रिपॉजिटरी संगठन के लिए "प्रोजेक्ट-माइनर" सम्मेलन का पालन किया, जो मुझे बड़े और छोटे दोनों संगठनों के लिए बहुत अच्छा काम करने के लिए मिला है।

हम अपनी रिपॉजिटरी शाखाओं की संरचना करेंगे; टैग और ट्रंक निम्नानुसार हैं:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

वास्तविक स्रोत वृक्ष के भीतर, हम निम्नलिखित संरचना का उपयोग करेंगे (जैसे कुछ):

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

इंजीनियरिंग टीम के बीच संरचना संचार में मदद करने के लिए रिपॉजिटरी की संरचना का उपयोग करने के लिए यह विचार (और अभी भी है) था; व्यवसाय का ग्राहक-सामना करने वाला हिस्सा और विभिन्न अन्य हितधारक और डोमेन विशेषज्ञ।

बुद्धि के लिए: "प्रोजेक्ट" निर्देशिकाओं में से एक में बैठने वाले स्रोत दस्तावेज केवल एक बार उपयोग किए जाते हैं (और पैसा कमाते हैं)। "प्रोडक्टलाइन" निर्देशिकाओं में से एक में बैठने वाले दस्तावेज़ पैसे कमाते हैं जितनी बार उस विशेष लाइन से उत्पाद बेचा जाता है। दस्तावेज़ जो "पुस्तकालयों" निर्देशिकाओं में से एक में बैठते हैं, वे कई बार पैसा कमाते हैं जितना कि उन उत्पादों में से कोई भी होता है जो उन्हें बेच देते हैं।

यह लागतों के परिशोधन की धारणा को स्पष्ट करता है, और व्यापार में स्रोत दस्तावेज़ पुन: उपयोग के लिए समर्थन बनाने में मदद करता है।

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

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

एक अंतिम नोट के रूप में; निरंतर एकीकरण प्रणाली को पता है कि इसे एक बिल्ड को ट्रिगर करने की आवश्यकता है; स्थिर विश्लेषण; हर बार ट्रंक को संशोधित करने के लिए हर बार ट्रंक को संशोधित किया जाता है, और हर बार किसी भी "टैग" शाखा को संशोधित किया जाता है। इस तरह, व्यक्तिगत डेवलपर्स अपनी व्यक्तिगत शाखाओं, एक महत्वपूर्ण क्षमता, IMHO के साथ CI सिस्टम का उपयोग कर सकते हैं।

Answer 6

मुझे लगता है कि आप "प्रलेखन फ़ोल्डर" का मतलब है। मैं क्षेत्र के लिए अपने दस्तावेज़ों का आयोजन सबसे पहले, ग्राहक / आवेदन के बाद, "विकास और रखरखाव" के लिए करता हूँ।

उदाहरण: प्रोजेक्ट

• वित्तीय

  • वेब एप्लीकेशन

    • ऐप अल्फा

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • ऐप बीटा

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • डेस्कटॉप सॉफ्टवेयर
• ऊर्जा और उपयोगिताओं
• बीएलए बीएलए

Comments

संस्करण नियंत्रण के बारे में क्या? जैसे-जैसे यह आगे बढ़ता है एक अल्फा दस्तावेज़ एक बीटा दस्तावेज़ नहीं बन जाता है?

— JBRWilkinson

स्थानीय डेस्कटॉप में मैंने सभी संस्करणों की सभी प्रतियां नहीं की हैं: मुझे कोड, दस्तावेज़ों आदि का अंतिम स्थिर संस्करण मिला है, अगर मुझे एक और पिछले संस्करण की आवश्यकता है, तो मैं इस संस्करण को सबवर्सन एट सिमिलिया (किसी अन्य परियोजना के रूप में संग्रहीत) द्वारा डाउनलोड करता हूं क्षेत्र: App Beta_version_XYZ यदि वित्तीय)

— alepuzio