vibe-coding प्लेटफ़ॉर्म से स्रोत कोड को साफ़ तरीके से एक्सपोर्ट करें

निर्यात के बाद स्वामित्व का क्या मतलब है

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

अधिकांश लॉक-इन की चिंता वही कुछ गैप से आती है:

• कॉन्फ़िगरेशन जो सिर्फ प्लेटफ़ॉर्म UI में मौजूद है
• बिल्ड स्टेप्स जो "कहीं और" होते हैं
• निर्भरताएँ जो मान ली जाती हैं पर लिखी नहीं जातीं

एक और आम आश्चर्य तब आता है जब होस्टेड वर्शन पर ऐप ठीक चलता है, पर लोकली फेल हो जाता है क्योंकि environment variables, डेटाबेस सेटअप, या सीक्रेट्स को स्पष्ट नहीं किया गया था।

vibe-coding प्लेटफ़ॉर्म से एक साफ़ एक्सपोर्ट से चार नतीजे होने चाहिए:

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

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

यदि आप Koder.ai का उपयोग कर रहे थे, तो आपका एक्सपोर्ट आमतौर पर परिचित स्टैक्स शामिल कर सकता है जैसे React वेब ऐप, Go बैकएंड, PostgreSQL, या Flutter मोबाइल ऐप। स्टैक से ज्यादा मायने सिद्धांत का है: चलाने के लिए सब कुछ रिपॉज़िटरी में दिखना चाहिए, होस्टेड एनवायरनमेंट में नहीं फंसा होना चाहिए।

एक संस्थापक को कंत्राटी को ऐप सौंपते हुए कल्पना करें। "यह रहा रिपो" पर्याप्त होना चाहिए। कंत्राटी को मूल प्लेटफ़ॉर्म प्रोजेक्ट का एक्सेस नहीं चाहिए कि वह API बेस URL ढूँढे, डेटाबेस स्कीमा बनाए, या फ्रंटेंड बिल्ड कैसे करना है यह जाने।

एक एक्सपोर्टेड प्रोजेक्ट में क्या उम्मीद करनी चाहिए

एक्सपोर्ट के बाद आपके पास एक सामान्य रिपॉज़िटरी होनी चाहिए जिसे आप एडिटर में खोल सकें, अपने लैपटॉप पर चला सकें, और बिना मूल प्लेटफ़ॉर्म के किसी टीम को दे सकें।

Koder.ai प्रोजेक्ट्स के साथ, एक्सपोर्ट अक्सर परिचित संरचनाओं से मेल खाते हैं: एक React वेब ऐप, एक Go बैकएंड, और (यदि आपने बनाया था) एक Flutter मोबाइल ऐप। फ़ोल्डर के नाम अलग हो सकते हैं, पर रिपो को स्पष्ट होना चाहिए कि हर भाग कहाँ रहता है और वे कैसे जुड़ते हैं।

प्रोजेक्ट का आकार: फ़ोल्डर्स, एंट्री पॉइंट, और कौन क्या चलाता है

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

आम संकेत:

• Web: एक package.json और एक src/ फ़ोल्डर (अक्सर main.tsx या समान)
• Backend: go.mod और एक cmd/ फ़ोल्डर या main.go
• Mobile: Flutter का pubspec.yaml और lib/main.dart
• एक शीर्ष-स्तरीय README या Makefile जो बताता है कि सब कुछ कैसे चलाएँ
• यदि एक्सपोर्ट को सर्विसेज़ के सेट के रूप में चलाना है तो docker-compose.yml

निर्भरताएँ, कॉन्फ़िगरेशन, और डेटाबेस के टुकड़े

निर्भरताएँ पिन की हुई होनी चाहिए। JavaScript के लिए इसका मतलब है एक लॉकफ़ाइल (package-lock.json, yarn.lock, या pnpm-lock.yaml)। Go के लिए go.mod और go.sum। लॉक मिस होने से प्रोजेक्ट असंभव नहीं बनता, पर रिपीटेबल बिल्ड्स कठिन हो जाते हैं।

