संक्षेप में जवाब
वेबसाइट का हैंडओवर पाँच चीज़ों में सिमटता है: डोमेन, होस्टिंग खाता, रिपॉज़िटरी, एडमिन पैनल का मालिकाना लॉगिन और एनवायरनमेंट वेरिएबल उनके मानों के साथ। अंतिम भुगतान से पहले हर एक को कैसे जाँचें।
हैंडओवर पर आपको क्या मिलता है: छोटा जवाब
हैंडओवर पर आपको पाँच चीज़ें मिलती हैं: डोमेन का नियंत्रण, होस्टिंग प्लेटफ़ॉर्म पर एक खाता, सोर्स कोड वाली रिपॉज़िटरी, एडमिन पैनल का मालिक-स्तरीय लॉगिन, और एनवायरनमेंट वेरिएबल की सूची इस टिप्पणी के साथ कि हर एक क्या करता है। बाक़ी सब इन्हीं पाँच के इर्द-गिर्द लिपटा दस्तावेज़ है।
वेबसाइट कोई फ़ाइल नहीं, चलती हुई व्यवस्था है। उसका एक पता है जिससे लोग उसे पाते हैं, एक जगह है जहाँ वह चलती है, कोड है जिससे वह बनी है, एक पैनल है जहाँ कंटेंट बदला जाता है, और सेटिंग्स हैं जो उसे बाहरी सेवाओं से जोड़ती हैं।
इन पाँच में से एक भी छूट जाए और आपके पास ऐसी साइट रह जाती है जिसे आप देख सकते हैं पर बदल नहीं सकते। यह व्यावसायिक स्थिति है, तकनीकी फ़ुटनोट नहीं: यही सूची तय करती है कि आप पहले से किए काम का दोबारा भुगतान किए बिना ठेकेदार बदल सकते हैं या नहीं।
आगे हर चीज़ बारी-बारी से है — वह कैसी दिखती है, मंज़ूरी से पहले क्या जाँचें, और VITON13 के पैकेजों में हैंडओवर कहाँ बैठता है, जहाँ दायरा और अवधि पहले से घोषित हैं।
डोमेन: रजिस्ट्रार खाते का नियंत्रण किसके पास है
डोमेन किसी रजिस्ट्रार के खाते के भीतर रहता है। स्वामित्व दो बातों पर टिका है: उस खाते में लॉगिन कौन करता है, और डोमेन के पंजीयक फ़ील्डों में किसका संपर्क विवरण है।
जो व्यवस्था काम करती है वह है: डोमेन आपकी कंपनी के नाम पंजीकृत, और डेवलपर को प्रत्यायोजित एक्सेस या DNS रिकॉर्ड पर अधिकार। जो काम नहीं करती वह है: आपको काग़ज़ी झंझट से बचाने के नाम पर डोमेन डेवलपर के नाम।
इसे ख़ुद जाँचें: अपने ही विवरण से रजिस्ट्रार में लॉगिन करें, पुष्टि करें कि पंजीयक ईमेल आपकी कंपनी के नियंत्रण वाला पता है, देखें कि स्वतः-नवीनीकरण चालू है, और DNS रिकॉर्ड खोलकर देखें कि वे संपादन योग्य हैं।
डोमेन एक दोहराया जाने वाला भुगतान भी है। नवीनीकरण उसी से लिया जाता है जिसके पास खाता है, इसलिए एक्सेस और नवीनीकरण की तारीख़ तथा दर्ज कार्ड की ज़िम्मेदारी साथ-साथ चलते हैं।
होस्टिंग और वह प्लेटफ़ॉर्म जहाँ साइट सचमुच चलती है
होस्टिंग वह जगह है जहाँ से बनी हुई साइट परोसी जाती है: वर्चुअल सर्वर, प्रबंधित प्लेटफ़ॉर्म, कंटेनर वातावरण। हैंडओवर पर मायने रखते हैं खाता, उसका प्लान और उससे जुड़ा भुगतान का साधन।
प्रदाता, प्रोजेक्ट का नाम, क्षेत्र और अपना अनुमति स्तर पूछें। लक्ष्य मालिक या प्रशासक अधिकार हैं; ऐसा अतिथि लिंक जो सिर्फ़ लॉग दिखाता है, एक्सेस नहीं, बस एक दृश्य है।
DNS इसी बातचीत का हिस्सा है: कौन-से रिकॉर्ड डोमेन को होस्टिंग की ओर भेजते हैं, मेल रिकॉर्ड कहाँ हैं, सर्टिफ़िकेट कैसे जारी और नवीनीकृत होता है। इन रिकॉर्डों की सूची वाली एक सादी टेक्स्ट फ़ाइल उचित डिलिवरेबल है।
विफलता का रास्ता भी लिख लें: कौन-सा लॉग खोलना है, पिछले डिप्लॉय पर कैसे लौटना है, यह करने का अधिकार किसके पास है। यह वादा नहीं कि कुछ नहीं टूटेगा, यह उस क्षण के लिए दर्ज रास्ता है जब कुछ टूटेगा।
रिपॉज़िटरी: सोर्स, फ़ाइलों का फ़ोल्डर नहीं
रिपॉज़िटरी यानी कोड, उसके बदलावों के इतिहास के साथ। site-final.zip नाम का आर्काइव सोर्स नहीं है: उसमें न ब्रांच हैं, न इतिहास, न किसी बदलाव और उसके कारण के बीच कोई कड़ी।
आपको चाहिए रिपॉज़िटरी अपने ही संगठन या खाते के भीतर, मालिक भूमिका आपके नाम। काम चलने तक डेवलपर सहयोगी बना रहता है और काम रुकने पर एक्सेस खो देता है।
भीतर जाँचने लायक़ चीज़ें: पढ़ने योग्य कमिट इतिहास, बिल्ड का निर्देश जिसे कोई और भी निभा सके, तय संस्करणों वाली डिपेंडेंसी सूची, और कोड में कमिट की गई कोई कुंजी या पासवर्ड न होना।
जाँच जल्दी हो जाती है। कोई दूसरा डेवलपर रिपॉज़िटरी क्लोन करे, README का पालन करे, और उसके पास चलती हुई स्थानीय प्रति हो। अगर वह शुरू नहीं होती, तो हैंडओवर अभी पूरा नहीं हुआ।
एडमिन पैनल: भूमिकाएँ, मालिकाना अधिकार और कंटेंट कहाँ रहता है
जहाँ CMS या कस्टम पैनल है, वहाँ आपको संपादक नहीं, मालिक खाता चाहिए। मालिक उपयोगकर्ता बनाता और हटाता है; संपादक सिर्फ़ टेक्स्ट और तस्वीरें बदलता है।
सिस्टम में मौजूद हर खाते की सूची उसकी भूमिका सहित माँगें। जिन खातों की किसी को ज़रूरत नहीं, वे स्वीकृति के हिस्से के रूप में हटा दिए जाते हैं — किसी ऐसी सफ़ाई के लिए नहीं छोड़े जाते जो कभी तय ही नहीं होती।
फिर तय करें कि कंटेंट भौतिक रूप से कहाँ है: डेटाबेस, अपलोड की गई फ़ाइलें, मीडिया स्टोर। और प्रति कैसे ली जाती है — मैन्युअल एक्सपोर्ट, स्वचालित बैकअप, और वे प्रतियाँ कहाँ रखी जाती हैं।
यह लिख रखना उपयोगी है कि पैनल के कौन-से फ़ील्ड सार्वजनिक पेजों तक पहुँचते हैं: शीर्षक, मेटाडेटा, रीडायरेक्ट। जो संपादक फ़ील्ड की सीमा जानता है, वह एक बड़ी तस्वीर से लेआउट नहीं तोड़ता।
एनवायरनमेंट वेरिएबल: वे सेटिंग्स जिनके बिना बिल्ड शुरू नहीं होती
एनवायरनमेंट वेरिएबल वे कुंजियाँ और पते हैं जिनसे साइट बाहरी सेवाओं से बात करती है — डेटाबेस, मेल डिलीवरी, भुगतान, एनालिटिक्स, फ़ाइल स्टोरेज। वे कोड में नहीं रखे जाते; वे प्लेटफ़ॉर्म पर सेट होते हैं।
हैंडओवर को दोनों आधे चाहिए: वेरिएबल की सूची, हर एक के काम की एक पंक्ति के साथ, और ख़ुद मान — उसी माध्यम से भेजे गए जिसका उपयोग आपकी कंपनी पहले से रहस्य रखने के लिए करती है, जैसे कोई कॉर्पोरेट पासवर्ड मैनेजर।
बिना मानों की सूची आपको ऐसी बिल्ड देती है जो शुरू होने से इनकार कर देती है। बिना सूची के मान आपको स्ट्रिंग्स का ऐसा ढेर देते हैं जिसे छह महीने बाद कोई नहीं समझ सकता।
इनमें से कुछ कुंजियाँ तीसरे पक्ष के खातों की होती हैं — कोई भुगतान प्रदाता, कोई मेल सेवा। वे खाते भी आपके नाम होने चाहिए, वरना उनकी तरफ़ की सामान्य कुंजी-बदली आपकी साइट को ऑफ़लाइन कर देती है।
बिल्ड और डिप्लॉय: सोर्स चलती हुई साइट कैसे बनते हैं
रिपॉज़िटरी और प्रकाशित साइट के बीच एक बिल्ड बैठी है: वे कमांड जो सोर्स को उसमें बदलते हैं जो सर्वर ब्राउज़र को देता है। यह प्रक्रिया लिखी हुई और किसी दूसरी मशीन पर दोहराई जा सकने वाली होनी चाहिए।
न्यूनतम यह है: रनटाइम का संस्करण, डिपेंडेंसी इंस्टॉल करने की कमांड, बिल्ड की कमांड और चलाने की कमांड। बेहतर यह है कि वही चरण निरंतर एकीकरण की फ़ाइल में हों, ताकि बिल्ड किसी एक लैपटॉप पर निर्भर न रहे।
डिप्लॉयमेंट अलग से दर्ज होता है: कौन-सी ब्रांच प्रोडक्शन तक जाती है, क्या अपने आप होता है, क्या हाथ से, रिलीज़ काटने का अधिकार किसे है, और वापसी कैसी दिखती है।
यहाँ मूल्य सुंदरता में नहीं, दोहराए जाने की क्षमता में है। जो बिल्ड सिर्फ़ अपने लेखक की मशीन पर सफल होती है, वह तकनीकी व्यवस्था के भेस में उस लेखक पर छिपी निर्भरता है।
तीसरे पक्ष की सेवाएँ: एनालिटिक्स, मेल, भुगतान, नक़्शे
साइट शायद ही अकेली खड़ी होती है। एनालिटिक्स प्रॉपर्टी, लेन-देन के मेल, फ़ॉर्म संभालना, भुगतान, नक़्शे, चैट विजेट — हर एक के पीछे एक खाता है, एक कुंजी है, और कोई है जिसके कार्ड से पैसे कटते हैं।
चार कॉलम की तालिका बनाएँ: सेवा, खाता, मालिक, कुंजी कहाँ रखी है। यह पन्ना उस दिन समय बचाता है जब इनमें से कोई सेवा बदलनी, दोबारा तय करनी या बंद करनी पड़े।
भुगतान में नियम सख़्त हैं। मर्चेंट खाता उस क़ानूनी इकाई का होता है जो पैसा लेती है, और उसे तकनीकी ब्योरे की तरह डेवलपर के पास खड़ा नहीं किया जा सकता। भुगतान लाइसेंसिंग Product Build के दायरे से बाहर है।
एनालिटिक्स की अपनी जाँच चाहिए: पुष्टि करें कि डेटा आपकी प्रॉपर्टी में उतरता है और प्रशासक अधिकार आपके हैं। वरना ठेकेदार बदलने पर वही इतिहास चला जाता है जिससे आप तुलना करने वाले थे।
दस्तावेज़: छोटे, पर वैकल्पिक नहीं
हैंडओवर का दस्तावेज़ सौ पन्नों की पुस्तिका नहीं है। यह रिपॉज़िटरी में एक README और एक पन्ने की कार्य-विधि है: साइट किन हिस्सों से बनी है, कहाँ चलती है, कैसे बिल्ड होती है, कैसे डिप्लॉय होती है, और किसे फ़ोन करना है।
जो नहीं किया गया और क्यों — उसकी सूची जोड़ें: टाला गया काम, ज्ञात सीमाएँ, जान-बूझकर स्वीकार किए गए समझौते। यह सूची चुप्पी से ईमानदार है और अगले ठेकेदार को हर फ़ैसला दोबारा खोजने से बचाती है।
वह सामग्री दर्ज करें जिस पर आपकी परफ़ॉर्मेंस जाँचें आधारित थीं। MDN Web Docs का Performance खंड लोडिंग की मापें और ब्राउज़र का व्यवहार बताता है, और उसकी ओर इशारा करना «तेज़» शब्द की मौखिक समझ से ज़्यादा टिकता है।
सुलभता भी इसी तरह। W3C की WCAG 2.2 त्वरित संदर्भिका सफलता मानदंडों को ऐसे रूप में सूचीबद्ध करती है जिसे जाँचा जा सके। अगर जाँचें हुई थीं, तो अनुरूपता का स्तर और उनसे ढके पेज नोट करें।
एक्सेस के बिना हैंडओवर का मतलब शून्य से शुरू करना क्यों है
एक्सेस न हो तो अगला ठेकेदार सोर्स कभी देखता ही नहीं और वही दोबारा बनाता है जो ब्राउज़र दिखाता है। लेआउट दोहराया जा सकता है; लॉजिक, इंटीग्रेशन और पैनल की कॉन्फ़िगरेशन बाहर से पढ़ी नहीं जा सकतीं।
तब उसके घंटे उस स्थिति को दोबारा बनाने में जाते हैं जो आपके पास पहले से है, उसे सुधारने में नहीं। आप उसी साइट का दूसरी बार भुगतान करते हैं जो आपके डोमेन पर बैठी है और चल रही है।
जोखिम सिर्फ़ आर्थिक नहीं है। रजिस्ट्रार खाते के बिना डोमेन चुपचाप समाप्त हो सकता है; होस्टिंग एक्सेस के बिना ठप साइट वापस नहीं लाई जा सकती; वेरिएबल की सूची के बिना सामान्य कुंजी-बदली सेवा-भंग बन जाती है।
एक्सेस के साथ हैंडओवर साइट को उस संपत्ति में बदल देता है जिसकी मालिक कंपनी है। उसके बिना साइट डेवलपर के बुनियादी ढाँचे का हिस्सा बनी रहती है, जिसे आप ऐसी शर्तों पर किराए पर लेते हैं जो कभी लिखी ही नहीं गईं।
VITON13 के पैकेजों में हैंडओवर कहाँ बैठता है
Site Fix Pack $70 का है और 1-2 कार्यदिवस लेता है: अधिकतम पाँच सहमत सुधार, मोबाइल और डेस्कटॉप जाँच, और हैंडओवर पर «पहले/बाद» सूची, 1 राउंड संशोधन के साथ। नए पेज, रीडिज़ाइन और माइग्रेशन शामिल नहीं।
Launch Site $380 का है, 3-5 कार्यदिवस: रिस्पॉन्सिव बिल्ड, बुनियादी CMS या डेटा कनेक्शन और डिप्लॉयमेंट सेटअप, लॉन्च से पहले 2 राउंड के साथ। कंटेंट और अनुवाद ग्राहक देता है — हम उन्हें नहीं लिखते।
Product Build $880 का है, 2-3 सप्ताह: फ़ीचर डिलीवरी, स्टेट और रूट लॉजिक, टेस्टिंग और हार्डनिंग, हर सौंपी गई फ़ीचर पर 2 राउंड के साथ। नेटिव मोबाइल ऐप और भुगतान लाइसेंसिंग उस दायरे से बाहर हैं।
Ongoing Dev Support $290/माह का है — प्राथमिक अपडेट, साप्ताहिक रिलीज़ लय और तकनीकी रखरखाव; यह मासिक चक्र पर चलता है, रोकने के लिए 30 दिन की सूचना चाहिए, काम की मात्रा हर चक्र की शुरुआत में तय होती है, और नई बिल्ड या रीडिज़ाइन का अनुमान अलग लगता है। Launch Site Express $520 का है, 2 कार्यदिवस: Launch Site का दायरा प्राथमिक कतार में, रोज़ाना बिल्ड, लॉन्च चेकलिस्ट और हैंडओवर कॉल के साथ, पहली पूरी बिल्ड के बाद 1 राउंड, जबकि कंटेंट, फ़ोटोग्राफ़ी और आगे का सपोर्ट शामिल नहीं।
मंज़ूरी देने से पहले क्या करें
जाँचें अंतिम भुगतान के बाद नहीं, पहले करें। एक्सेस माँगें, अपने ही उपकरण से अपने ही विवरण के साथ लॉगिन करें, और पुष्टि करें कि आप सेटिंग्स तक पहुँचते हैं, सिर्फ़ सार्वजनिक पेजों तक नहीं।
फिर रिपॉज़िटरी के साफ़ क्लोन से बिल्ड माँगें और उसे परीक्षण वातावरण में डिप्लॉय कराएँ। वेरिएबल की सूची इसी तरह जाँची जाती है: अगर कोई छूटा है, तो बिल्ड ख़ुद बता देगी।
सूची को अनुबंध में डालें: डोमेन, होस्टिंग, रिपॉज़िटरी, एडमिन पैनल, एनवायरनमेंट वेरिएबल, तीसरे पक्ष के खाते, दस्तावेज़। शर्त लागू कराई जा सकती है; «सब सौंप देंगे» की साझा समझ नहीं।
हर पैकेज का दायरा, अवधि और संशोधन राउंड की संख्या VITON13 डेवलपमेंट सेवा के पेज पर दी गई है। उस सूची से शुरू करना हैंडओवर की बातचीत को आश्वासनों के बजाय जाँचे जा सकने वाले बिंदुओं में बदल देता है।
व्यावहारिक चेकलिस्ट
- अपने ही विवरण से रजिस्ट्रार में लॉगिन करें और पंजीयक संपर्क तथा स्वतः-नवीनीकरण जाँचें।
- होस्टिंग खाते पर मालिक या प्रशासक अधिकार लें और DNS रिकॉर्ड का नक़्शा माँगें।
- रिपॉज़िटरी अपने खाते में लें और पुष्टि करें कि वह साफ़ क्लोन से बिल्ड होती है।
- भूमिकाओं सहित एडमिन खातों की सूची माँगें और स्वीकृति के दौरान ग़ैरज़रूरी खाते रद्द कराएँ।
- एनवायरनमेंट वेरिएबल मानों सहित इकट्ठा करें और कंपनी के पासवर्ड मैनेजर में रखें।
- सौंपे गए एक्सेस और दस्तावेज़ों की सूची अंतिम भुगतान से पहले अनुबंध में लिखवाएँ।
सवाल और जवाब
प्रोजेक्ट के अंत में ग्राहक को ठीक-ठीक क्या मिलना चाहिए?
डोमेन, होस्टिंग खाता, सोर्स कोड वाली रिपॉज़िटरी, एडमिन पैनल का मालिकाना लॉगिन और एनवायरनमेंट वेरिएबल उनके मानों सहित। इनके साथ तीसरे पक्ष के खातों की सूची और बिल्ड तथा डिप्लॉय पर छोटा दस्तावेज़ भी आना चाहिए।
डेवलपमेंट के काम की क़ीमत क्या है और उसके साथ क्या सौंपा जाता है?
Site Fix Pack $70 में 1-2 कार्यदिवस: अधिकतम पाँच सहमत सुधार, मोबाइल और डेस्कटॉप जाँच तथा हैंडओवर पर «पहले/बाद» सूची, 1 राउंड संशोधन के साथ। Launch Site $380 में 3-5 कार्यदिवस: रिस्पॉन्सिव बिल्ड, बुनियादी CMS या डेटा कनेक्शन और डिप्लॉयमेंट सेटअप, लॉन्च से पहले 2 राउंड के साथ।
क्या डोमेन डेवलपर के नाम रह सकता है?
तकनीकी रूप से रह सकता है, पर तब नवीनीकरण की तारीख़ और DNS रिकॉर्ड पर अधिकार आपके नियंत्रण से बाहर चले जाते हैं। डोमेन अपनी कंपनी के नाम पंजीकृत कराएँ और डेवलपर को इसके बजाय प्रत्यायोजित एक्सेस दें।
क्या रिपॉज़िटरी के बजाय फ़ाइलों का फ़ोल्डर काफ़ी है?
नहीं। आर्काइव में न बदलावों का इतिहास होता है, न ब्रांच, न किसी बदलाव और उसके पीछे के काम का संबंध — इसलिए अगला डेवलपर अंधेरे में काम करता है। आपको मालिक भूमिका के साथ अपने खाते में रिपॉज़िटरी चाहिए।
क्या मानों के बिना सिर्फ़ वेरिएबल के नामों की सूची काफ़ी है?
नहीं: मानों के बिना बिल्ड शुरू नहीं होगी, और बिना व्याख्या के मान छह महीने बाद समझे नहीं जा सकते। हर वेरिएबल के उद्देश्य सहित सूची और मान — दोनों अपने पासवर्ड मैनेजर के ज़रिए सौंपें।