क्लाइंट और एजेंसियों के लिए स्रोत कोड हैंडऑफ चेकलिस्ट

एक स्रोत कोड हैंडऑफ का उद्देश्य क्या होना चाहिए

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

किसी भी हैंडऑफ चेकलिस्ट का लक्ष्य सरल है: ट्रांसफर के बाद क्लाइंट बिना एजेंसी को कॉल पर रखे ही प्रोडक्ट को बिल्ड, रन और डिप्लॉय कर सके। इसका अर्थ यह नहीं है कि "कभी समर्थन नहीं चाहिए।" मतलब बेसिक्स रेपिटेबल और दस्तावेजीकृत हों, ताकि अगला व्यक्ति आत्मविश्वास के साथ काम सम्भाल सके।

डिलिवरेबल्स क्या होंगे यह स्पष्ट होना चाहिए। न्यूनतम रूप से, एक पूरा हैंडऑफ आमतौर पर शामिल करता है:

• पूरा रिपॉजिटरी (डिप्लॉयमेंट फाइलें और माइग्रेशन स्क्रिप्ट्स सहित)
• सेटअप डॉक्स जो क्लीन मशीन पर काम करें
• एक्सेस हैंडओवर (खाते, अनुमतियाँ, और सिस्टम कहाँ चलता है)
• रूटीन कार्यों के लिए रनबुक (डिप्लॉय, रोलबैक, बैकअप, लॉग्स)
• एक अंतिम "known-good" वर्जन टैग या स्नैपशॉट जिसे क्लाइंट संदर्भ के रूप में उपयोग करे

स्कोप भी उतना ही मायने रखता है जितना कंटेंट। कुछ हैंडऑफ सिर्फ एक एनवायरनमेंट (जैसे प्रोडक्शन) को कवर करते हैं। अन्य में dev, staging, और production अलग सेटिंग्स और प्रक्रियाओं के साथ शामिल होते हैं। यदि आप यह नहीं बताते कि कौन से एनवायरनमेंट कवर हैं, तो लोग अलग-अलग धारणाएँ बना लेते हैं और यहीं से आउटेज होते हैं।

सफलता को परिभाषित करने का एक व्यवहारिक तरीका वेरिफिकेशन टेस्ट है: कोई ऐसा व्यक्ति जिसने ऐप नहीं बनाया, कोड एक्सपोर्ट कर सके (उदाहरण के लिए किसी प्लेटफ़ॉर्म जैसे Koder.ai से), डॉक्‍स का पालन करे, एनवायरनमेंट वेरिएबल सेट करे, माइग्रेशन चलाए, बिल्ड करे, और सहमत एनवायरनमेंट में डिप्लॉय कर सके।

यह चेकलिस्ट तकनीकी रेडिनेस पर केंद्रित है: एनवायरनमेंट वेरिएबल, सीक्रेट रोटेशन, डेटाबेस माइग्रेशन, डिप्लॉयमेंट स्क्रिप्ट्स, और बिल्ड सत्यापन। यह कानूनी शर्तें, कॉन्ट्रैक्ट, IP क्लॉज, या पेमेंट विवादों को कवर नहीं करता। वे भी महत्वपूर्ण हैं, पर अलग समझौते में होने चाहिए।

एक्सपोर्ट से पहले: मालिकाना और समय पर सहमति

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

हैंडऑफ तारीख और छोटा फ्रीज़ विंडो तय करें

एक हैंडऑफ तारीख चुनें और एक फ्रीज़ विंडो परिभाषित करें (आमतौर पर 24–72 घंटे) जहाँ केवल आवश्यक फिक्स ही जाएँ। इससे एक्सपोर्ट किया गया कोड और चल रहा सिस्टम सिंक में रहता है। यदि फ्रीज़ के दौरान हॉटफिक्स चाहिए, तो क्या बदला यह लिख लें और सुनिश्चित करें कि वह फाइनल एक्सपोर्ट में शामिल हो।

खाते और बिलिंग की जिम्मेदारी स्पष्ट करें

निर्धारित करें कि DNS, क्लाउड होस्टिंग, और किसी भी पेड सर्विस के मालिक कौन होंगे हैंडऑफ के बाद। यह सिर्फ कागजी कार्य नहीं है। यदि बिलिंग एजेंसी के कार्ड पर रहती है, तो सेवाएँ बिना चेतावनी के रोकी जा सकती हैं।

इसे ठोस बनाने के लिए:

