अत्यधिक चिंता का अनुभव किए बिना मैं उत्पादन तैनाती को कैसे स्वचालित कर सकता हूं?


32

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

यह सब सुचारू रूप से काम करता है लेकिन हार्डवेयर और संसाधन की वजह से हमारा एकीकरण पर्यावरण हमारे उत्पादन वातावरण की तरह 2 सर्वर लोड संतुलित वातावरण नहीं है। जबकि बाकी सब समान है जो हमारे एकीकरण और उत्पादन वातावरण के बीच एकमात्र अंतर होगा (हालांकि एक बड़ा!)

सैद्धांतिक रूप से अंतर हमारे ऐप सर्वरों का थोड़ा अलग विन्यास है और तैनाती लिपि में केवल एक के बजाय बिल्ड कलाकृतियों को दो सर्वरों में छोड़ना होगा, लेकिन मैं अपने उत्पादन की तैनाती को स्वचालित करने के लिए इतना परेशान क्यों हूं?

मैं आम तौर पर एक नियंत्रण सनकी नहीं हूं, लेकिन मैं हमेशा उत्पादन को उत्पादन के लिए मैन्युअल रूप से तैनात करने की अतृप्त आवश्यकता महसूस करता हूं। मैंने सहकर्मियों से सुना है कि यह आम तौर पर एक सच में बात है ™ लेकिन वे इसके खिलाफ एक मामला बनाने में विफल रहे।

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

स्वचालित स्क्रिप्टेड उत्पादन परिनियोजन के लिए इस या तर्क के खिलाफ तर्क क्या हैं?


'rs' के बाद 'ls' ने एक बार मुझे एक विपत्तिपूर्ण rm को पकड़ने की अनुमति दी थी, जो फ़ाइल सिस्टम में उच्च स्थानों तक कठिन लिंक के माध्यम से नीचे आ रहा था। पहले से हटाई गई फ़ाइलों को पुनर्प्राप्त करने के लिए उपयोग करने के लिए बची हुई व्यवस्था का उपयोग करने के लिए बचा हुआ था, जबकि इसे पकड़ने में सक्षम था (लाखों फ़ाइलों को हटाने से लगता है कि सौभाग्य से! :-)
ब्रायन नोब्लुच

जवाबों:


30

इसके खिलाफ कुछ स्पष्ट तर्क हैं।

  1. छोड़ने पर क्या होता है क्या यह सब जानकारी सावधानी से प्रलेखित है, या यह ज्यादातर आपके सिर में है। स्वचालित स्क्रिप्ट किसी और से लेने के लिए एक बेहतर जगह है।

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

  3. पहर। जैसे-जैसे तैनाती बढ़ती जाती है वैसे-वैसे राशि बढ़ती जाती है। लिपियों को बस बंद करने की आवश्यकता होती है, एक मैनुअल जांच, और फिर एक मैनुअल स्विच-ओवर (आप इसे भी स्वचालित कर सकते हैं, लेकिन मैं कुछ व्यामोह साझा करता हूं :)।


21

आप सर्वश्रेष्ठ दुनिया का सर्वश्रेष्ठ प्राप्त कर सकते हैं: प्रक्रिया सत्यापन और स्वचालन की विश्वसनीयता के साथ मन की शांति।

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


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

@ जेफ़ो मुझे वह विचार पसंद है! हम सिर्फ एक अच्छा स्विंग GUI निर्माण उपकरण में निवेश किया है मैं इसे इस्तेमाल करने के लिए हर बहाने के लिए बिट पर chomp। मैं GUI टूल्स को पहले से अधिक तेज़ कर रहा हूं, और एक विज़ुअल विजार्ड कुछ इतना अच्छा होगा कि एक जूनियर डेवलपर इसे संभाल सके।
maple_shaft

@maple_shaft और आपको उस चरण को जानने के लिए मन का टुकड़ा मिलता है जहां वे सही फ़ाइलों की प्रतिलिपि बनाते हैं जो सही समय पर किया गया था।
जेएफओ

मैं इससे सहमत हु। आपके लिए अपनी तैनाती करने के लिए एक बैच फ़ाइल (या श्रृंखला) के रूप में सरल कुछ भी तनाव को बहुत कम कर सकता है। बैच फ़ाइलों का उपयोग यह सुनिश्चित करने के लिए करें कि आप कोई गलती नहीं करते हैं, और यह सुनिश्चित करने के लिए मैन्युअल रूप से चलाएं कि बैच फाइलें चलाते समय कोई भयावह त्रुटियां नहीं हैं।
किबी

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

