एक उत्पादन सर्वर पर विकसित करना


35

आज मुझे एक प्रोडक्शन सर्वर पर एक एप्लिकेशन विकसित करने के लिए चिल्लाया गया। उद्धरण, " उत्पादन सर्वर पर विकसित करना स्वीकार्य नहीं है - कभी भी! "

यहाँ स्थिति है।

  1. मैंने एक विकास उदाहरण स्थापित किया है: http://example.com:3000
  2. उत्पादन उदाहरण है: http://example.com
  3. मैं अपने सभी विकास कार्यों को पूरा करता हूं http://example.com:3000और जब ग्राहक परिवर्तनों से प्रसन्न होता है, तो मैं उन्हें स्थानांतरित करता हूं http://example.com

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

फिर से, क्या मैं एक बेवकूफ हूँ? शायद ऐसा है, लेकिन मैं अभी कुछ वर्षों से वेब विकास कर रहा हूं, और मुझे इस तरह की स्थिति का सामना कभी नहीं करना पड़ा। कौन सही है और क्यों?


46
एक ही वैध प्रतिशोध होगा "उत्पादन सर्वर जिसे विकास में पुन: पेश नहीं किया जा सकता है वह स्वीकार्य नहीं है - कभी भी।"
ब्लरफ्ल

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

@GregHewgill, हाँ यह एक अच्छी बात है
luk3thomas

25
ग्रेग सही है, यदि आप एक विकास मशीन पर पर्यावरण को पुन: पेश करने के लिए आवेदन के बारे में पर्याप्त नहीं हैं, तो न केवल आपको उत्पादन मशीन पर विकसित और परीक्षण नहीं करना चाहिए, आपको उस मशीन तक पहुंच की अनुमति भी नहीं दी जानी चाहिए। आप स्पष्ट रूप से गलत थे, लेकिन आपके द्वारा पूरी तरह से समझने से पहले कि आप क्या कर रहे थे, मैं आपको पहले स्थान पर पहुँच देने के लिए आपके बॉस पर चिल्लाया होगा।
maple_shaft

3
यदि आप स्थानीय विकास वातावरण को सेटअप नहीं कर सकते हैं, तो आपको कभी भी विकास नहीं करना चाहिए।
जस

जवाबों:


58

मैं उत्पादन सर्वर पर विकसित करता था। यह ठीक काम कर सकता है, लेकिन यह कम से कम दो कारणों से अपरिहार्य है:

  1. विकास कोड अनंत लूप, मेमोरी लीक या अन्य समस्याओं का कारण बन सकता है जो सीपीयू को बंद कर देते हैं, सभी मेमोरी को खा जाते हैं, या अन्यथा सर्वर को इस तरह से प्रभावित करते हैं जो आपके उत्पादन कोड को प्रभावित करेगा।
  2. यदि आपको अपने विकास कार्य के हिस्से के रूप में सर्वर वातावरण के घटकों में परिवर्तन करने की आवश्यकता है, जैसे कि रूबी या MySQL का संस्करण या जो भी हो, आप एक बाँध में होंगे।

1
हां, यह अच्छी बात है। जितना मैं इसके बारे में सोचता हूँ आप लोग बिलकुल सही हैं।
luk3thomas

6
एक तीसरा मुद्दा है: सुरक्षा। क्या होगा यदि कोई उत्पादन सर्वर को पोर्ट करता है और आपके (विकास) एप्लिकेशन को पता चलता है - और परिणामस्वरूप उत्पादन एप्लिकेशन से समझौता करता है? फिर से, जबकि यह एक संभावना परिदृश्य नहीं है कि सर्वर या सिस्टम से समझौता होने के बाद हर कोई बहुत कुछ कहता है।
मार्को

कुख्यात अनंत लूप की समस्या ...
मानसरो