• DNS, होस्टिंग, और ईमेल के लिए अकाउंट ओनर का नाम बताएं
• हैंडऑफ तारीख से कौन प्रत्येक बिल का भुगतान करेगा, इसकी पुष्टि करें
• तय करें कि खाते स्थानांतरित किए जाएँ या क्लाइंट के नाम से नए बनाए जाएँ
• हर प्रोवाइडर के लिए सपोर्ट संपर्क रिकॉर्ड करें

इसे सरल भाषा में लिखें ताकि दोनों पक्ष आसानी से अनुसरण कर सकें।

एनवायरनमेंट और वे कहाँ चलते हैं सूचीबद्ध करें

निर्धारित करें कि कौन-कौन से एनवायरनमेंट मौजूद हैं (local, staging, production) और प्रत्येक कहाँ चल रहा है। यह नोट करें कि क्या staging एक अलग सर्वर है, अलग डेटाबेस है, या सिर्फ एक फ़ीचर फ्लैग है। यदि आपने किसी प्लेटफ़ॉर्म जैसे Koder.ai का उपयोग किया है, तो यह भी कन्फर्म करें कि वहाँ क्या होस्ट किया गया है बनाम क्या क्लाइंट की इंफ्रास्ट्रक्चर में एक्सपेक्टेड है।

एक्सेस पहले ही इकट्ठा करें

आख़िरी दिन तक एक्सेस का इंतजार न करें। सुनिश्चित करें कि सही लोग जिन चीज़ों तक पहुँचने की जरूरत है—repo, CI, होस्टिंग, डेटाबेस, और ईमेल प्रोवाइडर—उन तक पहुँच रखते हैं।

अंत में फाइनल एक्सेप्टेंस टेस्ट और साइन-ऑफ प्रक्रिया पर भी सहमति करें। उदाहरण: “क्लाइंट क्लीन मशीन से बिल्ड कर सके, माइग्रेशन चला सके, स्टेजिंग पर डिप्लॉय कर सके, और स्मोक टेस्ट पास करे। फिर दोनों पक्ष लिखित में साइन-ऑफ करें।”

रिपो और डॉक्यूमेंटेशन के बेसिक्स

एक अच्छी स्रोत कोड हैंडऑफ चेकलिस्ट एक ऐसे रिपो से शुरू होती है जिसे नई टीम कुछ ही मिनटों में खोलकर समझ सके। पुष्टि करें कि क्या शामिल है (एप कोड, कॉन्फ़िग टेम्पलेट्स, स्क्रिप्ट्स) और क्या जानबूझकर बाहर रखा गया है (असली सीक्रेट्स, प्राइवेट 키, बड़े जनरेटेड फाइल्स)। यदि कुछ एक्सक्लूड किया गया है, तो बताएं कि वह कहाँ रहता है और किसका मालिक है।

स्ट्रक्चर को प्रेडिक्टेबल रखें। स्पष्ट टॉप-लेवल फोल्डर्स जैसे frontend/, backend/, mobile/, infra/, scripts/, और docs/ का लक्ष्य रखें। यदि प्रोजेक्ट मोनोरेपो है, तो समझाएँ कि पार्ट्स कैसे जुड़े हैं और प्रत्येक को कैसे चलाना है।

आपका README उस व्यक्ति द्वारा उपयोग के योग्य होना चाहिए जिसने प्रोजेक्ट नहीं बनाया। इसमें प्रीक्विज़िट्स और कामकाजी डेवलप रन तक पहुँचने का सबसे तेज़ तरीका होना चाहिए, बिना अनुमान के।

क्या दस्तावेज़ करें (न्यूनतम)

एक छोटा, मानवीय README सेक्शन शामिल करें जो इन सवालों का उत्तर दे:

• यह रिपो क्या रखता है और यह क्या करता है (एक पैरा)
• प्रीक्विज़िट्स के साथ सटीक वर्ज़न (रनटाइम, पैकेज मैनेजर, Docker अगर ज़रूरी हो)
• लोकल डेवलप के लिए एक-कमांड स्टार्ट स्टेप्स (और “सफलता” क्या दिखती है)
• टेस्ट कैसे चलाएँ और प्रोडक्शन आर्टिफैक्ट कैसे बनाएं
• मुख्य डॉक्स कहाँ मिलेंगे: आर्किटेक्चर नोट्स, माइग्रेशन, डिप्लॉयमेंट नोट्स

