2011-01-15 16 views
9

यहाँ हमारे बुनियादी आवश्यकताओं है का अनुकूलित संस्करण चलाएँ:एक रेल आवेदन

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

ऐसा करने के लिए है कि, मैं कई विकल्प देख सकते हैं कि लक्ष्य को प्राप्त करने:

  • Git शाखा
  • Rails::Engine
  • Rails::Application

सबसे स्पष्ट जवाब होगा पूर्ण लचीलापन के लिए गिट शाखा बनें।

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

हम यथासंभव मूल और अनुकूलित संस्करणों को रद्द करना चाहते हैं। दूसरे शब्दों में, हम मूल और अनुकूलित के बीच जितना संभव हो उतना संघर्ष करना चाहते हैं।

Rails::Engine या Rails::Application एक करीबी विचार (मैं रेल इंजन से परिचित नहीं हूँ) तरह लग रहा था, लेकिन मुझे समझ नहीं आता कि कैसे एक ही स्थान पर OurApp::Application और OurCustomizedApp::Application है और विश्व स्तर पर और गतिशील रूप से उन दोनों के बीच स्विच करने के लिए।

शायद यह है करने के लिए अच्छा होगा:

  • कस्टम initializers, नियंत्रक और एक अलग निर्देशिका में देखा गया ओवरराइड करने के लिए (या पैच) निर्दिष्ट करने के लिए मूल
  • क्षमता जो एप्लिकेशन (मूल या इच्छित एक वातावरण चर द्वारा बूट करने के लिए) RAILS_APP
  • अलग कॉन्फ़िग फ़ाइलों की तरह है, तो जैसे: config/database.ymlconfig/customer1/database.yml
  • Capistrano के लिए एक ही deploy.rb (पी उपयोग करने की क्षमता होने के लिए robably config/servers.yml और config/customer1/servers.yml साथ भूमिकाओं और आईपी परिभाषित करने के लिए?)

वहाँ प्रथाओं/सम्मेलनों हमारी आवश्यकताओं के लिए है? कोई सलाह?

हमारे ऐप्स रूबी 1.9.2 + रेल 3.0.3 पर चलते हैं।

अद्यतन

हम एक Git शाखा के रूप में यह शुरू कर दिया। हमने config/branch पर फ़ाइल बनाने के लिए एक रेक कार्य बनाया है जिसमें "मास्टर" या "कस्टमाइज्ड" जैसे टेक्स्ट शामिल हैं, और application.rb बूटस्ट्रैप पर इसे पढ़ता है।database.yml या servers.yml जैसे Configs अब config/mainline/ या config/customized/ में रहते हैं, और application.rb तदनुसार उन्हें संभालता है।

config.paths.config.database = "config/#{branch}/database.yml" 

सही नहीं है, लेकिन अभी पर्याप्त है। जब हम इसे करने का बेहतर तरीका खोजते हैं तो मैं अपडेट करूंगा।

उत्तर

1

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

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

+0

हम गिट शाखा के साथ समाप्त हो गए हैं और यह अब तक काफी अच्छा काम कर रहा है। धन्यवाद! – kenn

0

हम अक्सर ऐसा करने के लिए गिट का उपयोग करते हैं।

2

मुझे लगता है कि यह सबसे अच्छा तरीका है कि यह पुराने तरीके से किया जाए।

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

अपने ग्राहक के स्थल पर, (, एक रत्न के रूप में भेज दिया हो सकता है?) एक ही स्रोत कोड को तैनात, लेकिन यह भी है कि ओवरराइड करता है Affiliate इसलिए इसकी सिंगलटन instance विधि है कि ग्राहक-विशिष्ट जानकारी या व्यवहार की आपूर्ति के लिए एक कस्टम उपवर्ग रिटर्न एक रेल प्लगइन तैनात ।

संपादित जोड़ने के लिए: इस दृष्टिकोण के साथ जोखिम है कि डेवलपर्स inadvertantly चीजों को तोड़ने क्योंकि वे केवल डिफ़ॉल्ट सहबद्ध के खिलाफ उनके परिवर्तनों का परीक्षण। आपको इसे पकड़ने के लिए स्वचालित परीक्षण और निरंतर एकीकरण का उपयोग करना चाहिए।

+0

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

1

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

क्या आप यहां अपनी आवश्यकताओं को स्पष्ट कर सकते हैं?

मैं यहां गिट शाखाओं को एक समाधान के रूप में अनुशंसा नहीं करता। मैं इंजन का उपयोग करने की सिफारिश करेंगे। विशेष रूप से एक मणि में अपने इंजन bundling।

अपनी कस्टम प्रोजेक्ट में मणि शामिल करें और फिर इंजन में कार्यक्षमता ओवरराइड करने के पारंपरिक तरीकों का उपयोग करें। आप अपने मणि में कार्यक्षमता को ओवरराइड करने के लिए मौजूदा रूबी कोड को विस्तारित करने के पारंपरिक तरीकों का भी उपयोग कर सकते हैं।

इस तरह आप एक अलग परियोजना में रखे गए सभी मतभेदों को रखते हैं। इस अलग परियोजना में इसका परीक्षण भी होगा, आदि

+0

जबकि मुझे लगता है कि एक इंजन के लिए कई ऐप्स को चुनने के लिए सामान्य रूप से एक अच्छा विचार है, मुझे यकीन है कि इसे एक मणि के रूप में बनाए रखने के बारे में निश्चित नहीं है - मुख्यलाइन ऐप पर हमारी गतिविधि बहुत तीव्र है, और प्रत्येक प्रतिबद्धता के लिए एक मणि बनाना यथार्थवादी नहीं होगा। ऐसा लगता है जैसे वेब ऐप मणि से तैनात है, गिट रेपो से नहीं। मैं इसे दूसरी तरफ ले जाऊंगा - मेनलाइन के लिए आवेदन, और अनुकूलित/अनुकूलित करने के लिए इंजन/प्लगइन, हालांकि यह एक अच्छा फिट जैसा प्रतीत नहीं होता है। – kenn

संबंधित मुद्दे