प्रबंधक एक संयुक्त विकास और उत्पादन वातावरण चाहता है


19

मैं एक छोटे प्रोग्रामिंग टीम में काम करता हूं जो एक बड़े संगठन का समर्थन करता है। इस वर्ष हमारे प्रबंधक ने निर्णय लिया है कि हम अपनी कंपनी के अधिकांश डेटा को संभालने के लिए ओरेकल एपेक्स तकनीकों का उपयोग करने जा रहे हैं।

यह ठीक होगा, सिवाय इसके कि हमारे पास केवल एक एपेक्स सर्वर हो। हमारे प्रबंधक ने फैसला किया है कि सब कुछ उसी उदाहरण में होता है। हमारी टीम ऐप्स विकसित कर रही है, जबकि हमारे प्रबंधक ने उन्हें डेमो किया है, और हमारे आंतरिक ग्राहक उनका उपयोग करते हैं, जो स्पष्ट कारणों से पहले से ही समस्या पैदा कर रहे हैं!

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

प्रश्न: हमें अलग-अलग विकास, परीक्षण और उत्पादन वातावरण क्यों होना चाहिए?


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

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

1
उत्तर मैं वास्तव में यहाँ देखना चाहूंगा कि उत्पादन के विकास से पहले, उत्पादन में विकास के मंचन के विकास में कांग्रेस के समर्थक और चोर की व्याख्या होगी। उद्घोषणा का मुकाबला नहीं करना एक निश्चित तरीके से करना।
कैंडिड_ऑरेंज सेप

9
ओह चिंता मत करो, बस काफी लंबे समय तक प्रतीक्षा करें और आपको पता चल जाएगा कि पहले हाथ क्यों।
कार्ल

1
@ यहाँ मेरा अनुमान है कि प्रबंधक पैसे बचाने के लिए ऐसा करना चाहता है। आपको संभवत: लागत के संदर्भ में अपना उत्तर देना चाहिए। यदि आप कर सकते हैं, तो आपको और आपके सहयोगियों को बड़े संगठन से यह भी अवगत कराना चाहिए कि यह एक बहुत ही जोखिम भरा प्रस्ताव है। इस तरह, यदि आप इस प्रबंधक को मना नहीं सकते हैं, तो आने वाले अपरिहार्य मुद्दों को आप पर नहीं रखा जाएगा।
जिमीजम्स

जवाबों:


19

हमें अलग-अलग विकास, परीक्षण और उत्पादन वातावरण क्यों होना चाहिए?

आपके पास कई गतिविधियाँ समवर्ती रूप से चल रही हैं:

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

क्या आप चाहते हैं कि ये सब एक ही माहौल में हो? क्या आप चाहते हैं कि व्यवसाय ठप्प हो जाए क्योंकि एक नए परीक्षण ने आपके सर्वर को हार्ड-ड्राइव पर स्वैप करने में धकेल दिया है और प्रोसेसर पर हर कोर का उपभोग कर रहे हैं? क्या आप चाहते हैं कि आपके परीक्षण रुक जाएं क्योंकि एक डेवलपर ने स्केलिंग प्रयोग से एक जटिल फोर्क-बम बनाया? क्या आपको ऐसा कोड चाहिए जो आपने सोचा था कि उत्पादन में चलाने के लिए परीक्षणों में एक डेवलपर की सुतली और डक्ट-टेप के कारण काम किया है? क्या आप चाहते हैं कि डेवलपर्स संभावित संवेदनशील उत्पादन डेटा के साथ काम कर रहे हैं (मुझे पता है कि यह सभी व्यवसायों में चिंता का विषय नहीं है, लेकिन यह उनमें से एक में है)

क्या इन मुद्दों को होने से रोकता है?

अलग वातावरण।

तो आपको किस चीज़ की जरूरत है?

आपको अलग वातावरण चाहिए।

इसे औपचारिक रूप से लगाने के लिए

आपको निम्नलिखित कारणों से अलग वातावरण की आवश्यकता है:

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

आपके संदर्भ के लिए, एक नया प्रौद्योगिकी मंच

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


