2009-08-11 10 views
12

मुझे वास्तव में पता नहीं है कि वेब विकास में सही वेबसावर लाइव करने के लिए ऑफलाइन विकास से तैनाती कैसे करें। मैं ज्यादातर अंतर्ज्ञान पर सहारा लेता हूं, लेकिन यह अब तक कम या कम है जो मैंने अभी तक किया है: मेरे पास पाइथन या PHP में एक वेब एप्लिकेशन है, और मैं इसे लाइव वेबसर्वर पर होस्ट कर रहा हूं। मैं एक ऑफ़लाइन विकास संस्करण का उपयोग करता हूं जिसका स्रोत svn के अंतर्गत है।वेब एप्लिकेशन कैसे जारी करें?

अब, जैसा कि मैं ऑफ़लाइन संस्करण विकसित करता हूं, मैं svn पर काम करता हूं। समय जारी करने के लिए आ गया है जब, मैं कर सकता या तो:

  1. लाइव वेब सर्वर पर एक अस्थायी निर्देशिका के लिए ऑफ़लाइन सर्वर से कोड को कॉपी करें, फिर नया पता (। उदाहरण के लिए एक लिंक के साथ) के साथ पुराने codebase, स्वैप या ...
  2. में लाइव वेबसर्वर एक चेकआउट svn पर काम करता है, और बस svn अद्यतन चलाएं।

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

इस कार्य के लिए सर्वोत्तम अभ्यास क्या हैं?

+0

स्टीफानो, क्या आप मेरे उत्तर को एक अच्छा मानेंगे? – TheJacobTaylor

+0

@TheJacobTaylor: मैं हर कुछ हफ्तों में सत्र स्वीकार करता हूं। इस सप्ताहांत मैं सभी उत्तरों को फिर से पढ़ूंगा और स्वीकार करूंगा। –

उत्तर

10

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

मैंने चरण और उत्पादन के बीच फ़ाइलों को स्थानांतरित करने से पहले rsync का लाभ उठाया है।

मेरे ठेठ तैनाती आय इस प्रकार है:

  • बैकअप उत्पादन साइट
  • बैकअप से पुनर्स्थापित सभी बाहरी IP पते
  • निर्यात रिपोजिटरी से कोड से सर्वर मंच नीचे
  • लॉक सर्वर एक अस्थायी फ़ोल्डर में (वैकल्पिक रूप से छोटे बदलावों के लिए दो फ़ोल्डरों को अलग करें)
  • temp फ़ोल्डर से rsyc फ़ाइलों को चरण सर्वर फ़ोल्डर
  • पर
  • मान्य करें कि केवल उन फ़ाइलों को जिन्हें आप बदलना चाहते हैं, वास्तव में बदल गए हैं।
  • उन्नयन
  • डीबी
  • टेस्ट करने के लिए SQL स्क्रिप्ट लागू करें वेबसर्वर

अब अनलॉक, उत्पादन करने के लिए तैनात करने के लिए, तेजी से आगे में इन चरणों को पुनः चलाने के। स्क्रिप्ट का उपयोग करना इसे बहुत आसान बनाता है।

+0

मैं सहमत हूं, लेकिन अगर आपके पास बहुत सारी फाइलें हैं, तो एसवीएन निर्यात धीमा हो सकता है! –

+0

अधिकांश वेबसर्वर पर एक फ़िल्टर स्थापित करने के लिए यह छोटा है जो इसे एसएसएनएन फ़ोल्डर्स की सेवा नहीं करता है, इसलिए मैं इसे "svn update" का उपयोग करने के कारण नहीं लेता। जब आप पहली बार सर्वर स्थापित करते हैं तो यह ध्यान में रखना कुछ है। – rmeador

+0

अच्छी तरह से, सामान्य गति में कोई समस्या नहीं है यदि आप स्थानीय (डिस्क या नेटवर्क) svn से निर्यात कर रहे हैं। या यह है ? मेरा मतलब है, नहीं कि svn तेज है। इससे दूर। –

1

सिद्धांत रूप में मैं वेब सर्वर पर एक नए क्षेत्र में svn निर्यात करता हूं। फिर वेबसावर को नए क्षेत्र का उपयोग करने और पुनरारंभ करने के लिए पुन: कॉन्फ़िगर करें।