कॉन्फ़िगरेशन को कोड से अलग होना चाहिए। .env.example या config.example.yaml जैसे उदाहरण खोजें। आपको वास्तविक सीक्रेट्स (API कीज़, प्रोडक्शन पासवर्ड) एक्सपोर्ट में कमिट नहीं दिखने चाहिए। अगर दिखें तो इसे लीक समझें और रोटेट करें।

डेटाबेस के लिए, माइग्रेशन्स फ़ोल्डर (migrations/, db/migrations/) या टाइमस्टैम्प वाले SQL फ़ाइलें खोजें। Go + PostgreSQL ऐप में आप एक छोटा माइग्रेशन रनर या माइग्रेशन्स लागू करने वाला स्क्रिप्ट भी देख सकते हैं।

एक तेज़ सैनीटी चेक: पहले बिल्ड और रन कमांड्स खोजें (npm run dev, go run, make, और ऐसे ही)। अगर कोई स्क्रिप्ट प्लेटफ़ॉर्म-ओनली कमांड पर निर्भर है, तो उससे रिप्लेस करें ताकि रिपो स्वतंत्र बन सके।

कदम दर कदम: एक्सपोर्ट, कमिट, और लोकली रन करें

एक्सपोर्ट को एक रिलीज़ आर्टिफैक्ट की तरह ट्रीट करें। कुछ भी चलाने से पहले एक त्वरित "सब यहाँ है?" पास करें। कमी को पकड़ना शुरू के समय आसान है बजाय बाद में जब आप बदल रहे हों।

एक व्यावहारिक पूर्णता चेक यह है कि हर हिस्से की "जड़ें" देखें: React वेब ऐप के लिए package.json, Go बैकएंड के लिए go.mod, और PostgreSQL के लिए माइग्रेशन/सीड फ़ाइलें।

एक साफ़ पहला कमिट (ताकि इतिहास पढ़ने में आसान रहे)

एक्सपोर्टेड फ़ोल्डर से एक नया Git रिपोज़िटरी बनाएं, फिर ठीक वैसा ही कमिट करें जैसा आपको मिला, बिना कुछ ठीक किए। यह आपको एक साफ़ बेसलाइन देता है और बाद की बदलाओं की समीक्षा आसान बनाता है।

git init
# Optional: set default branch name
# git branch -M main

git add -A
git commit -m "Initial export"

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

यहाँ एक सरल कमांड सीक्वेंस है जिसे आप अपने एक्सपोर्टेड स्ट्रक्चर के अनुसार अनुकूलित कर सकते हैं:

# Frontend
cd web
npm install
npm run dev

# Backend
cd ../server
go mod download
go run ./cmd/server

पुष्टि करें कि डेटाबेस सच में काम कर रहा है (सिर्फ़ "सर्वर स्टार्ट हुआ" नहीं)

एक सर्वर बूट तो हो सकता है जबकि ऐप फिर भी टूटा हुआ हो। पुष्टि करें कि यह डेटा पढ़ और लिख सकता है।

उत्पाद के अनुरूप तेज़ चेक चुनें:

• ऐसा पेज खोलें जो स्पष्ट रूप से डेटा पर निर्भर हो (एक सूची, प्रोफ़ाइल, डैशबोर्ड)।
• एक रिकॉर्ड बनाएं (साइनअप, आइटम बनाएं, नोट जोड़ें), रिफ्रेश करें, और पुष्टि करें कि यह पर्सिस्ट हुआ।
• UI सपोर्ट करे तो एक अपडेट और एक डिलीट ट्रिगर करें।
• माइग्रेशन एरर या "relation does not exist" जैसे लॉग्स देखें।

एक बार लोकल रन काम करने लगे, अपने स्क्रैच नोट को एक वास्तविक README.md में बदल दें: कहां से कमांड चलानी है, सर्विसेज़ को किस क्रम में स्टार्ट करना है, और कौन से environment variables आवश्यक हैं।