3
@Marco वास्तव में यदि सर्वर सार्वजनिक रूप से सुलभ है तो इसकी बहुत संभावना है। विकास सर्वरों में आम तौर पर बहुत खराब सुरक्षा होती है (क्योंकि सुरक्षा की बात आते ही डिबगर्स और स्टैक ट्रैस जैसी उपयुक्तताएं दायित्व हैं)। यदि कोई हमलावर देव सर्वर का उपयोग करके विशेषाधिकार बढ़ा सकता है, तो वह पूरी तरह से उत्पादन ऐप का मालिक हो सकता है।
मार्क ई। हासे

29

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

विभिन्न व्यवसायों की इस पर अलग-अलग प्रतिक्रियाएं हैं, लेकिन इसे आम तौर पर इस तरह से तोड़ा जा सकता है:

  • क्या एक स्क्रू-अप हुआ था?
  • एक परिवर्तन को वापस लेने में कितना समय लगेगा (मैं मुख्य रूप से C ++ में काम करता हूं, इसलिए एक बाइनरी को रोल करना रूबी की तुलना में काफी अधिक समय ले सकता है , खासकर जब आप पुराने बाइनरी को "खो" चुके हैं और फिर से खेलना है)
  • क्या परिवर्तन के प्रभाव (किसी न किसी गाइड: संग्रहीत डेटा पंगा लेना है तो बहुत खराब भंडारण या डेटा, जो बारी में सब पर पेज नहीं दिखा रहा से भी बदतर है दिखाई नहीं दे रहा से)
  • यदि आप खराब हो गए तो दरवाजे से बाहर चले गए, क्या किसी को पता चलेगा कि आपने क्या किया है?
  • क्या एक और तैनाती विकल्प था जो प्रभाव से पहले स्क्रू-अप को रोक / कम कर देता / पता लगा सकता था?

यह आपको अंतिम गणना देता है:

  • यह पूरी तरह से रोकने योग्य पेंच-अप ने व्यवसाय को कितना खर्च किया है?

अब यह है कि बजट निर्णय लेने वाले व्यक्ति के लिए आपकी संपूर्ण प्रबंधन संरचना कितनी कम है। इसलिए चिल्लाना

यदि आप कंपनी के आंतरिक "हमारे बारे में" पृष्ठ पर काम कर रहे हैं और अपना नाम L. "गॉड-लाइक" थॉमस टाइप करते हैं, तो यह उपनाम की समस्या को शर्मसार करता है; यदि आप व्यवसाय-महत्वपूर्ण क्रय ऐप पर काम कर रहे हैं, और यह गलती से सादे-टेक्स्ट डिबगिंग को क्रेडिट कार्ड के विवरण को मुखपृष्ठ पर समाप्त कर देता है ... मुकदमा समस्या। उन चरम सीमाओं के बीच मिसकैरेज, अपंग उत्पादकता और अन्य सभी चीजें हैं जो ग्राहकों को भगा सकती हैं।

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

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

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


यह उत्पादन वातावरण में विकसित होने के साथ नुकसान का एक अच्छा सारांश है , लेकिन सवाल उत्पादन हार्डवेयर पर एक अलग वातावरण में विकसित करने के बारे में था ।
कार्सन 63000

@ कार्सन 63000 सहमत हैं, और जैकब का जवाब निश्चित रूप से उस तरफ बेहतर है। मैंने अपना थोड़ा बदल दिया है।
डेवार्डे

13

मैंने स्थानीय स्तर पर विकास के माहौल को स्थापित करने की कोशिश की, लेकिन मैं इसे कभी नहीं चला पाया। थोड़ी देर की कोशिश के बाद, मैंने उत्पादन सर्वर पर विकसित करने का फैसला किया।

मैं उत्पादन सर्वर पर AVOID विकास के बयानों का समर्थन करता हूं । आपको केवल GUN के तहत करना उचित हो सकता है, अगर यह config फ़ाइल में एक टाइपो सुधार है और आपके प्रबंधक द्वारा जोर दिया गया है।

