कई वातावरण होने के अच्छे, सरल कारण

71

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

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

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

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

culture development-environment

— smp7d
स्रोत

1

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

— maple_shaft

4

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

— JGWeissman 20

2

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

— smp7d

1

काश मुझे एक बाउंटी शुरू करने का सौभाग्य मिलता!

— क्रि।

7

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

— smp7d

86

जवाब: पैसा

मुझे परवाह नहीं है कि वास्तविक कारण क्या है। पैसा आपके सभी तर्क के मूल में होना चाहिए, खासकर जब प्रबंधन के साथ काम करना।

यदि हम दोनों 2 घंटे के लिए एक कमरे में बैठते हैं, तो हम दर्जनों कारणों के साथ आ सकते हैं, क्योंकि कई वातावरण होना बेहतर है।

यहाँ समस्या है: यदि कारण पैसे पर आधारित नहीं हैं, तो उनमें से कोई भी बात नहीं है ।

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

जब उस दृष्टिकोण से इसे देखते हैं, तो उत्तर सरल होता है:

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

इसे हर दिन दोहराएं।

नीचे कुछ बेहतरीन टिप्पणियाँ दी गई हैं जो इस उत्तर के लिए कुछ वास्तविक मूल्य जोड़ती हैं, इसलिए मैं उनका उल्लेख करूंगा:

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

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

— riwalk
स्रोत

12

+1 पैसे के लिए एकमात्र भाषा प्रबंधन समझता है। वैसे महान उद्धरण। यह सक्सेस और परफेक्ट है।

— maple_shaft

7

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

— कार्ल बेवेलफेल्ट

4

+1 के लिए "अपने आप को प्रोग्रामर न कहें" लेख

— nwahmaet

3

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

— ब्लेयरहिपो

इस सवाल के कई सही जवाब हैं, लेकिन यह एक गुच्छा सबसे अच्छा है।

— smp7d

18

असफलता की एक भी वजह

विकास या मंचन का माहौल न होने से आपके पास उन विरासत अनुप्रयोगों के लिए एकल बिंदु विफलता है । यदि आप उन शर्तों में विरासत अनुप्रयोगों का वर्णन करते हैं तो प्रबंधन आपको सुनेंगे।

आपको ध्वनि बाइट्स में अपने संदेश को पिच करने में सक्षम होना चाहिए जो उन्हें समझ में आता है। " प्रोग्रामर स्पीक " को चर्चा से बाहर निकालें और इसे " मैनेजर स्पीक " से बदलें । इसके अलावा, अपनी बात कहने के लिए 30 सेकंड की लिफ्ट की सवारी करें।

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

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

— माइकल रिले - उर्फ गनी
स्रोत

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

— फिलिप

9

क्या यह वास्तव में महत्वपूर्ण है?

मैं अलग वातावरण का उपयोग करने की इच्छा को समझ सकता हूं। गैर-स्पष्ट प्रश्न है:

क्या विरासत प्रणाली को स्थानांतरित करना वास्तव में महत्वपूर्ण है?

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

सभी व्यावसायिक निर्णय आम तौर पर कथित लागत / लाभ के आधार पर किए जाते हैं। तो सवाल यह है कि व्यवसाय शायद पूछ रहा है:

क्या एक विरासत परियोजना में अतिरिक्त प्रणाली और विकास निवेश की लागत एक ही परियोजना / उत्पाद में एक ही निवेश डालने के लायक है?

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

अलग वातावरण

व्यापार कारणों के वातावरण को अलग करने के।

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

— dietbuddha
स्रोत

+1 यह इंगित करने के लिए कि लागत को देखना महत्वपूर्ण है।

— sleske

अलग-अलग वातावरण में अपने व्यावसायिक कारणों से प्यार करें। विशेष रूप से पहला 3. सर्वश्रेष्ठ उत्तर। धन्यवाद।

— जॉन एसिम्प्टोथ

8

ऐसा लगता है कि आपके पास पहले से ही सभी "सही" तर्क हैं। इसके बजाय, आप "रेड-हेरिंग" का अनुभव कर रहे हैं, यदि आप करेंगे। या, "गाजर का पीछा करते हुए"

प्रबंधन के पास वास्तव में मुझे सुनने में समय और रुचि नहीं है जब तक कि कोई महत्वपूर्ण मुद्दा नहीं है

यही मैं वास्तविक समस्या मानता हूं। मेरे अनुभव में, यदि किसी कंपनी के पास उप-विकास की प्रथाएँ उतनी ही खराब हैं जितनी आप वर्णन करते हैं। यह केवल "हम किसी भी बेहतर नहीं जानते थे" की बात नहीं है। इसके बजाय, एक ऊपरी प्रबंधन टीम के कारण तकनीकी ऋण का एक संकलन जो इसे प्रस्तुत समस्याओं के बारे में नहीं जानता (देखभाल?)।

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