एक्सपोर्ट को हेंडऑफ-रेडी रिपो में बदलना

एक्सपोर्ट चल सकता है, पर फिर भी "जनरेटेड" जैसा महसूस करवा सकता है बजाय मालिकाना महसूस कराने के। एक हेंडऑफ-रेडी रिपो यह स्पष्ट कर देता है कि चीज़ें कहाँ रहती हैं, कैसे चलती हैं, और इसे कैसे स्थिर रखा जाए।

एक स्पष्ट शीर्ष-स्तरीय लेआउट से शुरू करें। नाम से ज़्यादा निरंतरता मायने रखती है।

• apps/ उपयोगकर्ता-समक्ष फ्रंटएंड्स के लिए (web, mobile)
• services/ बैकएंड APIs, workers, और jobs के लिए
• shared/ साझा प्रकार और यूटिलिटीज़ के लिए
• infra/ डिप्लॉयमेंट टेम्प्लेट, स्क्रिप्ट्स, और पर्यावरण उदाहरणों के लिए
• docs/ आर्किटेक्चर नोट्स और रनबुक्स के लिए

फिर कुछ छोटी फ़ाइलें जोड़ें जो अनुमान घटाएँ:

• README.md जिसमें प्रीरेक्विज़िट्स और सटीक कमांड हों
• CONTRIBUTING.md में कुछ नियम (ब्रांच, PR, कोई सीक्रेट्स नहीं)
• .gitignore ताकि लोकल env फ़ाइलें और बिल्ड आउटपुट Git में न जाएँ

README को व्यावहारिक रखें। यदि रिपो में कई हिस्से हैं (React frontend, Go API, PostgreSQL), तो उन्हें स्टार्ट करने का क्रम और कॉन्फ़िग कहाँ रहती है यह स्पष्ट करें (उदाहरण: ".env.example को .env में कॉपी करें")।

एक फ्रेश-मशीन चेक करें: नई फ़ोल्डर में क्लोन करें और अपने README को फॉलो करें। यदि आप Koder.ai से एक्सपोर्ट कर रहे हैं, तो एक्सपोर्ट को नए स्वतंत्र प्रोजेक्ट की पहली कमिट मानें, और उसी के बाद दूसरों को आमंत्रित करें।

लोकल डेवलपमेंट सेटअप जिसे नए लोग फॉलो कर सकें

एक अच्छा लोकल सेटअप एक सवाल का तेज़ जवाब देता है: क्या नया व्यक्ति बिना अनुमान के 15 मिनट से कम में ऐप चला सकता है?

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

एक सरल पैटर्न जो अच्छा काम करता है: एक README पेज, एक सैंपल env फ़ाइल, और एक बूटस्ट्रैप कमांड।

एक न्यूनतम, सुरक्षित env सेटअप

फेक वैल्यूज़ के साथ एक उदाहरण फ़ाइल कमिट करें ताकि लोग जानें क्या सेट करना है बिना सीक्रेट लीक किए।

# .env.example (example values only)
APP_ENV=local
PORT=8080
DATABASE_URL=postgres://app_user:app_pass@localhost:5432/app_db?sslmode=disable
JWT_SECRET=change-me
API_BASE_URL=http://localhost:8080

README में बताएं असली फ़ाइल कहाँ रहती है (उदाहरण के लिए, ".env.example को .env में कॉपी करें") और कौन से वेरिएबल्स आवश्यक बनाम वैकल्पिक हैं।

बूटस्ट्रैप के लिए एक कमांड

एक छोटा स्क्रिप्ट जोड़ें जो सही क्रम में उबाऊ स्टेप्स चलाए। इसे पठनीय रखें।

#!/usr/bin/env bash
set -euo pipefail

cp -n .env.example .env || true

# Backend deps
cd backend
go mod download

# Database: create, migrate, seed
./scripts/db_create.sh
./scripts/db_migrate.sh
./scripts/db_seed.sh

# Frontend deps
cd ../web
npm install

