21 ਸਤੰ 2025·8 ਮਿੰਟ
ਕਲਾਇੰਟਾਂ ਅਤੇ ਏਜੰਸੀਜ਼ ਲਈ ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ
ਇਸ ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ ਨੂੰ ਵਰਤੋ: ਨਿਰਯਾਤ ਕਰਨ, ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ, secrets ਰੋਟੇਟ ਕਰਨ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣ, ਬਿਲਡ ਵੈਰੀਫਾਈ ਕਰਨ, ਅਤੇ ਕਲਾਇੰਟ ਨਾਲ ਡਿਪਲੋਯਮੈਂਟ ਮਾਲਕੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ।
ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਦਾ ਮਕਸਦ ਕੀ ਹੈ
ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਉਹ ਮੋਮੈਂਟ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ "ਐਜੰਸੀ ਚਲਾ ਸਕਦੀ ਹੈ" ਤੋਂ ਬਦਲ ਕੇ "ਕਲਾਇੰਟ ਦੇ ਮਾਲਕੀ ਹੋ ਜਾਂਦਾ ਹੈ" ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਾਫ਼ ਹੈਂਡਆਫ਼ ਨਾ ਹੋਣ 'ਤੇ ਆਮ ਸਮੱਸਿਆਵਾਂ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ: ਐਪ ਸਿਰਫ ਇੱਕ ਲੈਪਟੌਪ 'ਤੇ ਹੀ ਬਣਦੀ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਕਿਸੇ ਰਾਜ਼ 'ਤੇ ਨਿਰਭਰ ਹੈ ਜੋ ਮਿਲਦਾ ਹੀ ਨਹੀਂ, ਜਾਂ ਇੱਕ ਛੋਟਾ ਅਪਡੇਟ ਦਿਨਾਂ ਦੀ ਛਾਂਟ 'ਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ ਦਾ ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਟ੍ਰਾਂਸਫਰ ਤੋਂ ਬਾਅਦ, ਕਲਾਇੰਟ ਬਿਨਾਂ ਐਜੰਸੀ ਦੀ ਤੁਰੰਤ ਮਦਦ ਦੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਬਿਲਡ, ਰਨ, ਅਤੇ ਡਿਪਲੋਯ ਕਰ ਸਕੇ। ਇਸਦਾ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕਿ "ਕਦੇ ਵੀ ਸਹਾਇਤਾ ਨਹੀਂ ਹੋਵੇਗੀ।" ਮਤਲਬ ਇਹ ਕਿ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਦੁਹਰਾਈਯੋਗ ਅਤੇ ਦਸਤਾਵੇਜ਼ਿਤ ਹਨ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਆਸਾਨੀ ਨਾਲ ਕੰਮ سنਭਾਲ ਸਕੇ।
ਜੋ ਡਿਲਿਵਰੇਬਲ ਮੰਨੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਉਹ ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਘੱਟੋ-ਘੱਟ, ਇੱਕ ਪੂਰਾ ਹੈਂਡਆਫ਼ ਆਮ ਤੌਰ ਤੇ ਦਰਜ ਹੈ:
- ਪੂਰਾ ਰੇਪੋ (ਡਿਪਲੋਯਮੈਂਟ ਫਾਇਲਾਂ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਸਮੇਤ)
- ਇੱਕ ਸੈਟਅੱਪ ਦਸਤਾਵੇਜ਼ ਜੋ ਇੱਕ ਖਾਲੀ ਮਸ਼ੀਨ 'ਤੇ ਕੰਮ ਕਰੇ
- ਐਕਸੈਸ ਹੈਂਡਓਵਰ (ਅਕਾਊਂਟ, ਅਨੁਮਤੀਆਂ, ਅਤੇ ਸਿਸਟਮ ਕਿੱਥੇ ਰਿਹਾਂਦਾ ਹੈ)
- ਰੋਟੀਨ ਟਾਸਕਾਂ ਲਈ ਰਨਬੁੱਕ (ਡਿਪਲੋਯ, ਰੋਲਬੈਕ, ਬੈਕਅੱਪ, ਲੌਗ)
- ਇੱਕ ਅਖ਼ੀਰਲਾ “ਜਾਣਿਆ-ਪਸੰਦ” ਵਰਜਨ ਟੈਗ ਜਾਂ ਸਨੈਪਸ਼ਾਟ ਜਿਹਨੂੰ ਕਲਾਇੰਟ ਰਿਫਰ ਕਰ ਸਕੇ
ਸਮੱਗਰੀ ਦੇ ਨਾਲ-ਨਾਲ ਸਕੋਪ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕੁਝ ਹੈਂਡਆਫ਼ ਸਿਰਫ ਇਕ ਵਾਤਾਵਰਣ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ)। ਹੋਰਾਂ ਵਿੱਚ dev, staging, ਅਤੇ production ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਹਰ ਇੱਕ ਲਈ ਵੱਖ-ਵੱਖ ਸੈਟਿੰਗ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕਿਹੜੇ ਵਾਤਾਵਰਣ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਲੋਕ ਵੱਖ-ਵੱਖ ਸੋਚਾਂਗੇ ਅਤੇ ਇੱਥੇ ਹੀ ਆਊਟੇਜ ਆ ਸਕਦੇ ਹਨ।
ਇਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਤਰੀਕਾ ਸਫਲਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰਨ ਲਈ ਇੱਕ ਵੈਰੀਫਿਕੇਸ਼ਨ ਟੈਸਟ ਹੈ: ਕੋਈ ਵਿਅਕਤੀ ਜਿਸਨੇ ਐਪ ਨਹੀਂ ਬਣਾਈ, ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕੇ (ਉਦਾਹਰਨ ਲਈ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai 'ਤੇੋਂ), ਦਸਤਾਵੇਜ਼ ਪਾਲਣਾ ਕਰੇ, env vars ਸੈਟ ਕਰੇ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਏ, ਬਿਲਡ ਕਰੇ, ਅਤੇ ਮਨਜ਼ੂਰੀ ਪ੍ਰਾਪਤ ਵਾਤਾਵਰਣ 'ਤੇ ਡਿਪਲੋਯ ਕਰ ਸਕੇ।
ਇਹ ਚੈਕਲਿਸਟ ਤਕਨੀਕੀ ਤਿਆਰੀ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ: environment variables, secrets ਰੋਟੇਸ਼ਨ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਡਿਪਲੋਯਮੈਂਟ ਸਕ੍ਰਿਪਟ, ਅਤੇ ਬਿਲਡ ਦੀ ਪੜਤਾਲ। ਇਹ ਕਾਨੂੰਨੀ ਸ਼ਰਤਾਂ, ਠੇਕੇ, IP ਕਲੌਜ਼, ਜਾਂ ਭੁਗਤਾਨੀ ਵਿਵਾਦਾਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦੀ—ਉਹ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ ਪਰ ਵੱਖ-ਵੱਖ ਸਮਝੌਤੇ ਵਿੱਚ ਰੱਖੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।
ਨਿਰਯਾਤ ਤੋਂ ਪਹਿਲਾਂ: ਮਾਲਕੀ ਅਤੇ ਸਮਾਂ-ਸੰਬੰਧੀ ਸਹਿਮਤੀ
ਇੱਕ ਸਾਫ਼ ਹੈਂਡਆਫ਼ ਕਿਸੇ ਵੀ ਨਿਰਯਾਤ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਤੈਅ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ ਕੌਣ ਕੀ ਮਾਸਲਿਕਤਾ ਰੱਖੇਗਾ ਅਤੇ ਕਦੋਂ, ਤਾਂ ਅੰਤਿਮ-ਮਿੰਟ ਦੇ ਹੈਰਾਨੀ-ਜਹਾਨਾ ਘਟਦੀਆਂ ਘਟਨਾਵਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ: ਟੁੱਟੇ ਹੋਏ ਡਿਪਲੋਯਮੈਂਟ, ਅਣਭੁਗਤੀਆ ਹੋਸਟਿੰਗ, ਜਾਂ ਗੁਮ ਹੋਇਆ ਐਕਸੈਸ।
ਹੈਂਡਆਫ਼ ਮਿਤੀ ਅਤੇ ਛੋਟਾ ਫ਼ਰੀਜ਼ ਵਿੰਡੋ ਤੈਅ ਕਰੋ
ਹੈਂਡਆਫ਼ ਮਿਤੀ ਚੁਣੋ ਅਤੇ ਇੱਕ ਫ਼ਰੀਜ਼ ਵਿੰਡੋ (ਅਕਸਰ 24-72 ਘੰਟੇ) ਨਿਰਧਾਰਿਤ ਕਰੋ ਜਿਸ ਦੌਰਾਨ ਸਿਰਫ ਜਰੂਰੀ ਫਿਕਸ ਆਉਂਦੇ ਹਨ। ਇਸ ਨਾਲ ਨਿਰਯਾਤਿਤ ਕੋਡ ਅਤੇ ਚੱਲ ਰਹੀ ਸਿਸਟਮ ਦਾ ਸਿੰਕ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਫ਼ਰੀਜ਼ ਦੌਰਾਨ ਹੌਟਫਿਕਸ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਬਿਲਕੁਲ ਲਿਖੋ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉ ਕਿ ਇਹ τελευταίο ਨਿਰਯਾਤ 'ਚ ਸ਼ਾਮਲ ਹੈ।
ਅਕਾਊਂਟ ਅਤੇ ਬਿਲਿੰਗ ਦੀ ਮਾਲਕੀ ਸਪਸ਼ਟ ਕਰੋ
ਫੈਸਲਾ ਕਰੋ ਕਿ DNS, ਕਲਾਉਡ ਹੋਸਟਿੰਗ, ਅਤੇ ਕੋਈ ਵੀ ਭੁਗਤਾਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਹਨ ਉਹਨਾਂ ਦੀ ਮਾਲਕੀ ਹੈਂਡਆਫ਼ ਤੋਂ ਬਾਅਦ ਕਿਹੜੇ ਕੋਲ ਹੋਵੇਗੀ। ਇਹ ਸਿਰਫ ਕਿਰਿਆਪੱਤਰ ਨਹੀਂ—ਜੇ ਬਿਲਿੰਗ ਐਜੰਸੀ ਕਾਰਡ 'ਤੇ ਰਹਿ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸੇਵਾਵਾਂ ਬਿਨਾਂ ਚેતਾਵਨੀ ਦੇ ਰੁਕ ਸਕਦੀਆਂ ਹਨ।
ਇਕ ਤਤਕਾਲ ਤਰੀਕਾ:
- DNS, ਹੋਸਟਿੰਗ, ਅਤੇ ਈਮੇਲ ਲਈ ਅਕਾਊਂਟ ਮਾਲਕ ਦਾ ਨਾਮ ਦਿਓ
- ਹੈਂਡਆਫ਼ ਮਿਤੀ ਤੋਂ ਹਰ ਬਿੱਲ ਦਾ ਭੁਗਤਾਨ ਕੌਣ ਕਰੇਗਾ, ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ
- ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਕਾਊਂਟ ਟ੍ਰਾਂਸਫਰ ਕੀਤੇ ਜਾਣਗੇ ਜਾਂ ਕਲਾਇੰਟ ਦੇ ਨਵੇਂ ਅਕਾਊਂਟ 'ਤੇ ਦੁਬਾਰਾ ਬਣਾਏ ਜਾਣਗੇ
- ਹਰ ਪ੍ਰੋਵਾਈਡਰ ਲਈ ਸਹਾਇਤਾ ਸੰਪਰਕ ਦਿਓ
ਇਹ ਸਾਰਾ ਕੁਝ ਸਾਫ਼ ਭਾਸ਼ਾ 'ਚ ਲਿਖੋ ਤਾ ਜੋ ਦੋਹਾਂ ਪੱਖਾਂ ਨੂੰ ਪਾਲਣਾ ਆਸਾਨ ਹੋਵੇ।
ਵਾਤਾਵਰਣਾਂ ਦੀ ਸੂਚੀ ਅਤੇ ਉਹ ਕਿੱਥੇ ਚਲਦੇ ਹਨ
ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੀ-ਕੀ ਵਾਤਾਵਰਣ ਮੌਜੂਦ ਹਨ (local, staging, production) ਅਤੇ ਹਰੇਕ ਕਿੱਥੇ ਚਲਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ staging ਵੱਖਰਾ ਸਰਵਰ ਹੈ, ਵੱਖਰਾ ਡੇਟਾਬੇਸ ਹੈ, ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਫੀਚਰ ਫਲੈਗ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਵਰਤਿਆ ਹੈ, ਤਾਂ ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉੱਥੇ ਕੀ ਹੋਸਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਨਿਰਯਾਤ ਤੋਂ ਬਾਅਦ ਕਿਹੜੇ ਹਿੱਸੇ ਕਲਾਇੰਟ ਦੀ ਇਨਫ੍ਰਾਸਟਰੱਕਚਰ 'ਤੇ ਚੱਲਣ ਦੀ ਉਮੀਦ ਹੈ।
ਐਕਸੈਸ ਪਹਿਲਾਂ ਹੀ ਇਕੱਠਾ ਕਰੋ
ਆਖਰੀ ਦਿਨ ਤੱਕ ਐਕਸੈਸ ਦੀ ਬੇਨਤੀ ਨਾ ਛੱਡੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਹੀ ਲੋਕਾਂ ਕੋਲ ਜ਼ਰੂਰੀ ਐਕਸੈਸ ਹੈ: ਰੇਪੋ, CI, ਹੋਸਟਿੰਗ, ਡੇਟਾਬੇਸ, ਅਤੇ ਈਮੇਲ ਪ੍ਰੋਵਾਈਡਰ।
ਇਸ ਦੇ ਨਾਲ ਆਖਰੀ ਐਕਸੈਪਟੈਂਸ ਟੈਸਟ ਅਤੇ ਸਾਈਨ-ਆਫ਼ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਵੀ ਸਹਿਮਤੀ ਕਰੋ। ਉਦਾਹਰਨ: “ਕਲਾਇੰਟ ਇੱਕ ਖਾਲੀ ਮਸ਼ੀਨ ਤੋਂ ਬਿਲਡ ਕਰ ਸਕਦਾ ਹੈ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾ ਸਕਦਾ ਹੈ, staging 'ਤੇ ਡਿਪਲੋਯ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ smoke test ਪਾਸ ਕਰਦਾ ਹੈ। ਫਿਰ ਦੋਹਾਂ ਪੱਖ ਲਿਖਤੀ ਤੌਰ 'ਤੇ ਸਾਈਨ-ਆਫ਼ ਕਰਦੇ ਹਨ।”
ਰੇਪੋ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਦੇ ਮੂਲ ਤੱਤ
ਇੱਕ ਚੰਗੀ ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ ਉਹ ਰੇਪੋ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜੋ ਇੱਕ ਨਵੀਂ ਟੀਮ Minutes ਵਿੱਚ ਖੋਲ੍ਹ ਸਕੇ ਅਤੇ ਸਮਝ ਸਕੇ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਸ਼ਾਮਲ ਹੈ (ਐਪ ਕੋਡ, ਕੰਫਿਗ ਟੈਂਪਲੇਟ, ਸਕ੍ਰਿਪਟ) ਅਤੇ ਕੀ ਜਾਣ-ਬੁਝ ਕੇ ਘਟਾਇਆ ਗਿਆ ਹੈ (ਅਸਲੀ secrets, ਪ੍ਰਾਈਵੇਟ ਕੀਜ਼, ਵੱਡੀਆਂ ਜੈਨਰੇਟ ਕੀਤੀਆਂ ਫਾਈਲਾਂ)। ਜੇ ਕੁਝ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ ਤਾਂ ਕਹੋ ਕਿ ਉਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕਿਸਦੀ ਮਾਲਕੀ ਹੈ।
ਢਾਂਚਾ ਪੇਸ਼ਬੰਧ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਪਸ਼ਟ ਟੌਪ-ਲੇਵਲ ਫੋਲਡਰਾਂ ਲਈ ਲਕੜੀ: frontend/, backend/, mobile/, infra/, scripts/, ਅਤੇ docs/। ਜੇ ਪ੍ਰੋਜੈਕਟ monorepo ਹੈ, ਤਾਂ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੇ ਰਿਸ਼ਤੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਹ ਵਿਆਖਿਆ ਕਰੋ।
ਤੁਹਾਡੀ README ਉਸ ਵਿਅਕਤੀ ਲਈ ਵਰਤਣਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸਨੇ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਬਣਾਇਆ। ਇਸ ਵਿੱਚ prerequisites ਅਤੇ ਇੱਕ ਤੇਜ਼ ਰਾਹ ਦਿੱਤਾ ਜਾਣا ਚਾਹੀਦਾ ਹੈ ਜੋ ਇੱਕ ਵਰਕਿੰਗ dev ਰਨ ਤੱਕ ਲੈ ਜਾਵੇ, ਬਿਨਾਂ ਅਟਕਾਵਾਂ ਦੇ।
ਘੱਟੋ-ਘੱਟ ਕੀ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਛੋਟਾ, ਮਨੁੱਖੀ ਪੜ੍ਹਨ ਯੋਗ README ਖੰਡ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇਹ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:
- ਇਹ ਰੇਪੋ ਕੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇਹ ਕੀ ਕਰਦਾ ਹੈ (ਇੱਕ ਪੈਰਾ)
- prerequisites ਨਾਲਠਿਕ ਅਨੁਕੂਲ ਵਰਜਨ (runtime, package manager, Docker ਜੇ ਲੋੜ ਹੋਵੇ)
- LOCAL DEV ਲਈ ਇੱਕ-ਕਮਾਂਡ ਸਟਾਰਟ ਸਟੈਪ (ਅਤੇ “ਸਫਲਤਾ” ਕੀ ਦਿਖਾਉਂਦੀ ਹੈ)
- ਟੈਸਟ ਚਲਾਉਣ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਆਰਟੀਫੈਕਟ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ
- ਮੁੱਖ ਦਸਤਾਵੇਜ਼ ਕਿੱਥੇ ਮਿਲਦੇ ਹਨ: ਆਰਕੀਟੈਕਚਰ ਨੋਟਸ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਡਿਪਲੋਯ ਨੋਟਸ
ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਛੋਟੀ ਆਰਕੀਟੈਕਚਰ ਨੋਟਸ ਸ਼ਾਮਲ ਕਰੋ: ਕੀ ਕੌਣ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ। ਇੱਕ ਛੋਟਾ ਡਾਇਅਗ੍ਰਾਮ ਵਿਕਲਪਿਕ ਹੈ, ਪਰ ਕੁਝ ਵਾਕਾਂ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨ: “React frontend Go API ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। API PostgreSQL ਨੂੰ ਪੜ੍ਹਦਾ ਅਤੇ ਲਿਖਦਾ ਹੈ। ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਵੱਖਰੇ ਵਰਕਰ ਪ੍ਰਕਿਰਿਆ ਵਜੋਂ ਦੌੜਦੇ ਹਨ।”
ਅਖੀਰ ਵਿੱਚ, ਹੈਂਡਆਫ਼ ਬਿਲਡ ਲਈ ਇੱਕ ਵਰਜਨਡ ਚੇਂਜਲੌਗ ਜਾਂ ਰਿਲੀਜ਼ ਨੋਟਸ ਸ਼ਾਮਲ ਕਰੋ। ਇਹ CHANGELOG.md ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਇੱਕ ਛੋਟਾ “handoff release notes” ਫਾਇਲ ਜੋ ਨਿਸ਼ਚਿਤ commit/tag, ਕੀ ਸ਼ਿਪ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਮੁੱਦੇ ਦਰਸਾਏ।
ਜੇ ਕੋਡ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਨਿਰਯਾਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਬਣਾਈ ਗਈ ਪ੍ਰੋਜੈਕਟ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਹੈ (web, server, mobile), ਉਮੀਦ ਕੀਤੀ ਟੂਲਚੇਨ (ਉਦਾਹਰਨ: React, Go, PostgreSQL, Flutter), ਅਤੇ ਕਿਹੜੇ OS/ਟੂਲਿੰਗ ਵਰਜਨ ਸਹਾਇਤਾਕਾਰੀ ਹਨ, ਇਹ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਬਿਲਡ ਨੂੰ ਦੁਹਰਾਉ ਸਕੇ।
Environment variables: ਇਨਵੈਂਟਰੀ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ
Environment variables ਅਕਸਰ ਉਹ ਕਾਰਨ ਹੁੰਦੇ ਹਨ ਕਿ "ਕਾਰਜ ਕਰਦੀ ਐਪ" ਹੈਂਡਆਫ਼ ਤੋਂ ਬਾਅਦ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਚੰਗੀ ਚੈਕਲਿਸਟ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਦਾ ਹਿੱਸਾ ਮੰਨਦੀ ਹੈ, ਨਾ ਕਿ ਇਕ ਬਾਅਦ ਦੀ ਗੱਲ।
ਇੱਕ ਇਨਵੈਂਟਰੀ ਲਿਖੋ ਜਿਹਨੂੰ ਨਵੀਂ ਟੀਮ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਫੋਲੋ ਕਰ ਸਕੇ। ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਰਤੋ ਅਤੇ ਉਦਾਹਰਨ ਮੁੱਲ ਦਿਖਾਓ (ਅਸਲੀ secrets ਨਹੀਂ)। ਜੇ ਕੋਈ ਵੈਰੀਏਬਲ ਆਪਸ਼ਨਲ ਹੈ ਤਾਂ ਦੱਸੋ ਕਿ ਗਾਇਬ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਡਿਫੌਲਟ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਇਨਵੈਂਟਰੀ ਪੇਸ਼ ਕਰਨ ਦਾ ਸਧਾਰਨ ਤਰੀਕਾ:
- ਵੈਰੀਏਬਲ ਨਾਂ, ਇਹ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਉਦਾਹਰਨ ਫਾਰਮੈਟ
- ਲਾਜ਼ਮੀ ਜਾਂ ਆਪਸ਼ਨਲ, ਅਤੇ ਕੋਈ ਡਿਫੌਲਟ ਵਿਵਹਾਰ
- ਇਹ ਕਿੱਥੇ ਸੈਟ ਹੁੰਦਾ ਹੈ (CI, ਹੋਸਟਿੰਗ ਡੈਸ਼ਬੋਰਡ, local .env ਫਾਇਲ)
- ਕਿਹੜੇ ਵਾਤਾਵਰਣ ਲਈ ਵੱਖਰੇ ਮੁੱਲ ਚਾਹੀਦੇ ਹਨ (dev, staging, production)
- ਬਦਲਾਅ ਦੀ ਮਾਲਕੀ ਕੌਣ ਰੱਖਦਾ ਹੈ (ਕਲਾਇੰਟ, ਐਜੰਸੀ, ਜਾਂ ਸਾਂਝਾ)
ਵਾਤਾਵਰਣ-ਨਿਰਭਰ ਅੰਤਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਓ। ਉਦਾਹਰਨ ਲਈ, staging ਇੱਕ ਟੈਸਟ ਡੇਟਾਬੇਸ ਅਤੇ ਸੈਂਡਬਾਕਸ ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਦਕਿ production ਲਾਈਵ ਸੇਵਾਵਾਂ ਵਰਤੇਗੀ। ਉਹ ਮੁੱਲ ਜਿਹਨਾਂ ਨੂੰ ਸਿਸਟਮਾਂ ਵਿੱਚ ਮਿਲਾਣਾ ਜਰੂਰੀ ਹੈ, ਜਿਵੇਂ callback URLs, allowed origins, ਜਾਂ ਮੋਬਾਈਲ ਐਪ ਬੰਡਲ ਆਈਡੈਂਟੀਫਾਇਰ, ਨੂੰ ਵੀ ਨੋਟ ਕਰੋ।
ਹਰ ਇੱਕ ਮੁੱਲ ਅੱਜ ਕਿੱਥੇ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਇਹ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਕਈ ਟੀਮ ਮੁੱਲ ਨੂੰ ਵੱਖ-ਵੱਖ ਥਾਂਵਾਂ 'ਤੇ ਰੱਖਦੀਆਂ ਹਨ: ਵਿਕਾਸ ਲਈ local .env ਫਾਇਲਾਂ, ਬਿਲਡ ਲਈ CI ਵੈਰੀਏਬਲ, ਅਤੇ ਰਨਟਾਈਮ ਲਈ ਹੋਸਟਿੰਗ ਸੈਟਿੰਗ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ Koder.ai ਵਰਤ ਕੇ ਐਪ ਨਿਰਯਾਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ .env.example ਫਾਇਲ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਸੰਖੇਪ ਨੋਟ ਦਿਓ ਕਿ ਕਿਹੜੇ ਵੈਰੀਏਬਲ ਪਹਿਲੇ ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ ਭਰੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।
ਆਖਿਰਕਾਰ, ਦਿਖਾਓ ਕਿ ਰੇਪੋ ਵਿੱਚ ਕੋਈ secrets ਲੁਕੇ ਹੋਏ ਨਹੀਂ ਹਨ। ਸਿਰਫ ਮੌਜੂਦਾ ਫਾਇਲਾਂ ਦੀ ਜਾਂਚ ਨਾ ਕਰੋ—ਕਮਿੱਟ ਇਤਿਹਾਸ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਤਾਂ ਜੋ ਗਲਤੀ ਨਾਲ ਕੀਤੇ ਕੁੰਜੀਆਂ, ਪੁਰਾਣੇ .env ਫਾਇਲਾਂ, ਜਾਂ ਸੈਂਪਲ ਕੰਫਿਗ ਵਿੱਚ ਨਕਲ ਕੀਤੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਮਿਲ ਸਕਣ।
ਨਮੂਨਾ: React frontend ਅਤੇ Go API ਨੂੰ API_BASE_URL (web app ਲਈ), ਅਤੇ DATABASE_URL ਅਤੇ JWT_SIGNING_KEY (backend ਲਈ) ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ staging ਵੱਖਰੇ ਡੋਮੇਨ 'ਤੇ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਦੋਹਾਂ ਮੁੱਲ ਲਿਖੋ ਅਤੇ ਦੱਸੋ ਕਿ ਕਿੱਥੇ ਬਦਲਣਾ ਹੈ ਤਾਂ ਜੋ ਨਵੀਂ ਟੀਮ staging ਸੈਟਿੰਗਾਂ ਨੂੰ ਗਲਤੀ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਨਾ ਭੇਜੇ।
Secrets rotation: ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ transfer ਕਰੋ, ਫਿਰ ਸਾਬਤ ਕਰੋ
Make ownership transfer easier
Move from agency-run to client-owned with exports, hosting, and rollback in one workflow.
ਹੈਂਡਆਫ਼ ਤਦ ਤੱਕ ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ ਜਦ ਤਕ ਕਿ ਕਲਾਇੰਟ ਹਰ ਉਹ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਨਿਯੰਤਰਿਤ ਨਾ ਕਰੇ ਜੋ ਐਪ ਨੂੰ ਚਾਹੀਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ secrets ਰੋਟੇਟ ਕਰਨਾ, ਸਿਰਫ਼ ਸਾਂਝਾ ਕਰਨਾ ਨਹੀਂ। ਜੇ ਐਜੰਸੀ (ਜਾਂ ਪਿਛਲਾ ਠੇਕੇਦਾਰ) ਕੋਲ ਹੁਣ ਵੀ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕੀਜ਼ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਖੁਲਾ ਦਰਵਾਜ਼ਾ ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਆਡਿਟ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਪੂਰੀ ਇਨਵੈਂਟਰੀ ਬਣਾਉਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਸਿਰਫ ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ ਉਤੇ ਹੀ ਰੁਕੋ ਨਹੀਂ। ਤੀਜੇ-ਪੱਖ API ਕੁੰਜੀਆਂ, OAuth ਕਲਾਇੰਟ ਸੀਕ੍ਰੇਟ, webhook ਸਾਈਨਿੰਗ ਸੀਕ੍ਰੇਟ, JWT ਸਾਈਨਿੰਗ ਕੀ, SMTP ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ, ਸਟੋਰੇਜ ਐਕਸੈਸ ਕੀਜ਼, ਅਤੇ CI ਵਿੱਚ ਮੌਜੂਦ ਕੋਈ ਵੀ "ਅਸਥਾਈ" ਟੋਕਨ ਸ਼ਾਮਲ ਕਰੋ।
ਰੋਟੇਸ਼ਨ ਦਿਨ ਲਈ ਸਧਾਰਨ ਚੈਕਲਿਸਟ:
- ਹਰ ਇੱਕ ਸੀਕ੍ਰੇਟ ਲਿਸਟ ਕਰੋ, ਇਹ ਕੀ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਅੱਜ ਕਿੱਥੇ ਸੈਟ ਹੈ (local env ਫਾਇਲਾਂ, CI, ਹੋਸਟਿੰਗ ਡੈਸ਼ਬੋਰਡ, vault)
- ਨਵੇਂ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਕਲਾਇੰਟ ਦੇ ਅਕਾਊਂਟਾਂ ਦੇ ਅਧੀਨ ਬਣਾਓ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਮਾਲਕ ਸੈਟ ਕਰੋ (ਇਕ ਵਿਅਕਤੀ ਅਤੇ ਇੱਕ ਟੀਮ ਇਨਬਾਕਸ)
- ਐਪ ਕੰਫਿਗ ਨੂੰ ਨਵੇਂ ਮੁੱਲਾਂ ਨਾਲ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਪਹਿਲਾਂ staging ਜਾਂ ਟੈਸਟ ਵਾਤਾਵਰਣ 'ਤੇ ਡਿਪਲੋਯ ਕਰੋ
- ਨਵੇਂ ਕੰਮ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਹੋਣ 'ਤੇ ਪੁਰਾਣੀਆਂ ਕੁੰਜੀਆਂ ਤੁਰੰਤ ਰੱਦ ਕਰੋ
- ਸਹੀ ਰੋਟੇਸ਼ਨ ਕਦਮ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲੀ ਵਾਰੀ ਰੋਟੇਸ਼ਨ ਨਿਰਾਸ਼ਾਜਨਕ ਨਹੀਂ ਲੱਗੇ
ਰੋਟੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਸਾਬਤ ਕਰੋ ਕਿ ਕੁਝ ਟੁੱਟਿਆ ਨਹੀਂ। ਸਿਰਫ ਲੌਗ ਚੈਕ ਕਰਨ ਦੀ ਥਾਂ ਤੇ ਤੇਜ਼ "ਅਸਲ ਯੂਜ਼ਰ" ਟੈਸਟ ਚਲਾਓ।
ਉਹ ਫਲੋਜ਼ ਤੇ ਫੋਕਸ ਕਰੋ ਜੋ secrets 'ਤੇ ਨਿਰਭਰ ਹਨ:
- ਲੌਗਿਨ, ਸਾਈਨਅਪ, ਪਾਸਵਰਡ ਰੀਸੈਟ, ਅਤੇ ਟੋਕਨ ਰੀਫ੍ਰੈਸ਼
- ਭੁਗਤਾਨ, ਈਮੇਲ ਭੇਜਣਾ, ਅਤੇ ਫ਼ਾਇਲ ਅੱਪਲੋਡ
- Webhooks (ਸਾਈਨਚਰ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਰੀਟ੍ਰਾਈ ਹੈਂਡਲਿੰਗ)
- ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਜਾਂ ਨਿਯਤ ਸਮੇਂ ਵਾਲੇ ਟਾਸਕ ਜੋ ਤੀਜੀਆਂ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ
- ਪ੍ਰਸ਼ਾਸਕੀ ਕਾਰਵਾਈਆਂ ਜੋ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਐਂਡਪੋਇੰਟ ਨੂੰ ਹਿੱਟ ਕਰਦੀਆਂ ਹਨ
ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਪ੍ਰੋਜੈਕਟ ਨਿਰਯਾਤ ਕੀਤਾ ਅਤੇ ਐਪ ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਈਡਰ ਅਤੇ ਈਮੇਲ ਡেলਿਵਰੀ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਦੋਹਾਂ ਕੁੰਜੀਆਂ ਰੋਟੇਟ ਕਰੋ, ਦੁਬਾਰਾ ਡਿਪਲੋਯ ਕਰੋ, ਫਿਰ ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਲੈਣ-ਦੇਣ ਅਤੇ ਇੱਕ ਟੈਸਟ ਈਮੇਲ ਭੇਜੋ। ਸਿਰਫ ਉਹੀ ਸਮਾਂ ਪੁਰਾਣੀਆਂ ਏਜੰਸੀ-ਮਾਲਕੀ ਕੁੰਜੀਆਂ ਰੱਦ ਕਰੋ ਜਦੋਂ ਇਹ ਸਫਲ ਹੋਣ।
ਆਖਰਕਾਰ, ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਸੀਕ੍ਰੇਟ ਅੱਗੇ ਕਿੱਥੇ ਰਹਿਣਗੇ (vault, CI variables, ਜਾਂ ਹੋਸਟਿੰਗ ਸੈਟਿੰਗ), ਕੌਣ ਇਨ੍ਹਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੇ ਰੋਟੇਸ਼ਨ ਗਲਤ ਹੋਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਰੋਲ ਬੈਕ ਕਰਨਾ ਹੈ।
ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਡੇਟਾ ਹੈਂਡਲਿੰਗ
ਹੈਂਡਆਫ਼ "ਮੁਕੰਮਲ" ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਡੇਟਾਬੇਸ ਪਹਿਲਾ ਟੁੱਟਦਾ ਹੈ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਡੇਟਾ ਨੂੰ ਇੱਕ ਆਪਣੀ ਉਤਪਾਦ ਵਾਂਗ ਸਮਝੋ: ਵਰਜ਼ਨਡ, ਦੁਹਰਾਈਯੋਗ, ਅਤੇ ਟੈਸਟ ਕੀਤੇ ਹੋਏ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਮੌਜੂਦਾ ਡੇਟਾਬੇਸ ਵਰਜ਼ਨ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਿੱਥੇ ਹਨ, ਇਹ ਦਰਜ ਕਰੋ। ਵਿਸ਼ੇਸ਼ ਹੋਵੇ: ਫੋਲਡਰ ਪਾਥ, ਨੇਮਿੰਗ ਪੈਟਰਨ, ਅਤੇ ਆਖਰੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ID (ਜਾਂ ਟਾਈਮਸਟੈਂਪ)। ਜੇ ਤੁਸੀਂ PostgreSQL ਵਰਤ ਰਹੇ ਹੋ (Go ਬੈਕਐਂਡ ਦੇ ਨਾਲ ਆਮ), ਤਾਂ ਲੋੜੀਂਦੇ extensions ਦੀ ਵੀ ਨੋਟ ਕਰੋ।
ਕੀ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਹੈ (ਤਾਂ ਜੋ ਹੋਰ ਕੋਈ ਚਲਾ ਸਕੇ)
ਇੱਕ ਛੋਟੀ ਰਨਬੁੱਕ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇਹ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:
- ਕਿਹੜੀ ਕਮਾਂਡ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਂਦੀ ਹੈ, ਅਤੇ ਕੰਮ ਕਰਨ ਦਾ ਆਰਡਰ (ਡੇਟਾਬੇਸ ਬਣਾਉ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਗਾਓ, ਫਿਰ seeds)
- ਇਹ ਵਾਤਾਵਰਣ ਅਨੁਸਾਰ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ (local, staging, production), ਸਮੇਤ ਕੋਈ “safe mode” ਫ਼ਲੈਗ
- ਕੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਡਿਪਲੋਯ 'ਤੇ ਆਪਣੇ ਆਪ ਚਲਦੇ ਹਨ ਜਾਂ ਮਨੁਆਲ ਚਲਾਉਣੇ ਪੈਂਦੇ ਹਨ, ਅਤੇ ਕੌਣ ਚਲਾ ਸਕਦਾ ਹੈ
- Seed ਡੇਟਾ ਰਣਨੀਤੀ: ਕੋਈ ਨਹੀਂ, ਸਿਰਫ ਡੈਮੋ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਜ਼ਰੂਰੀ ਰਿਕਾਰਡ (admin ਯੂਜ਼ਰ, ਡਿਫੌਲਟ ਸੈਟਿੰਗ)
- ਰੋਲਬੈਕ ਯੋਜਨਾ: ਕੀ ਵਾਪਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ (ਉਦਾਹਰਨ ਲਈ, ਨੁਕਸਾਨਦਾਇਕ column drops)
ਰੋਲਬੈਕ ਵਿੱਚ ਇਮਾਨਦਾਰੀ ਜ਼ਰੂਰੀ ਹੈ। ਕੁਝ ਬਦਲਾਅ ਸਿਰਫ ਬੈਕਅੱਪ ਰਿਪੋਰਸ ਦੇ ਨਾਲ ਹੀ ਉਲਟੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਓ ਅਤੇ ਇੱਕ ਬੈਕਅੱਪ ਕਦਮ (ਡੀਪਲੋਯ 'ਤੇ ਈ-ਸਨੈਪਸ਼ਾਟ, ਰਿਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪੁਸ਼ਟੀ) ਨਾਲ ਜੋੜੋ।
ਹੈਂਡਆਫ਼ ਮੁਕੰਮਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਦੀ ਇੱਕ ਨਕਲ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਓ। ਇਹ ਦੇਰ ਨਾਲ ਚੱਲਣ ਵਾਲੀਆਂ ਕਮਾਂਡਾਂ, ਗੁੰਮ ਹਾਂਡਿੰਗ ਇਸ਼ਯੂਜ਼, ਅਤੇ "ਖਾਲੀ ਡੇਟਾ 'ਤੇ ਚੱਲਦਾ" ਸਮੱਸਿਆਵਾਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਾਸ਼ਤਵਿਕ ਟੈਸਟ ਹੈ: ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ, env vars ਸੈੱਟ ਕਰੋ, ਆਨੋਨਿਮਾਈਜ਼ਡ ਡੰਪ ਰੀਸਟੋਰ ਕਰੋ, ਫਿਰ ਸ਼ੁਰੂ ਤੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਗਾਓ। ਇਹ ਇੱਕ ਵੱਡੇ ਹਿੱਸੇ ਦੀ ਜਾਂਚ ਸਾਬਤ ਕਰਦਾ ਹੈ।
ਜੇ ਐਪ Koder.ai ਵਿੱਚ ਬਣੀ ਹੋਈ ਸੀ ਅਤੇ ਫਿਰ ਨਿਰਯਾਤ ਕੀਤੀ ਗਈ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨ ਫਾਇਲਾਂ ਅਤੇ ਕੋਈ ਈ-ਸੀਡ ਸਕ੍ਰਿਪਟ ਨਿਰਯਾਤ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਬੈਕਐਂਡ ਸਟਾਰਟਅੱਪ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਰੈਫਰ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ।
ਬਿਲਡ ਅਤੇ CI: ਇਸ ਨੂੰ ਦੁਹਰਾਈਯੋਗ ਬਣਾਓ
ਹੈਂਡਆਫ਼ ਉਸ ਵੇਲੇ ਹੀ ਪੂਰਾ ਹੈ ਜਦੋਂ ਕੋਈ ਹੋਰ ਵਿਅਕਤੀ ਖਾਲੀ ਮਸ਼ੀਨ 'ਤੇ ਐਪ ਨੂੰ ਸਿਰੇ ਤੋਂ ਦੁਬਾਰਾ ਬਿਲਡ ਕਰ ਸਕੇ। ਤੁਹਾਡੀ ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ ਵਿੱਚ ਬਿਲਡ ਕਮਾਂਡਾਂ, ਲੋੜੀਂਦੇ ਵਰਜਨ, ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਆਉਟਪੁੱਟ (ਉਦਾਹਰਨ: "web bundle /dist ਵਿੱਚ", "API ਬਾਇਨਰੀ ਨਾਮ", "Flutter APK ਸਥਾਨ") ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਜੋ ਟੂਲਸ ਅਤੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਤੁਸੀਂ ਦਰਅਸਲ ਵਰਤਦੇ ਹੋ, ਉਹ ਲਿਖੋ—ਨ ਕਿ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਆਮ ਸਟੈਕ ਲਈ ਇਹ Node.js (npm ਜਾਂ pnpm) React ਲਈ, Go ਟੂਲਚੇਨ ਸਰਵਰ ਲਈ, PostgreSQL ਕਲਾਇੰਟ ਟੂਲ ਲੋਕਲ ਸੈਟਅੱਪ ਲਈ, ਅਤੇ Flutter SDK ਮੋਬਾਈਲ ਲਈ ਹੋ ਸਕਦਾ ਹੈ।
ਨਿਰਭਰਤਾ ਇੰਸਟਾਲ predictable ਬਣਾਓ। ਲੌਕਫਾਇਲ (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) ਕਮਿੱਟ ਕੀਤੇ ਗਏ ਹਨ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਨਵੇਂ ਕੰਪਿਊਟਰ ਜਾਂ ਸਾਫ਼ ਕੰਟੇਨਰ 'ਤੇ ਤਾਜ਼ਾ ਇੰਸਟਾਲ ਕਰਕੇ ਸਾਬਤ ਕਰੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ।
CI ਕੀ ਕਰਦਾ ਹੈ, ਕਦਮ-ਦਰ-कਦਮ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਲੋੜ ਪੈਣ 'ਤੇ ਇਸਨੂੰ ਹੋਰ CI ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਨਕਲ ਕੀਤਾ ਜਾ ਸਕੇ:
- ਨਿਰਭਰਤਾਵਾਂ ਇੰਸਟਾਲ ਕਰੋ (ਲੌਕਫਾਇਲ ਦੇ ਨਾਲ)
- ਟੈਸਟ ਅਤੇ ਲਿੰਟ ਚੈਕ ਚਲਾਓ
- ਬਿਲਡ ਆਉਟਪੁੱਟ (web bundle, server binary, mobile build)
- ਆਰਟੀਫੈਕਟ ਤਿਆਰ ਕਰੋ (zip, Docker image, release bundle)
- ਲੌਗ ਅਤੇ ਬਿਲਡ ਮੈਟਾਡੇਟਾ ਸੰਭਾਲੋ (ਵਰਜਨ, ਕਮਿੱਟ, ਤਾਰੀਖ)
ਬਿਲਡ-ਟਾਈਮ ਕੰਫਿਗ ਨੂੰ ਰਨਟਾਈਮ ਕੰਫਿਗ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ। ਬਿਲਡ-ਟਾਈਮ ਕੰਫਿਗ ਉਹ ਹੈ ਜੋ ਕੰਪਾਈਲ ਹੋਣ ਸਮੇਂ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ (ਜਿਵੇਂ API base URL ਜੋ web bundle ਵਿੱਚ bake ਹੋ ਜਾਵੇ)। ਰਨਟਾਈਮ ਕੰਫਿਗ ਉਹ ਹੈ ਜੋ ਐਪ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਇੰਜੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਿਵੇਂ database URLs, API keys, feature flags)। ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਇੱਕ ਵੱਡੀ ਕਾਰਨ ਹੁੰਦੀ ਹੈ ਕਿ "CI 'ਤੇ ਚੰਗਾ ਚੱਲਦਾ ਹੈ" ਪਰ ਡਿਪਲੋਯ 'ਤੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ lokਲ ਤਸਦੀਕ ਨੁਸਖਾ ਦਿਓ। ਇਕ ਛੋਟਾ ਕਮਾਂਡ ਸੈੱਟ ਵੀ ਕਾਫ਼ੀ ਹੈ:
# 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 ਫਾਇਲਾਂ ਜਾਂ ਬਿਲਡ ਪ੍ਰੀਸੈਟਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਡਿਪਲੋਯਮੈਂਟ ਦੌਰਾਨ ਵਰਤੀ ਗਈਆਂ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਪਲੇਟਫਾਰਮ ਤੋਂ ਬਾਹਰ ਇੱਕੋ ਜਿਹੀ ਬਿਲਡ ਦੁਹਰਾਉ ਸਕੇ।
ਡਿਪਲੋਯਮੈਂਟ ਸਕ੍ਰਿਪਟ ਅਤੇ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ
Export-ready code from day one
Build an app by chat, then export the repo with build and deploy files included.
ਏਕ ਚੰਗੀ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ ਸਿਰਫ "ਇਹ ਰੇਪੋ ਹੈ" 'ਤੋਂ ਅੱਗੇ ਨਹੀਂ ਰੁਕਦੀ। ਇਹ ਇਹ ਵੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ ਕਿ ਕੋਡ ਤੋਂ ਰਨਿੰਗ ਸੇਵਾ ਤੱਕ ਐਪ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਕੌਣ ਬਟਨ ਦਬਾਂਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਇਸ ਗੱਲ ਨੂੰ ਲਿਖ ਕੇ ਕਿ ਅੱਜ ਡਿਪਲੋਯ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ: ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਨੁਆਲ (ਕੋਈ ਵਰਕਰ ਸਰਵਰ 'ਤੇ ਕਮਾਂਡ ਚਲਾਂਦਾ ਹੈ), CI-ਚਲਿਤ (pipeline ਬਣਾਉਂਦੀ ਅਤੇ ਡਿਪਲੋਯ ਕਰਦੀ), ਜਾਂ ਹੋਸਟਡ ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ। ਦਰਜ ਕਰੋ ਕਿ configs ਕਿੱਥੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਵਾਤਾਵਰਣ ਮੌਜੂਦ ਹਨ (dev, staging, production)।
ਰਿਲੀਜ਼ ਕਦਮਾਂ ਨੂੰ ਦੁਹਰਾਈਯੋਗ ਬਣਾਓ। ਜੇ ਪ੍ਰਕਿਰਿਆ 12 ਕਮਾਂਡ ਯਾਦ ਰੱਖਣ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਬਦਲ ਦਿਓ ਅਤੇ ਲੋੜੀਂਦੀਆਂ ਅਨੁਮਤੀਆਂ ਨੋਟ ਕਰੋ।
ਡਿਪਲੋਯਮੈਂਟ ਪੈਕੇਜ ਨਾਲ ਕੀ ਸ਼ਾਮਲ ਹੋਵੇ
ਕਲਾਇੰਟ ਨੂੰ ਦਿਨ ਪਹਿਲੇ 'ਤੇ ਡਿਪਲੋਯ ਕਰਨ ਲਈ ਕਾਫੀ ਸਮੱਗਰੀ ਦਿਓ:
- ਬਿਲਡ ਅਤੇ ਰਨ ਕਮਾਂਡ (ਅਤੇ Node, Go, Flutter ਆਦਿ ਦੇ ਠੀਕ ਵਰਜਨ)
- ਡਿਪਲੋਯ ਸਕ੍ਰਿਪਟ (shell scripts, Makefile targets, ਜਾਂ pipeline configs)
- ਲੋੜੀਂਦਾ ਐਕਸੈਸ: ਕਲਾਉਡ ਅਕਾਊਂਟ ਰੋਲ, container registry, DNS, ਡੇਟਾਬੇਸ ਐਡਮਿਨ
- Environment ਸੈਟਅੱਪ ਨੋਟਸ: ਕਿੱਥੇ env vars ਸੈਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਹਰ env ਵਿੱਚ ਕਿਵੇਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ
- ਰਿਲੀਜ਼ ਨਾਂਮੀ: ਟੈਗ/ਰਿਲੀਜ਼ ਅਤੇ ਇਹ ਕਿਵੇਂ ਪਛਾਣੀ ਜਾਵੇ ਕਿ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ
ਡਾਉਨਟਾਈਮ ਉਮੀਦਾਂ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ। ਜੇ "ਜੀਰੋ ਡਾਉਨਟਾਈਮ" ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਵਿਆਖਿਆ ਕਰੋ ਕਿ ਇਹ ਅਮਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਹੈ (blue-green, rolling deploy, migrations ਲਈ read-only ਵਿੰਡੋ)। ਜੇ ਡਾਉਨਟਾਈਮ ਕਬੂਲਯੋਗ ਹੈ, ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਵਿੰਡੋ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਸਟੈਟਿਕ ਐਸੈਟ ਅਤੇ ਕੈਸ਼ ਆਮ ਫੇਲ ਪੁਆਇੰਟ ਹਨ। ਨੋਟ ਕਰੋ ਕਿ ਐਸੈਟ ਕਿਵੇਂ ਬਣਦੇ ਅਤੇ ਸਰਵ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਕਦੋਂ caches ਬੱਸਟ ਕਰਨੇ ਹਨ, ਅਤੇ CDN ਸ਼ਾਮਲ ਹੈ ਕਿ ਨਹੀਂ।
ਅਜਿਹਾ ਰੋਲਬੈਕ ਜੋ ਤੁਸੀਂ ਅਮਲ ਕਰ ਸਕੋ
ਰੋਲਬੈਕ ਇੱਕ ਛੋਟੀ, ਟੈਸਟ ਕੀਤੀ ਰੈਸੀਪੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਕਿਸੇ ਟੈਗ ਜਾਂ ਰਿਲੀਜ਼ ID ਨਾਲ ਜੁੜੀ ਹੋਵੇ। ਉਦਾਹਰਨ: ਪਿਛਲਾ ਟੈਗ ਡਿਪਲੋਯ ਕਰੋ, ਜੇ ਲੋੜ ਹੋਵੇ ਤਾ ਪਿਛਲਾ ਡੇਟਾਬੇਸ ਸਨੈਪਸ਼ਾਟ ਰੀਸਟੋਰ ਕਰੋ, ਅਤੇ caches ਇਨਵੈਲੀਡੇਟ ਕਰੋ।
ਜੇ ਐਪ Koder.ai 'ਤੇ ਬਣੀ ਹੋਈ ਸੀ ਅਤੇ ਫਿਰ ਨਿਰਯਾਤ ਕੀਤੀ ਗਈ, ਤਾਂ ਆਖਰੀ ਪਤਾ-ਚੰਗਾ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਨਿਰਯਾਤ ਵਰਜਨ ਦਰਸਾਓ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਨੂੰ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਰਿਲੀਜ਼ ਨਾਲ ਮਿਲਾ ਸਕੇ।
ਕਦਮ-ਦਰ-ਕਦਮ: ਨਿਰਯਾਤ ਤੋਂ ਬਾਅਦ ਬਿਲਡ ਦੀ ਤਸਦੀਕ
ਤਸਦੀਕ ਉਹ ਲਹਿਰ ਹੈ ਜਿਸ 'ਚ ਤੁਸੀਂ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ ਕਿ ਹੈਂਡਆਫ਼ ਵਾਸਤੇ ਵਿੱਚ ਹੈ ਜਾਂ ਨਹੀਂ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਕੋਈ ਨਵਾਂ ਵਿਅਕਤੀ ਨਿਰਯਾਤ ਕੀਤਾ ਹੋਇਆ ਕੋਡ ਲੈ ਕੇ, ਉਸਨੂੰ ਸੈੱਟ ਕਰਕੇ, ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ, ਉਹੀ ਐਪ ਚਲਾ ਸਕੇ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਦਰਜ ਕਰੋ ਕਿ "ਸਹੀ" ਦਿਖਾਈ ਕਿਵੇਂ ਦਿੰਦਾ ਹੈ: ਚੱਲ ਰਹੀ ਐਪ ਦਾ ਵਰਜਨ, ਮੌਜੂਦਾ commit/tag (ਜੇ ਉਪਲਬਧ ਹੋਵੇ), ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ ਮੁੱਖ ਸਕ੍ਰੀਨ ਜਾਂ API ਜਿਵੇਂ ਆਉਟਪੁੱਟ ਤੁਲਨਾ ਲਈ। ਜੇ ਨਿਰਯਾਤ Koder.ai ਤੋਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਨਿਰਯਾਤ ਟਾਈਮਸਟੈਂਪ ਨੋਟ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕੋ ਕਿ ਤੁਸੀਂ ਆਖਰੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕੀਤੀ।
- ਨਿਰਯਾਤ ਪ੍ਰੋਡਕਸ਼ਨ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ: commit ਇਤਿਹਾਸ, ਰਿਲੀਜ਼ ਨੋਟ, ਜਾਂ ਬਿਲਡ ਮੈਟਾਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰੋ। ਕਿਸੇ ਵਿਜ਼ੂਅਲ ਵਰਜਨ ਸਤਰ ਜਾਂ ਸੁਭਾਉ (ਜਿਵੇਂ ਇੱਕ ਨਿਰਧਾਰਿਤ ਸੈਟਿੰਗ ਜਾਂ UI ਲੇਬਲ) ਦੀ ਤੁਲਨਾ ਕਰੋ।
- Environment variables ਅਤੇ secrets ਸੈਟ ਕਰੋ: ਲਕਸ਼ੀਤ ਵਾਤਾਵਰਣ ਕੰਫਿਗ ਬਣਾਓ (local ਅਤੇ staging)। ਦਿੱਤੀ ਇਨਵੈਂਟਰੀ ਵਰਤੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਰੇਪੋ ਵਿੱਚ ਕੁਝ ਹਾਰਡ-ਕੋਡ ਨਹੀਂ ਹੈ।
- ਨਿਰਭਰਤਾਵਾਂ ਇੰਸਟਾਲ ਅਤੇ ਟੈਸਟ ਚਲਾਓ: ਸਾਫ਼ ਇੰਸਟਾਲ (ਕੋਈ ਕੈਸ਼ਡ node_modules/vendor ਫੋਲਡਰ ਨਹੀਂ)। ਯੂਨਿਟ ਟੈਸਟ ਅਤੇ ਕੋਈ ਲਿੰਟ ਚੈਕ ਡਾਕਯੂਮੈਂਟੇਡ ਤਰੀਕੇ ਨਾਲ ਚਲਾਓ।
- ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਓ ਅਤੇ ਲੋਕਲ ਰੂਪ 'ਤੇ ਸਟਾਰਟ ਕਰੋ: ਡੇਟਾਬੇਸ ਉੱਠਾਓ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਕ੍ਰਮਵਾਰ ਲਗਾਓ, ਅਤੇ ਐਪ ਸਟਾਰਟ ਕਰੋ। ਪੱਕਾ ਕਰੋ ਕਿ ਐਪ ਮੁਢਲੀਆਂ ਡਾਟਾ ਨੂੰ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦਾ ਹੈ ਅਤੇ ਕੋਈ ਬਕਾਇਆ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨਹੀਂ ਹੈ।
- Staging 'ਤੇ ਡਿਪਲੋਯ ਕਰੋ, smoke test ਕਰੋ, ਫਿਰ promote ਕਰੋ: ਉਹੀ ਸਕ੍ਰਿਪਟ/ਪਾਈਪਲਾਈਨ ਵਰਤੋਂ ਜੋ ਤੁਸੀਂ production ਲਈ ਯੋਜਨਾ ਬਣਾਈ ਹੈ। ਸਿਰਫ਼ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਤੇ promote ਕਰੋ ਜੇ staging ਉਮੀਦਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ।
Smoke tests ਨੂੰ ਛੋਟਾ ਤੇ ਜੋਖਿਮ-ਨਿਭਰਿਤ ਰੱਖੋ:
- ਲੌਗ ਇਨ/ਆਉਟ (ਜਾਂ ਇੱਕ ਟੈਸਟ ਯੂਜ਼ਰ ਬਣਾਓ)
- ਇੱਕ ਮੁੱਖ ਵਰਕਫਲੋ ਏਂਡ-ਟੂ-ਏਂਡ (ਬਣਾਓ-ਸੰਪਾਦਨ-ਸੇਵ)
- ਜੇ ਲਾਗੂ ਹੋਵੇ ਤਾਂ ਇੱਕ ਈਮੇਲ/webhook/ਭੁਗਤਾਨ ਕਾਲਬੈਕ
- ਸਧਾਰਨ ਤ੍ਰੁੱਟੀ ਹੈਂਡਲਿੰਗ (ਖਰਾਬ ਇਨਪੁਟ, ਮਿssਿੰਗ ਰਿਕਾਰਡ)
- ਲੌਗਾਂ 'ਚ ਕੋਈ ਮੁੜ-ਆ ਰਹੀ ਕਰੈਸ਼ ਜਾਂ secrets-ਸਬੰਧੀ ਗਲਤੀਆਂ ਨਾ ਹੋਣ
ਜੇ ਕੁਝ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਹੀ ਕਮਾਂਡ, ਐਰਰ ਆਉਟਪੁੱਟ, ਅਤੇ ਵਰਤੇ ਗਏ env vars ਦਰਜ ਕਰੋ। ਇਹ ਵਿਸਥਾਰ ਮਾਲਕੀ ਬਦਲਾਅ ਵੇਲੇ ਘੰਟਿਆਂ ਦੀ ਬਚਤ ਕਰਦਾ ਹੈ।
ਆਮ ਹੈਂਡਆਫ਼ ਗਲਤੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਾਅ
Build with a repeatable stack
Generate a React, Go, and PostgreSQL stack you can run locally and deploy confidently.
ਹੈਂਡਆਫ਼ ਨੂੰ ਫਾਇਰ ਡ੍ਰਿਲ 'ਚ ਬਦਲਣ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਏਹੋ ਹੈ ਕਿ "ਕੋਡ ਕਾਫ਼ੀ ਹੈ" ਇਹ ਮਾਨ ਲਿਆ ਜਾਵੇ। ਇੱਕ ਚੰਗੀ ਚੈਕਲਿਸਟ ਉਹਨਾਂ ਛੋਟੀਆਂ, ਬੋਰਿੰਗ ਵਿਸਥਾਰਾਂ 'ਤੇ ਧਿਆਨ ਦੇਂਦੀ ਹੈ ਜੋ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕਲਾਇੰਟ ਤੁਹਾਡੇ ਬਿਨਾਂ ਐਪ ਨੂੰ ਚਲਾ ਅਤੇ ਬਦਲ ਸਕੇ ਜਾਂ ਨਹੀਂ।
ਉਹ ਗਲਤੀਆਂ ਜੋ ਜ਼ਿਆਦातर ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ
ਅਕਸਰ ਸਮੱਸਿਆਵਾਂ ਕੁਝ ਹੀ ਨਕਸ਼ਿਆਂ ਵਿੱਚ ਪੈਂਦੀਆਂ ਹਨ:
- Secrets ਰੋਟੇਟ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਐਜੰਸੀ ਪਾਸਵਰਡ, API ਕੁੰਜੀਆਂ, ਜਾਂ ਕਲਾਉਡ ਟੋਕਨ ਹੈਂਡਓਵਰ ਤੋਂ ਬਾਅਦ ਵੀ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ।
- Environment variables ਅਧੂਰੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੁਝ ਮੁੱਲ ਸਿਰਫ CI ਸੈਟਿੰਗਾਂ ਜਾਂ ਹੋਸਟਿੰਗ ਡੈਸ਼ਬੋਰਡ 'ਚ ਰਹਿੰਦੇ ਹਨ, ਰੇਪੋ ਵਿੱਚ ਨਹੀਂ।
- ਇੱਕ-ਵਾਰ ਦੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਬਦਲਾਵਾਂ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਇੱਕ ਤੇਜ਼ ਫਿਕਸ, ਮਨੁਆਲ DB ਸੰਪਾਦਨ, ਜਾਂ ਸਰਵਰ 'ਤੇ ਸਿੱਧਾ ਸੈਟ ਕੀਤਾ ਹੋਇਆ ਕੰਫਿਗ ਟੌਗਲ।
- ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲੋਕਲ 'ਤੇ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਅਨੁਮਤੀਆਂ, ਇਕਸਟੈਨਸ਼ਨ, ਜਾਂ ਸਕੀਮਾ ਮਾਲਕੀ ਘੱਟ ਹੈ।
- ਕੋਈ ਰੋਲਬੈਕ ਯੋਜਨਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਕੋਈ ਟੈਗਡ ਰਿਲੀਜ਼ (ਜਾਂ ਰਿਲੀਜ਼ ਨੋਟ) ਨਹੀਂ ਹੈ ਜਿਸ ਤੇ ਪਹਿਲੀ ਡਿਪਲੋਯ ਗਲਤ ਹੋਣ 'ਤੇ ਵਾਪਸ ਜਾਇਆ ਜਾ ਸਕੇ।
ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਾਅ (ਹਫਤੇ ਨਹੀਂ ਲਗਾਉਣਾ)
ਰੋਟੇਸ਼ਨ ਅਤੇ ਐਕਸੈਸ ਕਲੀਨਅੱਪ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਟਾਸਕ ਬਣਾਓ, ਨਾ ਕਿ "ਜਦੋਂ ਸਮਾਂ ਮਿਲੇ" ਆਈਟਮ। ਇੱਕ ਮਿਤੀ ਨਿਰਧਾਰਿਤ ਕਰੋ ਜਦੋਂ ਏਜੰਸੀ ਅਕਾਊਂਟ ਹਟਾ ਦਿੱਤੇ ਜਾਣਗੇ, ਸੇਵਾ ਕੁੰਜੀਆਂ ਦੁਬਾਰਾ ਬਣਾਈਆਂ ਜਾਣਗੀਆਂ, ਅਤੇ ਕਲਾਇੰਟ ਪੁਸ਼ਟੀ ਕਰੇਗਾ ਕਿ ਉਹ ਸਿਰਫ ਆਪਣੇ ਹੀ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਨਾਲ ਡਿਪਲੋਯ ਕਰ ਸਕਦਾ ਹੈ।
Env vars ਲਈ, ਰੇਪੋ, CI ਸਿਸਟਮ, ਅਤੇ ਹੋਸਟਿੰਗ UI—ਇਨ੍ਹਾਂ ਤਿੰਨ ਥਾਵਾਂ ਤੋਂ ਇੱਕ ਸਾਦਾ ਇਨਵੈਂਟਰੀ ਬਣਾਓ। ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਤਾਜ਼ਾ ਮਸ਼ੀਨ ਜਾਂ ਕੰਟੇਨਰ 'ਤੇ ਇੱਕ ਸਾਫ਼ ਬਿਲਡ ਚਲਾ ਕੇ ਵੈਰੀਫਾਈ ਕਰੋ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ, ਉਨ੍ਹਾਂ ਨੂੰ ਉਸੇ ਡੇਟਾਬੇਸ ਰੋਲ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲੋਯ ਵਰਤਵੇਗਾ। ਜੇ ਪ੍ਰੋਡਕਸ਼ਨ elevated ਕਦਮ ਲੋੜਦੇ ਹਨ (ਜਿਵੇਂ ਇਕਸਟੈਂਸ਼ਨ ਐਨੀਬਲ ਕਰਨਾ), ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ ਅਤੇ ਮਾਲਕੀ ਸਪਸ਼ਟ ਕਰੋ।
ਇਕ ਵਾਸਤਵਿਕ ਉਦਾਹਰਨ: Koder.ai ਤੋਂ ਨਿਰਯਾਤ ਕਰਨ ਨੇ ਬਾਅਦ, ਕਲਾਇੰਟ ਸਫਲਤਾ ਨਾਲ ਡਿਪਲੋਯ ਕਰਦਾ ਹੈ ਪਰ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਕ ਕਤਾਰ URL ਸਿਰਫ ਹੋਸਟਿੰਗ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਸੈਟ ਸੀ। ਇੱਕ ਸਧਾਰਨ env var ਆਡੀਟ ਇਸਨੂੰ ਰੋਕ ਸਕਦਾ। ਇਸਨੂੰ ਇੱਕ ਟੈਗਡ ਰਿਲੀਜ਼ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਰੋਲਬੈਕ ਨਾਲ ਜੋੜੋ (ਉਦਾਹਰਨ: “redeploy tag v1.8.2 ਅਤੇ ਆਖਰੀ ਸਨੈਪਸ਼ਾਟ ਰੀਸਟੋਰ ਕਰੋ”) ਅਤੇ ਟੀਮ downtime ਤੋਂ ਬਚੇਗੀ।
ਅਖੀਰਲਾ ਚੈਕਲਿਸਟ, ਇੱਕ ਸਾਦਾ ਉਦਾਹਰਨ, ਅਤੇ ਅਗਲੇ ਕਦਮ
ਜੇ ਤੁਸੀਂ ਇਸ ਸੋਰਸ ਕੋਡ ਹੈਂਡਆਫ਼ ਚੈਕਲਿਸਟ 'ਚੋਂ ਸਿਰਫ ਇਕ ਪੰਨਾ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਰੱਖੋ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਸਾਫ਼ ਕਲੋਨ ਨਵੀਂ ਮਸ਼ੀਨ 'ਤੇ ਚਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਵੀਆਂ ਕੁੰਜੀਆਂ ਨਾਲ, ਅਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਜੋ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕੇ।
ਤੁਰੰਤ ਜਾਂਚ (ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਤਾਜ਼ਾ ਕਲੋਨ ਤੋਂ ਕਰੋ)
ਇਹ ਜਾਂਚਾਂ ਇੱਕ ਲੈਪਟੌਪ 'ਤੇ ਚਲਾਓ ਜੋ ਕਦੇ ਵੀ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਨਹੀਂ ਦੇਖਿਆ (ਜਾਂ ਇੱਕ ਕੋਲੀਨ ਕੰਟੇਨਰ/VM)। ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਮਿਸਿੰਗ ਫਾਇਲਾਂ, ਛੁਪੇ ਹੋਏ ਅਨੁਮਾਨ, ਅਤੇ ਪੁਰਾਣੀਆਂ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਫੜਨ ਦਾ।
- ਸਿਰੇ ਤੋਂ ਬਿਲਡ ਕਰੋ: deps ਇੰਸਟਾਲ ਕਰੋ, ਟੈਸਟ ਚਲਾਓ (ਜੇ ਕੋਈ ਹੋਣ), ਅਤੇ ਬਿਨ੍ਹਾਂ ਮਨੁਆਲ ਸੋਧਾਂ ਦੇ ਰਿਲੀਜ਼ ਬਿਲਡ ਤਿਆਰ ਕਰੋ।
- ਕੰਫਿਗ ਕੰਮ ਕਰਦੀ ਹੈ: ਦਰਜ ਕੀਤੀਆਂ environment variables ਸੈਟ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪ ਤਾਜ਼ਾ ਕੰਫਿਗ ਫਾਇਲ ਜਾਂ env ਸੈਟਅੱਪ ਨਾਲ ਬੂਟ ਹੁੰਦੀ ਹੈ।
- Secrets ਰੋਟੇਟ ਕੀਤੇ ਗਏ ਹਨ: ਨਵੇਂ ਕੀਜ਼ ਨਾਲ ਐਪ ਚਲਦੀ ਹੈ, ਫਿਰ ਪੁਰਾਣੀਆਂ ਕੁੰਜੀਆਂ ਰੱਦ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੁਝ ਟੁੱਟਦਾ ਨਹੀਂ।
- ਮਾਈਗ੍ਰੇਸ਼ਨ ਸੁਚੱਜੇ ਤਰੀਕੇ ਨਾਲ ਚਲਦੇ ਹਨ: ਖਾਲੀ ਡੇਟਾਬੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਓ, ਫਿਰ ਐਪ ਸਟਾਰਟ ਕਰੋ ਅਤੇ ਇੱਕ ਬੁਨਿਆਦੀ ਫਲੋ ਹਿੱਟ ਕਰੋ।
- ਡਿਪਲੋਯਮੈਂਟ ਰਾਹ ਅਸਲ ਹੈ: ਡਿਪਲੋਯ ਸਕ੍ਰਿਪਟ ਜਾਂ CI ਵਰਕਫਲੋ ਇੱਕ ਵਾਰੀ ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਉਹੀ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਸਾਦਾ ਹੈਂਡਆਫ਼ ਉਦਾਹਰਨ
ਇਕ ਐਜੰਸੀ ਇੱਕ React frontend, ਇੱਕ Go API, ਅਤੇ ਇੱਕ PostgreSQL ਡੇਟਾਬੇਸ ਹੈਂਡਓਵਰ ਕਰਦੀ ਹੈ। ਕਲਾਇੰਟ ਟੀਮ ਰੇਪੋ ਕਲੋਨ ਕਰਦੀ ਹੈ, ਦਿੱਤੀ .env.example ਨੂੰ ਅਸਲ env vars ਵਿੱਚ ਕਾਪੀ ਕਰਦੀ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ, ਈਮੇਲ ਪ੍ਰੋਵਾਈਡਰ, ਅਤੇ ਕਿਸੇ ਵੀ ਤੀਜੇ-ਪੱਖ API ਲਈ ਨਵੀਆਂ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਬਣਾਉਂਦੀ ਹੈ। ਉਹ go test (ਜਾਂ ਸਹਿਮਤ ਟੈਸਟ ਕਮਾਂਡ) ਚਲਾਉਂਦੇ ਹਨ, React ਐਪ ਬਿਲਡ ਕਰਦੇ ਹਨ, ਇੱਕ ਤਾਜ਼ਾ Postgres ਇੰਸਟੈਂਸ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਗਾਉਂਦੇ ਹਨ, ਅਤੇ ਦੋਨੋ ਸਰਵਿਸਜ਼ ਸਟਾਰਟ ਕਰਦੇ ਹਨ। ਆਖਿਰਕਾਰ, ਉਹ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਗਿਆ ਸਕ੍ਰਿਪਟ ਵਰਤ ਕੇ ਡਿਪਲੋਯ ਕਰਦੇ ਹਨ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ ਉਹੀ ਕਮਿੱਟ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਬਿਲਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਅਗਲੇ ਕਦਮ
ਹੈਂਡਆਫ਼ ਨੂੰ ਛੋਟਾ ਅਤੇ ਇੱਕ ਮਾਲਕ ਰੱਖੋ। 30 ਤੋਂ 60 ਮਿੰਟ ਦੀ ਇੱਕ walkthrough ਅਕਸਰ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਬਜਾਏ ਵਧੀਆ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ।
- ਇੱਕ walkthrough ਨਿਰਧਾਰਿਤ ਕਰੋ ਅਤੇ ਫੈਸਲੇ ਦਰਜ ਕਰੋ (ਕੌਣ ਡਿਪਲੋਯ, secrets, ਅਤੇ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਦਾ ਮਾਲਕ ਹੈ)
- ਪ੍ਰੋਡਕਸ਼ਨ ਐਕਸੈਸ ਲਈ ਇੱਕ ਮਾਲਕ ਅਤੇ ਇੱਕ ਬੈਕਅੱਪ ਮਾਲਕ ਨਿਰਧਾਰਿਤ ਕਰੋ
- ਆਖਰੀ "acceptance build" commit hash ਤੇ ਸਹਿਮਤ ਹੋਕੇ ਉਸ ਨੂੰ ਟੈਗ ਕਰੋ
- ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਇਆ, ਤਾਂ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ, ਫਿਰ ਪਹਿਲੀ ਕਲਾਇੰਟ-ਚਲਾਈ ਡਿਪਲੋਯਮੈਂਟ ਦੌਰਾਨ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਤੋਂ ਤਾਂ ਜੋ ਜੋਖਮ ਘਟ ਸਕੇ