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