डेटाबेस योजना के लिए, तीन चीज़ें दस्तावेज़ करें: DB कैसे बनती है, माइग्रेशन्स कैसे चलते हैं, और वास्तविक पहले रन के लिए seed डेटा कैसे मिलता है।

अंत में, एक त्वरित हेल्थ चेक जोड़ें ताकि लोग क्लिक करने से पहले पुष्टि कर सकें कि ऐप काम कर रहा है। GET /health जैसा छोटा endpoint जो "ok" रिटर्न करे (और डेटाबेस कनेक्टिविटी भी वेरिफाई करे) अक्सर काफी होता है।

सीक्रेट्स और कॉन्फ़िगरेशन बिना कुछ लीक किए

जब आप प्रोजेक्ट एक्सपोर्ट करते हैं, कोड आपका हो सकता है, पर सीक्रेट्स प्राइवेट रहने चाहिए। मान लें कि रिपो नए teammates के साथ साझा किया जाएगा।

शुरू करें ये सूची बनाकर कि ऐप को रन करने के लिए क्या चाहिए। अंदाज़ा न लगाएं। कोड में कॉन्फ़िग रीड्स (environment variables, config files) स्किम करें और किसी भी इंटीग्रेशन को चेक करें जो आपने सक्षम किए थे।

एक बेसिक सीक्रेट्स इन्वेंटरी में आमतौर पर डेटाबेस क्रेडेंशियल्स, थर्ड-पार्टी API कीज़, ऑथ सेटिंग्स (OAuth या JWT), स्टोरेज क्रेडेंशियल्स, और ऐप-विशेष सीक्रेट्स जैसे एन्क्रिप्शन कीज़ या webhook साइनिंग सीक्रेट्स शामिल होते हैं।

निर्धारित करें कि हर एनवायरनमेंट में हर सीक्रेट कहाँ रखा जाएगा। एक अच्छा डिफ़ॉल्ट नियम:

• लोकल: डेवलपर-स्वामित्व वाली .env (कमिट न करें)
• CI: CI प्रोवाइडर का सीक्रेट स्टोर
• प्रोडक्शन: समर्पित सीक्रेट मैनेजर या होस्टिंग एनवायरनमेंट वेरिएबल्स

यदि आपने Koder.ai जैसे vibe-coding प्लेटफ़ॉर्म से एक्सपोर्ट किया है, तो मान लें कि चैट, लॉग्स, या सेटिंग पैनल में दिखे किसी भी चीज़ की कॉपी कहीं न कहीं जा सकती है। सीक्रेट्स को रिपो से तुरंत निकाल दें।

एक व्यावहारिक अप्रोच यह है कि एक सुरक्षित टेम्पलेट (.env.example) कमिट करें, असली वैल्यूज़ Git में न रखें (.env को .gitignore करें), और प्रोडक्शन सीक्रेट्स डिप्लॉय के समय इंजेक्ट करें।

अगर एक्सपोर्ट के दौरान किसी भी तरह का रिस्क रहा कि सीक्रेट्स एक्सपोज़ हुए, तो उन्हें रोटेट करें। प्राथमिकता दें: डेटाबेस पासवर्ड, OAuth क्लाइंट सीक्रेट्स, और webhook साइनिंग कीज़।

कुछ गार्डरेल्स जोड़ें ताकि यह फिर न हो: obvious सीक्रेट पैटर्न के लिए pre-commit चेक, CI में सीक्रेट स्कैन, तेज़ फेल करने वाला कड़ा कॉन्फ़िग लोडिंग, और अलग-अलग एनवायरनमेंट के लिए अलग क्रेडेंशियल्स।

एक छोटा SECRETS.md हेंडऑफ के लिए मददगार होगा। सरल रखें: आवश्यक वेरिएबल्स, प्रत्येक एनवायरनमेंट में वे कहाँ स्टोर हैं, और कौन उन्हें रोटेट कर सकता है।

CI सेटअप ताकि रिपो स्वस्थ रहे

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