मेरा सुझाव या तो इसे चूसना है और चीजों को लेना है जो वे हैं या एक नई स्थिति की तलाश में हैं।

— P.Brian.Mackey
स्रोत

7

एक बार में ऐप पर कितने लोगों के काम करने की योजना है? Usuaslly मैंने प्रत्येक समूह के लोगों के लिए एक वातावरण देखा है। यह डेवलपर्स हैं (उन्हें एक डीईवी वातावरण और एक डीईवी एकीकरण वातावरण मिलता है - कुछ कहेंगे 100% आवश्यक नहीं, मैं कहूंगा कि यह परियोजना से भिन्न होता है), दो परीक्षण वातावरण (बहुत विस्तृत परीक्षण करने वाले परीक्षकों का एक समूह, अन्य के लिए) उच्च-स्तरीय क्यूए परीक्षक - आमतौर पर वे वास्तविक व्यवसाय उपयोगकर्ता होते हैं, प्रशिक्षित परीक्षक नहीं)। आमतौर पर एक अलग प्रदर्शन परीक्षण वातावरण भी होता है (ताकि आप डेटा के विशाल संस्करणों का परीक्षण कर सकें, उपयोगकर्ताओं की भारी मात्रा का अनुकरण कर सकें, आदि ... जी)।

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

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

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

— FrustratedWithFormsDesigner
स्रोत

क्या कोई नीच को समझा सकता है?

— FrustratedWithFormsDesigner

@maple_shaft: LOL! मेरे पास एक स्पष्टीकरण था, इसलिए मैं अपना उत्तर ठीक कर सकता था।

— FrustratedWithFormsDesigner

1

क्या नीचता? मैं एक downvote नहीं दिख रहा है ...

— Yannis

@YannisRizos: एक था ... लेकिन यह कभी नहीं समझाया गया था।

— FrustratedWithFormsDesigner

5

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

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

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

— S.Robins
स्रोत

"बदलती आदतें, पूर्वाग्रहों को तोड़ना, और अंततः संभावित संभावनाओं के लिए बंद दिमाग खोलने के बारे में" - पूर्वव्यापी में यह कुंजी थी और मैं किसी भी एक कारण की ओर संकेत नहीं कर सकता कि आखिरकार ऐसा क्यों हुआ

— smp7d

4

यहाँ एक है: परीक्षणशीलता।

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

4

आप बदलना चाहते हैं कि आपका संगठन अपने सॉफ़्टवेयर को कैसे विकसित करता है? "चीजों को अलग तरीके से करने" के लिए "कारणों" की चिंता करना भूल जाएं। तर्कसंगत तर्क के कारण मनुष्य व्यवहार में बदलाव नहीं करता है। वे अपनी आदतों पर मनोवैज्ञानिक प्रभावों के कारण बदल जाते हैं।

तो इसके साथ मैं कहां जा रहा हूं?

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

जमीनी स्तर का समर्थन: एक दूसरे "विरासत" डेवलपर को ढूंढें जो आपको एक शॉट देने के लिए तैयार है। उसके साथ भागीदार बनें और बदलें कि चीजें कैसे काम करती हैं। परिवर्तन की घोषणा न करें। बस बदलाव करें। अगर कोई भी आपको इसके बारे में पूछता है, तो बस कहें "ओह, हाँ, अब हम इसे कैसे करते हैं।"
जिम्मेदारी संभालें। विरासत लोगों के लिए तैनाती को संभालने के लिए स्वयंसेवक। आप जैसा अभिनय करते हैं, उससे प्यार करते हैं। वे उस जिम्मेदारी को त्याग कर खुश हो सकते हैं। फिर उसे चलाएं जो आप चाहते हैं।
अपनी गलतियों के लिए सही लोगों को दोष दें। अगली बार जब आपके पाषाण काल परिनियोजन तंत्र के कारण विरासत ऐप बग को उत्पादन में पेश किया जाता है, तो इसे इंगित करें। इसे सूक्ष्मता से करें ... ईमेल में नहीं। अगली बार जब आप एक प्रबंधक के साथ एक बैठक में हों, तो बस लापरवाही से एक कारण का उदाहरण दें कि तैनाती समस्याग्रस्त थी। "हाँ, याद रखें कि हम पिछले शुक्रवार को कैसे फुदक रहे थे क्योंकि फू बग बॉब ने उत्पादन में जाँच की थी? हाँ, यह बहुत ही कठिन प्रयास था!"
इसे बेहतर तरीके से करना आसान बनाएं। उदाहरण के लिए, iPhone को देखें। इस पर एक बटन है। (खैर, दो)। इसे चालू करना बहुत आसान है। तैनाती-से-कई-वातावरण पागल बेवकूफ आसान बनाओ। यह इतना आसान बनाओ कि सभी प्रबंधक इसे कर सकें!

