दो साल बाद ऐप्लिकेशन का रखरखाव कौन करेगा?

एक चल रही ऐप्लिकेशन स्वतः ही डिग्रेड नहीं होती

आम धारणा है कि सॉफ्टवेयर "उम्र बढ़ाता" है और अंततः स्वयं ही टूट जाता है। ऐसा वास्तव में नहीं होता। एक जनरेट की गई ऐप्लिकेशन का `package.json` प्रत्येक निर्भरता को उसके सटीक संस्करण नंबर पर फिक्स कर देता है, कोई संस्करण-रेंज नहीं, कोई 'अंतिम संगत संस्करण' नहीं, बल्कि ठीक वही संस्करण जो निर्दिष्ट किया गया है, जैसे `next@x.y.z`, `react@x.y.z`, `prisma@x.y.z` आदि। दो साल बाद ऐप्लिकेशन को फिर से इंस्टॉल करने पर वह ठीक उसी लाइब्रेरी ट्री को दोबारा बनाती है जो पहले दिन थी, और कोड स्वयं एक बाइट भी नहीं बदला होता।

जो डिग्रेड होता है, वह उसके चारों ओर का वातावरण है, समाप्त होने वाला सर्टिफिकेट, माइग्रेट किया जा रहा सर्वर, होस्टिंग प्रदाता द्वारा हटाई गई Node की संस्करण, और सबसे महत्वपूर्ण, फिक्स किए गए संस्करणों को अब सुरक्षा पैच नहीं मिलते। यह "सॉफ्टवेयर टूटना" से स्वभाव में भिन्न है, और यह पूरी तरह से यह बदल देता है कि आपको क्या योजना बनानी चाहिए।

तीन अलग-अलग प्रकार का रखरखाव, जिन्हें अक्सर एक साथ गिन लिया जाता है

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

दूसरा है होस्टिंग: डोमेन, सर्टिफिकेट, डेटाबेस, बैकअप। जब तक ऐप्लिकेशन शामिल URL पर ही सर्व की जा रही है, यह सब प्लेटफॉर्म द्वारा संभाला जाता है, और यही वह सटीक प्रश्न है जो आपको यहाँ या किसी भी प्रदाता से पूछना चाहिए: बैकअप की नीति क्या है, और वे कितनी बार लिए जाते हैं। जिस दिन आप ऐप्लिकेशन को अपने सर्वर पर लाते हैं, यह ज़िम्मेदारी पूरी तरह आपकी हो जाती है।

तीसरा वास्तव में रखरखाव नहीं है, बल्कि काम है: आपके व्यवसाय के बदलाव के कारण कोई फ़ील्ड, स्टेटस या स्क्रीन जोड़ना। यह केवल तभी होता है जब आप इसे माँगते हैं, और इसे अपने अलग से दायरे में संभाला जाता है, यही गाइड “अपनी ऐप्लिकेशन को कैसे विकसित करें” का विषय है।

इसे कौन कर सकता है, और कोई भी आपको ज़बरदस्ती नहीं पकड़ता

कोड मानक Next.js और Prisma है, जिसे ZIP आर्काइव के रूप में एक्सपोर्ट किया जा सकता है या GitHub पर पुश किया जा सकता है, और यह पूरी तरह आपका है। इसमें कोई प्रॉपराइटरी डायलेक्ट नहीं है, न ही कोई ऐसा फॉर्मेट जिसे केवल *प्लेटफॉर्म का विक्रेता* (vendor) ही पढ़ सके।: जो डेवलपर भी इस प्रोजेक्ट को संभाले, वह अपने पहले से जाने हुए टूल्स के साथ काम करता है, और यही कारण है कि बिना हमारी मदद के भी इसे सौंपा जा सकता है। यह एक बंद टूल के ठीक विपरीत है, जहाँ “कौन रखरखाव करेगा?” का एक ही जवाब होता है, विक्रेता, जब तक वह मौजूद है।

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

जिसे आपको वास्तव में बजट में रखना चाहिए

कस्टम विकसित सॉफ्टवेयर के मामले में, उद्योग के सामान्य स्रोतों के अनुसार, सुधारात्मक रखरखाव की लागत प्रारंभिक लागत का लगभग १५ से २० प्रतिशत प्रति वर्ष होती है, और रखरखाव व विकास की कुल लागत पाँच साल के कुल स्वामित्व लागत का लगभग आधा होता है। यह बजट लगभग कोई भी नहीं बनाता, और यही कारण है कि एक सफल प्रोजेक्ट तीन साल बाद एक छोड़ा हुआ टूल बन जाता है।

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