15

मुझे लगता है कि कुंजी यहां है: आपको क्यों लगता है कि आप सत्यापन प्रक्रिया को स्क्रिप्ट नहीं कर सकते हैं?

मेरी परिनियोजित स्क्रिप्ट केवल अभिलेखागार और सेवाओं को पुनरारंभ नहीं करती हैं। वे तैनाती के प्रत्येक चरण के दौरान बहुत सारे रंग-कोडित जानकारी का प्रिंट आउट लेते हैं, और मुझे अंत में घटनाओं का सारांश प्रदान करते हैं। यह मुझे बताता है कि प्रक्रियाएँ ऊपर और चल रही हैं, कि मुखपृष्ठ 200 स्थिति कोड की सेवा कर रहा है, और सभी मशीनों और सेवाओं को एक और जुर्माना मिल सकता है। फिर मेरे पास एक अलग सेवा है जो स्क्रिप्ट का हिस्सा नहीं है जो लॉग फ़ाइलों, 4xx और 5xx-स्तरीय त्रुटियों और प्रमुख साइट मैट्रिक्स पर नज़र रखता है। यह तब हर संभव माध्यम (ईमेल, txt संदेश, और अलार्म) के माध्यम से मुझ पर चिल्लाने के लिए आगे बढ़ता है अगर कठोर नकारात्मक प्रभाव वाले स्पाइक्स होते हैं।

परीक्षण चलाने वाले सीआई और सीआई सर्वरों के बीच, मैं सचमुच स्वचालन के इस स्तर पर तैनात और भूल जाता हूं। मैं इस प्रक्रिया के बाद एक पृष्ठ पर एक पृष्ठ भी ब्राउज़ नहीं करता क्योंकि यह प्रक्रिया अब कितनी विश्वसनीय है, जो न केवल मुझे जितनी बार चाहे उतनी तैनाती करने देती है, लेकिन परियोजना के एक नए डेवलपर को लाइव के लिए एक अद्यतन करने देती है। बोर्ड पर आने के कुछ ही मिनटों के भीतर साइट। अतीत में मैं भी एक सर्वर / ट्रंक शाखा है कि सब कुछ गुजरता है के लिए प्रतिबद्ध करने के बाद CI सर्वर ऑटो उत्पादन के लिए तैनात किया है। मैं अपने उपकरणों में कितना आश्वस्त हूं।

आपको भी होना चाहिए।


1
काश, मैं इस स्तर का विश्वास रख सकता था, लेकिन यह उन उपकरणों में विश्वास नहीं है जो इसे रोकता है, यह उस अनुप्रयोग की गुणवत्ता में विश्वास है जो मुझे विरासत में मिला है और तैनात होने के बाद इसकी "प्रिमेडोना" प्रकृति है। निश्चित रूप से आप जो भी वर्णन करते हैं वह मेरा गीला सपना है और अंतिम गेम है जिसकी मुझे तलाश है।
मेपल_शफ्ट

@maple_shaft हाँ, अगर यह अपर्याप्त परीक्षण कवरेज के साथ एक विरासत अनुप्रयोग है, तो मैं निश्चित रूप से मैन्युअल हस्तक्षेप लेने के लिए इच्छुक देख सकता हूं, खासकर अगर यह फ़िक्सी होने के लिए जाना जाता है।
Pewpewarrows

1
स्क्रिप्ट तैयार करने का एक अच्छा तरीका यह है कि आप किसी फाइल, इनपुट और आउटपुट में से किसी एक परिनियोजन को रिकॉर्ड करें, फिर इसे संशोधित करके उन तथ्यों के लिए आउटपुट को शामिल करें जिन्हें आप सामान्य रूप से अपनी आंखों से जांचते हैं।
एसएफ।

8

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

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

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

  • आपके पास एक अच्छा लॉग नहीं है, शेल इतिहास गिनती नहीं है
  • और कोई नहीं जानता कि यह कैसे करना है
  • कदम चूक जाते हैं
  • चेक कभी-कभी ही होते हैं
  • तैनात करने के लिए कुछ आइटम छूट सकते हैं, मैंने पहले भी ऐसा किया है
  • इसमें काफी समय लगता है
  • आप प्रक्रिया के दौरान बाधित हो सकते हैं

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