साधारण भाषा में छोटे आर्किटेक्चर नोट्स जोड़ें: क्या किससे बात करता है और क्यों। एक छोटा डायग्राम वैकल्पिक है, लेकिन कुछ वाक्य अक्सर पर्याप्त होते हैं। उदाहरण: “React frontend Go API को कॉल करता है। API PostgreSQL पढ़ता/लिखता है। बैकग्राउंड जॉब्स अलग वर्कर प्रोसेस के रूप में चलते हैं।”

अंत में, हैंडऑफ बिल्ड के लिए एक वर्ज़नड चेंज्लॉग या रिलीज नोट्स शामिल करें। यह CHANGELOG.md हो सकता है या एक छोटा “handoff release notes” फाइल जिसमें सटीक commit/tag, क्या शिप हुआ, और ज्ञात समस्याएँ हों।

यदि कोड किसी प्लेटफ़ॉर्म जैसे Koder.ai से एक्सपोर्ट किया गया था, तो जेनरेटेड प्रोजेक्ट टाइप (web, server, mobile), अपेक्षित टूलचेन (जैसे React, Go, PostgreSQL, Flutter), और समर्थित OS/टूलिंग वर्ज़न नोट करें ताकि क्लाइंट बिल्ड को पुन: उत्पन्न कर सके।

एनवायरनमेंट वेरिएबल: इन्वेंटरी और डॉक्यूमेंटेशन

एनवायरनमेंट वेरिएबल अक्सर कारण होते हैं कि हैंडऑफ के ठीक बाद “वर्किंग ऐप” फ़ैल हो जाता है। एक अच्छी हैंडऑफ चेकलिस्ट उन्हें प्रोडक्ट का हिस्सा समझती है, न कि बाद की बात।

एक इन्वेंटरी लिखकर शुरू करें जिसे नई टीम अनुमान लगाए बिना फ़ॉलो कर सके। इसे सरल भाषा में रखें और उदाहरण मान का फॉर्मेट शामिल करें (असली सीक्रेट नहीं)। यदि कोई वैरिएबल ऑप्शनल है, तो बताएं कि गायब होने पर क्या होता है और कौन सा डिफॉल्ट उपयोग होता है।

प्रस्तुत करने का एक आसान तरीका यह है:

• वैरिएबल का नाम, यह क्या नियंत्रित करता है, और एक उदाहरण फॉर्मेट
• आवश्यक बनाम वैकल्पिक, और कोई डिफॉल्ट व्यवहार
• यह कहाँ सेट होता है (CI, होस्टिंग डैशबोर्ड, लोकल .env फाइल)
• किस एनवायरनमेंट में अलग वैल्यू चाहिए (dev, staging, production)
• परिवर्तन के लिए जिम्मेदार कौन है (क्लाइंट, एजेंसी, या साझा)

एनवायरनमेंट-विशिष्ट अंतर स्पष्ट रूप से बताएं। उदाहरण के लिए, staging टेस्ट डेटाबेस और सैंडबॉक्स पेमेंट प्रोवाइडर की ओर पॉइंट कर सकता है, जबकि प्रोडक्शन लाइव सर्विसेस उपयोग करता है। साथ ही उन मूल्यों को नोट करें जिन्हें सिस्टमों के बीच मेल खाना चाहिए, जैसे callback URLs, allowed origins, या मोबाइल ऐप बंडल आईडेंटिफायर्स।

वर्तमान में प्रत्येक वैल्यू कहाँ रहती है यह दस्तावेज करें। कई टीमें मानwerte अलग-अलग जगह रखती हैं: डेवलपमेंट के लिए लोकल .env फाइलें, बिल्ड्स के लिए CI वेरिएबल्स, और रनटाइम के लिए होस्टिंग सेटिंग्स। यदि आपने Koder.ai से प्रोजेक्ट एक्सपोर्ट किया है, तो .env.example फाइल और एक छोटा नोट शामिल करें कि किस वैरिएबल को पहले बिल्ड से पहले भरना ज़रूरी है।

अंत में, यह साबित करें कि रिपो में कोई सीक्रेट छिपा नहीं है। सिर्फ वर्तमान फाइलों की जाँच न करें। कमिट इतिहास की भी समीक्षा करें ताकि गलती से डाले गए कीज़, पुराने .env फाइल्स, या सैंपल कॉन्फ़िग्स में कॉपी किए गए क्रेडेंशियल्स मिल सकें।

उदाहरण: एक React फ्रंटएंड और Go API को API_BASE_URL (वेब ऐप के लिए) और DATABASE_URL तथा JWT_SIGNING_KEY (बैकएंड के लिए) की ज़रूरत पड़ सकती है। यदि staging अलग डोमेन उपयोग करता है, तो दोनों वैल्यूस लिखें और बताएं कहाँ बदलना है, ताकि नई टीम स्टेजिंग सेटिंग्स प्रोडक्शन में न भेज दे।

