इस AI-निर्मित कोडबेस एक्सपोर्ट चेकलिस्ट का उपयोग करके प्रोजेक्ट सुरक्षित रूप से हैंडऑफ करें: एन्वायरनमेंट वेरिएबल्स, सीक्रेट्स, लोकल सेटअप, डेटाबेस बूटस्ट्रैप, CI, और एक स्पष्ट 'कैसे चलाएँ' README।
अधिकांश एक्सपोर्टेड प्रोजेक्ट्स एक साधारण कारण से फेल होते हैं: वे मूल प्लेटफ़ॉर्म के अंदर ठीक चल रहे थे, जहाँ डिफॉल्ट्स, सीक्रेट्स, डेटाबेस स्टेट, और बिल्ड स्टेप्स पहले से मौजूद थे। जब कोड उस बबल से बाहर जाता है, तो अगला डेवलपर अनुमान लगाना शुरू कर देता है कि क्या माना गया था।
एक साफ़ हैंडऑफ का मतलब है कि प्रोजेक्ट किसी ऐसे व्यक्ति द्वारा क्लोन, कॉन्फ़िगर और शुरू किया जा सकता है जिसने उसे बनाया नहीं था, एक ताज़ा मशीन पर, बिना लंबी संवाद-ही-डैम को। यह परफेक्ट कोड की मांग नहीं करता। यह बुनियादी चीज़ों को स्पष्ट और दोहराने योग्य बनाने की मांग करता है।
एक्सपोर्ट्स बार-बार उन्हीं समस्याओं पर टूटते हैं: छुपा कॉन्फ़िग, अस्पष्ट सीक्रेट हैंडलिंग, धुंधले लोकल सेटअप स्टेप्स, डेटाबेस आश्चर्य, और CI जो सिर्फ़ एक वातावरण में काम करता है।
इसलिए AI-निर्मित कोडबेस एक्सपोर्ट चेकलिस्ट ज़्यादातर दस्तावेज़ीकरण और पुनरुत्पादनयोग्यता के बारे में है, न कि बस फाइलें कॉपी करने के बारे में। अगर आपने ऐप किसी vibe-coding प्लेटफ़ॉर्म जैसे Koder.ai में बनाया और फिर सोर्स कोड एक्सपोर्ट किया, तो अगली टीम को फिर भी एक नक्शे की ज़रूरत होती है: क्या सेट करना है, क्या चलाना है, और "काम करना" किस रूप में दिखता है।
यह चेकलिस्ट हैंडऑफ के अनिवार्य पहलुओं पर केंद्रित है: एन्वायरनमेंट वेरिएबल्स, सीक्रेट्स, लोकल डेवलपमेंट सेटअप, डेटाबेस बूटस्टैप, CI सेटअप, और एक व्यावहारिक "कैसे चलाएँ" README। यह प्रोडक्ट निर्णय, UX पॉलिश, या आर्किटेक्चर के री-डिजाइन को कवर नहीं करती।
Ownership भी स्पष्ट होना चाहिए। बिल्डर की ज़िम्मेदारी है मान्यताओं को दृश्य बनाना (डॉक्स, स्क्रिप्ट, सुरक्षित डिफॉल्ट्स)। रिसीवर की ज़िम्मेदारी है परियोजना को अपनी एन्वायरनमेंट के अनुरूप ढालना (सीक्रेट्स मैनेजर, होस्टिंग, सख्त CI नियम)। जब दोनों पक्ष अपनी भूमिका जानते हैं, तो हैंडऑफ रूटीन बन जाता है।
एक साफ़ हैंडऑफ एक सरल समझौते से शुरू होता है: कोड प्लेटफ़ॉर्म छोड़ते समय "डन" का क्या मतलब है। इसके बिना, टीमें बाद में गायब स्क्रिप्ट्स, अचम्भित निर्भरताओं, या किस वर्जन को असली समझा जाए पर बहस करती हैं।
एक अकेले स्थिर समय बिंदु चुनें और उसे स्रोत सत्य मानें। बीच-बीच में एक्सपोर्ट करना टीमों को ऐसे रिपो देता है जो लगभग चलती है।
एक अच्छा एक्सपोर्ट बिंदु आमतौर पर इनमें से एक होता है:
यह बताने के लिए एक वाक्य जोड़ें कि यह क्यों सही एक्सपोर्ट पॉइंट है। उदाहरण: “सभी मुख्य फ्लो पास हैं और डेटाबेस स्कीमा इस माइलस्टोन के लिए अंतिम है।”
एक छोटा इन्वेंटरी लिखें कि रिसीवर क्या अपेक्षा करे। स्पष्ट रूप से बताएं क्या शामिल है और क्या जान बूझकर बाहर रखा गया है।
बुनियादी चीज़ें शामिल करें: सोर्स कोड (ऐप्स, सर्विसेस, शेयर्ड पैकेजेस), कॉन्फ़िग टेम्प्लेट्स (.env.example जैसी), स्क्रिप्ट्स (build, dev, test, migrations, seed), और डिप्लॉयमेंट नोट्स। यदि सैंपल डेटा शामिल कर रहे हैं तो सुनिश्चित करें कि वह scrubbed और सुरक्षित हो।
फिर वर्जन्स फ्रीज़ कर दें ताकि “works on my machine” नया बेसलाइन न बन जाए। रनटाइम और टूलचेन वर्जन्स कैप्चर करें (Node, Go, Flutter, पैकेज मैनेजर), साथ में डेटाबेस वर्जन (PostgreSQL का मेजर वर्जन मायने रखता है)।
अंत में,Prerequisites की सूची दें जिन्हें कुछ भी चलाने से पहले पूरा करना होगा। इसे छोटा और ठोस रखें: आवश्यक अकाउंट्स, इंस्टॉल किए जाने वाले टूल्स, खुले होने चाहिए पोर्ट्स, और कोई भी वन-टाइम सेटअप स्टेप्स।
अधिकांश "यह प्लेटफ़ॉर्म पर काम कर रहा था" एक्सपोर्ट इसलिए फेल होते हैं क्योंकि प्रमुख सेटिंग्स कभी लिखा ही नहीं गया थीं। एन्वायरनमेंट वेरिएबल्स आम दोषी होते हैं: वे रिपो के बाहर रहते हैं, इसलिए नया टीम मेंबर प्रोजेक्ट क्लोन करता है और उसे कोई अंदाज़ा नहीं होता कि किस तरह के मान अपेक्षित हैं।
इसे एक आवश्यक चीज़ मानें: हर वेरिएबल को खोजा जा सके, समझाया गया हो, और अनुमान लगाए बिना सेट करना आसान हो।
अपने हैंडऑफ README में एक सिंगल सोर्स ऑफ ट्रuth बनाएं: env var नामों की सूची, वे ऐप में क्या नियंत्रित करते हैं, और मान कहाँ से आते हैं। स्पष्टीकरण सादा भाषा में रखें, और किसी भी सुरक्षा-संबंधित चीज़ को खास तौर पर बताएं।
प्रत्येक वेरिएबल के लिए एक सरल प्रारूप:
उस दस्तावेज़ीकरण के साथ, रिपो में .env.example फ़ाइल रखें। इसमें हर संभावित वेरिएबल के सुरक्षित प्लेसहोल्डर शामिल होने चाहिए ताकि ऐप न्यूनतम संपादनों के साथ स्टार्ट हो सके।
# Required
APP_ENV=development
PORT=3000
DATABASE_URL=postgres://user:password@localhost:5432/app_dev
# Optional
LOG_LEVEL=info
CORS_ORIGINS=http://localhost:5173
# Environment specific
PUBLIC_BASE_URL=http://localhost:3000
कुछ छोटे विवरण अधिकांश कन्फ्यूज़न रोक देते हैं:
"Required vs optional" स्पष्ट करें। अगर कोई गायब वेरिएबल क्रैश कराता है, तो बताएं। अगर यह किसी फीचर को सक्रिय करता है (इमेल भेजना, पेमेंट्स, फ़ाइल स्टोरेज), तो फीचर का नाम बताएं और यह बताएं कि सेट न होने पर क्या होता है।
बताएँ कि प्रति एन्वायरनमेंट क्या बदलता है। DATABASE_URL और PUBLIC_BASE_URL आमतौर पर dev, staging, और production में बदलते हैं, जबकि LOG_LEVEL हर जगह समान हो सकता है। अगर आपने Koder.ai में एक्सपोर्ट और डिप्लॉय किया है, तो प्लेटफ़ॉर्म डिफ़ॉल्ट्स (पोर्ट्स, बेस URLs, allowed origins) दस्तावेज़ में प्रतिबिंबित करें ताकि प्लेटफ़ॉर्म के बाहर व्यवहार निरंतर रहे।
अंत में, बताएं कि लोकल में env vars कैसे लोड होते हैं। अगर प्रोजेक्ट .env फ़ाइल की अपेक्षा करता है, तो बताएं कि वह कहाँ रहती है और ऐप उसे ऑटोमैटिक पढ़ता है या किसी कमांड/टूल की ज़रूरत होती है।
सीक्रेट्स वो मान हैं जिनके लीक होने पर नुकसान हो सकता है: API कीज़, डेटाबेस पासवर्ड, auth टोकन, OAuth क्लाइंट सीक्रेट्स, प्राइवेट कीज़, webhook साइनिंग सीक्रेट्स आदि।
एक्सपोर्ट के लिए सरल रखें: रिपो में केवल प्लेसहोल्डर्ज़ ही होने चाहिए, असली सीक्रेट वैल्यूज़ कभी नहीं। अगर किसी सीक्रेट की ज़रूरत है स्टार्ट करने के लिए, तो उसे .env.example में स्पष्ट नाम के साथ प्लेसहोल्डर के रूप में शामिल करें और असली कैसे जनरेट करें यह समझाएँ।
एक व्यावहारिक पैटर्न इन तीन चीज़ों को अलग करना है: सैंपल फ़ाइल, लोकल फ़ाइल, और CI/डिप्लॉयमेंट सीक्रेट स्टोर। आपका एक्सपोर्टेड कोड सैंपल शामिल करे, लोकल फ़ाइल को ignore करे, और बताये कि CI/होस्टिंग को सीक्रेट्स कैसे मिलते हैं।
एक-एक एन्वायरनमेंट के लिए एक तरीका चुनें और उसी पर टिकें।
.env (gitignored) जिसे ऐप लोड करता है, या आपकी टीम का लोकल सीक्रेट्स मैनेजरउदाहरण: रिपो में PAYMENTS_API_KEY=replace_me शामिल है। रिसीवर अपने प्रोवाइडर डैशबोर्ड में अपना की जेनरेट करता है और उसे लोकल .env और CI में सेट करता है। कोड वही रहता है।
हैंडऑफ के समय सीक्रेट्स को रोटेट करना अच्छा रहता है, खासकर अगर वे कभी साझा प्लेटफ़ॉर्म से इस्तेमाल हुए हों।
.env फ़ाइलें अपडेट करें।अगर आपने Koder.ai से एक्सपोर्ट किया है, तो एक्सपोर्ट को एक नए एन्वायरनमेंट की तरह मानें और रिसीविंग टीम के लिए ताज़ा सीक्रेट्स जेनरेट करें।
एक सफल हैंडऑफ तब होता है जब नया डेवलपर रिपो क्लोन कर सके, कुछ कमांड्स चला सके, और बिना गेसिंग के ऐप को काम करते हुए देख सके। अनुमानित प्रीरेक्विज़िट्स, स्पष्ट कमांड ऑर्डर, और छोटा "कैसे चलाएँ" ब्लॉक होना चाहिए जो रियलिटी से मेल खाता हो।
README के ऊपर इनको रखें ताकि कोई एरर मेसेज से अनुमान न लगाये:
अगर प्रोजेक्ट Koder.ai पर बनाकर एक्सपोर्ट किया गया था, तो लोकल सेटअप को एक्सपोर्ट के अनुरूप रखें (वही फोल्डर स्ट्रक्चर, वही स्टार्ट कमांड)। यह मत मानिए कि “Postgres पहले से चल रहा है” जब तक आपने स्पष्ट न कहा हो।
नया teammate किस क्रम में कमांड्स चलाएगा यह वही लिखें। कापी-पेस्ट करने लायक रखें:
# 1) Install dependencies
cd web
npm ci
cd ../server
go mod download
# 2) Create your env file
cp .env.example .env
# 3) Start dependencies (if needed)
# e.g., start Postgres locally or via docker compose
# 4) Run the app
cd server
go run ./cmd/api
cd ../web
npm run dev
इसके ठीक नीचे минимल टेस्ट और बिल्ड सेक्शन जोड़ें:
# Tests
cd server && go test ./...
cd web && npm test
# Build
cd web && npm run build
cd server && go build ./...
अधिकांश "यह नहीं चलता" समस्याएँ कुछ ही बक्से में आती हैं:
गलत वर्जन्स (Node/Go)। लक्षण: dependency या compile एरर। समाधान: पिन किए गए वर्जन्स इंस्टॉल करें और इंस्टॉल्स फिर चलाएँ।
गायब env वैल्यूज़। लक्षण: "undefined" config, auth फेल्यर्स, 500 एरर। समाधान: .env को .env.example से मिलाएँ और आवश्यक वैल्यूज़ भरें।
डेटाबेस पहुँच न होना। लक्षण: connection refused, “database does not exist.” समाधान: Postgres स्टार्ट करें, host/port/user सत्यापित करें, और डेटाबेस init स्टेप्स ठीक से चलाएँ।
जब कोई प्रोजेक्ट किसी प्लेटफ़ॉर्म से एक्सपोर्ट होता है, डेटाबेस अक्सर नई मशीन पर पहली चीज़ होती है जो टूटती है। लक्ष्य सरल है: एक teammate को "मैंने रिपो क्लोन किया" से "ऐप रियल डेटा के साथ चलता है" तक बिना अनुमान के पहुँचाना।
ताज़ा PostgreSQL सेटअप के लिए न्यूनतम स्टेप्स लिखें, और कमांड्स को स्क्रिप्ट्स में रखें जहाँ संभव हो। आपका हैंडऑफ चार प्रश्नों के जवाब देता हो:
अगर पहले से स्क्रिप्ट्स हैं (Makefile टार्गेट्स, शेल स्क्रिप्ट्स, टास्क रनर कमांड्स), तो मैनुअल स्टेप्स के बजाय उन्हीं का उपयोग करें। अगर नहीं हैं, तो अभी कुछ जोड़ दें।
एन्वायरनमेंट्स (लोकल, CI, स्टेजिंग) में फ्लो निरंतर रखें। एक अच्छा बेसलाइन ऐसा दिखता है:
# 1) Create role + database (example names)
createuser app_user --pwprompt
createdb app_db --owner=app_user
# 2) Apply migrations
# Replace with your repo's migration command
./scripts/migrate up
# 3) Seed minimal demo data
./scripts/seed
सीड्स के लिए, प्रोडक्शन जैसी डंप के बजाय न्यूनतम वर्किंग डेटा पसंद करें। सीड्स को बार-बार चलाने योग्य बनाएं (idempotent inserts, या स्पष्ट "खाली DB पर ही चलाएँ" नियम)।
रीसेट्स के लिए, सुरक्षा के बारे में स्पष्ट रहें। एक रिसेट कमांड डिफ़ॉल्ट रूप से केवल लोकल विकास को टारगेट करे। अगर आप विनाशकारी स्क्रिप्ट देते हैं, तो एक गार्डरेइल जोड़ें (उदा., CONFIRM_RESET=1 की जरूरत या APP_ENV=development चेक)। और परिभाषित करें कि "रीसेट" का मतलब क्या है: ड्रॉप और रिक्रिएट, टेबल्स वाइप करना, या किसी ज्ञात स्नैपशॉट को restore करना।
हैंडऑफ तब बिगड़ता है जब रिपो एक जंक ड्रॉअर जैसा लगने लगता है। किसी नए व्यक्ति को बताना चाहिए कि क्या महत्वपूर्ण है, क्या जनरेटेड है, और सेटिंग्स कहाँ बदलनी हैं।
दोहराने योग्य बनाने वाली चीज़ें commit करें: lockfiles, migration फाइल्स, छोटे कॉन्फ़िग टेम्प्लेट्स जैसे .env.example, और कोई भी स्क्रिप्ट्स जो ऐप bootstrap करती हैं।
व्यक्तिगत, जनरेटेड, या संवेदनशील फाइल्स सोर्स कंट्रोल से बाहर रखें: लोकल एन्वायरनमेंट फाइलें, एडिटर सेटिंग्स, बिल्ड आउटपुट, लॉग्स, कैशेज़, और कुछ भी जो एक्सेस देता है (API कीज़, डेटाबेस पासवर्ड, सर्विस अकाउंट फाइल्स)।
एक सरल नियम: यदि इसे बदलने से सब प्रभावित होते हैं, तो commit करें। यदि यह मशीन या एन्वायरनमेंट के अनुसार बदलता है, तो डॉक्यूमेंट करें और रिपो से बाहर रखें।
यदि आप एक छोटा "क्या रखें बनाम क्या ignore करें" नोट शामिल करें, तो संक्षेप में रखें:
README, lockfiles, migrations, seed scripts, .env.example.env, सीक्रेट्स फ़ाइलें, बिल्ड फोल्डर्स, लॉग्स, लोकल कैशेज़एक संक्षिप्त डायरेक्टरी मैप जोड़ें ताकि स्ट्रक्चर बिना क्लिक किए भी स्पष्ट हो। उदाहरण: “/backend API सर्विस, /web फ्रंटेंड, /mobile ऐप, /db माईग्रेशन्स और सीड्स, /scripts सेटअप हेल्पर्स।”
अगर आपने Koder.ai से एक्सपोर्ट किया है, तो एक्सपोर्ट को इस क्लीनअप पास की शुरुआत मानें: जनरेटेड कचरा हटाएँ, ignore नियमों की पुष्टि करें, और डायरेक्टरी मैप लिखें।
हैंडऑफ तब चुपचाप फेल होता है जब CI लोकल से लगभग वही है। अगर कोई प्रोजेक्ट उनके लैपटॉप पर चल सकता है, तो CI को वही कमांड्स रन कर के वही परिणाम देना चाहिए।
प्रत्येक पुल रिक्वेस्ट पर CI से क्या साबित करवाना है, यह तय करें। अधिकांश टीमों को केवल कुछ चीज़ों की ज़रूरत होती है:
इंटीग्रेशन टेस्ट्स और डिप्लॉय स्टेप्स ठीक हैं, लेकिन केवल तभी शामिल करें जब वे भरोसेमंद और स्पष्ट रूप से सीमित हों।
CI स्टेप्स को लोकल कमांड्स के करीब रखें ताकि drift न हो। अगर लोकल make test है, तो CI भी make test चलाए। अगर आपके पास Makefile नहीं है, तो एक जोड़ने पर विचार करें और उसे साझा एंट्री पॉइंट के रूप में इस्तेमाल करें।
CI अक्सर इसलिए टूटता है क्योंकि वह छुपे कॉन्फ़िग पर निर्भर होता है। README में एक छोटा "CI variables" सेक्शन जोड़ें जिसमें CI जिन नामों की उम्मीद करता है वे लिखें। सार्वजनिक कॉन्फ़िग को सीक्रेट्स से अलग रखें।
उदाहरण नाम (अपने स्टैक के अनुसार समायोजित करें): APP_ENV, DATABASE_URL, PORT, JWT_SECRET, S3_BUCKET, STRIPE_API_KEY। CI में सीक्रेट्स हमेशा CI सीक्रेट स्टोर से आने चाहिए, कभी commit की फ़ाइलों से नहीं। Go + Postgres बैकएंड (Koder.ai एक्सपोर्ट्स में आम) के लिए यह भी नोट करें कि माईग्रेशन्स ऑटोमैटिक चलते हैं या एक स्पष्ट स्टेप चाहिए।
निर्धारित करें कौन से चेक मर्ज से पहले अनिवार्य हैं और उन्हें लिखकर रखें। सामान्यतः “lint + unit tests + build” काफी होता है। अगर आप वैकल्पिक जॉब्स (जैसे मोबाइल बिल्ड्स) जोड़ते हैं, तो उन्हें non-blocking रखें जब तक कि वास्तव में उनकी ज़रूरत न हो।
CI आउटपुट को डिबग के लिए आसान बनाएं: टूल वर्जन प्रिंट करें और स्पष्ट मेसेज के साथ फेल करें। पाइपलाइन स्थिर होने के बाद कैशिंग जोड़ें।
Maya को Koder.ai से एक एक्सपोर्टेड प्रोजेक्ट मिलता है। यह एक सामान्य सेटअप है: एक React वेब ऐप, एक Go API, और एक PostgreSQL डेटाबेस। उसे इसका क्लोन करके बिना अनुमान के वर्किंग स्क्रीन तक पहुँचना चाहिए।
उसके पहले 30 मिनट कुछ इस तरह दिखने चाहिए:
.env.example को .env में कॉपी करें (या वे मान शेल में सेट करें) दोनों web और api के लिए।एक गंदे हैंडऑफ में, उसे आम तौर पर तीन ब्लॉकर्स मिलते हैं।
पहला: ऐप बूट होता है, फिर किसी vague “missing config” एरर के साथ क्रैश हो जाता है। असली समस्या अक्सर एक अनदेखा वेरिएबल होता है जैसे AUTH_JWT_SECRET या अपेक्षित DATABASE_URL फ़ॉर्मैट। अगर README हर आवश्यक वेरिएबल सूचीबद्ध करे, सुरक्षित उदाहरण दिखाये, और बताए कि यह कहाँ उपयोग होता है, तो यह एक तेज़ फिक्स बन जाता है।
दूसरा: API स्टार्ट हो जाता है, पर हर पेज पर “no data” आता है या 500 एरर आता है। डेटाबेस मौजूद है, पर उसमे टेबल्स या सीड डेटा नहीं है। एक साफ़ हैंडऑफ में एक या दो भरोसेमंद कमांड होते हैं: माईग्रेशन्स चलाएँ, न्यूनतम डेमो डेटा सीड करें, और जब कुछ गड़बड़ हो तो रिसेट कमांड चलाएँ।
तीसरा: सब कुछ चल रहा है, पर फ्रंटेंड गलत पोर्ट की ओर पॉइंट कर रहा है। Maya localhost:3000 खोलती है, पर API localhost:8080 उम्मीद करता है, या CORS रीक्वेस्ट ब्लॉक कर देता है। यहाँ निरंतर डिफॉल्ट्स मदद करते हैं: एक जगह WEB_PORT, API_PORT, और API_BASE_URL सेट करें, और README में अपेक्षित लोकल URLs बताएं।
हैंडऑफ तब पूरा माना जाता है जब कोई और व्यक्ति क्लीन क्लोन से प्रोजेक्ट चला सके बिना सवाल पूछे। साबित करें कि प्रोजेक्ट प्लेटफ़ॉर्म के बाहर भी ज़िंदा रह सकता है।
फ्रेश मशीन या थ्रोअवे कंटेनर पर एक अंतिम "क्लीन क्लोन" टेस्ट करें। अपने मौजूदा फोल्डर, कैश किए हुए डिपेंडेंसीज़, या लोकल डेटाबेस का पुन:उपयोग न करें। README को बिल्कुल उसी तरह फॉलो करें। अगर आपको improvisation करनी पड़ी तो डॉक्स या स्क्रिप्ट्स ठीक करें जब तक कि आपको पुनरावृत्ति न मिल जाए।
तेज़ जाँचें जो अधिकांश फेल्यर्स पकड़ लेती हैं:
.env.example मौजूद हो, और हर आवश्यक वेरिएबल सुरक्षित उदाहरण मान के साथ समझाया गया हो।सामान्य फंदे बोरिंग होते हैं, इसलिए छूट जाते हैं:
अगला कदम: एक ओनर असाइन करें जो 24–48 घंटे के अंदर एक्सपोर्ट को वैलिडेट करे, न कि हफ्तों बाद। उनसे क्लीन क्लोन टेस्ट करवा कर गैप्स रिपोर्ट कराएँ।
अगर आप Koder.ai पर बना रहे हैं (koder.ai), तो इस चेकलिस्ट को अपने सामान्य वर्कफ़्लो का हिस्सा मानना मददगार है: रन पाथ को प्लानिंग मोड में लिखें, बड़े बदलावों से पहले स्नैपशॉट लें, और एक शेड्यूल पर सोर्स एक्सपोर्ट करें ताकि हैंडऑफ पैकेज अपडेटेड रहे।
एक स्थिर बिंदु चुनें और उसे स्रोत सत्य के रूप में मानें।
न्यूनतम रूप से प्रमुख चीज़ें शामिल करें:
.env.example और स्पष्ट env var डॉक्सकिसी भी संवेदनशील जानकारी या असली क्रेडेंशियल्स को शामिल न करें।
हर env var को एक जगह (आम तौर पर रूट README) में दस्तावेज़ करें और .env.example भेजें।
हर वेरिएबल के लिए लिखें:
सीक्रेट्स को commit न करें। केवल प्लेसहोल्डर्स commit करें।
सरल सेटअप:
.env.example में replace_me प्लेसहोल्डर्स.env (gitignored)साथ ही हर आवश्यक सीक्रेट कैसे जनरेट करें यह डॉक्यूमेंट करें (उदा., “ के लिए 32+ कैरेक्टर का रैंडम स्ट्रिंग बनाएं”)।
किसी भी चीज़ को रोटेट करें जो साझा या दोहराई गई हो सकती है।
एक व्यावहारिक रोटेशन क्रम:
.env अपडेट करेंएक्सपोर्ट को एक नए वातावरण की तरह मानें और साफ-सुथरा शुरू करें।
पहला रन “कॉपि-पेस्ट-रन” जैसा बनाएं:
अगर प्रोजेक्ट को Docker या Make की जरूरत है, तो स्पष्ट रूप से बताएं—लोग़ों को एरर से खुद पता न चले।
हाँ—क्योंकि PostgreSQL के मेजर वर्जन और टूल वर्जन व्यवहार बदल सकते हैं।
कम से कम रिकॉर्ड करें:
जहां संभव हो वर्जन पिन करें, और CI में टूल वर्जन प्रिंट करें ताकि फेल्यर्स डिबग करना आसान हो।
एक “शून्य से” दोहराने योग्य पाथ दें:
विनाशकारी क्रियाओं पर गार्डरेइल्स जोड़ें (उदा., APP_ENV=development या कन्फर्मेशन फ्लैग)।
CI को लोकल कमांड्स के करीब रखें और कॉन्फ़िग स्पष्ट बनाएं:
यदि माईग्रेशन्स टेस्ट के लिए आवश्यक हैं, तो डॉक्यूमेंट करें कि CI उन्हें ऑटोमेटिक चलाता है या नहीं।
एक “क्लीन क्लोन” टेस्ट चलाएँ:
अगर आपको एक बार भी improvisation करना पड़ा, तो डॉक्स या स्क्रिप्ट्स को ठीक करें जब तक कि आप बिना improvisation के सफल क्लोन न कर सकें। यह सबसे तेज़ तरीका है यह पकड़ने का कि मूल बिल्ड वातावरण में कौन-कौन सी छुपी धारणाएँ थीं (जिसमें vibe-coding प्लेटफ़ॉर्म जैसे Koder.ai भी शामिल हैं)।
JWT_SECRET