आप विभिन्न स्टेजिंग वातावरण में जावा वेबपैप्स कैसे बनाए रखते हैं?

Question

आपके पास डेवलपर मशीन पर उपयोग की जाने वाली गुणों का एक सेट हो सकता है, जो डेवलपर से डेवलपर, एक स्टेजिंग वातावरण के लिए एक और सेट, और फिर भी उत्पादन वातावरण के लिए भिन्न होता है।

एक स्प्रिंग आवेदन में आप भी सेम है कि आप एक स्थानीय वातावरण में लोड करना चाहते हैं, लेकिन उत्पादन परिवेश में नहीं, और इसके विपरीत हो सकता है।

आप इसे कैसे संभालेंगे? क्या आप अलग-अलग फाइलों, चींटी/मेवेन संसाधन फ़िल्टरिंग या अन्य दृष्टिकोणों का उपयोग करते हैं?

Answer 1

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

यदि आप प्रत्येक पर्यावरण के लिए अलग-अलग ऐप फाइलें (युद्ध/कान) बना रहे हैं, तो आप उसी युद्ध/कान को तैनात नहीं कर रहे हैं जिसका आप परीक्षण कर रहे हैं।

मेरे ऐप्स में से एक में, हम कई आरईएसटी सेवाओं का उपयोग करते हैं। मैंने सिर्फ जेएनडीआई में रूट यूआरएल रखा है। फिर प्रत्येक वातावरण में, सर्वर को उस वातावरण के लिए उचित REST सेवा के साथ संवाद करने के लिए कॉन्फ़िगर किया जा सकता है।

Answer 2

मैं फ़िल्टर फ़ाइल के साथ चींटी की प्रति का उपयोग करता हूं। चर के साथ कॉन्फ़िगरेशन फ़ाइल के साथ निर्देशिका में मेरे पास प्रत्येक वातावरण के लिए एक फ़ाइल है। बिल्ड स्क्रिप्ट env पता है और सही चर फ़ाइल का उपयोग करता है।

Answer 3

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

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

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

आशा यह कुछ समझ में आता है ...

Answer 4

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

उत्पादन वातावरण में अत्यधिक स्केलेबल सिस्टम के लिए मैं गंभीरता से हैं एक योजना है जिसमें विन्यास फाइल टेम्पलेट्स में रखा जाता है की सलाह देते हैं, और निर्माण स्क्रिप्ट के हिस्से के रूप इन टेम्पलेट्स प्रस्तुत करना "अंतिम" विन्यास फाइल (सभी वातावरण चाहिए उपयोग किया जाता है एक ही प्रक्रिया का उपयोग करें)।

Answer 5

मैं लक्ष्य तैनाती के लिए विन्यास धारण विभिन्न विन्यास फ़ोल्डरों है, और मुझे चींटी का उपयोग एक फ़ाइल प्रतिलिपि चरण के दौरान उपयोग करने के लिए चयन करने के लिए।

Answer 6

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

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

हम भी अलग अलग साइटों के रूप में अच्छी तरह से निर्माण एक ही स्रोत परियोजना से (सामग्री, सुरक्षा भूमिकाओं, आदि differeing) के लिए चींटी रणनीति का उपयोग करें।

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

Answer 7

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

Answer 8

एक समाधान जिसे मैंने देखा है, स्टेजिंग पर्यावरण को कॉन्फ़िगर करना है ताकि यह उत्पादन वातावरण के समान हो। इसका मतलब है कि प्रत्येक वातावरण में एक ही आईपी रेंज के साथ एक वीएलएएन होता है, और उसी आईपी पते पर मशीन भूमिकाएं होती हैं (उदा। डीबी क्लस्टर आईपी हमेशा प्रत्येक वातावरण में 1 9 2.168.1.101 होती है)। फ़ायरवॉल ने वेब सर्वर पर बाहरी चेहरे वाले पते मैप किए, इसलिए आपके पीसी पर मेजबान फाइलों को स्वैप करके एक ही यूआरएल का इस्तेमाल किया जा सकता था - http://www.myapp.com/webapp/file.jsp या तो स्टेजिंग या प्रोडक्शन पर जायेगा, इस पर निर्भर करता है कि आपने कौन सी मेजबान फाइल को बदल दिया था।

I मुझे यकीन नहीं है कि यह एक आदर्श समाधान है, यह बनाए रखने के लिए काफी मुश्किल है, लेकिन यह ध्यान रखना दिलचस्प है।

Answer 9

कालेब पी और जीबी शायद आपके सबसे तेज़ समाधान हैं। इसके अलावा आपको विभिन्न मशीनों पर विभिन्न सेवाओं को सेट करने या फ़ाइलों को इंगित करने की आवश्यकता नहीं है। आप या तो $ {user.name} चर का उपयोग करके या एंटी या मेवेन के लिए -D तर्क में प्रोफ़ाइल निर्दिष्ट करके अपने पर्यावरण को निर्दिष्ट कर सकते हैं।

इसके अतिरिक्त इस सेटअप में, आपके पास सामान्य गुण फ़ाइल हो सकती है, और विशिष्ट वातावरण के लिए गुण फ़ाइलों को ओवरराइड कर सकते हैं। चींटी और मेवेन दोनों इन क्षमताओं का समर्थन करते हैं।

Answer 10

मैं अपने प्रोजेक्ट में स्रोत/मुख्य/संसाधनों के तहत संसाधनों को फ़िल्टर करने के लिए मेवेन का उपयोग करता हूं। मैं अपनी स्प्रिंग-आधारित परियोजनाओं में अनुकूलित विशेषताओं को खींचने के लिए संपत्ति फ़ाइलों के साथ संयोजन में इसका उपयोग करता हूं।

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

Answer 11

PropertyPlaceholderConfigurer जांच करने के लिए मत भूलना - इस वातावरण में विशेष रूप से उपयोगी है, जहां JNDI उपलब्ध

Answer 12

मैं हाल ही में भी लाइव या निर्धारण वातावरण के लिए वैकल्पिक विन्यास के लिए Maven का उपयोग नहीं किया है। Production configuration using Maven Profiles।आशा करता हूँ की ये काम करेगा।

Answer 13

विभिन्न गुण फ़ाइलों का उपयोग करें और चींटियों को प्रतिस्थापित करने वाले एंटी का उपयोग करें जो पर्यावरण के आधार पर प्रतिस्थापन करेगा जिसके लिए निर्माण किया जाता है। http://www.devrecipes.com/2009/08/14/environment-specific-configuration-for-java-applications/