— स्टीफन ग्रॉस
स्रोत

Humans don't change behavior because of rational arguments. They change because of psychological influences on their habits.

कितना निराशाजनक सच है। चाहे सॉफ्टवेयर की बात हो या "मुक्त बाजार" की, लोगों का यह मानना कि उनके हित में तर्कसंगत निर्णय करना एक पतन है।

— maple_shaft

4

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

हम हमेशा DEV -> QA -> PROD करते हैं (कभी-कभी उन चरणों को छोटे टुकड़ों में तोड़ दिया जाता है) उनके पीछे समान हार्डवेयर के साथ। वर्तमान उत्पादन डेटा को हमेशा PROD से QA से DEV तक धकेल दिया जाता है।

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

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

PROD: एक बार जब आप इस स्तर पर पहुंच जाते हैं, तो आपको यह सुनिश्चित करना चाहिए कि कोड वर्तमान डेटा के साथ काम करता है और आपके QA समूह / व्यवसाय उपयोगकर्ता कार्यान्वयन से खुश हैं। यदि आपने सब कुछ सही ढंग से किया है तो आपको बस कोड को अपडेट करने और इसके साथ काम करने में सक्षम होना चाहिए।

उसी तरह से आप कभी भी ग्राहकों को अनटाइटेड प्रोडक्ट जारी नहीं करेंगे। आपको कभी भी प्रोडक्ट के माहौल में अनटाइटेड कोड जारी नहीं करना चाहिए।

यदि कंपनी इसे ठीक से करने के लिए समय का निवेश करने के लिए तैयार नहीं है, तो वे आपातकालीन रखरखाव और त्रुटियों को 10 गुना में वापस भुगतान करेंगे।

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

जब हमने रिपोर्ट में अनियमितता की ओर इशारा किया तो सीएफओ का चेहरा सफ़ेद हो गया, पता चला कि किसी बदलाव को तेज करने के कारण वे ~ $ 250,000 एक चौथाई खो रहे थे।

अधिक बार होता है तो आप सोचते हैं, यदि आप इसे ठीक से करने का जोखिम नहीं उठा सकते, तो न करें।

— DarkStar33
स्रोत

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

— ११

3

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

मैं कुछ हद तक @ Stargazer712 से सहमत हूं कि आपका स्टेटमेंट मनी के मामलों की ओर इशारा करता है, लेकिन निम्नलिखित कथन की जांच करें कि मुझे सॉफ्टवेयर डेवलपमेंट पर मार्क हैमिल्टन की पुस्तक: बिल्डिंग रिलायबल सिस्टम्स (अप्रेंटिस हॉल पीटीआर, 1999, आईएसबीएन) 0-13-081246- से मिला है। 3)। इन सभी कारकों को देखने के बाद; आपके प्रश्न के बारे में मेरी राय यह है कि एकल पर्यावरण आपको बचत नहीं दे रहा है, यह परियोजना / सॉफ्टवेयर को पूरा करने के लिए एक दीर्घकालिक प्रक्रिया बना देगा। वितरित वातावरण समय और राजस्व को बचाएगा जैसा कि मैंने सीखा और अपने अनुभव में देखा कि स्टार्ट-अप सॉफ़्टवेयर कंपनियों के साथ क्या हुआ, जिससे मैंने अपना कैरियर शुरू किया है।

बहुत सारे लेख प्रदर्शित करते हैं कि सफलता के लिए क्या बात है, इस सफल सॉफ्टवेयर विकास के लिए एक आयोजन करें

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

सॉफ्टवेयर डेवलपर्स का एक बड़ा सेट संघर्ष करेगा और अंततः अपने लक्ष्यों को पूरा करने में विफल रहेगा, अगर उन्हें अपना सारा समय अनुचित संगठनात्मक ढांचे के खिलाफ लड़ने में बिताना होगा।

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

— निरंजन सिंह
स्रोत

1

समय, धन, परीक्षण, गुणवत्ता को भूल जाओ ... कैसे प्रतिष्ठा के बारे में ।

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

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

बस अपने प्रबंधक को याद दिलाएं कि गलतियाँ होती हैं, इसलिए सीईओ से पहले उनके सामने आने से बचने का तरीका, जो पत्रकारों के सामने ग्रिलिंग पाने के लिए है और तकनीकी जनता द्वारा हंसी है, उन गलतियों को रोकने के लिए सरल, स्पष्ट कदम उठाए जा रहे हैं लोगों को।

