27 ਜੁਲਾ 2025·7 ਮਿੰਟ
ਸਾਫ ਹੈਂਡਆਫ਼ ਲਈ AI-ਬਣਾਇਆ ਕੋਡਬੇਸ ਐਕਸਪੋਰਟ ਚੈਕਲਿਸਟ
ਇਸ AI-ਬਣਾਈ ਕੋਡਬੇਸ ਐਕਸਪੋਰਟ ਚੈਕਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਆਫ਼ ਕਰੋ: env vars, ਸੀਕ੍ਰੇਟ, ਲੋਕਲ ਸੈਟਅਪ, ਡੇਟਾਬੇਸ ਬੂਟਸਟ੍ਰੈਪ, CI, ਅਤੇ ਇੱਕ ਸਪੱਠ ਰਨ README।
ਇਸ AI-ਬਣਾਈ ਕੋਡਬੇਸ ਐਕਸਪੋਰਟ ਚੈਕਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਆਫ਼ ਕਰੋ: env vars, ਸੀਕ੍ਰੇਟ, ਲੋਕਲ ਸੈਟਅਪ, ਡੇਟਾਬੇਸ ਬੂਟਸਟ੍ਰੈਪ, CI, ਅਤੇ ਇੱਕ ਸਪੱਠ ਰਨ README।
ਜ਼ਿਆਦਾਤਰ ਐਕਸਪੋਰਟ ਕੀਤੇ ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਸਧਾਰਣ ਕਾਰਨ ਕਰਕੇ ਰਨ ਨਹੀਂ ਹੁੰਦੇ: ਉਹ ਮੁਢਲੀ ਪਲੇਟਫਾਰਮ ਦੇ ਅੰਦਰ ਠੀਕ ਚੱਲਦੇ ਸਨ, ਜਿੱਥੇ ਡੀਫਾਲਟ, ਸੀਕ੍ਰੈਟ, ਡੇਟਾਬੇਸ ਦੀ ਸਥਿਤੀ ਅਤੇ ਬਿਲਡ ਕਦਮ ਪਹਿਲਾਂ ਹੀ ਸੈੱਟ ਸਨ। ਕੋਡ ਜਦੋਂ ਉਸ 'ਬੁਬਲ' ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਤਾਂ ਅਗਲਾ ਡਿਵੈਲਪਰ ਇਹ ਅਨੁਮਾਨ ਲਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਮਹਿੱਤਵਪੂਰਨ ਸੀ।
ਇੱਕ ਸਾਫ ਹੈਂਡਆਫ਼ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਕਿਸੇ ਨਵੇਂ ਵਿਅਕਤੀ ਵੱਲੋਂ ਕਲੋਨ, ਸੰਰਚਿਤ ਅਤੇ ਸਟਾਰਟ ਕੀਤਾ ਜਾ ਸਕੇ — ਇਕ ਸਾਫ ਮਸ਼ੀਨ 'ਤੇ, ਬਿਨਾਂ ਲੰਬੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਦੇ। ਇਹ ਬਿਲਕੁਲ ਪੂਰੀ ਕੋਡ ਪਰਫੈਕਟ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦਾ; ਬਸ ਬੇਸਿਕ ਚੀਜ਼ਾਂ ਸਪਸ਼ਟ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਐਕਸਪੋਰਟ ਮੁੜ-ਮੁੜ ਇਕੋ ਹੀ ਸਮੱਸਿਆਵਾਂ ਕਰਕੇ ਟੁੱਟਦੇ ਹਨ: ਛੁਪਿਆ ਕਨਫਿਗਰੇਸ਼ਨ, ਅਸਪਸ਼ਟ ਸੀਕ੍ਰੈਟ ਹੈਂਡਲਿੰਗ, ਮੁਝਲਕ ਲੋਕਲ ਸੈਟਅਪ ਕਦਮ, ਡੇਟਾਬੇਸ ਸਪਰਾਈਜ਼, ਅਤੇ CI ਜੋ ਸਿਰਫ਼ ਇਕ ਹੀ ਵਾਤਾਵਰਣ 'ਚ ਕੰਮ ਕਰਦਾ ਹੈ।
ਇਸ ਲਈ AI-ਬਣਾਈ ਕੋਡਬੇਸ ਐਕਸਪੋਰਟ ਚੈਕਲਿਸਟ ਵੱਧ ਤਰ ਡੌਕਯੂਮੇਨਟੇਸ਼ਨ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਦੀ ਯੋਗਤਾ ਬਾਰੇ ਹੈ, ਫਾਇਲਾਂ ਦੀ ਨਕਲ ਬਾਰੇ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਪਲੇਟਫਾਰਮ 'ਤੇ ਐਪ ਬਣਾਈ ਤੇ ਫਿਰ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕੀਤਾ, ਤਾਂ ਅਗਲੀ ਟੀਮ ਨੂੰ ਫਿਰ ਵੀ ਇੱਕ ਨਕਸ਼ੇ ਦੀ ਲੋੜ ਹੈ: ਕੀ ਸੈੱਟ ਕਰਨਾ ਹੈ, ਕੀ ਚਲਾਉਣਾ ਹੈ, ਅਤੇ "ਚੱਲ ਰਹਿਣਾ" ਕਿਵੇਂ ਦਿੱਖਦਾ ਹੈ।
ਇਹ ਚੈਕਲਿਸਟ ਹੈਂਡਆਫ਼ ਦੀਆਂ ਅਹੰਕਾਰਕ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦੇਂਦੀ ਹੈ: ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ, ਸੀਕ੍ਰੈਟ, ਲੋਕਲ ਡੈਵ ਸੈਟਅਪ, ਡੇਟਾਬੇਸ ਬੂਟਸਟ੍ਰੈਪ, CI ਸੈਟਅਪ, ਅਤੇ ਇੱਕ ਵਰਤੀਯੋਗ “ਕਿਵੇਂ ਚਲਾਉਂਦਾ ਹੈ” README। ਇਹ ਉਤਪਾਦ ਫੈਸਲੇ, UX ਪਾਲਿਸ਼, ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਦੇ ਮੁੜ-ਡਿਜ਼ਾਇਨ ਦੀ ਚਰਚਾ ਨਹੀਂ ਕਰਦੀ।
ਮਿਲਕਤਦਾਰੀਆਂ ਵੀ ਸਪੱਸ਼ਟ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਬਣਾਉਣ ਵਾਲਾ ਜਿੰਮੇਵਾਰ ਹੈ ਕਿ ਉਹ ਅਨੁਮਾਨ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦਰਸਾਵੇ (ਡੌਕਸ, ਸਕ੍ਰਿਪਟ, ਸੁਰੱਖਿਅਤ ਡੀਫਾਲਟ)। ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਜਿੰਮੇਵਾਰ ਹੈ ਕਿ ਉਹ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਆਪਣੇ ਵਾਤਾਵਰਣ ਲਈ ਅਨੁਕੂਲ ਕਰੇ (ਸੀਕ੍ਰਿਟਸ ਮੈਨੇਜਰ, ਹੋਸਟਿੰਗ, ਕੜੀ CI ਨੀਤੀਆਂ)। ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੂੰ ਆਪਣਾ-ਆਪਣਾ ਕੰਮ ਪਤਾ ਹੋਵੇ ਤਾਂ ਹੈਂਡਆਫ਼ ਰੋਟੀਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਾਫ ਹੈਂਡਆਫ਼ ਇਕ ਸਧਾਰਣ ਸਮਝੌਤੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਕੋਡ ਪਲੇਟਫਾਰਮ ਤੋਂ ਨਿਕਲਣ 'ਤੇ "ਹੋ ਗਿਆ" ਦਾ ਕੀ ਅਰਥ ਹੈ। ਇਸ ਦੇ ਬਿਨਾਂ, ਟੀਮਾਂ ਬਾਅਦ ਵਿੱਚ ਗੱਲਾਂ ਤੇ ਝਗੜਦੀਆਂ ਹਨ—ਕੋਣ-ਕੋਣ ਸਿੰਡ ਸਕ੍ਰਿਪਟ ਗਾਇਬ ਹਨ, ਕਿਹੜੀਆਂ ਆਸ਼ਚਰਜ dependencies ਹਨ, ਜਾਂ ਕੌਣ-ਸਾ ਵਰਜਨ ਅਸਲੀ ਸੀ।
ਇੱਕ ਇਕੱਲਾ ਸਥਿਰ ਸਮਾਂ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਸਰੋਤ-ਸੱਚ ਮੰਨੋ। ਬਦਲਵ ਦੇ ਵਿਚਕਾਰ ਐਕਸਪੋਰਟ ਕਰਨਾ ਉਹੀ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਅਜਿਹਾ ਰਿਪੋ ਦਿੰਦਾ ਹੈ ਜੋ ਲਗਭਗ ਚੱਲਦਾ ਹੈ।
ਚੰਗਾ ਐਕਸਪੋਰਟ ਪੁਆਇੰਟ ਅਕਸਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹੁੰਦਾ ਹੈ:
ਇਸ ਦੇ ਨਾਲ ਇੱਕ ਵਾਕ ਦਿਓ ਕਿ ਇਹ ਐਕਸਪੋਰਟ ਪੁਆਇੰਟ ਕਿਉਂ ਠੀਕ ਹੈ। ਉਦਾਹਰਨ: “ਸਾਰੇ ਕੋਰ ਫ਼ਲੋ ਪਾਸ ਹਨ ਅਤੇ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਇਸ ਮਾਈਲਸਟੋਨ ਲਈ ਫਾਈਨਲ ਹੈ।”
ਜੇਮਲ੍ਹਾ ਇਕ ਛੋਟੀ ਇਨਵੈਂਟਰੀ ਲਿਖੋ ਕਿ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਕੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ। ਸ਼ਾਮਲ ਕੀ ਹੈ ਅਤੇ ਕੀ ਜਾਣ-ਬੁਝ ਕੇ ਨਹੀਂ ਸ਼ਾਮਲ, ਇਹ ਸਪਸ਼ਟ ਕਰੋ।
ਬੇਸਿਕ ਸਮਾਨ ਸ਼ਾਮਲ ਕਰੋ: ਸੋਰਸ ਕੋਡ (ਐਪ, ਸਰਵਿਸ, ਸ਼ੇਅਰਡ ਪੈਕੇਜ), ਕਨਫਿਗ ਟੈਮਪਲੇਟ (.env.example), ਸਕ੍ਰਿਪਟ (build, dev, test, ਮਾਈਗ੍ਰੇਸ਼ਨ, seed), ਅਤੇ ਡਿਪਲੋਯਮੈਂਟ ਨੋਟਸ। ਸੈਂਪਲ ਡੇਟਾ ਸਿਰਫ਼ ਸਾਫ ਕੀਤੀ ਹੋਈ ਹੋਵੇ ਤਾਂ ਸ਼ਾਮਲ ਕਰੋ।
ਫਿਰ ਵਰਜਨਾਂ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ ਤਾਂ ਜੋ “ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੰਗਾ ਹੈ” ਨਵਾਂ ਮੁਆਰਿਆਂ ਨਾ ਬਣ ਜਾਏ। ਰਨਟਾਈਮ ਅਤੇ ਟੂਲਚੇਨ ਵਰਜਨਾਂ (Node, Go, Flutter, package manager) ਅਤੇ ਡੇਟਾਬੇਸ ਵਰਜਨ (PostgreSQL ਮੈਜਰ ਵਰਜਨ ਅਹਿਮ ਹੁੰਦਾ ਹੈ) ਦਰਜ ਕਰੋ।
ਅੰਤ ਵਿੱਚ, ਉਹ ਪ੍ਰੀਰਿਕੁਇਜ਼ਾਈਟ ਲਿਖੋ ਜੋ ਕਿਸੇ ਕੰਮ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤੇ ਜਾਣੇ ਲਾਜ਼ਮੀ ਹਨ। ਸਪਸ਼ਟ ਅਤੇ ਸੰਖੇਪ ਰੱਖੋ: ਲੋੜੀਂਦੇ ਖਾਤੇ, ਇੰਸ੍ਟਾਲ ਕੀਤੇ ਟੂਲ, ਫ੍ਰੀ ਪੋਰਟ, ਅਤੇ ਕੋਈ ਇਕ-ਵਾਰੀ ਸੈਟਅਪ ਕਦਮ।
ਜ਼ਿਆਦਾਤਰ "ਪਲੇਟਫਾਰਮ 'ਚ ਚੱਲ ਰਿਹਾ ਸੀ" ਐਕਸਪੋਰਟ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਮੁੱਖ ਸੈਟਿੰਗਾਂ کبھی ਲਿਖੀਆਂ ਨਹੀਂ ਜਾਣਗੀਆਂ। ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਅਕਸਰ ਇਸ ਦਾ ਕਾਰਨ ਹੁੰਦੇ ਹਨ: ਉਹ ਰਿਪੋ ਦੇ ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਨਵੇਂ ਮੈਂਬਰ ਕੋਡ ਕਲੋਨ ਕਰਦਾ ਹੈ ਤੇ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕਿਹੜੇ ਮੁੱਲ ਉਮੀਦ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ।
ਇਸਨੂੰ ਸਾਫ ਐਕਸਪੋਰਟ ਲਈ ਲਾਜ਼ਮੀ ਮੰਨੋ: ਹਰ ਵੈਰੀਏਬਲ ਲੱਭ ਸਕਣਯੋਗ, ਸਮਝਾਇਆ ਹੋਇਆ, ਅਤੇ ਅਨੁਮਾਨ ਤੇ ਆਧਾਰਿਤ ਨਾ ਹੋਵੇ।
ਹੈਂਡਆਫ਼ README ਵਿੱਚ ਇੱਕ ਹੀ ਸਰੋਤ-ਸੱਚ ਬਣਾਓ: ਵੈਰੀਏਬਲ ਨਾਂਵਾਂ ਦੀ ਸੂਚੀ, ਉਹ ਕੀ ਕੰਟਰੋਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਮੁੱਲ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ। ਵਿਆਖਿਆ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਕੋਈ ਵੀ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਚੀਜ਼ ਹਾਈਲਾਈਟ ਕਰੋ।
ਹਰ ਵੈਰੀਏਬਲ ਲਈ ਇਕ ਸਧਾਰਣ ਫਾਰਮੈਟ:
ਇਸ ਡੌਕ ਨਾਲ ਨਾਲ, .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 ਸਪਸ਼ਟ ਕਰੋ। ਜੇ ਕੋਈ ਗਾਇਬ ਵੈਰੀਏਬਲ crash ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਦੱਸੋ। ਜੇ ਇਹ ਕਿਸੇ ਫੀਚਰ (email ਭੇਜਣਾ, payments, file storage) ਨੂੰ ਏਨেবল ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਫੀਚਰ ਨਾਂ ਦਿਓ ਅਤੇ ਦੱਸੋ ਕਿ ਨਾਹ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਜਿਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਵਾਤਾਵਰਣ ਦੇ ਅਨੁਸਾਰ ਫਰਕ ਆਉਂਦਾ ਹੈ, ਉਹ ਨੋਟ ਕਰੋ। DATABASE_URL ਅਤੇ PUBLIC_BASE_URL ਆਮ ਤੌਰ 'ਤੇ dev, staging, production ਵਿੱਚ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ, ਜਦਕਿ LOG_LEVEL ਹਰ ਥਾਂ ਇੱਕੋ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਐਕਸਪੋਰਟ ਅਤੇ ਡਿਪਲੋਯ ਕੀਤਾ ਸੀ, ਤਾਂ ਡੌਕਸ ਵਿੱਚ ਪਲੇਟਫਾਰਮ ਡੀਫਾਲਟ (ਪੋਰਟ, ਬੇਸ URLs, allowed origins) ਵੀ ਦਰਜ ਕਰੋ ਤਾਂ ਕਿ ਬਾਹਰ ਪਲੇਟਫਾਰਮ ਵਿਹਾਰ ਇਕੱਠ ਨਹੀਂ ਝਲਕੇ।
ਅੰਤ ਵਿੱਚ, ਦੱਸੋ ਕਿ ਲੋਕਲ ਤੌਰ 'ਤੇ env vars ਕਿਵੇਂ ਲੋਡ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਪ੍ਰੋਜੈਕਟ .env ਫ਼ਾਈਲ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਦੱਸੋ ਕਿ ਇਹ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਐਪ ਆਪ-ਆਪ .env ਨੂੰ ਰੀਡ ਕਰਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਕਮਾਂਡ/ਟੂਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਸੀਕ੍ਰੇਟ ਉਹ ਮੁੱਲ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਲੀਕ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ: API ਕੀਜ਼, ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ, auth ਟੋਕਨ, OAuth ਕਲਾਇੰਟ ਸੀਕ੍ਰੇਟ, ਪ੍ਰਾਈਵੇਟ ਕੀਜ਼, webhook ਸਾਈਨਿੰਗ ਸੀਕ੍ਰੇਟ।
ਐਕਸਪੋਰਟ ਲਈ, ਸਧਾਰਣ ਰੱਖੋ: ਰਿਪੋ ਵਿੱਚ ਸਿਰਫ ਪਲੇਸਹੋਲਡਰ ਰੱਖੋ, ਕਦੇ ਵੀ ਅਸਲ ਸੀਕ੍ਰੇਟ ਨਹੀਂ। ਜੇ ਕਿਸੇ ਸੀਕ੍ਰੇਟ ਦੀ ਲੋੜ ਐਪ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਹੈ, ਤਾਂ .env.example ਵਿੱਚ ਉਸਨੂੰ ਕਲਿਆਰ ਨਾਂ ਦੇ ਕੇ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਦੱਸੋ ਕਿ ਅਸਲੀ ਕੀ ਕਿਵੇਂ ਬਣਾਉਣੀ ਹੈ।
ਇੱਕ ਕਾਰਗਰ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਤਿੰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਵੱਖ ਕਰੋ: ਇੱਕ sample ਫ਼ਾਈਲ, ਇੱਕ ਲੋਕਲ ਫ਼ਾਈਲ, ਅਤੇ CI/ਡਿਪਲੋਯਟਮੈਂਟ ਸੀਕ੍ਰਿਟ ਸਟੋਰ। ਤੁਹਾਡੇ ਐਕਸਪੋਰਟ ਕੋਡ ਵਿੱਚ sample ਹੋਵੇ, ਲੋਕਲ ਫ਼ਾਈਲ ignore ਹੋਵੇ, ਅਤੇ ਇਹ ਦਸਤਾਵੇਜ਼ ਹੋਵੇ ਕਿ CI/ਹੋਸਟਿੰਗ ਸੀਕ੍ਰੇਟਸ ਕਿਵੇਂ ਮਿਲਦੀਆਂ ਹਨ।
ਹਰ ਵਾਤਾਵਰਣ ਲਈ ਇੱਕ ਵਿਧੀ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਮੰਨੋ।
.env (gitignored) ਜੋ ਐਪ ਵੱਲੋਂ ਲੋਡ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਟੀਮ ਦਾ ਲੋਕਲ ਸੀਕ੍ਰਿਟਸ ਮੈਨੇਜਰਉਦਾਹਰਨ: ਰਿਪੋ ਵਿੱਚ PAYMENTS_API_KEY=replace_me ਸ਼ਾਮਲ ਹੈ। ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਵਾਈਡਰ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਆਪਣਾ ਕੀ ਬਣਾਏ ਅਤੇ ਲੋਕਲ .env ਅਤੇ CI ਵਿੱਚ ਸੈਟ ਕਰੇ। ਕੋਡ ਬਦਲੇ ਨਹੀਂ।
ਹੈਂਡਆਫ਼ ਇੱਕ ਵਧੀਆ ਸਮਾਂ ਹੁੰਦਾ ਹੈ ਸੀਕ੍ਰਿਟ ਰੋਟੇਟ ਕਰਨ ਦਾ, ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਉਹ ਪਹਿਲਾਂ ਕਿਸੇ ਸ਼ੇਅਰਡ ਪਲੇਟਫਾਰਮ ਸੈਸ਼ਨ ਵਿੱਚ ਵਰਤੇ ਗਏ ਹੋਣ।
.env ਫਾਇਲਾਂ ਅਪਡੇਟ ਕਰੋ।ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਐਕਸਪੋਰਟ ਕੀਤਾ ਹੈ, ਤਾਂ ਐਕਸਪੋਰਟ ਨੂੰ ਇੱਕ ਨਵੇਂ ਵਾਤਾਵਰਣ ਵਜੋਂ ਲਓ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਟੀਮ ਲਈ ਤਾਜ਼ੇ ਸੀਕ੍ਰਿਟ ਜਨਰੇਟ ਕਰੋ।
ਹੈਂਡਆਫ਼ ਤਦ ਹੀ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦ ਇੱਕ ਨਵਾਂ ਡਿਵੈਲਪਰ ਰਿਪੋ ਕਲੋਨ ਕਰਕੇ ਕੁਝ ਕਮਾਂਡ ਚਲਾਏ ਅਤੇ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਐਪ ਵੇਖ ਸਕੇ। ਉਦੇਸ਼ ਹੈ: ਪੂਰੀਪੱਤਰ ਪ੍ਰੀਰਿਕੁਇਜ਼ਾਈਟ, ਸਪੱਠ ਕਮਾਂਡ ਕ੍ਰਮ, ਅਤੇ ਇੱਕ ਛੋਟਾ "ਕਿਵੇਂ ਚਲਾਓ" ਬਲਾਕ ਜੋ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋ।
README ਦੇ ਸਿਰਲੇਖ 'ਤੇ ਇਹ ਰੱਖੋ ਤਾਂ ਜੋ ਕੋਈ ਗਲਤੀ ਦੇ ਸੁਨੇਹਿਆਂ ਤੋਂ ਸਿੱਖ ਕੇ ਨਾ ਜਾਣੇ:
ਜੇ ਪ੍ਰੋਜੈਕਟ Koder.ai 'ਤੇ ਬਣਿਆ ਸੀ, ਤਾਂ ਲੋਕਲ ਸੈਟਅਪ ਨੂੰ ਉਸੀ ਤਰ੍ਹਾਂ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਐਕਸਪੋਰਟ ਕੀਤਾ (ਉਸੇ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਉਹੀ start ਕਮਾਂਡ)। "Postgres ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਿਹਾ ਹੈ" ਇਹ ਫਰਜ਼ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹ ਨਾ ਕਿਹਾ ਹੋਵੇ।
ਨਕਲ-ਪੇਸਟ ਯੋਗ ਕਮਾਂਡਾਂ ਨੂੰ ਠੀਕ ਕ੍ਰਮ ਵਿੱਚ ਦਿਓ:
# 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
ਇਸਦੇ ਨੀਚੇ ਇੱਕ ਘੱਟੋ-ਘੱਟ test ਅਤੇ build ਸੈਕਸ਼ਨ ਜੋੜੋ:
# Tests
cd server && go test ./...
cd web && npm test
# Build
cd web && npm run build
cd server && go build ./...
ਜ਼ਿਆਦਾਤਰ "ਚੱਲਦਾ ਨਹੀਂ" ਮੁੱਦੇ ਕੁਝ ਹੀ ਗਰੁੱਪਾਂ ਵਿੱਚ ਪੈਂਦੇ ਹਨ:
ਗਲਤ ਵਰਜਨ (Node/Go). ਲੱਛਣ: dependency ਜਾਂ compile errors. ਸੁਧਾਰ: ਫਿਕਸ ਕੀਤਾ ਵਰਜਨ ਇੰਸਟਾਲ ਕਰੋ ਅਤੇ installs ਦੁਬਾਰਾ ਚਲਾਓ।
ਗੁੰਮ ਵਾਤਾਵਰਣ ਮੁੱਲ. ਲੱਛਣ: "undefined" config, auth ਫੇਲ, 500 errors. ਸੁਧਾਰ: .env ਨੂੰ .env.example ਨਾਲ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਲਾਜ਼ਮੀ ਮੁੱਲ ਭਰੋ।
ਡੇਟਾਬੇਸ ਪਹੁੰਚ ਨਹੀਂ ਹੋ ਰਹੀ. ਲੱਛਣ: connection refused, "database does not exist." ਸੁਧਾਰ: Postgres ਚਲਾਓ, host/port/user ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਡੇਟਾਬੇਸ init ਕਦਮ ਇਕਦਮ ਉਸੇ ਤਰ੍ਹਾਂ ਚਲਾਓ ਜਿਵੇਂ ਦਿੱਤੇ ਗਏ ਹਨ।
ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਪਲੇਟਫਾਰਮ ਤੋਂ ਐਕਸਪੋਰਟ ਹੁੰਦਾ ਹੈ, ਡੇਟਾਬੇਸ ਨਵੀਂ ਮਸ਼ੀਨ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾ ਹੀ ਟੁੱਟਦਾ ਹੈ। ਲਕਸ਼ ਸਰਲ ਹੈ: ਇੱਕ ਸਹਿਯੋਗੀ ਨੂੰ "ਮੈਂ ਰਿਪੋ ਕਲੋਨ ਕੀਤਾ" ਤੋਂ "ਐਪ ਅਸਲੀ ਡੇਟਾ ਨਾਲ ਚਲ ਰਿਹਾ ਹੈ" ਤੱਕ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ।
ਨਵੀਂ PostgreSQL ਸੈਟਅਪ ਲਈ ਘੱਟੋ-ਘੱਟ ਕਦਮ ਲਿਖੋ, ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਕਮਾਂਡਾਂ ਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਰੱਖੋ। ਤੁਹਾਡਾ ਹੈਂਡਆਫ਼ ਚਾਰ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਸਕ੍ਰਿਪਟ ਹਨ (Makefile targets, shell scripts, task runner ਕਮਾਂਡ), ਉਹਨਾਂ ਨੂੰ ਵਰਤੋ। ਜੇ ਨਹੀਂ, ਤਾਂ ਹੁਣ ਕੁਝ ਛੋਟੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਜੋੜੋ।
ਵਾਤਾਵਰਣਾਂ (ਲੋਕਲ, CI, staging) ਵਿੱਚ ਫਲੋ ਇੱਕੋ-ਸਮਾਨ ਰੱਖੋ। ਚੰਗਾ ਬੇਸਲਾਈਨ ਇਹ ਹੈ:
# 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
Seeds ਲਈ, ਪ੍ਰੋਡੈਕਸ਼ਨ-ਵਰਗੀ ਡਾਮਪ ਦੀ ਥਾਂ ਘੱਟੋ-ਘੱਟ ਕਾਰਗਰ ਡੇਟਾ ਪਸੰਦ ਕਰੋ। Seeds ਨੂੰ ਇਕ ਤੋਂ ਵੱਧ ਵਾਰੀ ਚਲਾਣਾ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (idempotent inserts, ਜਾਂ ਸਪਸ਼ਟ "ਖਾਲੀ DB 'ਤੇ ਹੀ ਚਲਾਓ" ਨਿਯਮ)।
ਰੀਸੈਟ ਲਈ, ਸੁਰੱਖਿਅਤਤਾ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ। ਇੱਕ ਰੀਸੈਟ ਕਮਾਂਡ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਲੋਕਲ ਵਿਕਾਸ ਨੂੰ ਟਾਰਗੇਟ ਕਰੇ। ਜੇ ਤੁਸੀਂ ਨਾਸ਼ਕ ਸਕ੍ਰਿਪਟ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਗਾਰਡਰੇਲ ਜਮ੍ਹਾਂ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, CONFIRM_RESET=1 ਦੀ ਲੋੜ, ਜਾਂ APP_ENV=development ਦੀ ਜਾਂਚ)। ਇਹ ਵੀ ਦਰਜ ਕਰੋ ਕਿ "ਰੀਸੈਟ" ਦਾ ਕੀ ਅਰਥ ਹੈ: ਡ੍ਰੌਪ ਅਤੇ ਦੁਬਾਰਾ ਬਣਾਉਣਾ, ਟੇਬਲ ਮਿਟਾਉਣਾ, ਜਾਂ ਜਾਣੇ-ਮਾਨੇ ਸਨੈਪਸ਼ਾਟ ਕੋਲ ਵਾਪਸ ਲਿਆਉਣਾ।
ਹੈਂਡਆਫ਼ ਉਸ ਵੇਲੇ ਖਰਾਬ ਹੁੰਦਾ ਹੈ ਜਦ ਰਿਪੋ ਇਕ ਜੰਕ ਡਰੌਅਰ ਜਿਹਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਨਵਾਂ ਆਇਆ ਵਿਅਕਤੀ ਅਸਾਨੀ ਨਾਲ ਦੱਸ ਸਕੇ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕੀ ਜਨਰੇਟ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਸੈਟਿੰਗਾਂ ਬਦਲਣੀਆਂ ਹਨ।
ਉਹ ਚੀਜ਼ਾਂ commit ਕਰੋ ਜੋ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ: lockfiles, migration files, ਛੋਟੇ config templates ਜਿਵੇਂ .env.example, ਅਤੇ ਕੋਈ ਵੀ ਸਕ੍ਰਿਪਟ ਜੋ ਐਪ ਬੂਟਸਟ੍ਰੈਪ ਕਰਦਾ ਹੈ।
ਨਿੱਜੀ, ਜਨਰੇਟ ਕੀਤੇ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਫਾਇਲਾਂ ਨੂੰ ਸਰੋਤ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਰੱਖੋ: ਲੋਕਲ env ਫਾਇਲ, editor ਸੈਟਿੰਗ, build output, logs, caches, ਅਤੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਐਕਸੈਸ ਦਿੰਦੀ ਹੈ (API keys, DB passwords, service account files)।
ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਇਹ ਬਦਲਣ ਨਾਲ ਹਰ ਕੋਈ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ ਤਾਂ commit ਕਰੋ। ਜੇ ਇਹ ਮਸ਼ੀਨ ਜਾਂ ਵਾਤਾਵਰਣ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ ਰਿਪੋ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
ਇਕ ਛੋਟਾ "ਰੱਖੋ ਵਿਰੁੱਧ ignore" ਨੋਟ ਦਿਓ:
README, lockfiles, migrations, seed scripts, .env.example.env, secrets files, build folders, logs, local cachesਡਾਇਰੈਕਟਰੀ ਮੈਪ ਵੀ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਸਟ੍ਰਕਚਰ ਬਿਨਾਂ ਘੁੰਮਣ ਦੇ ਸਪੱਸ਼ਟ ਹੋ ਜਾਏ। ਉਦਾਹਰਨ: “/backend API service, /web frontend, /mobile app, /db migrations and seeds, /scripts setup helpers.”
ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਐਕਸਪੋਰਟ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਹ ਐਕਸਪੋਰਟ ਇਸ ਸਫਾਈ ਪਾਸ ਦੀ ਸ਼ੁਰੂਆਤ ਮੰਨੋ: ਜਨਰੇਟ ਕੀਤੇ ਕਚਰੇ ਨੂੰ ਹਟਾਓ, ignore ਨਿਯਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਮੈਪ ਲਿਖੋ।
ਹੈਂਡਆਫ਼ ਸ਼ਾਂਤ ਤਰੀਕੇ ਨਾਲ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ ਜਦ CI ਲੋਕਲ ਨਾਲ ਲਗਭਗ ਇੱਕੋ ਹੁੰਦਾ ਹੈ। ਜੇ ਕੋਈ ਪ੍ਰੋਜੈਕਟ ਉਸਦੇ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲਦਾ ਹੈ, ਤਾਂ CI ਨੂੰ ਉਹੀ ਕਮਾਂਡ ਚਲਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਉਹੀ ਨਤੀਜਾ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ।
ਹਰ pull request 'ਤੇ 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” ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਵਿਕਲਪਿਕ ਨੌਕਿਆਂ (ਜਿਵੇਂ ਮੋਬਾਈਲ ਬਿਲਡ) ਜੋੜਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਬਿਨਾਂ ਰੋਕਟੋਕ ਵਾਲੇ ਰੱਖੋ ਜਦ ਤੱਕ ਉਹ ਸੱਚਮੁਚ ਲਾਜ਼ਮੀ ਨਾ ਹੋਣ।
CI ਆਉਟਪੁੱਟਸ ਨੂੰ ਡਿਬੱਗ ਕਰਨ ਯੋਗ ਬਣਾਓ: ਟੂਲ ਵਰਜਨ ਪ੍ਰਿੰਟ ਕਰੋ ਅਤੇ ਸਾਫ ਏਰਰ ਮੈਸੇਜ ਦਿਓ। ਪਾਈਪਲਾਈਨ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ caching ਜੋੜੋ।
Maya ਨੂੰ Koder.ai ਤੋਂ ਇੱਕ ਐਕਸਪੋਰਟ ਕੀਤਾ ਪ੍ਰੋਜੈਕਟ ਮਿਲਦਾ ਹੈ। ਇਹ ਇੱਕ ਆਮ ਸੈਟਅਪ ਹੈ: React ਵੈਬ ਐਪ, Go API, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ। ਉਹ ਰਿਪੋ ਕਲੋਨ ਕਰਕੇ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਇੱਕ ਵਰਕਿੰਗ ਸਕ੍ਰੀਨ ਤੱਕ ਪਹੁੰਚਣ ਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਉਸਦੇ ਪਹਿਲੇ 30 ਮਿੰਟ ਇਸ ਤਰ੍ਹਾਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
.env.example ਨੂੰ .env ਵਿੱਚ ਨਕਲ ਕਰੋ (ਜਾਂ ਉਹੀ ਮੁੱਲ ਆਪਣੀ shell ਵਿੱਚ ਸੈੱਟ ਕਰੋ) ਦੋਹਾਂ web ਅਤੇ api ਲਈ।ਇੱਕ ਗੰਦੜੇ ਹੈਂਡਆਫ਼ ਵਿੱਚ, ਉਹ ਆਮ ਤੌਰ ਤਿੰਨ ਰੁਕਾਵਟਾਂ ਨਾਲ ਵੱਕਰਾਏਗੀ।
ਪਹਿਲੀ: ਐਪ ਬੂਟ ਹੈ ਤੇ ਫਿਰ "missing config" ਨਾਲ ਕਰੈਸ਼ ਕਰਦਾ ਹੈ। ਅਸਲ ਮੁੱਦਾ ਇੱਕ ਅਣਦਸਤਾਵੇਜ਼ ਵੈਰੀਏਬਲ ਜਿਵੇਂ AUTH_JWT_SECRET ਜਾਂ ਲਾਜ਼ਮੀ DATABASE_URL ਫਾਰਮੈਟ ਹੁੰਦੀ ਹੈ। ਜੇ README ਹਰ ਲਾਜ਼ਮੀ ਵੈਰੀਏਬਲ ਨੂੰ ਲਿਸਟ ਕਰਦਾ, ਸੁਰੱਖਿਅਤ ਉਦਾਹਰਨ ਮੁੱਲ ਦਿਖਾਉਂਦਾ, ਅਤੇ ਦੱਸਦਾ ਕਿ ਇਹ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਠੀਕ ਹੋ ਜਾਣਾ ਇੱਕ ਛੋਟੀ ਗੱਲ ਬਣ ਜਾਂਦੀ ਹੈ।
ਦੂਜੀ: API ਚਲਦਾ ਹੈ, ਪਰ ਹਰ ਪੇਜ 'ਤੇ "no data" ਜਾਂ 500 errors ਆਉਂਦੇ ਹਨ। ਡੇਟਾਬੇਸ ਹੈ, ਪਰ ਟੇਬਲਾਂ ਜਾਂ seed ਡੇਟਾ ਨਹੀਂ ਹਨ। ਇੱਕ ਸਾਫ ਹੈਂਡਆਫ਼ ਵਿੱਚ ਇਕ ਜਾਂ ਦੋ ਭਰੋਸੇਯੋਗ ਕਮਾਂਡ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: migrations ਚਲਾਓ, ਮਿਨੀਮਲ ਡੈਮੋ ਡੇਟਾ ਸੀਡ ਕਰੋ, ਅਤੇ ਜਦ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਰੀਸੈੱਟ ਕਮਾਂਡ।
ਤੀਜੀ: ਸਭ ਕੁਝ ਚੱਲ ਰਿਹਾ ਹੈ, ਪਰ ਫਰੰਟਐਂਡ ਗਲਤ ਪੋਰਟ ਵੱਲ ਨੁਕਤ੍ਹਾ ਕਰਦਾ ਹੈ। Maya localhost:3000 ਖੋਲ੍ਹਦੀ ਹੈ, ਪਰ API localhost:8080 ਉਮੀਦ ਕਰਦਾ ਹੈ, ਜਾਂ CORS ਰੀਕਤ ਕਰਦਾ ਹੈ। ਇੱਥੇ consistent defaults ਮਦਦ ਕਰਦੇ ਹਨ: ਇੱਕ ਥਾਂ WEB_PORT, API_PORT, ਅਤੇ API_BASE_URL ਸੈੱਟ ਕਰਨ ਲਈ, README ਵਿੱਚ ਉਮੀਦ ਕੀਤੇ ਲੋਕਲ URLs ਦਿਖਾਏ ਜਾਣ।
ਹੈਂਡਆਫ਼ ਤਦ ਹੀ ਮੁਕੰਮਲ ਮੰਨਿਆ ਜਾਵੇ ਜਦ ਕੋਈ ਹੋਰ ਵਿਅਕਤੀ ਸਾਫ ਕਲੋਨ ਤੋਂ ਪ੍ਰੋਜੈਕਟ ਚਲਾ ਸਕੇ ਬਿਨਾਂ ਸਵਾਲ ਪੁੱਛੇ। ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਪਲੇਟਫਾਰਮ ਤੋਂ ਬਾਹਰ ਬਚ ਕੇ ਰਹਿਣ ਦੀ ਸਾਬਤ ਕਰੋ।
ਇੱਕ ਫ੍ਰੈਸ਼ ਮਸ਼ੀਨ ਜਾਂ ਟ੍ਰੋਅਵੇਅ-ਕੰਟੇਨਰ 'ਤੇ ਇੱਕ ਆਖਰੀ "ਕਲੀਨ ਕਲੋਨ" ਟੈਸਟ ਕਰੋ। ਆਪਣੇ ਮੌਜੂਦਾ ਫੋਲਡਰ, ਕੈਸ਼ਡ ਦੇਪੈਂਡੇਂਸੀਜ਼, ਜਾਂ ਲੋਕਲ ਡੇਟਾਬੇਸ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋਂ ਨਾ ਕਰੋ। README ਨੂੰ ਬਿਲਕੁਲ ਅਨੁਸਰੋ। ਜੇ ਤੁਹਾਨੂੰ improvisation ਕਰਨੀ ਪਈ, ਡੌਕਸ ਜਾਂ ਸਕ੍ਰਿਪਟ ਨੂੰ ਠੀਕ ਕਰੋ ਜਦ ਤੱਕ ਤੁਹਾਨੂੰ ਮੁਸ਼ਕਲ ਨਾ ਆਏ।
ਜ਼ਰੂਰੀ ਜਾਂਚ ਜੋ ਅਕਸਰ ਅਤਿਅਧਿਕ ਫੇਲURE ਫੜ ਲੈਂਦੀ ਹੈ:
.env.example ਮੌਜੂਦ ਹੈ, ਅਤੇ ਹਰ ਲਾਜ਼ਮੀ ਵੈਰੀਏਬਲ ਦੀ ਵਿਆਖਿਆ ਸੁਰੱਖਿਅਤ ਉਦਾਹਰਨ ਮੁੱਲ ਦੇ ਨਾਲ ਹੈ।ਆਮ ਫੇਸਲੇ ਉਦਾਸ ਅਕਸਰ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਅਕਸਰ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ:
ਅਗਲੇ ਕਦਮ: ਇੱਕ ਮਾਲਿਕ ਨਿਯੁਕਤ ਕਰੋ ਜੋ 24-48 ਘੰਟਿਆਂ ਵਿੱਚ ਐਕਸਪੋਰਟ ਦੀ ਜਾਂਚ ਕਰੇ, ਨਾ ਕਿ ਹਫ਼ਤੇ ਬਾਅਦ। ਉਹ clean clone ਟੈਸਟ ਕਰੇ ਅਤੇ ਖਾਮੀਆਂ ਦੀ ਰਿਪੋਰਟ ਦੇਵੇ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਆਪਣੇ ਨਾਰਮਲ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣਾਉ: ਰਨ ਪਾਥ ਲਿਖਣ ਲਈ planning ਮੋਡ ਵਰਤੋ, ਵੱਡੇ ਬਦਲੋਂ ਤੋਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲਓ, ਅਤੇ ਨਿਯਮਤ ਅੰਤਰਾਲ 'ਤੇ ਸੋర్స్ ਐਕਸਪੋਰਟ ਕਰੋ ਤਾਂ ਕਿ ਹੈਂਡਆਫ਼ ਪੈਕੇਜ ਅਪ-ਟੂ-ਡੇਟ ਰਹੇ।
ਇੱਕ ਸਥਿਰ ਬਿੰਦੂ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਸਰੋਤ-ਸਚ ਮੰਨੋ।
ਘੱਟੋ-ਘੱਟ ਇਹ ਸ਼ਾਮਲ ਕਰੋ:
.env.example ਅਤੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਦੀ ਸਪੱਸ਼ਟ ਡੌਕਸੰਵੇਦਨਸ਼ੀਲ ਚੀਜ਼ਾਂ ਅਤੇ ਅਸਲੀ ਕ੍ਰੈਡੈਂਸ਼ਲਜ਼ ਬਾਹਰ ਰੱਖੋ।
ਸਭ ਵੈਰੀਏਬਲ ਇੱਕ ਹੀ ਥਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ (ਅਮੂਮਨ ਰੂਟ README) ਅਤੇ .env.example ਸ਼ਾਮਲ ਕਰੋ।
ਹਰ ਵੈਰੀਏਬਲ ਲਈ ਦਰਜ ਕਰੋ:
ਸੀਕ੍ਰੇਟ ਕਦੇ ਕਮਿਟ ਨਾ ਕਰੋ। ਸਿਰਫ ਪਲੇਸਹੋਲਡਰ ਕਮਿਟ ਕਰੋ।
ਸਧਾਰਣ ਵਿਵਸਥਾ:
.env.example ਵਿੱਚ replace_me ਪਲੇਸਹੋਲਡਰ.env (gitignored)ਹਰ ਲੋੜੀਂਦੇ ਸੀਕ੍ਰੇਟ ਨੂੰ ਕਿਵੇਂ ਤਿਆਰ ਕਰਨਾ ਹੈ, ਉਸਦੀ ਵੀ ਦਿਸ਼ਾ ਦਿਓ (ਉਦਾਹਰਨ: ਲਈ 32+ ਕਿਰਦਾਰਾਂ ਵਾਲੀ ਰੈਂਡਮ ਸਟ੍ਰਿੰਗ ਬਣਾਓ)।
ਜੋ ਵੀ ਪਹਿਲਾਂ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਦੁਹਰਾਇਆ ਗਿਆ ਹੈ, ਉਹ ਘੁਮਾਓ।
ਵਿਆਵਹਾਰਕ ਰੋਜ਼ਾਨਾ ਢੰਗ:
.env ਅਪਡੇਟ ਕਰੋਐਕਸਪੋਰਟ ਨੂੰ ਇੱਕ ਨਵੇਂ ਵਾਤਾਵਰਣ ਵਜੋਂ ਲਓ ਅਤੇ ਸੁੱਧ ਸ਼ੁਰੂ ਕਰੋ।
ਪਹਿਲੀ ਰਨ ਨੂੰ “ਕਾਪੀ, ਪੇਸਟ, ਰਨ” ਬਣਾਓ:
ਜੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ Docker ਜਾਂ Make ਦੀ ਲੋੜ ਹੈ, ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ—ਲੋਕਾਂ ਨੂੰ ਇਹ ਗਲਤੀਆਂ ਦੇ ਰਾਹੀਂ ਖੋਜਣ ਨਾ ਦੇਵੋ।
ਹਾਂ — ਕਿਉਂਕਿ PostgreSQL ਦੇ ਮਹੱਤਵਪੂਰਨ ਵਰਜਨ ਅਤੇ ਟੂਲ ਵਰਜਨ ਵੱਖਰੇ ਵਰਤਾਵ ਕਰ ਸਕਦੇ ਹਨ।
ਘੱਟੋ-ਘੱਟ ਦਰਜ ਕਰੋ:
ਜਦ ਵੀ ਹੋ ਸਕੇ ਵਰਜਨਾਂ ਨੂੰ ਪਿਨ ਕਰੋ, ਅਤੇ CI ਵਿੱਚ ਵਰਜਨ ਪ੍ਰਿੰਟ ਕਰੋ ਤਾਂ ਕਿ ਫੇਲਿਅਰ ਡਿਬੱਗ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ।
ਸ਼ੁਰੂਆਤ ਤੋਂ 'ਜ਼ੀਰੋ' ਤੱਕ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਰਾਹ ਦਿਖਾਓ:
ਖਤਰਨਾਕ ਐਕਸ਼ਨ ਲਈ ਗਾਰਡਰੇਲ ਦਿਓ (ਉਦਾਹਰਨ: APP_ENV=development ਜਾਂ CONFIRM ਫਲੈਗ)।
CI ਨੂੰ ਲੋਕਲ ਕਮਾਂਡਾਂ ਦੇ ਨਾਲ ਨਜ਼ਦੀਕ ਰੱਖੋ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਓ।
ਜੇ ਟੈਸਟ ਲਈ migrations ਲੋੜੀਂਦੇ ਹਨ, ਦਰਜ ਕਰੋ ਕਿ CI ਉਨ੍ਹਾਂ ਨੂੰ ਆਪ-ਆਪ ਚਲਾਉਂਦਾ ਹੈ ਜਾਂ ਇਹ ਇੱਕ ਖਾਸ ਕਦਮ ਹੈ।
“ਕਲੀਨ ਕਲੋਨ” ਟੈਸਟ ਚਲਾਓ:
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਵੀ ਵਾਰੀ improvisation ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਡੌਕਸ ਜਾਂ ਸਕ੍ਰਿਪਟ ਨੂੰ ਠੀਕ ਕਰੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਸਨੂੰ ਵਿਸ਼ਵਾਸਯੋਗ ਨਾ ਬਣਾ ਲਓ। ਇਹ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਅਸਲ ਪਰਿਸ਼ਰ ਦੀਆਂ ਛੁਪੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ (ਉਹਨਾਂ vibe-coding ਪਲੇਟਫਾਰਮਾਂ ਸਮੇਤ ਜਿਵੇਂ Koder.ai)।
JWT_SECRET