एक और कारण जोड़ने के लिए: जोखिम को कम करने के लिए जो एक डेवलपर द्वारा विफल प्रयोग वसूली से परे महत्वपूर्ण व्यावसायिक जानकारी को नष्ट कर देता है।
बार्ट वैन इनगेन शेनौ सेप

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

7

मैंने सुना है कि सबसे अच्छा अभ्यास अलग विकास, परीक्षण और उत्पादन वातावरण है, लेकिन यह मामला क्यों है?

यह स्पष्ट नहीं है कि इन दिनों में कटौती।

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

हमें अलग-अलग विकास, परीक्षण और उत्पादन वातावरण क्यों होना चाहिए?

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

अनिवार्य रूप से, यदि वातावरण होने की लागत पर्यावरण नहीं होने की लागत से कम है


2
+1। यह मूल रूप से एक nonanswer है, लेकिन एक nonanswer है इस मामले में जवाब।
एंडरलैंड 15

1
यदि मेरे पास डेवलपर्स की एक टीम होती है, जिसमें से प्रत्येक को पता था कि मेरे पास सोने का दिल है और अविश्वसनीय रूप से स्मार्ट और कर्तव्यनिष्ठ है, तब भी मैं उन्हें उत्पादन के माहौल में विकसित करने के लिए भरोसा नहीं करूंगा जब तक कि दांव बहुत कम नहीं थे (किस मामले में वास्तव में उत्पादन नहीं है?)
हारून हॉल

2
@AaronHall - नहीं, आप मान लेते हैं कि वे मुख्य कार्यक्षमता को सत्यापित करने के लिए यूनिट परीक्षणों के साथ पहले स्थानीय स्तर पर विकसित होते हैं। फिर कई कंपनियों में, आपकी तैनाती उत्पादन के कुछ सबसेट पर जा कर इसे स्मोक टेस्ट करेगी - आमतौर पर ए / बी टेस्टिंग, सर्किट ब्रेकर या कुछ तरीके के फीचर फ्लैग के साथ जो इसे वापस रोल करना आसान बनाता है। सही डेप्स सपोर्ट के साथ कई उद्योगों के लिए दांव उत्पादन में कम हो सकता है।
तेलस्टिन

3

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

यह उन सामान्य सेवाओं तक फैली हुई है, जिनका उपयोग आपको अपने दिन-प्रतिदिन के काम में करना चाहिए जैसे कि आपके संस्करण पर नियंत्रण। यदि आप जिस कोड को नियंत्रित कर रहे हैं वह लाइव वातावरण में है, तो आप संभवतः संस्करण नियंत्रण का ठीक से उपयोग नहीं कर सकते हैं! आपके उपयोगकर्ता पागल हो जा रहे हैं - क्या होगा अगर आपको वापस या रोलबैक करने की आवश्यकता है? क्या होगा यदि आप एक पंद्रह गलती गहरी करते हैं? आप शाखाओं को कैसे संभालेंगे?

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

यह सब अंततः आपके सामने वाले एप्लिकेशन (और इस प्रकार आपके उपयोगकर्ताओं के साथ आपकी प्रतिष्ठा) के लिए ही नहीं, बल्कि आपकी टीम की कार्यकुशलता के प्रति भी विनम्रता से काम लेता है।


2

केवल एक ओरेकल उदाहरण उपलब्ध होने का अर्थ "देव, परीक्षण और उत्पादन वातावरण के बीच कोई अलगाव" के रूप में ही नहीं है!

आपने एक टिप्पणी में लिखा था

वर्तमान में हम विभिन्न परियोजनाओं के लिए विभिन्न स्कीमाओं का उपयोग करते हैं

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

इसलिए, आपको जो वास्तविक प्रश्न पूछना है, वह है:

क्या हमें विकास, परीक्षण और उत्पादन वातावरण को अलग करने के लिए विभिन्न उदाहरणों और / या सर्वरों का उपयोग करने की आवश्यकता है, या स्कीमा पृथक्करण पर्याप्त है?

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

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

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


1
यह सबसे अधिक संभावना है कि ओपी अपनी बात को लागू करने के लिए अलग स्कीमा का उल्लेख करने के लिए उपेक्षित है। यह सबसे अच्छा जवाब imho
winkbrace

