ਸਿੱਖੋ ਕਿ vibe-coding ਪਲੇਟਫਾਰਮ ਤੋਂ ਸੋਰਸ ਕੋਡ ਕਿਵੇਂ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਿਰਯਾਤ ਕਰਨਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਮਾਲਕੀਅਤ ਲੈਣੀ ਹੈ: ਲੋਕਲ ਤੇ ਚਲਾਉਣਾ, CI ਸੈਟਅਪ, ਸੀਕ੍ਰੇਟਸ ਸੰਭਾਲਣਾ, ਅਤੇ handoff-ਤਿਆਰ ਰਿਪੋ ਤਿਆਰ ਕਰਨਾ।
कोਡ ਦਾ ਮਾਲਕ ਹੋਣਾ ਸਿਰਫ਼ ਪਲੇਟਫਾਰਮ ਤੋਂ ਇਕ zip ਫਾਈਲ ਮਿਲਣ ਦਾ ਮਤਲਬ ਨਹੀਂ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਮੁਢਲੇ ਵਰਕਸਪੇਸ, ਖਾਸ ਬਟਨਾਂ ਜਾਂ ਛੁਪੇ ਸੈਟਿੰਗਾਂ ਦੀ ਲੋੜ ਦੇ, ਐਪ ਨੂੰ ਬਣਾਉਣ, ਚਲਾਉਣ, ਬਦਲਣ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਹੋ। ਇਕ ਪ੍ਰੋਜੈਕਟ ਜੋ ਤੁਸੀਂ ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ ਮਾਲਕ ਹੋ, ਉਹ ਕਿਸੇ ਸਧਾਰਣ ਰਿਪੋ ਵਰਗ ਵਰਤਦਾ ਹੈ: ਨਵਾਂ ਟੀਮਮੈਟ ਕਲੋਨ ਕਰ ਸਕਦਾ ਹੈ, ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ ਚਾਲੂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਮਿਆਰੀ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਡਿਪਲੌਯ ਕਰ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ lock-in ਦੀ ਚਿੰਤਾ ਉਹਨਾਂ ਥੋੜ੍ਹੀਆਂ ਗੱਲਾਂ ਤੋਂ ਹੁੰਦੀ ਹੈ:
ਹੋਰ ਆਮ ਹੈਰਾਨੀ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ ਹੋਸਟ ਕੀਤੇ ਵਰਜਨ ਤੇ ਐਪ ਠੀਕ ਚੱਲਦਾ ਹੋਵੇ ਪਰ ਲੋਕਲ ਤੇ ਫੇਲ ਹੋ ਜਾਵੇ ਕਿਉਂਕਿ ਵਾਤਾਵਰਣ ਵੇਰਵਿਆਂ, ਡੇਟਾਬੇਸ ਸੈਟਅਪ ਜਾਂ ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਕਦੇ ਖੁਲਾਸਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।
vibe-coding ਪਲੇਟਫਾਰਮ ਤੋਂ ਇੱਕ ਸਾਫ਼ ਐਕਸਪੋਰਟ ਚਾਰ ਨਤੀਜੇ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:
ਇਹ ਗੱਲ ਮਹੱਤਵਪੂਰਨ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਕਦੇ ਪਲੇਟਫਾਰਮ ਛੱਡਣ ਦਾ ਸੋਚਦੇ ਹੀ ਨਾ ਹੋਵੋ। ਵਧੀਆ ਮਾਲਕੀਅਤ ਇੱਕ ਬੀਮਾ ਹੈ: ਇਹ ਖ਼ਤਰਾ ਘਟਾਉਂਦੀ ਹੈ, ਆਡਿਟਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਏਜੰਸੀ ਨੌਕਰੀ 'ਤੇ ਲੈਓ, ਫੰਡ ਰੇਜ ਕਰਦੇ ਹੋ ਜਾਂ ਟੀਮ ਬਦਲਦੇ ਹੋ ਤਾਂ ਨੇਗੋਸ਼ੀਏਸ਼ਨ ਸਧਾਰਨ ਰਹਿੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਐਕਸਪੋਰਟ ਵਿੱਚ ਆਮ ਸਟੈਕ ਮਿਲ ਸਕਦੇ ਹਨ ਜਿਵੇਂ ਕਿ React ਵੈੱਬ ਐਪ, Go ਬੈਕਐਂਡ, PostgreSQL, ਜਾਂ Flutter ਮੋਬਾਈਲ ਐਪ। ਸਟੈਕ ਤੋਂ ਵੱਧ ਲੋੜੀਨੁਮਾ ਗੱਲ ਇਹ ਹੈ: ਚੱਲਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹਰ ਚੀਜ਼ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦਿੱਖਣੀ ਚਾਹੀਦੀ ਹੈ, ਹੋਸਟ ਕੀਤੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਫੈਸਲਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਫਾਊਂਡਰ ਨੂੰ ਸੋਚੋ ਜੋ ਐਪ ਇੱਕ ٹھੇਕੇਦਾਰ ਨੂੰ ਦੇ ਰਿਹਾ ਹੈ। "ਇੱਥੇ ਰਿਪੋ ਹੈ" ਕਹਿਣਾ ਕਾਫ਼ੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ٹھੇਕੇਦਾਰ ਨੂੰ ਮੁਢਲੇ ਪਲੇਟਫਾਰਮ ਪ੍ਰੋਜੈਕਟ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ ਕਿ API ਬੇਸ URL ਲੱਭਣ, ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਬਣਾਉਣ ਜਾਂ ਫਰੰਟਐਂਡ ਕਿਵੇਂ ਬਣਦਾ ਹੈ ਸਮਝਣ ਲਈ।
ਐਕਸਪੋਰਟ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਆਮ ਰਿਪੋ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਐਡੀਟਰ ਵਿੱਚ ਖੋਲ੍ਹ ਸਕੋ, ਆਪਣੀ ਲੈਪਟੌਪ 'ਤੇ ਚਲਾ ਸਕੋ, ਅਤੇ ਮੁੜ-ਹਾਦੀ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਟੀਮ ਨੂੰ ਦੇ ਸਕੋ ਬਿਨਾਂ ਮੁਢਲੇ ਪਲੇਟਫਾਰਮ ਦੀ ਲੋੜ ਦੇ।
Koder.ai ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ, ਐਕਸਪੋਰਟ ਆਮ ਤੌਰ 'ਤੇ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਸਰੂਪਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਇੱਕ React ਵੈੱਬ ਐਪ, ਇੱਕ Go ਬੈਕਐਂਡ, ਅਤੇ (ਜੇ ਤੁਸੀਂ ਬਣਾਇਆ) ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ। ਫੋਲਡਰਾਂ ਦੇ ਨਾਮ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਰਿਪੋ ਨੂੰ ਇਹ ਸਪੱਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਰ ਹਿੱਸਾ ਕਿੱਥੇ ਹੈ ਅਤੇ ਉਹ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਐਂਟਰੀ ਪੌਇੰਟ ਅਤੇ ਮਨਜ਼ੂਰ ਕੀਤੀ ਵਰਕਫਲੋ ਲੱਭੋ। ਤੁਹਾਨੂੰ ਹਰ ਐਪ ਫਾਈਲ ਦੀ ਉਹ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ ਜੋ ਐਪ ਨੂੰ ਬੂਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹ ਸਕ੍ਰਿਪਟਸ ਜਿਹੜੇ ਦੱਸਦੇ ਹਨ ਕਿ ਵਿਕਾਸ ਅਤੇ ਚਲਾਣ ਦਾ ਤਰੀਕਾ ਕੀ ਹੈ।
ਆਮ ਨਿਸ਼ਾਨ:
package.json ਨਾਲ ਇੱਕ src/ ਫੋਲਡਰ (ਅਕਸਰ main.tsx ਜਾਂ ਸਮਾਨ)go.mod ਅਤੇ cmd/ ਫੋਲਡਰ ਜਾਂ main.gopubspec.yaml ਅਤੇ lib/main.dartREADME ਜਾਂ Makefile ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈdocker-compose.ymlਡਿਪੈਂਡੈਂਸੀਜ਼ pinned ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। JavaScript ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਈ lockfile موجود ਹੋਵੇ (package-lock.json, yarn.lock, ਜਾਂ pnpm-lock.yaml)। Go ਲਈ, go.mod ਅਤੇ go.sum ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। pinned ਨਾ ਹੋਣ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਅਸੰਭਵ ਨਹੀਂ ਬਣਦਾ, ਪਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ builds ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਕਨਫਿਗਰੇਸ਼ਨ ਕੋਡ ਤੋਂ ਅਲੱਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। .env.example ਜਾਂ config.example.yaml ਵਰਗੀਆਂ ਉਦਾਹਰਣਾਂ ਲਈ ਤਲਾਸ਼ ਕਰੋ। ਤੁਸੀਂ ਅਸਲੀ ਸੀਕ੍ਰੇਟਸ (API key, ਪ੍ਰੋਡੈਕਸ਼ਨ ਪਾਸਵਰਡ) ਕਦੇ ਵੀ export ਵਿੱਚ commit ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ। ਜੇ ਤੁਸੀਂ ਦੇਖੋ, ਤਾਂ ਉਸਨੂੰ ਲੀਕ ਸਮਝੋ ਅਤੇ ਰੋਟੇਟ ਕਰੋ।
ਡੇਟਾਬੇਸ ਲਈ, migrations ਫੋਲਡਰ ਲੱਭੋ (migrations/, db/migrations/) ਜਾਂ ਟਾਈਮਸਟੈਂਪ ਵਾਲੀਆਂ SQL ਫਾਈਲਾਂ। Go + PostgreSQL ਐਪ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ migration runner ਜਾਂ script ਵੀ ਵੇਖ ਸਕਦੇ ਹੋ ਜੋ migrations ਲਗਾਉਂਦਾ ਹੈ।
ਇੱਕ ਤੇਜ਼ sanity ਚੈੱਕ: build ਅਤੇ run commands ਪਹਿਲਾਂ ਲੱਭੋ (npm run dev, go run, make ਆਦਿ)। ਜੇ ਕੋਈ ਸਕ੍ਰਿਪਟ ਪਲੇਟਫਾਰਮ-ਖਾਸ ਕਮਾਂਡ ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਿਪੋ ਨੂੰ ਸਵਤੰਤਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਸਧਾਰਨ ਟੂਲਿੰਗ ਨਾਲ ਬਦਲੋ।
ਐਕਸਪੋਰਟ ਨੂੰ ਇੱਕ release artifact ਵਾਂਗ ਸਮਝੋ। ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਛੋਟੀ "ਕੀ ਸਭ ਇੱਥੇ ਹੈ?" ਜਾਂਚ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਕਰਨ ਨੂੰ ਸ਼ੁਰੂ ਕਰੋਗੇ ਤਾਂ ਗੁੰਮ ਹੋਏ ਹਿੱਸੇ ਫੜਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ।
ਇੱਕ ਵਿਹਾਰਕ completeness ਚੈੱਕ ਇਹ ਹੈ ਕਿ ਹਰ ਹਿੱਸੇ ਦੇ "root" ਲੱਭੋ: React ਵੈੱਬ ਐਪ ਲਈ package.json, Go ਬੈਕਐਂਡ ਲਈ go.mod, ਅਤੇ PostgreSQL ਲਈ migration/seed ਫਾਈਲਾਂ।
Export ਕੀਤੇ ਫੋਲਡਰ ਤੋਂ ਇੱਕ ਨਵਾਂ Git ਰਿਪੋ ਬਣਾਓ, ਫਿਰ ਉਸ ਵਿੱਚ ਜੋ ਕੁਝ ਮਿਲਿਆ ਉਹੀ ਬਿਨਾਂ ਬਦਲਾਅ commit ਕਰੋ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ਼ ਬੇਸਲਾਈਨ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਾਲੇ ਬਦਲਾਅ ਆਸਾਨੀ ਨਾਲ ਰਿਵਿਊ ਹੋ ਸਕਦੇ ਹਨ।
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
ਇੱਕ ਸਰਵਰ ਬੂਟ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਐਪ ਫ਼ਿਰ ਵੀ ਟੁੱਟੀ ਹੋ ਸਕਦੀ ਹੈ। ਪੱਕਾ ਕਰੋ ਕਿ ਇਹ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਦੋਹਾਂ ਕਰ ਸਕਦਾ ਹੈ।
ਛੋਟੀਆਂ ਜਾਂਚਾਂ ਚੁਣੋ ਜੋ ਉਤਪਾਦ ਨਾਲ ਮਿਲਦੀਆਂ हों:
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਲੋਕਲ ਤੇ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਰਨ ਹੋਵੇ, ਆਪਣੇ scratch ਨੋਟਸ ਨੂੰ ਇੱਕ ਅਸਲੀ README.md ਵਿੱਚ ਬਦਲ ਦਿਓ: ਕਿੱਥੇ ਕਮਾਂਡ ਦੌੜਾਉਣੀਆਂ ਹਨ, ਸੇਵਾਵਾਂ ਦਰਜ ਕਰਨ ਦਾ ਆਰਡਰ, ਅਤੇ ਕਿਹੜੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਲਾਜ਼ਮੀ ਹਨ।
ਇਕਸਪੋਰਟ ਚੱਲ ਸਕਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ "generated" ਜਿਹਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਮਾਲਕੀਅਤ ਵਾਲਾ। ਇੱਕ handoff-ਤਿਆਰ ਰਿਪੋ ਦੇ ਨਾਲ ਇਹ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਹਨ, ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਉਹ consistent ਰੱਖਣੀਆਂ ਹਨ।
ਟੌਪ-ਲੇਵਲ ਲੇਆਉਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਨਾਮ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ, ਲਗਾਤਾਰਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
apps/ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਫਰੰਟਐਂਡ (web, mobile) ਲਈservices/ ਬੈਕਐਂਡ APIs, ਵర్కਰز, ਅਤੇ ਜਾਬਜ਼ ਲਈshared/ ਸ਼ੇਅਰ ਕੀਤੇ ਟਾਈਪਸ ਅਤੇ ਯੂਟਿਲਿਟੀਜ਼ ਲਈinfra/ ਡਿਪਲੌయਮੈਂਟ ਟੈਂਪਲੇਟ, ਸਕ੍ਰਿਪਟ ਅਤੇ ਵਾਤਾਵਰਣ ਉਦਾਹਰਣਾਂ ਲਈdocs/ ਆਰਕੀਟੈਕਚਰ ਨੋਟਸ ਅਤੇ ਰਨਬੁੱਕਸ ਲਈਫਿਰ ਕੁਝ ਛੋਟੀ ਫਾਈਲਾਂ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀਆਂ ਹਨ:
README.md ਪ੍ਰਿਰਕੀਜੀ ਅਤੇ ਸਹੀ ਕਮਾਂਡਸ ਨਾਲCONTRIBUTING.md ਕੁਝ ਨਿਯਮਾਂ ਨਾਲ (ਬ੍ਰਾਂਚ, PRs, ਕੋਈ ਸੀਕ੍ਰੇਟ ਨਹੀ).gitignore ਲੋਕਲ env ਫਾਈਲਾਂ ਅਤੇ ਬਿਲਡ ਆਉਟਪੁੱਟ ਗਿੱਟ ਤੋਂ ਬਾਹਰ ਰੱਖਣ ਲਈREADME ਨੂੰ ਵਰਤਣ ਯੋਗ ਰੱਖੋ। ਜੇ ਰਿਪੋ ਵਿੱਚ ਕਈ ਹਿੱਸੇ ਹਨ (React ਫਰੰਟਐਂਡ, Go API, PostgreSQL), ਤਦ ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਆਰਡਰ ਅਤੇ ਕਿੱਥੇ ਕਨਫਿਗ ਰਹਿੰਦੀ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, ".env.example ਨੂੰ .env ਵਿੱਚ ਕਾਪੀ ਕਰੋ") ਸਪਸ਼ਟ ਲਿਖੋ।
ਇੱਕ ਨਵੀਂ ਮਸ਼ੀਨ 'ਤੇ ਕੰਮ ਚੈੱਕ ਕਰੋ: ਨਵਾਂ ਫੋਲਡਰ ਬਣਾਕੇ ਕਲੋਨ ਕਰੋ ਅਤੇ ਆਪਣੀ README ਫੋਲੋ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ export ਕੀਤੀ ਸੀ, ਤਦ export ਨੂੰ ਨਵੀਂ ਸੁਤੰਤਰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ commit ਵਜੋਂ ਲਓ ਅਤੇ ਫਿਰ ਹੀ ਦੂਜਿਆਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ।
ਛੇਤੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਇੱਕ ਚੰਗਾ ਲੋਕਲ ਸੈਟਅਪ ਇਹ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਨਵਾਂ ਵਿਅਕਤੀ 15 ਮਿੰਟ ਵਿੱਚ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ ਐਪ ਚਲਾ ਸਕਦਾ ਹੈ?
ਇੱਕ ਡਿਫਾਲਟ ਲੋਕਲ ਅਪ੍ਰੋਚ ਚੁਣੋ ਅਤੇ ਸਪਸ਼ਟ ਹੋਵੋ। ਨੈਟਿਵ ਇੰਸਟਾਲ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਜਿਹੜੇ ਲੋਕ ਪਹਿਲਾਂ ਹੀ ਸੰਦ ਰੱਖਦੇ ਹਨ। ਕੰਟੇਨਰਜ਼ ਹਰੇਕ ਮਸ਼ੀਨ 'ਤੇ ਇੱਕਸਾਰ ਹਨ ਪਰ ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ ਓਵਰਹੈਡ ਲਿਆਉਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਦੋਹਾਂ ਸਹਿਯੋਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਨੂੰ ਡਿਫਾਲਟ ਅਤੇ ਦੂਜੇ ਨੂੰ ਵਿਕਲਪ ਤੌਰ 'ਤੇ ਨਿਸ਼ਾਨ ਲਗਾਓ।
ਇੱਕ ਸਧਾਰਣ ਪੈਟਰਨ ਜੋ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕ README ਪੰਨਾ, ਇੱਕ ਨਮੂਨਾ env ਫਾਈਲ, ਅਤੇ ਇੱਕ bootstrap ਕਮਾਂਡ।
ਨਮੂਨੇ ਵਾਲੀ ਫਾਈਲ commit ਕਰੋ ਜਿਸ ਵਿੱਚ ਨਕਲੀਆਂ ਕੁੱਲਮਾਂ ਹਨ ਤਾਂ ਜੋ ਲੋਕ ਜਾਣ ਸਕਣ ਕਿ ਕੀ ਭਰਣਾ ਹੈ ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਲੀਕ ਕੀਤੇ।
# .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 ਕਿਵੇਂ ਬਣਦੀ ਹੈ, migrations ਕਿਵੇਂ ਚਲਦੇ ਹਨ, ਅਤੇ realistic ਪਹਿਲੀ ਰਨ ਲਈ seed ਡਾਟਾ ਕਿੱਥੇ ਮਿਲਦਾ ਹੈ।
ਅੰਤੀਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਛੋਟਾ health check ਜੋ ਲੋਕਾਂ ਨੂੰ ਵਿਸ਼ਵਾਸ ਦਿਵਾਏ ਕਿ ਐਪ ਚੱਲ ਰਿਹਾ ਹੈ, ਸ਼ਾਮਲ ਕਰੋ। ਇੱਕ ਛੋਟਾ endpoint ਜਿਵੇਂ GET /health ਜੋ "ok" ਰੀਟਰਨ ਕਰੇ (ਅਤੇ ਡੇਟਾਬੇਸ ਕਨੈਕਟਿਵਿਟੀ ਵੇਰੀਫਾਈ ਕਰੇ) ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨਿਰਯਾਤ ਕਰਦੇ ਹੋ, ਕੋਡ ਤੁਹਾਡਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸੀਕ੍ਰੇਟਸ ਨਿੱਜੀ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। ਸਮਝੋ ਕਿ ਰਿਪੋ ਨਵੇਂ ਟੀਮਮੈਟਸ ਨਾਲ ਸਾਂਝੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਲਿਖੋ ਕਿ ਐਪ ਚਲਾਉਣ ਲਈ ਕੀ-ਕੀ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਕੋਡ ਨੂੰ skim ਕਰੋ ਕਿ ਕਿੱਥੋਂ ਕਨਫਿਗ पढ़ੀ ਜਾ ਰਹੀ ਹੈ (environment variables, config files) ਅਤੇ ਉਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਚੈਕ ਕਰੋ ਜੋ ਤੁਸੀਂ ਐਨੇਬਲ ਕੀਤੇ ਸਨ।
ਆਮ ਤੌਰ 'ਤੇ ਸੀਕ੍ਰੇਟਸ ਇਨਵੈਂਟਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ: ਡੇਟਾਬੇਸ ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ, ਤੀਸਰੇ-ਪਾਸੇ API key, auth ਸੈਟਿੰਗ (OAuth ਜਾਂ JWT), ਸਟੋਰੇਜ ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ, ਅਤੇ ਐਪ-ਖਾਸ ਸੀਕ੍ਰੇਟਸ ਜਿਵੇਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼ ਜਾਂ webhook ਸਾਈਨਿੰਗ ਸੀਕ੍ਰੇਟ।
ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਹਰ ਸੀਕ੍ਰੇਟ ਕਿੱਥੇ ਰਹੇਗਾ ਇਹ ਫੈਸਲਾ ਕਰੋ। ਇੱਕ ਚੰਗਾ ਡਿਫਾਲਟ ਨਿਯਮ:
.env (commit ਨਾ ਕਰੋ)ਜੇ ਤੁਸੀਂ vibe-coding ਜਿਹੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਨਿਰਯਾਤ ਕੀਤਾ ਹੈ (ਜਿਵੇਂ Koder.ai), ਤਾਂ ਮਨ ਲਵੋ ਕਿ ਚੈਟ, ਲੋਗਜ਼, ਜਾਂ ਸੈਟਿੰਗ ਪੈਨਲ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਕਈ ਵਾਰੀ ਨਕਲ ਹੋ ਸਕਦੀ ਹੈ। ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਰਿਪੋ ਤੋਂ ਤੁਰੰਤ ਬਾਹਰ ਲੈ ਜਾਓ।
ਅਮਲ ਦਾ ਇਕ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸੁਰੱਖਿਅਤ ਟੈਮਪਲੇਟ commit ਕਰੋ (ਜਿਵੇਂ .env.example), ਅਸਲੀ ਮੁੱਲ Git ਵਿੱਚ ਨਾ ਰੱਖੋ (.env ਨੂੰ .gitignore ਵਿੱਚ ਜੋੜੋ), ਅਤੇ ਪ੍ਰੋਡੈਕਸ਼ਨ 'ਤੇ deploy ਵੇਲੇ ਸੀਕ੍ਰੇਟਸ inject ਕਰੋ।
ਜੇ ਐਕਸਪੋਰਟ ਦੌਰਾਨ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਸੀਕ੍ਰੇਟਸ ਲੀਕ ਹੋਣ ਦਾ ਸੰਭਾਵਨਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਰੋਟੇਟ ਕਰੋ। ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ, OAuth client secrets, ਅਤੇ webhook signing keys ਨੂੰ ਪਹਿਲੇ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ।
ਕੁਝ guardrails ਜੋ ਇਹ ਦੋਹਰਾਉਣ ਤੋਂ ਰੋਕ ਸਕਦੇ ਹਨ: obvious secret patterns ਲਈ pre-commit ਚੈੱਕ, CI ਵਿੱਚ secret scan, ਸਖਤ config loading ਜੋ required variables ਨਹੀਂ ਮਿਲਣ ਤੇ fail ਕਰੇ, ਅਤੇ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਲਈ ਵੱਖ-ਵੱਖ credentials।
ਇੱਕ ਛੋਟੀ SECRETS.md ਨਾਲ ਹandoff ਆਸਾਨ ਬਣਾਓ। ਸਧਾਰਨ ਰੱਖੋ: ਲਾਜ਼ਮੀ ਵੇਰੀਏਬਲ, ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿੱਥੇ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੌਣ ਰੋਟੇਟ ਕਰ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਮਾਲਕੀਅਤ ਲੈ ਲੈਂਦੇ ਹੋ, CI ਤੁਹਾਡੀ safety net ਹੈ। ਪਹਿਲਾ ਵਰਜਨ ਛੋਟਾ ਰੱਖੋ। ਹਰ push ਤੇ ਇਹ ਸਾਬਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਅਜੇ ਵੀ build ਹੁੰਦਾ ਹੈ, ਮੂਢਲੇ checks ਪਾਸ ਹੁੰਦੇ ਹਨ, ਅਤੇ tests ਚਲ ਰਹੇ ਹਨ (ਜੇ ਹੋਣ)।
CI ਨੂੰ ਇਕ ਛੇਤੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: "ਕੀ ਇਹ ਬਦਲਾਅ merge ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ?" ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਜ਼ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ dependencies install, build, lint, ਅਤੇ unit tests ਚਲਾਉਣਾ।
ਜੋਬਜ਼ ਨੂੰ ਐਪ ਦੇ ਹਿੱਸਿਆਂ ਅਨੁਸਾਰ ਵੰਡੋ ਤਾਂ ਜੋ ਫੇਲਯਰ ਸਪੱਸ਼ਟ ਹੋ ਜਾਵੇ:
ਕੈਸ਼ਿੰਗ ਵਰਤੋਂ, ਪਰ ਕੈਸ਼ ਸਮੱਸਿਆਆਂ ਨੂੰ ਲੁਕਾਉਣ ਨਾ ਦਿਓ। ਜਦੋਂ caches miss ਕਰਦੇ ਹਨ, CI ਫਿਰ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਧੀਮਾ ਹੋਵੇ।
ਹਰ ਇੱਕ ਸਰੁਪ ਲਈ ਇੱਕ single command ਪ੍ਰਿਫਰ ਕਰੋ (make test, npm run test), ਤਾਂ ਕਿ ਉਹੀ command ਲੋਕਲ ਅਤੇ CI ਦੋਹਾਂ ਵਿੱਚ ਕਮ ਕਰੇ। ਇਹ ਗੁੰਝਲਦਾਰੀਆਂ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਲੌਗ ਲੰਬੇ ਨਹੀਂ ਹੁੰਦੇ।
ਉਦਾਹਰਣ ਸਰੂਪ (ਆਪਣੇ ਰਿਪੋ ਦੇ ਨਾਂ ਅਨੁਸਾਰ ਬਦਲੋ):
jobs:
web:
steps:
- run: npm ci
- run: npm run lint
- run: npm run build
api:
steps:
- run: go test ./...
- run: go build ./...
ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਸਧਾਰਣ ਰਿਲੀਜ਼ ਫਲੋ ਜੋੜੋ: ਰਿਲੀਜ਼ ਟੈਗ ਕਰੋ, ਅਰਟੀਫੈਕਟ ਬਣਾਓ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ CI ਆਰਟੀਫੈਕਟ ਵਜੋਂ ਰੱਖੋ। ਭਾਵੇਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਅੱਜ ਪਲੇਟਫਾਰਮ ਤੋਂ deploy ਕਰ ਰਹੇ ਹੋ, ਪਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ artifacts ਹੋਣ ਨਾਲ مستقبل ਵਿੱਚ ਹੋਸਟ ਬਦਲਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨਾ ਅੱਧਾ ਕੰਮ ਹੈ। ਦੂਜਾ ਅੱਧਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਬਾਹਰ ਆ ਕੇ ਵੀ ਇੱਕੋ ਜਿਹਾ ਵਰਤਾਵ ਕਰੇ।
ਏਕਸਪੋਰਟ ਅਕਸਰ environment variables, migrations, seed data, ਅਤੇ build steps 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਲਈ ਸੈੱਟ ਕੀਤੇ ਗਏ ਸਨ। ਪਹਿਲੀ ਵਾਰ ਖਾਲੀ ਸਕਰੀਨ ਜਾਂ ਡੇਟਾਬੇਸ ਏਰਰ ਨਾਰਮਲ ਹੈ।
ਇੱਕ ਬੇਸਲਾਈਨ ਰਨ ਕਰੋ ਪਹਿਲਾਂ: deps install, env vars ਸੈੱਟ ਕਰੋ, migrations ਚਲਾਓ, ਸਰਵਿਸਜ਼ ਆਰਡਰ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ। ਕੇਵਲ ਜਰੂਰੀ ਸੋਧ ਕਰੋ ਤਾਂ ਜੋ ਉਮੀਦ ਕੀਤੀ ਸੈਟਅਪ ਮਿਲ ਸਕੇ।
ਸਭ ਤੋਂ ਆਮ ਹਾਦਸਾ ਅਸਲੀ API keys ਜਾਂ password commit ਹੋ ਜਾਣਾ ਹੈ, ਅਕਸਰ .env ਫਾਈਲ ਦੀ ਨਕਲ ਕਰਦੇ ਸਮੇਂ।
ਸਿਰਫ਼ ਟੈਮਪਲੇਟ commit ਕਰੋ। ਅਸਲੀ ਮੁੱਲਾਂ ਲੋਕਲ environment ਜਾਂ secret store ਵਿੱਚ ਰੱਖੋ।
ਪੈਕੇਜ ਅੱਪਗਰੇਡ ਕਰਨ ਜਾਂ ਫੋਲਡਰਾਂ ਨੂੰ turhan ਕਰ ਦੇਣ ਨਾਲ ਇਹ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਸਮੱਸਿਆਐਂ ਐਕਸਪੋਰਟ ਤੋਂ ਆਈਆਂ ਹਨ ਜਾਂ ਤੁਹਾਡੇ ਬਦਲਾਅ ਤੋਂ।
ਪਹਿਲਾਂ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਰਨ ਲੱਭੋ, ਫਿਰ ਛੋਟੇ, ਵੱਖ-ਵੱਖ commits ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ।
"ਮੇਰੀ ਮਸ਼ੀਨ ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ" ਅਕਸਰ unpinned tool versions (Node, Go, Flutter, package managers) ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
ਰਨਟਾਈਮ ਵਰਜਨਾਂ ਨੂੰ ਕਿਸੇ ਸਪੱਸ਼ਟ ਥਾਂ 'ਤੇ ਪਿਨ ਕਰੋ (ਫਾਈਲ ਜਾਂ README), lockfiles (package-lock, go.sum, pubspec.lock) ਰੱਖੋ, ਅਤੇ ਸੈਟਅਪ ਨੂੰ ਦੂਜੀ ਮਸ਼ੀਨ ਜਾਂ ਇੱਕ ਤਾਜ਼ਾ ਕੰਟੇਨਰ 'ਤੇ ਵੇਰੀਫਾਈ ਕਰੋ।
Handoffs ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਇੱਕ ਅਜਿਹੇ ਛੋਟੇ ਕਦਮ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ ਜੋ ਐਪ start ਕਰਨ ਲਈ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਨੋਟ ਕਰ ਲਓ ਜਦੋਂ ਚੀਜ਼ਾਂ ਤਾਜ਼ਾ ਹਨ: ਲਾਜ਼ਮੀ env vars, migrations ਕਿਵੇਂ ਚਲਾਉਣੇ ਹਨ, ਲੋਗ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਲੋਕਲ ਸਟੇਟ ਰੀਸੈਟ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।
ਇੱਕ ਤਿੰਨ-ਵਿਆਕਤੀ ਟੀਮ Koder.ai ਵਿੱਚ ਇੱਕ customer portal ਬਣਾਉਂਦੀ ਹੈ: React ਵੈੱਬ ਐਪ, Go API, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ। ਜਦੋਂ ਉਹ ਬਾਹਰੀ dev ਟੀਮ ਨੂੰ ਸੌਂਪਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਐਕਸਪੋਰਟ ਇੱਕ ਆਮ ਰਿਪੋ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ ਜੋ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਦਿਨ ਇੱਕ 'ਤੇ ਚੱਲ ਸਕੇ।
Day 1: ਉਹ export ਕਰਦੇ ਹਨ, ਇੱਕ ਨਵਾਂ Git ਰਿਪੋ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਲੋਕਲ ਤੇ ਚਲਾਉਂਦੇ ਹਨ। ਫਰੰਟਐਂਡ ਚੱਲ ਜਾਂਦਾ ਹੈ, ਪਰ API fail ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ environment variables ਮੌਜੂਦ ਨਹੀਂ। ਉਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਂਦੇ। ਉਹ ਕੋਡ ਪੜ੍ਹਦੇ ਹਨ, ਸਹੀ ਕੀ-ਕੀ ਕੁੰਜੀਆਂ ਦੀ ਪਛਾਣ ਕਰਦੇ ਹਨ, ਅਤੇ .env.example ਬਣਾਉਂਦੇ ਹਨ placeholders ਨਾਲ। ਅਸਲੀ ਮੁੱਲ password manager ਅਤੇ ਲੋਕਲ .env ਫਾਈਲਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ।
ਉਹ ਨੋਟਿਸ ਕਰਦੇ ਹਨ ਕਿ ਪੋਰਟ ਅਤੇ CORS ਸੈਟਿੰਗਾਂ ਪਲੇਟਫਾਰਮ 'ਤੇ ਠੀਕ ਸਨ ਪਰ ਲੋਕਲ ਲਈ defaults ਲੋੜੀਂਦੇ ਹਨ। ਉਹ ਪੇਸ਼ਗੀ defaults ਰੱਖਦੇ ਹਨ (ਉਦਾਹਰਣ ਲਈ, API 8080 'ਤੇ ਅਤੇ web 3000 'ਤੇ) ਤਾਂ ਜੋ ਨਵੀਆਂ ਮਸ਼ੀਨਾਂ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ।
Day 2: ਉਹ migrations ਅਤੇ ਇੱਕ ਛੋਟਾ seed script ਜੋ demo user ਅਤੇ ਕੁਝ rows ਬਣਾਉਂਦਾ ਹੈ ਜੋੜਦੇ ਹਨ। ਫਿਰ ਉਹ ਇੱਕ ਛੋਟਾ README ਲਿਖਦੇ ਹਨ ਜੋ prerequisites, ਰਨ ਕਰਨ ਵਾਲੀਆਂ ਕਮਾਂਡ, ਅਤੇ ਕਿਵੇਂ verify ਕਰਨਾ ਹੈ (API ਲਈ health endpoint ਅਤੇ UI ਲਈ sample login) ਕਵਰ ਕਰਦਾ ਹੈ।
Day 3: ਉਹ ਇੱਕ ਬੁਨਿਆਦੀ CI workflow ਜੋ tests, linting, ਅਤੇ builds ਦੋਹਾਂ ਲਈ ਹਰ pull request 'ਤੇ ਚਲਦੀ ਹੈ ਜੋੜਦੇ ਹਨ। staging ਲਈ, ਉਹ ਇੱਕ ਸਧਾਰਣ ਯੋਜਨਾ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹਨ: containers build ਕਰੋ, environment ਵਿੱਚ secrets ਸੈੱਟ ਕਰੋ, deploy 'ਤੇ migrations ਚਲਾਓ, ਅਤੇ rollback ਵਿਕਲਪ ਰੱਖੋ।
Acha handoff ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਐਸਾ ਰਿਪੋ ਹੁੰਦਾ ਹੈ ਜੋ fresh clone ਤੋਂ ਲੋਕਲ ਤੇ ਚੱਲਦਾ ਹੈ, .env.example ਨਾਲ ਨੋਟਸ ਕਿ ਸੀਕ੍ਰੇਟਸ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ, migrations ਅਤੇ seed ਡਾਟਾ, CI checks ਜੋ ਫੈਲ ਹੋ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਦੱਸਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟਾ deploy ਨੋਟ staging ਅਤੇ rollback ਲਈ।
ਆਪਣੀ ਅਧੀਨਤਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਾਬਤ ਕਰੋ ਕਿ ਪ੍ਰੋਜੈਕਟ ਪਲੇਟਫਾਰਮ ਤੋਂ ਬਾਹਰ ਜੀਊਂਦਾ ਰਹਿ ਸਕਦਾ ਹੈ। ਜੇ ਇਕ ਹੋਰ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਚਲਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਚੰਗੀ ਸਥਿਤੀ ਵਿੱਚ ਹੋ।
ਆਖਰੀ ਚੈੱਕਲਿਸਟ ਵਰਤੋ:
ਤਕਨੀਕੀ ਜਾਂਚ ਤੋਂ ਬਾਅਦ, ਮਾਲਕੀਅਤ ਸਪੱਸ਼ਟ ਬਣਾਓ। ਫੈਸਲਾ ਕਰੋ ਕਿ dependency updates, infrastructure ਬਦਲਾਅ (ਡੇਟਾਬੇਸ, queues, DNS), ਅਤੇ releases ਦੀ ਕੋਣ ਮਾਲਕ ਹੈ। ਜੇ ਕੋਈ ਮਾਲਕ ਨਹੀਂ, ਤਾਂ ਰਿਪੋ ਹੌਲੀ-ਹੌਲੀ ਖਰਾਬ ਹੋ ਜਾਏਗੀ ਭਾਵੇਂ ਅੱਜ ਐਪ ਚੱਲ ਰਿਹਾ ਹੋਵੇ।
ਵੱਡੇ ਫੀਚਰ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ stabilization window ਯੋਜਨਾ ਬਣਾਓ। 2–5 ਕੰਮਕਾਜੀ ਦਿਨ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ ਐਕਸਪੋਰਟ ਦੀਆਂ ਖੂਟੀਆਂ ਦੁਰੁਸਤ ਕਰਨ, README ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਨ, ਅਤੇ "ਮੇਰੀ ਮਸ਼ੀਨ ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ" ਸਮੱਸਿਆਵਾਂ ਹਟਾਉਣ ਲਈ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਐਕਸਪੋਰਟਾਂ ਅਤੇ ਵਰਗੇ ਫੀਚਰ snapshots ਅਤੇ rollback ਨਾਲ ਤੁਸੀਂ ਇਟਰੇਟ ਕਰਨ ਦਾ ਕੰਮ ਆਸਾਨ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਰਿਪੋ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰ ਰਹੇ ਹੋ। ਇੱਕ ਵਾਰੀ ਰਿਪੋ ਸਥਿਰ ਹੋ ਜਾਵੇ, Git ਨੂੰ truth ਸਰੋਤ ਮੰਨੋ ਅਤੇ ਭਵਿੱਖ ਦੇ ਐਕਸਪੋਰਟਾਂ ਨੂੰ checkpoints ਵਜੋਂ ਵਰਤੋ, ਮੁੱਖ ਇਤਿਹਾਸ ਵਜੋਂ ਨਹੀਂ।
ਅਗਲਾ handoff ਮਿਲਸਟੋਨ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: "ਕੋਈ ਵੀ ਡਿਵੈਲਪਰ 30 ਮਿੰਟ ਵਿੱਚ ਚਲਾ ਸਕੇ।" ਫਿਰ ਕਿਸੇ ਨਵੇਂ ਵਿਅਕਤੀ ਨੂੰ ਤਾਜ਼ਾ ਮਸ਼ੀਨ 'ਤੇ README ਫੋਲੋ ਕਰਨ ਲਈ ਕਹੋ। ਉਹਦੇ ਸਵਾਲ ਤੁਹਾਡੀ ਆਖਰੀ to-do ਸੂਚੀ ਬਣ ਜਾਣਗੇ।
Treat ownership as independence: you can build, run, change, and deploy the app from a normal repo without needing the original platform project, special UI settings, or hidden build steps.
A good test is: can a new teammate clone the repo and get it running using only the README?
Start with a quick completeness check:
package.json, go.mod, pubspec.yaml).package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).migrations/ or similar).docker-compose.yml).If anything required to run is only described in a UI or chat, write it down and move it into the repo.
Do it in small, verifiable steps:
.env.example → .env.Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.
Because the hosted environment often had things you never made explicit:
Fix this by making the setup visible: .env.example, migration scripts, and a README with exact commands.
A server “starting” isn’t enough—verify real data flow:
If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.
Default approach:
.env.example with fake values..env to .gitignore.If you find real keys in the repo, assume they’re compromised and rotate them. Prioritize database credentials, OAuth client secrets, and webhook signing secrets.
Keep the first CI simple and consistent with local commands:
go test ./... and build the backend.Make CI call the same scripts you expect developers to run (for example make test or npm run build). That reduces “works locally but not in CI.”
Yes—if you want a predictable handoff. A good default is:
README.md with copy-paste commands..env.example describing required vs optional variables.Aim for a new developer being able to run the app in 15–30 minutes without guessing.
Common structure is:
apps/ for frontends (web, mobile).services/ for APIs and workers.shared/ for shared types/utilities.infra/ for deployment templates and environment examples.The exact names don’t matter as much as making it obvious what runs where, and how the pieces connect.
A practical sequence:
Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.