... या क्या आपको अपना कोड तैनात करने के लिए किसी और के माध्यम से जाना है (एक व्यक्ति जो सर्वर प्रबंधित करता है)?क्या आप अपने कोड को लाइव वातावरण में तैनात करने के लिए ज़िम्मेदार हैं?
मैं हर किसी को लाइव उत्पादन सर्वर पर लॉग इन करने की नीति को समझने की नीति को समझता हूं लेकिन मैं अपने कोड, डेटाबेस और फ़ाइलों को लाइव होने के बाद एक्सेस करने की क्षमता चाहता हूं।
यह सबके लिए कैसा है?
कॉन्फ़िगरेशन प्रबंधन समूह होने या उत्पादन समूह के लिए कोड को तैनात करने वाले विकास समूह के अलावा कोई अन्य व्यक्ति के फायदे हैं। जिनमें से अधिकांश रिलीज के कठोरता और लेखापरीक्षा के निशान को लागू करने में मदद करते हैं। आदर्श कॉन्फ़िगरेशन प्रबंधन टीम को स्क्रिप्टिंग द्वारा कोड जारी करना चाहिए। स्क्रिप्ट एक निश्चित टैग के लिए कोड भंडार से खींचती है, और एक निश्चित सर्वर पर रिलीज़ होती है। ऐसा करने से रास्ते में गलतियों को कम किया जाता है।
मुझे लगता है कि विकास टीम को केवल उत्पादन डेटा के अधिकार, और किसी भी लॉग फाइल को देखने की क्षमता पढ़नी चाहिए थी। यह समस्याओं की आसान डिबगिंग के लिए अनुमति देता है। यदि कोड के एक नए संस्करण को डेटाबेस अपडेट की भी आवश्यकता होती है, तो कॉन्फ़िगरेशन प्रबंधन टीम को निश्चित रूप से स्क्रिप्ट द्वारा उन परिवर्तनों को तैनात करना चाहिए।
यह सब इस बात पर निर्भर करता है कि कंपनी की कौन सी प्रक्रियाएं हैं। कुछ दूसरों की तुलना में अधिक लचीला हैं। हमारा संगठन उत्पादन वातावरण तक पहुंचने वाले डेवलपर्स से दूर जा रहा है। अब सब कुछ क्यूए की प्रक्रिया का पालन करना है और फिर संचालन (जो कोड की तैनाती और रखरखाव का ख्याल रखता है)। मुझे लगता है कि आप कम घटनाओं के साथ खत्म हो जाएगा, लेकिन एक लंबा बग फिक्स समय।
मुझे लगता है कि आप घटनाओं की एक ही संख्या के साथ खत्म होने की संभावना है, और एक लंबे समय तक बग-फिक्स समय। –
@ ब्रायन - ऐसा हो सकता है या नहीं हो सकता है। यह अभी भी नया है, इसलिए चलो इसे संदेह का लाभ दें। यह दिन का स्वाद है। –
मुझे लगता है कि कुछ तय करने के बीच एक छोटा बाधा एक अच्छा विचार है और इसे लाइव साइट पर आज़माकर एक अच्छी बात है, जो हर समय बेवकूफ गलतियों की संख्या के कारण होती है। लेकिन शायद छोटा कुंजी शब्द है। –
आखिरी जगह पर मैंने अनुबंध किया, उत्पादन सर्वर पर तैनाती और विन्यास के लिए जिम्मेदार लोगों का एक विशिष्ट समूह है।
आपके सभी कोड को वीसीएस में चेक किया जाना था और यही वह जगह है जहां उन्हें तैनात करने के लिए कोड मिला। इसलिए आपके पास लाइव होने के बाद कोड में परिवर्तन करने के लिए "एक्सेस" नहीं है। उन्होंने सप्ताह में दो बार नए/बदले गए कोड को तैनात किया जब तक कि यह आपातकालीन तैनाती न हो।
मुझे लगता है कि आपके मामले में लाइव वातावरण ने परीक्षण पर्यावरण को प्रतिबिंबित किया है। सुनिश्चित नहीं है कि हमारा क्या करता है:/ – JohnnyBizzle
उनके पास कई वातावरण, दो विकास, एक क्यूए और उत्पादन था। – buckbova
मैंने आज सिर्फ एक जीवंत वातावरण में कुछ तैनात किया है। मेरे पास लाइव डेटाबेस तक पहुंच है।
यह अतीत में कुछ महाकाव्य विफलताओं का कारण बन गया है। कभी-कभी किसी ने विकास पर्यावरण के बजाय उत्पादन वातावरण पर एक टेबल गिरा दी। हालांकि, मुझे रिलीज करने वाले किसी अन्य व्यक्ति में थोड़ा सा लाभ दिखाई देता है, खासकर जब वह सॉफ़्टवेयर से परिचित नहीं होता है।
लाइव पर एक टेबल छोड़ना? मान लीजिए कि आप बैकअप लेते हैं! – JohnnyBizzle
बेशक, लेकिन इसका अभी भी मतलब है कि सिस्टम नीचे है जबकि कोई बैकअप से तालिका को पुनर्स्थापित कर रहा है। – Sjoerd
आदर्श रिहाई प्रक्रिया प्रवाह इस प्रकार हैं (मेरी छोटी दुनिया में) है:
आपकी कंपनी कितनी सख्त है इस पर निर्भर करता है कि डेवलपर लाइव रिलीज तक पहुंच सकता है या नहीं, खासकर यदि यह एक बड़ी कंपनी है।
मैं समान हूं। - मैं अपनी मशीन पर विकसित करता हूं। - एक आंतरिक/इंट्रानेट सर्वर पर तैनात करें और परीक्षक को इसके पास जाने दें। - तैयार होने पर इसे तैनाती सूची (हालिया अवधारणा) पर रखा जाता है और जीने के लिए तैनात किया जाता है। – JohnnyBizzle
प्रत्येक वातावरण थोड़ा अलग है। तुलना में, आपको यह तय करना होगा कि आपके लिए क्या काम करता है। उदाहरण के लिए अमेज़ॅन अपने डेवलपर्स को अपना कोड बना देता है, जो कुछ डेवलपर्स नफरत करते हैं, लेकिन यह उस माहौल की एक विशेषता है जो बग को कम रखती है (पिछली बार जब आपने amazon.com पर एक बग देखा था?)।
अन्य एक कड़े क्यूए प्रक्रिया चाहते हैं इसलिए तैनाती की देखभाल के लिए एक संचालन विभाग बनाएं, लेकिन मुझे लगता है कि वे कंपनी में नकारात्मकता का वातावरण बनाते हैं: उन्हें अपनी भूमिका को न्यायसंगत बनाकर पुरस्कृत किया जाता है, जो इंगित करता है और दुनिया में बुरी चीजों का समर्थन करना। यदि देव अपने काम पर अच्छे हैं, तो उनके वेतन किसी भी तरह से प्रदर्शन से संबंधित होने पर नाराजगी हो सकती है।
व्यक्तिगत रूप से, मैं पूरे ढेर की देखभाल करना पसंद करता हूं, लेकिन तेजी से प्रदाताओं को आगे बढ़ रहा हूं जो मुझे हार्डवेयर (ईसी 2, हेरोकू इत्यादि) के बारे में कम और कम चिंता करने की अनुमति देता है, और कार्यक्षमता पर अधिक ध्यान केंद्रित करने के लिए क्षुधा।मुझे व्यक्तिगत रूप से कोड और बग का स्वामित्व पसंद है, क्योंकि इसका मतलब है कि मैं बग टिकटों को नीचे रखने के लिए प्रेरित हूं - हर खुली टिकट नई कार्यक्षमता में देरी है जिसे मैं काम करना चाहता हूं।
प्रत्येक के लिए स्वयं।
तर्क भी किसी भी तरह से हैं। व्यक्तिगत रूप से मैं अपने लाइव कोड के लिए ज़िम्मेदार होना चाहता हूं और कुछ भी नहीं जानता कि पहले से ही छेड़छाड़ की गई है (यह पहले हुआ है!) इसके अलावा वातावरण को प्रतिबिंबित करना अच्छा होगा! – JohnnyBizzle
ऊपर उल्लिखित विकास और परीक्षण पर्यावरण का उत्तर दें। समर्पित, अलग बिल्ड सर्वर के लिए भी महत्वपूर्ण है जिसका उपयोग विकास के लिए नहीं किया जाता है। यह भंडार से स्रोत कोड खींचता है, संकलित करता है और वितरण (जावा वर्ल्ड ईएआर या डब्ल्यूएआर फ़ाइल में) बनाता है जिसे बाद में पर्यावरण के परीक्षण के लिए तैनात किया जाता है।
यह बिल्ड सर्वर सीआई पर्यावरण की मेजबानी भी कर सकता है और नियमित स्वचालित दैनिक निर्माण कर सकता है।
जिस व्यक्ति को मैंने प्रतिस्थापित किया वह लाइव वातावरण पर विकसित होता था! –
मैंने पूछा क्यों अधिक विशिष्ट होने के लिए, मेरे पास एक वेब ऐप है जो कुछ एक्सएमएल फाइलों का उपयोग करता है। एप्लिकेशन के माध्यम से उन फ़ाइलों में परिवर्तन करने की बजाय मैं उन्हें स्थानीय रूप से संपादित करना और उन्हें सर्वर पर अपलोड करना चाहता हूं। उन्हें अक्सर नहीं बदला जाना चाहिए। कुछ साइट छवियों के साथ ही। वे अक्सर नहीं बदलेंगे, लेकिन मैं उपयोगकर्ताओं को खुद को बनाए रखने की अनुमति नहीं दूंगा। – JohnnyBizzle
@ एडी बी अब मैं अब तक नहीं जाऊंगा! – JohnnyBizzle