7

मैं समझ सकता हूँ कि थोड़ा नर्वस होने की कोशिश कर रहा हूँ ठेस वातावरण पर कुछ नया। संभावित आपदा से सावधान होने के नाते एक अच्छी बात है टीएम

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

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

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


1
मुझे लगता है कि आपका उत्तर सर्वश्रेष्ठ में से एक है, क्योंकि यह वास्तव में चिंता को स्वीकार करता है, जबकि अन्य उत्तर ऑफ-टॉपिक हैं, स्वचालित तैनाती की वकालत करते हैं- जिसका लाभ ओपी को अवगत है। इस प्रकार आपका जवाब इनाम का हकदार है!
user40989

4

यहाँ उत्पादन के लिए मैनुअल deploys के खिलाफ सबसे बड़ा तर्क है: आप एक मानव हैं और गलतियाँ करेंगे। निस्संदेह ऐसा समय होगा जब आप कुछ ऐसा करना भूल जाएंगे जिससे आपको दुःख होगा। एक अच्छी तरह से लिखित स्वचालित तैनाती में वही प्रवृत्ति नहीं होती है। यह सच है कि आप अभी भी गड़बड़ कर सकते हैं उत्पादन deploys, लेकिन ऐसा इसलिए है क्योंकि आपकी स्वचालित तैनाती में बग हैं जिन्हें हल करने की आवश्यकता है।

मेरे अनुभव में उत्पादन के लिए स्वचालित deploys के लाभ जबरदस्त हैं। सबसे बड़ी बात यह है कि आपको मैनुअल तैनाती प्रक्रिया के माध्यम से मार्च करने की बजाय सप्ताहांत पर मौज-मस्ती करने का मौका मिलता है जो सहयोग नहीं करेगा।

कहा कि, यहाँ कुछ महत्वपूर्ण बिंदु हैं जो आपके उत्पादन की तैनाती को स्वचालित करते हैं:

  • यह सब एक बार में मत करो! धीरे-धीरे अपनी स्वचालित तैनाती लिखना शुरू करें। पहले एक अलग गैर-उत्पादन वातावरण सेट करें, और वहां तैनाती को स्वचालित करने का प्रयास करें। एक बार जब आप अपनी स्वचालित तैनाती में विश्वास पैदा कर लेते हैं, तो आप उत्पादन करने के बारे में सोचना शुरू कर सकते हैं
  • बहुत बार रिलीज और तैनात करना शुरू करें! जब आप 4 महीने का कोड जारी होने की प्रतीक्षा नहीं करते हैं तो स्वचालित तैनाती करना बहुत आसान है। छोटी सुविधाओं को जारी करें और प्रति सप्ताह कई बार बग ठीक करता है। इस रिलीज़ शैली के लाभों को नहीं समझा जा सकता है!
  • स्वचालित परीक्षणों पर भरोसा करें ताकि आपको विश्वास हो सके कि आपका उत्पादन वातावरण काम करेगा। फिर, इसे बनाने में समय लगता है, लेकिन बहुत महत्वपूर्ण है। स्वचालित परीक्षण हमेशा मैन्युअल स्वीकृति परीक्षणों से बेहतर होते हैं। निश्चित रूप से, मैनुअल स्वीकृति परीक्षण ठीक हैं, लेकिन स्वचालित परीक्षण आपको यह जानने में मदद कर सकते हैं कि आपको उत्पादन में तैनात करना चाहिए या नहीं। वे मुख्य हैं जो स्वचालित, निरंतर वितरण की इस पूरी प्रक्रिया को सक्षम करते हैं। यदि आपके परीक्षण पास नहीं होते हैं, तो आप उत्पादन में तैनात नहीं होना जानते हैं।

3

लाइव सर्वर पर स्क्रिप्ट चलाएँ। यह काम करेगा, और जब आपने इसे ठीक से काम करते देखा है, तो आप इसमें पूरी तरह से विश्वास करेंगे।

गंभीरता से, हालांकि, आप परिनियोजन स्क्रिप्ट की तुलना में गलतियाँ करने की अधिक संभावना है।


3

कंप्यूटर गलतियाँ नहीं करते, लोग करते हैं।