सीक्रेट रोटेशन: सुरक्षित रूप से ट्रांसफर करें, फिर प्रमाणित करें

हैंडऑफ तब तक पूरा नहीं होता जब तक क्लाइंट हर क्रेडेंशियल का नियंत्रण नहीं ले लेता। इसका मतलब है सीक्रेट्स को रोटेट करना, सिर्फ शेयर नहीं करना। यदि एजेंसी (या पूर्व ठेकेदार) के पास अभी भी काम कर रही कीज़ हैं, तो आपके पास ऑडिट करने के लिए खुला रास्ता होगा।

पूरी इन्वेंटरी बनाकर शुरू करें। सिर्फ डेटाबेस पासवर्ड पर नहीं रुकें। तीसरे पक्ष की API कीज़, OAuth क्लाइंट सीक्रेट्स, webhook सिग्निंग सीक्रेट्स, JWT साइनिंग कीज़, SMTP क्रेडेंशियल्स, स्टोरेज एक्सेस कीज़, और CI में रखे गए किसी भी “टेम्पररी” टोकन को शामिल करें।

रोटेशन डे के लिए एक सरल चेकलिस्ट:

• हर सीक्रेट की सूची बनाएं, यह क्या अनलॉक करता है, और यह वर्तमान में कहाँ सेट है (लोकल env फाइल्स, CI, होस्टिंग डैशबोर्ड, वॉल्ट)
• क्लाइंट के खातों के अंतर्गत नई क्रेडेंशियल बनाएं, और हर एक के लिए एक मालिक निर्धारित करें (व्यक्ति और टीम इनबॉक्स)
• ऐप कॉन्फ़िग को नई वैल्यूज़ से अपडेट करें, फिर पहले स्टेजिंग या टेस्ट एनवायरनमेंट में डिप्लॉय करें
• नई वैल्यूज़ काम करने के बाद पुराने क्रेडेंशियल्स को तुरंत रिवोक करें
• अगली रोटेशन प्रक्रिया को आसान और तेज़ बनाने के लिए सटीक रोटेशन स्टेप्स लिखें

रोटेशन के बाद, साबित करें कि कुछ भी टूट नहीं गया। केवल लॉग जांचने के बजाय त्वरित "रियल यूजर" टेस्ट चलाएँ।

उन फ्लोज़ पर ध्यान दें जो सीक्रेट्स पर निर्भर हैं:

• लॉगिन, साइनअप, पासवर्ड रीसेट, और टोकन रिफ्रेश
• पेमेंट्स, ईमेल भेजना, और फ़ाइल अपलोड
• वेबहुक्स (सिग्नेचर सत्यापन और रिट्राई हैंडलिंग)
• बैकग्राउंड जॉब्स या शेड्यूल्ड टास्क जो एक्सटर्नल APIs को कॉल करते हैं
• ऐसे एडमिन एक्शन्स जो प्रिविलेज्ड एंडपॉइंट्स को हिट करते हैं

उदाहरण: यदि आपने Koder.ai से प्रोजेक्ट एक्सपोर्ट किया है और ऐप एक पेमेंट प्रोवाइडर और ईमेल डिलीवरी उपयोग करता है, तो दोनों कीज़ रोटेट करें, फिर redeploy करें, और एक छोटा टेस्ट ट्रांज़ैक्शन प्लेस करें और एक टेस्ट ईमेल भेजें। केवल इन सफलताओं के बाद ही एजेंसी-ओन्ड कीज़ को रिवोक करें।

अंत में, दस्तावेज करें कि आगे सीक्रेट्स कहाँ रखेंगे (वॉल्ट, CI वेरिएबल्स, या होस्टिंग सेटिंग्स), कौन बदल सकता है, और यदि रोटेशन में त्रुटि आये तो कैसे सुरक्षित रूप से रोलबैक करें।

डेटाबेस माइग्रेशन्स और डेटा हैंडलिंग

हैंडऑफ "पूरा हुआ" दिख सकता है जबकि डेटाबेस वह हिस्सा है जो सबसे पहले टूटता है। माइग्रेशन्स और डेटा को अपने आप में एक प्रोडक्ट मानें: वर्ज़न्ड, रेपिटेबल, और टेस्टेड।