CI को एक सवाल का तेज़ जवाब देना चाहिए: "क्या यह परिवर्तन मर्ज करने के लिए सुरक्षित है?" अधिकांश रिपो के लिए इसका मतलब है निर्भरताएँ इंस्टॉल करें, बिल्ड करें, lint चलाएँ, और यूनिट टेस्ट चलाएँ।

ऐप पार्ट के हिसाब से जॉब्स को अलग करें ताकि फेलियर स्पष्ट हों:

• Web: install, lint/typecheck, build, run tests
• Backend: build, run unit tests, run linters/format checks
• वैकल्पिक मोबाइल (Flutter): analyze, test, build
• वैकल्पिक डेटाबेस चेक: माइग्रेशन्स को थ्रोअवे एनवायरनमेंट में लागू करना

कैशिंग का उपयोग करें, पर कैश समस्याएँ छुपाने न दे। जब कैश मिस हो, CI अभी भी काम करना चाहिए, बस धीमा होगा।

हर स्टेप के लिए एक सिंगल कमांड पसंद करें (make test, npm run test, आदि) ताकि वही कमांड लोकल और CI दोनों जगह काम करे। इससे भ्रम कम होता है और लॉग छोटे रहते हैं।

नमूना संरचना (अपने रिपो के अनुसार नाम समायोजित करें):

jobs:
  web:
    steps:
      - run: npm ci
      - run: npm run lint
      - run: npm run build
  api:
    steps:
      - run: go test ./...
      - run: go build ./...

बेसिक्स स्थिर होने के बाद, एक साधारण रिलीज़ फ्लो जोड़ें: रिलीज़ टैग करें, आर्टिफैक्ट बनाएं, और उन्हें CI आर्टिफैक्ट्स के रूप में स्टोर करें। भले ही आप आज भी किसी प्लेटफ़ॉर्म से डिप्लॉय करते हों, रिपीटेबल आर्टिफैक्ट्स होस्ट बदलने में मदद करते हैं।

सामान्य गलतियाँ और उन्हें कैसे टालें

कोड एक्सपोर्ट करना आधा काम है। दूसरा आधा यह सुनिश्चित करना है कि प्रोजेक्ट प्लेटफ़ॉर्म के बाहर उसी तरह व्यवहार करे।

गलती 1: उम्मीद करना कि बिना किसी सेटअप के चलेगा

एक्सपोर्ट अक्सर environment variables, माइग्रेशन्स, seed डेटा, और बिल्ड स्टेप्स पर निर्भर होते हैं जो आपके लिए संभाले गए थे। पहले रन पर खाली स्क्रीन या डेटाबेस एरर सामान्य है।

बेसलाइन रन करें पहले: निर्भरताएँ इंस्टॉल करें, env vars सेट करें, माइग्रेशन्स चलाएँ, और सेवाओं को क्रम से स्टार्ट करें। केवल आवश्यक बदलाव करें ताकि प्रत्याशित सेटअप मैच करे।

गलती 2: सीक्रेट्स को Git में लीक करना

सबसे आम दुर्घटना असली API कीज़ या पासवर्ड कमिट करना है, अक्सर .env कॉपी करने या टूल-जनरेटेड कॉन्फ़िग के कारण।

केवल टेम्पलेट कमिट करें। असली वैल्यूज़ लोकल एनवायरनमेंट या सीक्रेट स्टोर में रखें।

गलती 3: तुरंत निर्भरताएँ बदलना

पैकेजेस अपडेट करना या फ़ोल्डर तुरंत पुनर्गठित करना यह बताने में मुश्किल बनाता है कि समस्या एक्सपोर्ट की वजह से है या आपकी बदलावों की वजह से।

पहले एक काम करने वाला रन पाएं, फिर छोटे, अलग कमिट्स में सुधार करें।

गलती 4: वर्ज़न पिन न करना

"मेरी मशीन पर चलता है" अक्सर अनपिन्ड टूल वर्ज़न्स (Node, Go, Flutter, यहां तक कि पैकेज मैनेजर्स) की वजह से होता है।