WHY NOT?- क्योंकि, यह बहुत जोखिम भरा और बाद में आदत बनने के लिए कहा जाता है जो आपको बुरी तरह से जकड़ लेगा। क्योंकि, घातक उत्पादन त्रुटियों / विफलताओं से आपको अपने काम से निकाल दिया जा सकता है

मुझे इसे फिर से पुन: प्रसारित करने दें, भले ही आपने productionसर्वर पर टाइपो सुधार करने का अनुरोध किया हो , पहले इसे करें Staging। या दूसरे शब्दों में, अपने परिवर्तनों का परीक्षण करें, उसका परीक्षण करें और उत्पादन में रखने से पहले फिर से उसका परीक्षण करें।

यह कुछ ऐसा है जो अक्सर उन जगहों पर होता है जहां "इसे जल्दी और गंदा करना" की संस्कृति एक आदर्श लगती है।

संपादित करें: एक अलग वातावरण के रूप में उत्पादन सर्वर पर विकसित करना भी स्वीकार्य नहीं है । आपके काम में होने वाली कोई भी समस्या बस उत्पादन सर्वर को नीचे ला सकती है, और उत्पादन एप्लिकेशन के प्रदर्शन को प्रभावित कर सकती है । उदाहरण के लिए, मुझे एक मामला याद है जब एक सुरक्षा छेद था, जब मेरे पिछले सहकर्मी ने उत्पादन सर्वर WinServer 2003 का उपयोग विकास उद्देश्यों के लिए करने की कोशिश की थी।


यह उत्पादन वातावरण में विकसित होने के साथ नुकसान का एक अच्छा सारांश है , लेकिन सवाल उत्पादन हार्डवेयर पर एक अलग वातावरण में विकसित करने के बारे में था ।
कार्सन 63000

धन्यवाद, मैंने एक संपादन जोड़ा है जो इसे करने की चिंताओं को संबोधित करता है।
ईएल यूसुबोव

10

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

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


ठीक है धन्यवाद। क्या विकास कोड एक मशीन को अस्थिर कर सकता है? मैं एक पुराने रेल ऐप पर काम कर रहा हूं। यह मुझे (भोले-भाले व्यक्ति) को लगता है कि विकास कोड http://example.com:3000प्रभावित नहीं करेगा http://example.com
luk3thomas

2
@ luk3thomas: ठीक है, यकीन है, यह नहीं होना चाहिए। क्या होगा अगर वेबसर्वर या रेल फ्रेमवर्क में कोई बग है, हालांकि, जो सर्वर को क्रैश करता है? क्या होगा अगर, जैकोब टेरी ने अपने जवाब में सुझाव दिया, आपके देव कोड में एक अनंत लूप या मेमोरी लीक, उत्पादन सर्वर पर सभी संसाधनों को बेकार कर देता है और लाइव साइट के प्रदर्शन से समझौता करता है?
कार्सन 63000

1
कभी-कभी इसकी आवश्यकता होती है। ऐसी दुकानें जो महंगे सॉफ़्टवेयर का लाइसेंस देती हैं और उनके पास सिर्फ देव कार्य के लिए दूसरी प्रति के लिए बजट नहीं है।
ब्रायन नोब्लुक

8

उत्पादन में सीधे विकसित नहीं होने का एक अन्य महत्वपूर्ण कारण यह है कि एक विकास उदाहरण आमतौर पर क्रिया त्रुटियों और स्टैक के निशान का उत्पादन और दिखाएगा। आप उपयोगकर्ता को कभी भी उजागर नहीं करना चाहते हैं।

हां, आप उन्हें क्लाइंट को दिखाने के बजाय लॉग इन कर सकते हैं, लेकिन यह डीबगिंग बनाता है जो पहले से कहीं कम मनोरंजक है।

अपने विकास की समस्या से परेशान होने की अपनी समस्या को संबोधित करते हुए जोड़ा : मुझे एक UbuntuBox सर्वर के साथ एक वर्चुअलबॉक्स- आधारित वीएम को तैनात करने में बड़ी सफलता मिली है जो हमारे उत्पादन वातावरण (विशेष रूप से हार्डवेयर) को डुप्लिकेट करता है ।