शुरू में वर्तमान डेटाबेस वर्ज़न और माइग्रेशन्स रिपो में कहाँ हैं यह लिखें। विशेष रूप से बताएं: फोल्डर पाथ, नेमिंग पैटर्न, और नवीनतम माइग्रेशन ID (या टाइमस्टैम्प)। यदि आप PostgreSQL इस्तेमाल कर रहे हैं (Go बैकएंड के साथ सामान्य), तो किसी आवश्यक एक्सटेंशन का भी उल्लेख करें।

क्या दस्तावेज़ करें (ताकि कोई और चला सके)

एक छोटा रनबुक शामिल करें जो इन प्रश्नों का उत्तर दे:

• कौन सा कमांड माइग्रेशन्स चलाता है, और चीज़ें किस क्रम में चलानी हैं (डेटाबेस बनाओ, माइग्रेशन्स लागू करो, फिर सीड्स)
• यह एनवायरनमेंट के हिसाब से कैसे अलग होता है (local, staging, production), और कोई “सेफ़ मोड” फ्लैग
• क्या माइग्रेशन्स डिप्लॉय पर ऑटोमेटिक हैं या मैन्युअली रन करने होते हैं, और किसे अनुमति है
• सीड डेटा रणनीति: कोई नहीं, सिर्फ डेमो, या न्यूनतम जरूरी रिकॉर्ड (एडमिन यूजर, डिफॉल्ट सेटिंग्स)
• रोलबैक प्लान: क्या उल्टा किया जा सकता है और क्या नहीं (उदाहरण: विनाशकारी कॉलम ड्रॉप)

रोलबैक के बारे में ईमानदार रहें। कुछ बदलाव केवल बैकअप रीस्टोर के साथ ही उल्टे जा सकते हैं। इसे स्पष्ट रूप से बताएं और एक बैकअप स्टेप (डिप्लॉय से पहले स्नैपशॉट, रीस्टोर प्रक्रिया को सत्यापित करना) के साथ जोड़ें।

हैंडऑफ पूरा होने से पहले, संभव हो तो प्रोडक्शन डेटा की एक कॉपी पर माइग्रेशन्स चलाएँ। इससे धीमे क्वेरीज़, ग़ायब इंडेक्स, और "खाली डेटा पर काम करता है" जैसी समस्याएँ पकड़ी जाती हैं। एक वास्तविक परीक्षण है: कोड एक्सपोर्ट करें, एनवायरनमेंट वेरिएबल सेट करें, एनोनीमाइज़्ड डंप रीस्टोर करें, फिर माइग्रेशन्स को स्क्रैच से लागू करें। यह अभ्यास किसी भी हैंडऑफ चेकलिस्ट के बड़े हिस्से को मान्य करता है।

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

बिल्ड और CI: इसे दोहराने योग्य बनाएं

हैंडऑफ तभी पूरा होता है जब कोई और क्लीन मशीन पर स्क्रैच से ऐप को फिर से बिल्ड कर सके। आपकी हैंडऑफ चेकलिस्ट में सटीक बिल्ड कमांड्स, आवश्यक वर्ज़न, और अपेक्षित आउटपुट (उदा.: “web bundle /dist में”, “API बाइनरी का नाम”, “Flutter APK स्थान”) शामिल होना चाहिए।

वास्तविक में जो टूल्स और पैकेज मैनेजर आप उपयोग करते हैं उन्हें लिखें, न कि जो आप सोचते हैं कि आप उपयोग करते हैं। सामान्य स्टैक के लिए यह Node.js (npm या pnpm) React वेब ऐप के लिए, सर्वर के लिए Go टूलचेन, लोकल सेटअप के लिए PostgreSQL क्लाइंट टूल्स, और मोबाइल के लिए Flutter SDK हो सकते हैं।

डिपेंडेन्सी इंस्टॉल को प्रेडिक्टेबल बनाएं। लॉकफाइल्स कमिट हैं यह सुनिश्चित करें (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) और एक नई मशीन या क्लीन कंटेनर पर फ्रेश इंस्टॉल करके साबित करें कि यह काम करता है।

CI जो करता है उसे स्टेप बाय स्टेप कैप्चर करें ताकि इसे किसी और CI प्रोवाइडर पर कॉपी किया जा सके:

• डिपेंडेन्सीज़ इंस्टॉल करें (लॉकफाइल्स के साथ)
• टेस्ट और लिंट चेक चलाएँ
• बिल्ड आउटपुट्स (वेब बंडल, सर्वर बाइनरी, मोबाइल बिल्ड)
• आर्टिफैक्ट्स तैयार करें (zip, Docker image, रिलीज बंडल)
• लॉग्स और बिल्ड मेटाडेटा स्टोर करें (वर्ज़न, कमिट, तारीख)

