इस स्रोत कोड हैंडऑफ चेकलिस्ट का उपयोग करके कोड एक्सपोर्ट करें, डॉक्यूमेंट करें, सीक्रेट्स रोटेट करें, माइग्रेशन्स चलाएँ, बिल्ड सत्यापित करें, और क्लाइंट के साथ डिप्लॉयमेंट मालिकाना कन्फर्म करें।

एक स्रोत कोड हैंडऑफ वह पल है जब प्रोजेक्ट "एजेंसी चला सकती है" से बदलकर "क्लाइंट के पास सुरक्षित रूप से होगा" बन जाता है। स्पष्ट हैंडऑफ के बिना जल्दी ही सामान्य समस्याएँ सामने आती हैं: ऐप केवल एक लैपटॉप पर बनता है, प्रोडक्शन किसी गुप्त कुंजी पर निर्भर है जो किसी के पास नहीं है, या एक छोटा अपडेट दिनों तक अनुमान लगाने का काम बन जाता है।
किसी भी हैंडऑफ चेकलिस्ट का लक्ष्य सरल है: ट्रांसफर के बाद क्लाइंट बिना एजेंसी को कॉल पर रखे ही प्रोडक्ट को बिल्ड, रन और डिप्लॉय कर सके। इसका अर्थ यह नहीं है कि "कभी समर्थन नहीं चाहिए।" मतलब बेसिक्स रेपिटेबल और दस्तावेजीकृत हों, ताकि अगला व्यक्ति आत्मविश्वास के साथ काम सम्भाल सके।
डिलिवरेबल्स क्या होंगे यह स्पष्ट होना चाहिए। न्यूनतम रूप से, एक पूरा हैंडऑफ आमतौर पर शामिल करता है:
स्कोप भी उतना ही मायने रखता है जितना कंटेंट। कुछ हैंडऑफ सिर्फ एक एनवायरनमेंट (जैसे प्रोडक्शन) को कवर करते हैं। अन्य में dev, staging, और production अलग सेटिंग्स और प्रक्रियाओं के साथ शामिल होते हैं। यदि आप यह नहीं बताते कि कौन से एनवायरनमेंट कवर हैं, तो लोग अलग-अलग धारणाएँ बना लेते हैं और यहीं से आउटेज होते हैं।
सफलता को परिभाषित करने का एक व्यवहारिक तरीका वेरिफिकेशन टेस्ट है: कोई ऐसा व्यक्ति जिसने ऐप नहीं बनाया, कोड एक्सपोर्ट कर सके (उदाहरण के लिए किसी प्लेटफ़ॉर्म जैसे Koder.ai से), डॉक्स का पालन करे, एनवायरनमेंट वेरिएबल सेट करे, माइग्रेशन चलाए, बिल्ड करे, और सहमत एनवायरनमेंट में डिप्लॉय कर सके।
यह चेकलिस्ट तकनीकी रेडिनेस पर केंद्रित है: एनवायरनमेंट वेरिएबल, सीक्रेट रोटेशन, डेटाबेस माइग्रेशन, डिप्लॉयमेंट स्क्रिप्ट्स, और बिल्ड सत्यापन। यह कानूनी शर्तें, कॉन्ट्रैक्ट, IP क्लॉज, या पेमेंट विवादों को कवर नहीं करता। वे भी महत्वपूर्ण हैं, पर अलग समझौते में होने चाहिए।
साफ़ हैंडऑफ किसी भी एक्सपोर्ट से पहले शुरू होता है। यदि आप यह तय कर लें कि किसका क्या मालिकाना है और कब, तो आख़िरी मिनट के सरप्राइज़ जैसे टूटे हुए डिप्लॉयमेंट, बिना भुगतान वाला होस्टिंग, या गायब एक्सेस से बचा जा सकता है।
एक हैंडऑफ तारीख चुनें और एक फ्रीज़ विंडो परिभाषित करें (आमतौर पर 24–72 घंटे) जहाँ केवल आवश्यक फिक्स ही जाएँ। इससे एक्सपोर्ट किया गया कोड और चल रहा सिस्टम सिंक में रहता है। यदि फ्रीज़ के दौरान हॉटफिक्स चाहिए, तो क्या बदला यह लिख लें और सुनिश्चित करें कि वह फाइनल एक्सपोर्ट में शामिल हो।
निर्धारित करें कि DNS, क्लाउड होस्टिंग, और किसी भी पेड सर्विस के मालिक कौन होंगे हैंडऑफ के बाद। यह सिर्फ कागजी कार्य नहीं है। यदि बिलिंग एजेंसी के कार्ड पर रहती है, तो सेवाएँ बिना चेतावनी के रोकी जा सकती हैं।
इसे ठोस बनाने के लिए:
इसे सरल भाषा में लिखें ताकि दोनों पक्ष आसानी से अनुसरण कर सकें।
निर्धारित करें कि कौन-कौन से एनवायरनमेंट मौजूद हैं (local, staging, production) और प्रत्येक कहाँ चल रहा है। यह नोट करें कि क्या staging एक अलग सर्वर है, अलग डेटाबेस है, या सिर्फ एक फ़ीचर फ्लैग है। यदि आपने किसी प्लेटफ़ॉर्म जैसे Koder.ai का उपयोग किया है, तो यह भी कन्फर्म करें कि वहाँ क्या होस्ट किया गया है बनाम क्या क्लाइंट की इंफ्रास्ट्रक्चर में एक्सपेक्टेड है।
आख़िरी दिन तक एक्सेस का इंतजार न करें। सुनिश्चित करें कि सही लोग जिन चीज़ों तक पहुँचने की जरूरत है—repo, CI, होस्टिंग, डेटाबेस, और ईमेल प्रोवाइडर—उन तक पहुँच रखते हैं।
अंत में फाइनल एक्सेप्टेंस टेस्ट और साइन-ऑफ प्रक्रिया पर भी सहमति करें। उदाहरण: “क्लाइंट क्लीन मशीन से बिल्ड कर सके, माइग्रेशन चला सके, स्टेजिंग पर डिप्लॉय कर सके, और स्मोक टेस्ट पास करे। फिर दोनों पक्ष लिखित में साइन-ऑफ करें।”
एक अच्छी स्रोत कोड हैंडऑफ चेकलिस्ट एक ऐसे रिपो से शुरू होती है जिसे नई टीम कुछ ही मिनटों में खोलकर समझ सके। पुष्टि करें कि क्या शामिल है (एप कोड, कॉन्फ़िग टेम्पलेट्स, स्क्रिप्ट्स) और क्या जानबूझकर बाहर रखा गया है (असली सीक्रेट्स, प्राइवेट 키, बड़े जनरेटेड फाइल्स)। यदि कुछ एक्सक्लूड किया गया है, तो बताएं कि वह कहाँ रहता है और किसका मालिक है।
स्ट्रक्चर को प्रेडिक्टेबल रखें। स्पष्ट टॉप-लेवल फोल्डर्स जैसे frontend/, backend/, mobile/, infra/, scripts/, और docs/ का लक्ष्य रखें। यदि प्रोजेक्ट मोनोरेपो है, तो समझाएँ कि पार्ट्स कैसे जुड़े हैं और प्रत्येक को कैसे चलाना है।
आपका README उस व्यक्ति द्वारा उपयोग के योग्य होना चाहिए जिसने प्रोजेक्ट नहीं बनाया। इसमें प्रीक्विज़िट्स और कामकाजी डेवलप रन तक पहुँचने का सबसे तेज़ तरीका होना चाहिए, बिना अनुमान के।
एक छोटा, मानवीय README सेक्शन शामिल करें जो इन सवालों का उत्तर दे:
साधारण भाषा में छोटे आर्किटेक्चर नोट्स जोड़ें: क्या किससे बात करता है और क्यों। एक छोटा डायग्राम वैकल्पिक है, लेकिन कुछ वाक्य अक्सर पर्याप्त होते हैं। उदाहरण: “React frontend Go API को कॉल करता है। API PostgreSQL पढ़ता/लिखता है। बैकग्राउंड जॉब्स अलग वर्कर प्रोसेस के रूप में चलते हैं।”
अंत में, हैंडऑफ बिल्ड के लिए एक वर्ज़नड चेंज्लॉग या रिलीज नोट्स शामिल करें। यह CHANGELOG.md हो सकता है या एक छोटा “handoff release notes” फाइल जिसमें सटीक commit/tag, क्या शिप हुआ, और ज्ञात समस्याएँ हों।
यदि कोड किसी प्लेटफ़ॉर्म जैसे Koder.ai से एक्सपोर्ट किया गया था, तो जेनरेटेड प्रोजेक्ट टाइप (web, server, mobile), अपेक्षित टूलचेन (जैसे React, Go, PostgreSQL, Flutter), और समर्थित OS/टूलिंग वर्ज़न नोट करें ताकि क्लाइंट बिल्ड को पुन: उत्पन्न कर सके।
एनवायरनमेंट वेरिएबल अक्सर कारण होते हैं कि हैंडऑफ के ठीक बाद “वर्किंग ऐप” फ़ैल हो जाता है। एक अच्छी हैंडऑफ चेकलिस्ट उन्हें प्रोडक्ट का हिस्सा समझती है, न कि बाद की बात।
एक इन्वेंटरी लिखकर शुरू करें जिसे नई टीम अनुमान लगाए बिना फ़ॉलो कर सके। इसे सरल भाषा में रखें और उदाहरण मान का फॉर्मेट शामिल करें (असली सीक्रेट नहीं)। यदि कोई वैरिएबल ऑप्शनल है, तो बताएं कि गायब होने पर क्या होता है और कौन सा डिफॉल्ट उपयोग होता है।
प्रस्तुत करने का एक आसान तरीका यह है:
.env फाइल)एनवायरनमेंट-विशिष्ट अंतर स्पष्ट रूप से बताएं। उदाहरण के लिए, 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 में रखे गए किसी भी “टेम्पररी” टोकन को शामिल करें।
रोटेशन डे के लिए एक सरल चेकलिस्ट:
रोटेशन के बाद, साबित करें कि कुछ भी टूट नहीं गया। केवल लॉग जांचने के बजाय त्वरित "रियल यूजर" टेस्ट चलाएँ।
उन फ्लोज़ पर ध्यान दें जो सीक्रेट्स पर निर्भर हैं:
उदाहरण: यदि आपने Koder.ai से प्रोजेक्ट एक्सपोर्ट किया है और ऐप एक पेमेंट प्रोवाइडर और ईमेल डिलीवरी उपयोग करता है, तो दोनों कीज़ रोटेट करें, फिर redeploy करें, और एक छोटा टेस्ट ट्रांज़ैक्शन प्लेस करें और एक टेस्ट ईमेल भेजें। केवल इन सफलताओं के बाद ही एजेंसी-ओन्ड कीज़ को रिवोक करें।
अंत में, दस्तावेज करें कि आगे सीक्रेट्स कहाँ रखेंगे (वॉल्ट, CI वेरिएबल्स, या होस्टिंग सेटिंग्स), कौन बदल सकता है, और यदि रोटेशन में त्रुटि आये तो कैसे सुरक्षित रूप से रोलबैक करें।
हैंडऑफ "पूरा हुआ" दिख सकता है जबकि डेटाबेस वह हिस्सा है जो सबसे पहले टूटता है। माइग्रेशन्स और डेटा को अपने आप में एक प्रोडक्ट मानें: वर्ज़न्ड, रेपिटेबल, और टेस्टेड।
शुरू में वर्तमान डेटाबेस वर्ज़न और माइग्रेशन्स रिपो में कहाँ हैं यह लिखें। विशेष रूप से बताएं: फोल्डर पाथ, नेमिंग पैटर्न, और नवीनतम माइग्रेशन ID (या टाइमस्टैम्प)। यदि आप PostgreSQL इस्तेमाल कर रहे हैं (Go बैकएंड के साथ सामान्य), तो किसी आवश्यक एक्सटेंशन का भी उल्लेख करें।
एक छोटा रनबुक शामिल करें जो इन प्रश्नों का उत्तर दे:
रोलबैक के बारे में ईमानदार रहें। कुछ बदलाव केवल बैकअप रीस्टोर के साथ ही उल्टे जा सकते हैं। इसे स्पष्ट रूप से बताएं और एक बैकअप स्टेप (डिप्लॉय से पहले स्नैपशॉट, रीस्टोर प्रक्रिया को सत्यापित करना) के साथ जोड़ें।
हैंडऑफ पूरा होने से पहले, संभव हो तो प्रोडक्शन डेटा की एक कॉपी पर माइग्रेशन्स चलाएँ। इससे धीमे क्वेरीज़, ग़ायब इंडेक्स, और "खाली डेटा पर काम करता है" जैसी समस्याएँ पकड़ी जाती हैं। एक वास्तविक परीक्षण है: कोड एक्सपोर्ट करें, एनवायरनमेंट वेरिएबल सेट करें, एनोनीमाइज़्ड डंप रीस्टोर करें, फिर माइग्रेशन्स को स्क्रैच से लागू करें। यह अभ्यास किसी भी हैंडऑफ चेकलिस्ट के बड़े हिस्से को मान्य करता है।
यदि ऐप Koder.ai में बनाया गया था और फिर एक्सपोर्ट किया गया, तो सुनिश्चित करें कि माइग्रेशन फाइलें और कोई सीड स्क्रिप्ट्स एक्सपोर्ट में शामिल हैं और बैकएंड स्टार्टअप प्रोसेस द्वारा सही तरीके से रेफरेंस की जा रही हैं।
हैंडऑफ तभी पूरा होता है जब कोई और क्लीन मशीन पर स्क्रैच से ऐप को फिर से बिल्ड कर सके। आपकी हैंडऑफ चेकलिस्ट में सटीक बिल्ड कमांड्स, आवश्यक वर्ज़न, और अपेक्षित आउटपुट (उदा.: “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 प्रोवाइडर पर कॉपी किया जा सके:
बिल्ड-टाइम कॉन्फ़िग को रन-टाइम कॉन्फ़िग से अलग रखें। बिल्ड-टाइम कॉन्फ़िग उस चीज़ को बदलती है जो कंपाइल होती है (जैसे 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 कमांड याद रखने पर निर्भर है, तो उन्हें स्क्रिप्ट्स में बदलें और आवश्यक अनुमतियाँ नोट करें।
क्लाइंट को पहले दिन ही डिप्लॉय करने के लिए पर्याप्त दें:
डाउनटाइम की उम्मीदों पर सहमति करें। यदि "जीरो डाउनटाइम" चाहिए, तो व्यावहारिक रूप से इसका अर्थ क्या है (blue-green, rolling deploy, migrations के लिए read-only विंडो) बताएं। यदि डाउनटाइम स्वीकार्य है, तो स्पष्ट विंडो पर सहमत हों।
स्टेटिक एसेट्स और कैशेस सामान्य विफलता बिंदु हैं। लिखें कि एसेट्स कब और कैसे बनते हैं, कब कैश बस्ट करना है, और क्या CDN शामिल है।
रोलबैक एक छोटा, टेस्टेड रेसिपी होना चाहिए जो किसी टैग या रिलीज ID से जुड़ी हो। उदाहरण: पिछला टैग डिप्लॉय करें, आवश्यक हो तो पिछला डेटाबेस स्नैपशॉट रीस्टोर करें, और कैशेस को इनवैलीडेट करें।
यदि ऐप Koder.ai पर बनाया गया था और फिर एक्सपोर्ट किया गया, तो आखिरी ज्ञात अच्छी स्नैपशॉट और सटीक एक्सपोर्ट वर्ज़न का उल्लेख करें ताकि क्लाइंट तेज़ी से कोड को वर्किंग रिलीज़ से मिलान कर सके।
वेरिफिकेशन वह क्षण है जब आप जान पाते हैं कि हैंडऑफ वास्तविक है या नहीं। लक्ष्य सरल है: कोई नई व्यक्ति एक्सपोर्ट किया हुआ कोड लेकर उसे सेटअप कर सके और बिना अनुमान के वही ऐप चला सके।
शुरू करने से पहले रिकॉर्ड करें कि "सही" क्या दिखता है: रनिंग ऐप का वर्ज़न, वर्तमान commit/tag (यदि है), और एक-दो मुख्य स्क्रीन या API रिस्पांस जिन्हें तुलना के लिए उपयोग किया जाएगा। यदि एक्सपोर्ट किसी प्लेटफ़ॉर्म जैसे Koder.ai से आया है, तो स्नैपशॉट या एक्सपोर्ट टाइमस्टैम्प नोट करें ताकि आप पुष्टि कर सकें कि आपने नवीनतम स्थिति को टेस्ट किया।
स्मोक टेस्ट्स संक्षिप्त रखें और जोखिम से जुड़े रहें:
यदि कुछ भी फेल होता है, तो सटीक कमांड, एरर आउटपुट, और उपयोग किए गए एनव वेरिएबल्स कैप्चर करें। यह विवरण ओनरशिप बदलने पर घंटों बचा सकता है।
हैंडऑफ को फायर ड्रिल में बदलने का सबसे तेज़ तरीका यह मान लेना है कि "कोड ही काफी है।" एक अच्छी हैंडऑफ चेकलिस्ट उन छोटे, बोरिंग डिटेल्स पर फोकस करती है जो यह तय करते हैं कि क्लाइंट वास्तव में ऐप चला और बदल सके बिना आपकी मदद के।
अधिकतर समस्याएँ कुछ ही पैटर्न में आती हैं:
रोटेशन और एक्सेस क्लीनअप को कोई "जब समय हो" वाला आइटम न बनाएं—इसे शेड्यूल करें। एक तारीख तय करें जब एजेंसी खाते हटा दिए जाएँगे, सर्विस कीज़ फिर से जेनरेट होंगी, और क्लाइंट की पुष्टि करे कि वे केवल अपने क्रेडेंशियल्स से डिप्लॉय कर सकते हैं।
एनव वेरिएबल्स के लिए, रिपो, CI सिस्टम, और होस्टिंग UI—इन तीन जगहों से एक सरल इन्वेंटरी बनाएं। फिर इसे प्रमाणित करें एक फ्रेश मशीन या कंटेनर से क्लीन बिल्ड चलाकर।
माइग्रेशन्स के लिए, उसी डेटाबेस रोल के साथ टेस्ट करें जिसे प्रोडक्शन डिप्लॉय उपयोग करेगा। यदि प्रोडक्शन में एलीवेटेड स्टेप्स चाहिए (जैसे एक्सटेंशन एनेबल करना), तो उन्हें लिखें और मालिकाना स्पष्ट करें।
एक वास्तविक उदाहरण: Koder.ai से एक्सपोर्ट करने के बाद, क्लाइंट सफलतापूर्वक डिप्लॉय करता है पर बैकग्राउंड जॉब्स फेल होते हैं क्योंकि एक क्यू URL सिर्फ होस्टिंग डैशबोर्ड में सेट था। एक सरल एनव ऑडिट इसे पकड़ लेता। इसे टैग्ड रिलीज और डॉक्यूमेंटेड रोलबैक (उदा., "redeploy tag v1.8.2 और अंतिम स्नैपशॉट रीस्टोर करें") के साथ जोड़ें और टीम डाउनटाइम से बचती है।
यदि आप इस स्रोत कोड हैंडऑफ चेकलिस्ट में से केवल एक पेज रखें, तो यह पेज रखें। लक्ष्य सरल है: एक क्लीन क्लोन नई मशीन पर चले, नई सीक्रेट्स के साथ, और ऐसा डेटाबेस हो जो सुरक्षित रूप से आगे बढ़ सके।
इन जाँचों को एक लैपटॉप पर चलाएँ जिसने कभी प्रोजेक्ट नहीं देखा हो (या एक क्लीन कंटेनर/VM में)। यही सबसे तेज़ तरीका है गायब फाइल्स, छिपी धारणाएँ, और पुराने क्रेडेंशियल्स पकड़ने का।
एक एजेंसी React फ्रंटएंड, Go API, और PostgreSQL डेटाबेस हैंडऑफ करती है। क्लाइंट टीम रिपो क्लोन करती है, प्रदान किए गए .env.example को वास्तविक एनव वेरिएबल्स में कॉपी करती है, और डेटाबेस, ईमेल प्रोवाइडर, और किसी भी थर्ड-पार्टी API के लिए नए क्रेडेंशियल बनाती है। वे go test (या सहमति किया गया टेस्ट कमांड) चलाते हैं, React ऐप बनाते हैं, माइग्रेशन्स को एक नए Postgres इंस्टेंस पर लागू करते हैं, और दोनों सेवाओं को स्टार्ट करते हैं। अंत में, वे डॉक्यूमेंटेड स्क्रिप्ट से डिप्लॉय करते हैं और पुष्टि करते हैं कि वही कमिट बाद में दोबारा बिल्ड किया जा सकता है।
हैंडऑफ को संक्षिप्त और स्वामित्व वाला रखें। 30–60 मिनट का वॉकथ्रू अक्सर लंबी डाक्यूमेंटेशन से बेहतर होता है।