— gbjbaanb
स्रोत

1

लगता है कि आपके पास कई अलग-अलग वातावरण हैं और लोगों को "पर्यावरण" सेटअप करने में बहुत समय लगता है।

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

वैकल्पिक रूप से केवल अंतर होना चाहिए:

आकार (न्यूनतम, अनुशंसित, सबसे बड़ा समर्थित / परीक्षण के खिलाफ);
मंचन और उत्पादन में विकास उपकरण नहीं होते हैं
डेटा के आकस्मिक ओवरराइट के खिलाफ उत्पादन सुरक्षित है
आप बहुत आसानी से डेमो, परीक्षण या [anoymized] क्लाइंट डेटा को विकास या स्टेजिंग सर्वर पर लोड कर सकते हैं

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

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

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

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

इसलिए, लाइव से मेरे नवीनतम बैकअप सहित एक दूसरे qa वातावरण को सेट करने के लिए, कमांड होंगे:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

अंत में, मेरे पास एक अतिरिक्त (वैकल्पिक) सर्वर है जिसे "रेडोनली" कहा जाता है जो जमीन से टकराने से पहले अंतिम सुरक्षा जाल के रूप में है। इसे क्यूए सिस्टम की तरह प्रावधान किया गया है लेकिन पिछली रात बैकअप और अपडेट डिसेबल (सॉफ्टवेयर भी कल रात अपडेट किया गया है) के साथ।

यह "सभी अंडों को एक अलग टोकरी में" दृष्टिकोण का उपयोग करता है: यह एक अलग स्थान / डीएनएस रजिस्ट्रार, डीएनएस होस्ट, सिस्टम होस्ट सेवा प्रदाताओं के साथ प्रावधान किया गया है। यह अंतिम / अंतिम सुरक्षा जाल है, इसलिए अगर सब कुछ आग की लपटों में ऊपर चला गया है तो आप कम से कम कल रात तक डेटा प्राप्त कर सकते हैं। प्रोविजनिंग स्क्रिप्ट अलग-अलग प्रदाताओं के बीच के अंतर को अलग करती है, इसलिए 99% एक ही है, बस आसानी से झंडा। यदि सभी लाइव सर्वर विफल हो गए हैं, तो क्लाउडफ्लेयर लोड बैलेंसर रीडऑनली साइट पर ट्रैफ़िक पुनर्निर्देशित करेगा।

— iheggie
स्रोत

0

जब परिवर्तन करने की बात आती है, तो आप किसी ऐसे व्यक्ति के लिए भाग्यशाली होंगे जो आपकी व्यावसायिक राय को सुनेगा और सुझाए गए परिवर्तनों को लागू करेगा।

मेरे अनुभव पर, हर बार मुझे एक बड़ा बदलाव करना पड़ा, मुझे इसे व्यवसाय को बचाने के लिए बचत के मामले में सही ठहराना पड़ा। उदाहरण के लिए, विकास पाइपलाइन में ReSharper को पेश करना बहुत आसान था, क्योंकि मैं लाइनों पर कुछ कहने में सक्षम था:

ReSharper की लागत लगभग 50 पाउंड प्रति डेवलपर है। प्रति वर्ष औसत डेवलपर लागत £ 40k है। ReSharper को अपनी पूर्ण क्षमता के लिए उपयोग में लाए जाने वाले डेवलपर्स की उत्पादकता में कम से कम 20% की वृद्धि करनी चाहिए। कहो डेवलपर अपने समय का 75% वास्तव में आईडीई में कोड लिखने में खर्च करता है। 40k का 75% £ 30k है। £ 30k अब डेवलपर की उत्पादकता की लागत है। उत्पादकता का एक अतिरिक्त प्रतिशत (1%) प्रति वर्ष £ 300 खर्च होता है। अतिरिक्त 20% उत्पादकता प्राप्त करने के लिए, व्यवसाय को £ 6k खर्च करना होगा।

यदि आप इसे व्यवसाय के परिप्रेक्ष्य में रखते हैं, तो आप कह सकते हैं कि आप किसी और को किराए पर ले सकते हैं और £ 6k के लिए अतिरिक्त 20% उत्पादकता प्राप्त कर सकते हैं, या आप ReSharper लाइसेंस पर £ 50 खर्च करके एक ही परिणाम प्राप्त कर सकते हैं। एक बार जब आंकड़े व्यवसाय के सामने होंगे, तो निर्णय लेना आसान हो जाएगा।

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

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

मैं व्यक्तिगत रूप से इस तरह की राजनीति से नफरत करता हूं, लेकिन यह आम है और हमें इसके साथ रहना होगा।

— CodeART
स्रोत