बिल्ड-टाइम कॉन्फ़िग को रन-टाइम कॉन्फ़िग से अलग रखें। बिल्ड-टाइम कॉन्फ़िग उस चीज़ को बदलती है जो कंपाइल होती है (जैसे API बेस URL वेब बंडल में बेक हो जाना)। रन-टाइम कॉन्फ़िग स्टार्ट होने पर इंजेक्ट की जाती है (जैसे डेटाबेस URLs, API कीज़, फीचर फ्लैग्स)। इनका मिक्स होना आम वजह है कि "CI पर काम करता है" पर डिप्लॉय के बाद फ़ेल हो जाता है।

एक सरल लोकल सत्यापन रेसिपी दें। यहाँ कुछ कमांड्स का छोटा सेट ही पर्याप्त है:

# Web
pnpm install
pnpm test
pnpm build

# API
go test ./...
go build ./cmd/server

# Mobile
flutter pub get
flutter test
flutter build apk

यदि आप Koder.ai से एक्सपोर्ट कर रहे हैं, तो किसी भी जेनरेटेड CI फाइल्स या बिल्ड प्रीसेट्स को शामिल करें जो डिप्लॉय के दौरान उपयोग हुए थे ताकि क्लाइंट प्लेटफ़ॉर्म के बाहर भी वही बिल्ड पुन: उत्पन्न कर सके।

डिप्लॉयमेंट स्क्रिप्ट्स और रिलीज प्रोसेस

एक अच्छी हैंडऑफ चेकलिस्ट सिर्फ "यहाँ रिपो है" पर नहीं रुकती। यह यह भी समझाती है कि सोर्स से चलती सर्विस तक ऐप कैसे जाता है, और कौन बटन दबाता है।

शुरू में यह लिखें कि आज डिप्लॉयमेंट कैसे होते हैं: पूरा मैन्युअल (कोई सर्वर पर कमांड चलाता है), CI-ड्रिवन (पाइपलाइन बिल्ड करके डिप्लॉय करती है), या होस्टेड प्लेटफ़ॉर्म के जरिए। बताएं कि कॉन्फ़िग कहाँ रहती है, और कौन से एनवायरनमेंट मौजूद हैं (dev, staging, production)।

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

डिप्लॉयमेंट पैकेज के साथ क्या शामिल करें

क्लाइंट को पहले दिन ही डिप्लॉय करने के लिए पर्याप्त दें:

• बिल्ड और रन कमांड्स (और Node, Go, Flutter आदि के सटीक वर्ज़न)
• डिप्लॉयमेंट स्क्रिप्ट्स (शेल स्क्रिप्ट्स, Makefile टार्गेट्स, या पाइपलाइन कॉन्फ़िग)
• आवश्यक एक्सेस: क्लाउड अकाउंट रोल्स, कंटेनर रजिस्ट्रि, DNS, डेटाबेस एडमिन
• एनवायरनमेंट सेटअप नोट्स: कहाँ env vars सेट हैं और प्रत्येक एनव में कैसे भिन्न हैं
• रिलीज नामकरण: टैग/रिलीज़ और यह कैसे पहचानें कि क्या चल रहा है

डाउनटाइम की उम्मीदों पर सहमति करें। यदि "जीरो डाउनटाइम" चाहिए, तो व्यावहारिक रूप से इसका अर्थ क्या है (blue-green, rolling deploy, migrations के लिए read-only विंडो) बताएं। यदि डाउनटाइम स्वीकार्य है, तो स्पष्ट विंडो पर सहमत हों।

स्टेटिक एसेट्स और कैशेस सामान्य विफलता बिंदु हैं। लिखें कि एसेट्स कब और कैसे बनते हैं, कब कैश बस्ट करना है, और क्या CDN शामिल है।

व्यवहारिक रोलबैक

रोलबैक एक छोटा, टेस्टेड रेसिपी होना चाहिए जो किसी टैग या रिलीज ID से जुड़ी हो। उदाहरण: पिछला टैग डिप्लॉय करें, आवश्यक हो तो पिछला डेटाबेस स्नैपशॉट रीस्टोर करें, और कैशेस को इनवैलीडेट करें।