अपनी स्क्रिप्ट को एक बार लिखें और अच्छी तरह से जांच लें, लाइन से लाइन के माध्यम से जाएं। तब से आप यह सुनिश्चित कर सकते हैं कि हर बार जब आप तैनाती करेंगे, तो यह काम करेगा।

इसे हाथ से करें और आप गलतियाँ करने के लिए बाध्य हैं। हो सकता है कि आपने लिखा हो, सब कुछ आपको करना है, नीचे, लेकिन यह ओह इतना आसान है कि एक गलती करना आसान है। आपको web.config फ़ाइल को छोड़कर सभी फ़ाइलों को कॉपी करना होगा? आप शर्त लगा सकते हैं कि किसी दिन आप इसे अधिलेखित कर देंगे। एक स्क्रिप्ट कभी यह गलती नहीं करेगी।


3

अत्यधिक चिंता का अनुभव किए बिना मैं उत्पादन तैनाती को कैसे स्वचालित कर सकता हूं?

उत्पादन संबंधी नियुक्तियों को स्वचालित करते समय आपको सबसे अधिक चिंता का अनुभव होगा, दो मान्यताओं के आधार पर, संभवतः सबसे अधिक:

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

  2. उत्पादन में एक अनदेखी विफलता के नाटकीय परिणाम हैं।

असफलता से बचने के अलावा, लगभग 2. कोई भी कर सकता है, इसलिए हम 1 पर ध्यान दें।

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

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


2

मुझे क्या पसंद है आप मंचन या क्यूए पर तैनाती का परीक्षण कर सकते हैं और यह जान सकते हैं कि जब आप इसे ठेस पर चलाते हैं तो ठीक उसी चरण में होगा।

जब आप इसे मैन्युअल रूप से करते हैं तो एक स्टेप को भूल जाना या उन्हें आउट ऑफ ऑर्डर करना आसान होता है।


समस्या यह है कि ठेस और मंचन और क्यूए समान नहीं दिख रहे हैं। इसलिए स्क्रिप्ट प्रत्येक पर्यावरण पर अलग-अलग काम करेगी। इसलिए स्क्रिप्ट का उत्पादन पर पहली बार परीक्षण किया जाएगा।
पियोट्र पर्क

फिर एक वातावरण सेट करें जिसे आप स्वचालित स्क्रिप्ट को चलाने से ठीक पहले उत्पादन से ताज़ा करते हैं। इसे और कुछ नहीं के लिए उपयोग करें।
एचएलजीईएम

मुझे समझ नहीं आ रहा है। अगर वह ऐसा वातावरण स्थापित कर सकता है जो PROD की तरह दिखता है तो उसे कोई समस्या नहीं होगी।
पियोट्र पर्क

1

... हार्डवेयर और संसाधन के कारण हमारे एकीकरण का वातावरण हमारे उत्पादन वातावरण की तरह 2 सर्वर लोड संतुलित वातावरण नहीं है। जबकि बाकी सब समान है जो हमारे एकीकरण और उत्पादन वातावरण के बीच एकमात्र अंतर होगा (हालांकि एक बड़ा!)

ऊपर दिए गए, मैं शायद आप के रूप में चिंतित हो जाएगा।

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


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

  • एक परियोजना में मैं उन्हें देव टीम प्रतिनिधि के रूप में तैनाती में सहायता कर रहा था। तैनाती से पहले, वे मेरे निर्देशों की समीक्षा कर रहे थे और तैनाती के दौरान मैं सिर्फ सलाह के लिए ऑनलाइन तैयार बैठा था अगर चीजें गलत हो जाती हैं। इसके बाद, मैंने उस अलगाव की सराहना करना सीख लिया ।
     
    ऐसा नहीं है कि वे तेज़ थे (वे क्यों करेंगे? मैंने 5x-10x परीक्षण तैनाती उनसे अधिक बार की)। बड़ा अंतर फोकस में था। मेरा मतलब है, मेरा सिर हमेशा "मुख्य" सामान से भरा हुआ है - कोडिंग, डिबगिंग, नई विशेषताएं - तैनाती पर ठीक से ध्यान केंद्रित करने के लिए बस बहुत अधिक ध्यान भंग होता है। उस के विपरीत, उनका मुख्य सामान सिर्फ उत्पादन रखरखाव था और वे उस पर केंद्रित थे।
     
    यह आश्चर्यजनक है कि केंद्रित होने पर मस्तिष्क कितना बेहतर काम करता है। ये लोग, वे सिर्फ इतना अधिक चौकस थे, उन्होंने मुझसे बहुत कम गलतियाँ कीं। वे सिर्फ इतना जानते थे कि सामान मुझसे बेहतर है। उन्होंने मुझे एक या दो चीजें सिखाईं, जिससे मेरी खुद की परीक्षा में आसानी हुई।

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