4

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

आप क्या सोच सकते हैं एक स्टेजिंग सर्वर है। आप अपने स्थानीय परिवर्तन करते हैं, फिर स्टेजिंग सर्वर पर svn चेकआउट और अपनी अपग्रेड स्क्रिप्ट को भी चलाएं। आप स्टेजिंग सर्वर पर अपना स्वीकृति परीक्षण करते हैं। जब सब कुछ अच्छा होता है, तो आप लाइव सर्वर पर कभी भी तैनात करते हैं। यह कुछ स्क्रिप्ट चलाने के रूप में सरल होना चाहिए। i.e. update-staging.pl और update-prod.pl।

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

+0

वास्तव में, जब भी संभव हो, मैं "रोलबैक" स्क्रिप्ट भी लिखता हूं। मुझे नहीं पता कि यह कितना उपयोगी है, क्योंकि मैं डेटा को फिर से सम्मिलित नहीं करूंगा, लेकिन कम से कम मेरे पास SQL ​​संरचना को डाउनग्रेड करने का एक तरीका होगा, बस मामले में। –

3

मैं Capistrano का उपयोग स्क्रिप्ट & पर तैनाती प्रक्रिया को स्वचालित करता हूं। मेरे स्थानीय वर्कस्टेशन से cap deploy दर्ज करते समय क्या होता है इसकी एक रूपरेखा यहां दी गई है:

कैपिस्ट्रानो। । ।

  1. चेकआउट नवीनतम मेरी वेबसर्वर पर एक समय मुहर लगी निर्देशिका (जैसे /var/http/mywebsite.com/releases/20090715014527 करने के लिए) में स्रोत के संस्करण,, मुझे उत्साह @ किसी भी पासवर्ड के लिए अपने स्थानीय कार्य केंद्र यदि आवश्यक हो तो।

  2. भागो पूर्व प्रसंस्करण लिपियों (जैसे अद्यतन डेटाबेस स्कीमा)

  3. शीतल लिंक एक जीवित निर्देशिका के लिए साइट:

    ln -sf /var/http/mywebsite.com/releases/20090715014527/var/http/mywebsite.com/वर्तमान

  4. भागो पोस्ट-प्रोसेसिंग लिपियों (जैसे हो सकता है आप फिर से शुरू करनी अपाचे या कुछ और)

यदि रास्ते में कोई समस्या थी, तो Capistrano पिछले कामकाजी रिलीज के लिए रोलबैक होगा।

हालांकि कैपिस्ट्रानो रूबी में लिखा गया है, यह किसी भी भाषा/ढांचे में वेब अनुप्रयोगों को तैनात कर सकता है। विचारों के लिए "Deploying non-rails apps" section of the tutorials देखें। railsless-deploy PHP और पायथन ऐप्स को तैनात करने के प्रबंधन के लिए कैपिस्ट्रानो का उपयोग करने के लिए विशेष रूप से उपयोगी लगता है।

1
छोटे, php आधारित प्रणाली के लिए

, हम क्या करने के लिए इस्तेमाल यह है:

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

एसक्यूएल परिवर्तनों के लिए, हम प्रत्येक परिवर्तन (आमतौर पर हमारे बग-ट्रैकर में) के लिए एक स्क्रिप्ट बनाए रखने की कोशिश करते हैं और मैन्युअल रूप से लक्ष्य प्रणाली पर प्रत्येक परिवर्तन चलाते हैं।

बड़े सिस्टम के लिए आप वास्तव में कुछ और मजबूत उपयोग करते हैं।

ध्यान दें कि यदि आपका प्रोड सिस्टम सीधे svn से खींच रहा है तो आप उन परिवर्तनों को अपमानित कर रहे हैं जिन्हें ठीक से परीक्षण नहीं किया जा सकता है (आप कुछ करने के लिए भूल सकते हैं, स्थानीय प्रणाली का परीक्षण कर सकते हैं, और सब कुछ प्रोड में टूट जाएगा ...)

+0

ज़िप के बारे में: पुरानी फाइलों को हटाने के बारे में क्या? अंतिम टिप्पणी के लिए +1। मैं थोड़ा सा रहा हूँ –

+1

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

1

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

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