यदि ऐप Koder.ai पर बनाया गया था और फिर एक्सपोर्ट किया गया, तो आखिरी ज्ञात अच्छी स्नैपशॉट और सटीक एक्सपोर्ट वर्ज़न का उल्लेख करें ताकि क्लाइंट तेज़ी से कोड को वर्किंग रिलीज़ से मिलान कर सके।

चरण-दर-चरण: एक्सपोर्ट के बाद बिल्ड सत्यापित करें

वेरिफिकेशन वह क्षण है जब आप जान पाते हैं कि हैंडऑफ वास्तविक है या नहीं। लक्ष्य सरल है: कोई नई व्यक्ति एक्सपोर्ट किया हुआ कोड लेकर उसे सेटअप कर सके और बिना अनुमान के वही ऐप चला सके।

शुरू करने से पहले रिकॉर्ड करें कि "सही" क्या दिखता है: रनिंग ऐप का वर्ज़न, वर्तमान commit/tag (यदि है), और एक-दो मुख्य स्क्रीन या API रिस्पांस जिन्हें तुलना के लिए उपयोग किया जाएगा। यदि एक्सपोर्ट किसी प्लेटफ़ॉर्म जैसे Koder.ai से आया है, तो स्नैपशॉट या एक्सपोर्ट टाइमस्टैम्प नोट करें ताकि आप पुष्टि कर सकें कि आपने नवीनतम स्थिति को टेस्ट किया।

1. पुष्टि करें कि एक्सपोर्ट प्रोडक्शन से मेल खाता है: कमिट इतिहास, रिलीज नोट्स, या बिल्ड मेटाडेटा चेक करें। रनिंग ऐप के किसी दिखाई देने वाले वर्ज़न स्ट्रिंग या छोटे व्यवहार की तुलना करें।
2. एनवायरनमेंट वेरिएबल्स और सीक्रेट्स सेट करें: टारगेट एनवायरनमेंट कॉन्फ़िग बनाएँ (लोकल और स्टेजिंग)। दी गई एनव इन्वेंटरी का उपयोग करें और सुनिश्चित करें कि कुछ भी हार्ड-कोडेड न हो।
3. डिपेंडेन्सीज इंस्टॉल करें और टेस्ट चलाएँ: एक क्लीन इंस्टॉल करें (कोई कैश्ड node_modules/vendor फोल्डर नहीं)। यूनिट टेस्ट और किसी भी लिंट चेक्स को उसी तरह चलाएँ जैसा डॉक्यूमेंट में बताया गया है।
4. माइग्रेशन्स चलाएँ और लोकली स्टार्ट करें: डेटाबेस उठाएँ, माइग्रेशन्स क्रम से लागू करें, और ऐप स्टार्ट करें। पुष्टि करें कि ऐप बेसिक डेटा पढ़/लिख सकता है और कोई पेंडिंग माइग्रेशन्स नहीं हैं।
5. स्टेजिंग पर डिप्लॉय करें, स्मोक टेस्ट करें, फिर प्रमोट करें: उसी स्क्रिप्ट/पाइपलाइन का उपयोग करके डिप्लॉय करें जिसे आप प्रोडक्शन में भी उपयोग कर रहे हैं। केवल तभी प्रमोट करें जब स्टेजिंग अपेक्षाओं से मेल खाए।

स्मोक टेस्ट्स संक्षिप्त रखें और जोखिम से जुड़े रहें:

• लॉग इन/आउट (या टेस्ट यूजर बनाना)
• एक मुख्य वर्कफ़्लो एंड-टू-एंड (create-edit-save)
• एक ईमेल/वेबहुक/पेमेंट कॉलबैक यदि लागू हो
• बेसिक एरर हैंडलिंग (खराब इनपुट, मिसिंग रिकॉर्ड)
• लॉग्स में दोहराए गए क्रैशेस या सीक्रेट-सम्बन्धी एरर न दिखें

यदि कुछ भी फेल होता है, तो सटीक कमांड, एरर आउटपुट, और उपयोग किए गए एनव वेरिएबल्स कैप्चर करें। यह विवरण ओनरशिप बदलने पर घंटों बचा सकता है।

सामान्य हैंडऑफ गलतियाँ और उनसे कैसे बचें

हैंडऑफ को फायर ड्रिल में बदलने का सबसे तेज़ तरीका यह मान लेना है कि "कोड ही काफी है।" एक अच्छी हैंडऑफ चेकलिस्ट उन छोटे, बोरिंग डिटेल्स पर फोकस करती है जो यह तय करते हैं कि क्लाइंट वास्तव में ऐप चला और बदल सके बिना आपकी मदद के।