1

आपको प्रत्येक वातावरण में कई प्रकार के और शायद कई सर्वरों की आवश्यकता होती है।

डेवलपर विकास में कोड अपडेट कर सकते हैं। कोड भी काम नहीं कर सकता है - शायद आवेदन भी शुरू नहीं होगा।

यह क्यूए को प्रभावित नहीं करता है जो अपने वातावरण में नवीनतम स्थिर निर्माण का परीक्षण कर रहे हैं।

जैसा कि विकास और क्यूए दोनों अपने वातावरण को अपडेट कर रहे हैं, उत्पादन छह महीने पहले से जारी नवीनतम निर्माण पर है और अन्य वातावरणों में परिवर्तन से प्रभावित नहीं है।

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

यदि आपके पास कई रिलीज़ हैं तो क्या होगा? हो सकता है कि आप संस्करण 2.0 विकसित कर रहे हों, लेकिन 1.0 रखरखाव शाखा पर अभी भी बग फिक्स रिलीज की आवश्यकता है। अब आपको एक से अधिक विकास और क्यूए वातावरण की आवश्यकता है ताकि आप यह सुनिश्चित कर सकें कि एक महत्वपूर्ण बग की खोज होने पर आप हमेशा या तो शाखा का विकास कर सकते हैं और परीक्षण कर सकते हैं।


0

आप पहले से ही समस्याओं कि ध्यान दिया नहीं होने अलग वातावरण का कारण बनता है। वहीं, आपको अलग-अलग वातावरण के लिए मूल कारण मिला है: एक ही वातावरण में विकास, परीक्षण और उत्पादन कार्यों को करने की कोशिश करते समय अनिवार्य रूप से उत्पन्न होने वाली उलझनों के कारण होने वाली समस्याओं को समाप्त करना। एक ही तर्क डेवलपर्स को काम करने के लिए व्यक्तिगत सैंडबॉक्स देने पर लागू होता है, यह एक डेवलपर की गलतियों या यहां तक ​​कि पूरी विकास टीम को अपंग करने से सिर्फ असंगत परिवर्तन रखता है।

एकल वातावरण से दूर होने के लिए प्रबंधन करने के लिए आप कर सकते हैं यह भी सबसे अच्छा तर्क है: समस्याओं के लिए एक एकल वातावरण पहले से ही पैदा कर रहा है, प्रवृत्ति रेखा दिखा रहा है और बहस कर रहा है कि जितनी जल्दी हो या बाद में अगर चीजें जारी रहती हैं तो वे एक होने जा रही हैं अलग-अलग वातावरण के लिए चीजों को फिर से तैयार करने की तुलना में समस्या को साफ करने में बहुत अधिक खर्च होगा (दोनों को प्रत्यक्ष प्रयास में और आपकी कंपनी की सेवाओं में खोए ग्राहक विश्वास में)।


-1

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

आमतौर पर स्पष्ट लागत को समझना आसान होता है।

अमूर्त लागतों को निर्धारित करना कठिन है और इस प्रकार समझना कठिन है। TechnicalDebt, त्रुटियों की लागत, तनाव की लागत, डेवलपर्स पर बोझ, परिवर्तन के प्रभाव, प्रतिगमन परीक्षण, डाउनटाइम का प्रभाव और इतने पर समझाने के लिए कठिन हैं।

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

हम बदलावों को तुच्छ बनाने के लिए विभिन्न वातावरणों का उपयोग करते हैं।

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

हम बदलाव के प्रभावों पर विचार करने के लिए वातावरण का उपयोग करते हैं।

हम बदलाव के साथ शामिल लागतों को कम करने के लिए वातावरण का उपयोग करते हैं।

यह एक प्रणाली का परीक्षण करने और स्थिर करने में बहुत खर्च करता है आप स्थिर वातावरण पर किए गए निवेश को सुरक्षित करने के लिए वातावरण बनाते हैं।

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

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

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


इससे पहले किए गए 6 अंकों से अधिक कुछ भी नहीं दिया गया था और पहले 6 उत्तरों में समझाया गया था
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.