सत्यापन स्क्रिप्ट मैं देख रहा हूँ। अपनी स्थिति को देखते हुए, यह समर्पित बिल्ड टीम के बाद अगली सबसे अच्छी बात है। मुझे आश्चर्य है कि दो-सर्वर सेटअप पर परीक्षण करने के लिए आपके पास वास्तव में कोई विकल्प नहीं है? यहां तक ​​कि अगर आप लोड बैलेंसर को छोड़ते हैं, तो केवल धूम्रपान-परीक्षण करने के लिए कि दोनों मास्टर / दास यूआरएल जवाब देते हैं?
gnat

1

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


1
  1. सरल। आपकी परिवर्तन प्रक्रिया rsync फ़ाइलें होनी चाहिए, SQL स्क्रिप्ट चलाएं, इससे अधिक कुछ नहीं।
  2. स्वचालित।
  3. परीक्षा।

स्वचालित करने का कारण कुछ ऐसा प्राप्त करना है जो परीक्षण-योग्य, दोहराए जाने योग्य है, और यह कि आप हर अपेक्षित स्थिति में सही ढंग से काम करने के लिए भरोसा कर सकते हैं।

किसी भी संदर्भ में किसी भी परिवर्तन के लिए आपको अभी भी एक बैक आउट योजना की आवश्यकता है, और इसे स्वचालित भी होना चाहिए।

आप अभी भी इस प्रक्रिया का पालन करना चाहते हैं क्योंकि ऐसा होता है यदि पर्यावरण वास्तव में संवेदनशील है, लेकिन इसे मैन्युअल रूप से कभी नहीं करें क्योंकि यह केवल पुन: पेश नहीं किया जा सकता है।


0

उत्पादन वातावरण में तैनात करने के लिए स्वचालन स्क्रिप्ट का उपयोग करना पूरी तरह से संभव है। हालाँकि ऐसा करने के लिए मज़बूती से आपको कई काम करने में सक्षम होना चाहिए।

  1. विश्वसनीय रूप से पिछले संस्करण में वापस रोल करें।
  2. सकारात्मक पुष्टि प्राप्त करें कि तैनाती सफलतापूर्वक लागू की गई है, और मान्य ट्रैफ़िक पर प्रतिक्रिया दे रहा है।
  3. विकास और क्यूए के लिए तुलनीय वातावरण है जो समान लिपियों का भी उपयोग करते हैं।

लिपियों के कुछ फायदे हैं, जैसे कि वे कभी भी याद नहीं करेंगे क्योंकि इसकी 2am और इसकी थकावट है।

हालाँकि, स्क्रिप्ट अभी भी विफल हो सकती हैं। कभी-कभी असफलता स्क्रिप्ट के डिजाइन में होती है, लेकिन यह नेटवर्क या बिजली की विफलता, भ्रष्ट फ़ाइल सिस्टम, ध्यान आकर्षित होने के कारण भी हो सकती है .....

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


-2
  1. अगर चीजें गलत हो जाती हैं तो पहली बार तैनाती के लिए एक बड़ी खिड़की लें
  2. परिनियोजन प्रक्रिया को दो भागों में विभाजित करें। ए। बैकअप (मैनुअल) - यह आपको आत्मविश्वास देना चाहिए अगर तैनाती के दौरान कुछ भी गलत होता है

    ख। तैनाती (स्वचालित)

एक बार जब आप पहली बार आत्मविश्वास के साथ तैनात करने में सक्षम होते हैं। आप बैकअप प्रक्रिया को भी स्वचालित कर सकते हैं।


यह पूछे गए सवाल का जवाब नहीं देता है: "स्वचालित स्क्रिप्टेड उत्पादन परिनियोजन के लिए इस या तर्क के खिलाफ तर्क क्या हैं?"
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.