वे गलतियाँ जो ज़्यादातर हैंडऑफ सिरदर्द पैदा करती हैं

अधिकतर समस्याएँ कुछ ही पैटर्न में आती हैं:

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

इन्हें कैसे रोकें (सप्ताहों जोड़ें बिना)

रोटेशन और एक्सेस क्लीनअप को कोई "जब समय हो" वाला आइटम न बनाएं—इसे शेड्यूल करें। एक तारीख तय करें जब एजेंसी खाते हटा दिए जाएँगे, सर्विस कीज़ फिर से जेनरेट होंगी, और क्लाइंट की पुष्टि करे कि वे केवल अपने क्रेडेंशियल्स से डिप्लॉय कर सकते हैं।

एनव वेरिएबल्स के लिए, रिपो, CI सिस्टम, और होस्टिंग UI—इन तीन जगहों से एक सरल इन्वेंटरी बनाएं। फिर इसे प्रमाणित करें एक फ्रेश मशीन या कंटेनर से क्लीन बिल्ड चलाकर।

माइग्रेशन्स के लिए, उसी डेटाबेस रोल के साथ टेस्ट करें जिसे प्रोडक्शन डिप्लॉय उपयोग करेगा। यदि प्रोडक्शन में एलीवेटेड स्टेप्स चाहिए (जैसे एक्सटेंशन एनेबल करना), तो उन्हें लिखें और मालिकाना स्पष्ट करें।

एक वास्तविक उदाहरण: Koder.ai से एक्सपोर्ट करने के बाद, क्लाइंट सफलतापूर्वक डिप्लॉय करता है पर बैकग्राउंड जॉब्स फेल होते हैं क्योंकि एक क्यू URL सिर्फ होस्टिंग डैशबोर्ड में सेट था। एक सरल एनव ऑडिट इसे पकड़ लेता। इसे टैग्ड रिलीज और डॉक्यूमेंटेड रोलबैक (उदा., "redeploy tag v1.8.2 और अंतिम स्नैपशॉट रीस्टोर करें") के साथ जोड़ें और टीम डाउनटाइम से बचती है।

अंतिम चेकलिस्ट, एक सरल उदाहरण, और अगले कदम

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

त्वरित जाँच (इन्हें फ्रेश क्लोन से करें)

इन जाँचों को एक लैपटॉप पर चलाएँ जिसने कभी प्रोजेक्ट नहीं देखा हो (या एक क्लीन कंटेनर/VM में)। यही सबसे तेज़ तरीका है गायब फाइल्स, छिपी धारणाएँ, और पुराने क्रेडेंशियल्स पकड़ने का।

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

एक सरल हैंडऑफ उदाहरण

एक एजेंसी React फ्रंटएंड, Go API, और PostgreSQL डेटाबेस हैंडऑफ करती है। क्लाइंट टीम रिपो क्लोन करती है, प्रदान किए गए .env.example को वास्तविक एनव वेरिएबल्स में कॉपी करती है, और डेटाबेस, ईमेल प्रोवाइडर, और किसी भी थर्ड-पार्टी API के लिए नए क्रेडेंशियल बनाती है। वे go test (या सहमति किया गया टेस्ट कमांड) चलाते हैं, React ऐप बनाते हैं, माइग्रेशन्स को एक नए Postgres इंस्टेंस पर लागू करते हैं, और दोनों सेवाओं को स्टार्ट करते हैं। अंत में, वे डॉक्यूमेंटेड स्क्रिप्ट से डिप्लॉय करते हैं और पुष्टि करते हैं कि वही कमिट बाद में दोबारा बिल्ड किया जा सकता है।

अगले कदम

हैंडऑफ को संक्षिप्त और स्वामित्व वाला रखें। 30–60 मिनट का वॉकथ्रू अक्सर लंबी डाक्यूमेंटेशन से बेहतर होता है।

• एक वॉकथ्रू शेड्यूल करें और निर्णय रिकॉर्ड करें (कौन डिप्लॉय, सीक्रेट्स, और डेटाबेस परिवर्तनों का मालिक है)।
• प्रोडक्शन एक्सेस के लिए एक मालिक और एक बैकअप असाइन करें।
• एक अंतिम “acceptance build” commit hash पर सहमति करें और उसे टैग करें।
• यदि आपने Koder.ai में बनाया है, तो स्रोत कोड एक्सपोर्ट करें, फिर पहले क्लाइंट-रन डिप्लॉयमेंट के दौरान स्नैपशॉट और रोलबैक का उपयोग करें ताकि जोखिम कम हो।