रनटाइम वर्ज़न्स किसी स्पष्ट जगह पर पिन करें (एक फ़ाइल या README), लॉकफ़ाइल्स रखें (package-lock, go.sum, pubspec.lock), और किसी दूसरी मशीन या फ्रेश कंटेनर पर सेटअप वेरिफाई करें।

गलती 5: डॉक्यूमेंट्स छोड़ देना और बाद में इसकी कीमत चुकाना

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

एक वास्तविक उदाहरण: प्लेटफ़ॉर्म प्रोजेक्ट से स्वतंत्र रिपो तक

एक तीन-व्यक्ति की टीम Koder.ai में एक कस्टमर पोर्टल बनाती है: एक React वेब ऐप, एक Go API, और एक PostgreSQL डेटाबेस। जब इसे बाहरी डेवलपर टीम को सौंपने का समय आता है, तो वे चाहते हैं कि एक्सपोर्ट एक सामान्य रिपो जैसा लगे जिसे कोई व्यक्ति पहले दिन चला सके।

Day 1: वे एक्सपोर्ट करते हैं, एक नया Git रिपो बनाते हैं, और लोकली चलाते हैं। फ्रंटेंड चलता है, पर API फेल करता है क्योंकि environment variables गायब हैं। वे अनुमान नहीं लगाते—कोड पढ़ते हैं, उपयोग किए गए सटीक कीज़ पहचानते हैं, और प्लेसहोल्डर्स के साथ .env.example बनाते हैं। असली वैल्यूज़ पासवर्ड मैनेजर और लोकल .env फ़ाइलों में रहती हैं।

वे यह भी नोट करते हैं कि प्लेटफ़ॉर्म पर पोर्ट्स और CORS सेटिंग्स ठीक थीं पर लोकल में डिफ़ॉल्ट चाहिए। वे पूर्वानुमेय डिफ़ॉल्ट्स सेट करते हैं (उदाहरण के लिए, API 8080 पर और वेब 3000 पर) ताकि नई मशीनें समान व्यवहार करें।

Day 2: वे माइग्रेशन्स और एक छोटा सीड स्क्रिप्ट जोड़ते हैं जो एक डेमो यूज़र और कुछ रो बनाती है। फिर वे एक छोटा README लिखते हैं जो प्रीरेक्विज़िट्स, चलाने के कमांड, और यह कैसे वेरिफाई करें बताता है (API के लिए एक हेल्थ endpoint और UI के लिए सैंपल लॉगिन)।

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

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

त्वरित चेक्स और अगले कदम

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

अंतिम चेकलिस्ट:

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

तकनीकी चेक के बाद, स्वामित्व को स्पष्ट बनाएं। तय करें कि किसका जिम्मा है: निर्भरता अपडेट्स, इन्फ्रास्ट्रक्चर बदलाव (डेटाबेस, कतारें, DNS), और रिलीज़। यदि कोई इनका मालिक नहीं है, तो रिपो धीरे-धीरे खराब होगा भले ही आज ऐप चले।

मुख्य फीचर वर्क से पहले एक छोटा stabilization विंडो योजना बनाएं। आम तौर पर दो से पांच कामकाजी दिन पर्याप्त होते हैं ताकि एक्सपोर्ट की खामियाँ ठीक हो सकें, README कड़ा हो, और "मेरी मशीन पर चलता है" समस्याएँ दूर हो सकें।

यदि आप Koder.ai (Koder.ai) का उपयोग कर रहे हैं, तो एक्सपोर्ट्स के साथ snapshots और rollback जैसी विशेषताएँ यह आसान बनाती हैं कि आप रिपो कड़ाई से तैयार करते हुए भी इटरेट करें। एक बार रिपो स्टेबल हो जाए, Git को स्रोत माने और भविष्य के एक्सपोर्ट्स को मुख्य इतिहास न बल्कि चेकपॉइंट ही मानें।

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