3
ध्यान दिया, सलाह के लिए धन्यवाद w / VirtualBox
luk3thomas

1
@ luk3thomas यह भी मुफ़्त है! VirtualBox + Ubuntu (शायद सबसे आम वर्चुअलाइजेशन संयोजनों में से एक) के लिए ऑनलाइन ट्यूटोरियल के टन हैं ।
एमएसनफोर्ड

8

मैं काफी हैरान हूं कि किसी ने अभी तक सबसे महत्वपूर्ण कारण का उल्लेख नहीं किया है, यह उत्पादन सर्वर पर विकसित करने के लिए बिल्कुल निषिद्ध क्यों है:

उत्पादन डेटा के साथ गड़बड़ न करें, जो ओह इतनी आसानी से हो सकता है!

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

अधिकांश अनुप्रयोगों के लिए, मान डेटा में निहित है न कि रूटीन में।


1
उत्पादन के आंकड़े खराब होने के बाद आप इसे बहुत जल्दी सीखते हैं। मुझे लगता है कि वह एक DB नहीं है।
रॉकलान

8

मैं हमेशा कोशिश करता हूं और अन्य डेवलपर्स से पूछता हूं कि विशेष कंपनी के लिए क्या प्रक्रियाएं हैं। सामान्य तौर पर, आपको हमेशा:

  1. स्थानीय स्तर पर निर्माण।
  2. इसे किसी प्रकार के बॉक्स में धकेलें, जो जितना संभव हो सके उतना अच्छा लगे, यह देखने के लिए उत्पादन की नकल करता है।
  3. परिवर्तनों की समीक्षा करने के लिए क्लाइंट / क्यूए टीम को पास करने के लिए संभवतः इसे एक क्यूए या प्रमाणन उदाहरण पर धकेल दें।
  4. उत्पादन के लिए धक्का।

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


२.३.११, मैं संभवत: कुछ ऐसा ही
करूंगा

1

ठेस पर विकसित होने के साथ एक और समस्या यह है कि, कभी-कभी, ये चीजें स्रोत नियंत्रण में छूट जाती हैं और भविष्य में रिलीज आपके त्वरित-परिवर्तन को पूर्ववत कर सकती हैं।

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


0

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

अपने कैरियर में मुझे उत्पादन सर्वर पर कोड बदलने के केवल दो कारण मिले हैं:

  1. कीड़े या व्यवहार जो केवल वहां होते हैं और विकास के वातावरण पर प्रजनन योग्य नहीं होते हैं। ये दुर्लभ हैं लेकिन खोजने के लिए बहुत कष्टप्रद और कठिन हो सकता है।

  2. यदि आप कुछ मिनटों से अधिक समय लेते हैं, तो आप सामान्य तैनाती प्रक्रिया को पारित करने के लिए प्रतीक्षा करने का जोखिम नहीं उठा सकते हैं। इसके बाद प्रबंधन के साथ सफाई दी गई है। यदि आप भाग्यशाली हैं तो आपके पास अपने पूरे करियर के लिए कुछ ही होना चाहिए।

दोनों वरिष्ठ डेवलपर्स के लिए सबसे अच्छा बचा है जो सिस्टम को आंतरिक रूप से जानते हैं।


यदि आपके पास बग हैं जो केवल उत्पादन वातावरण पर होते हैं, तो आपका विकास वातावरण उत्पादन वातावरण के काफी करीब नहीं है। आपको बहुत कम से कम सटीक ओएस सेटिंग्स के नीचे उत्पादन वातावरण, प्रसंस्करण हार्डवेयर और इंस्टॉल किए गए सॉफ़्टवेयर के समान सटीक कॉन्फ़िगरेशन के साथ एक मचान वातावरण होना चाहिए।
नजल्ल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.