02 ਦਸੰ 2025·8 ਮਿੰਟ
ਪ੍ਰੀਵਿਊ ਵਾਤਾਵਰਣਾਂ ਬਨਾਮ ਪ੍ਰੋਡਕਸ਼ਨ: ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼ ਵਰਕਫਲੋ
ਪ੍ਰੀਵਿਊ ਵਾਤਾਵਰਣ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ: ਹਰ ਫੀਚਰ ਲਈ ਪ੍ਰੀਵਿਊ URL ਬਣਾਉਣ, ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਉਤਾਰਨ ਅਤੇ ਮੁਸੀਬਤ ਆਉਣ 'ਤੇ ਤੇਜ਼ ਰੋਲਬੈਕ ਲਈ ਸਧਾਰਨ ਵਰਕਫਲੋ।
ਪ੍ਰੀਵਿਊ ਵਾਤਾਵਰਣ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ: ਹਰ ਫੀਚਰ ਲਈ ਪ੍ਰੀਵਿਊ URL ਬਣਾਉਣ, ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਉਤਾਰਨ ਅਤੇ ਮੁਸੀਬਤ ਆਉਣ 'ਤੇ ਤੇਜ਼ ਰੋਲਬੈਕ ਲਈ ਸਧਾਰਨ ਵਰਕਫਲੋ।
ਪ੍ਰੀਵਿਊ ਵਾਤਾਵਰਣ ਤੁਹਾਡੀ ਐਪ ਦੀ ਇੱਕ ਅਸਥਾਈ ਨਕਲ ਹੁੰਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਹੋਰ ਲੋਕਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਅਲੱਗ ਹੁੰਦੀ ਹੈ, ਐਸੇ ਕੋਈ ਵੀ ਬਦਲਾਅ ਜੋ ਤੁਸੀਂ ਇੱਥੇ ਕਰਦੇ ਹੋ ਉਹ ਲਾਈਵ ਐਪ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ। ਇਸਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਭਿਆਸ ਮੰਚ ਸਮਝੋ ਜਿੱਥੇ ਨਵੀਂ ਫੀਚਰ ਨੂੰ ਸਭ ਨੂੰ ਮਿਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖਿਆ ਅਤੇ ਕਲਿੱਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਆਮ ਸੈਟਅਪ ਹੁੰਦਾ ਹੈ: ਹਰ ਫੀਚਰ ਜਾਂ ਬਦਲਾਅ ਲਈ ਇੱਕ ਪ੍ਰੀਵਿਊ URL। ਇਸ ਨਾਲ ਫੀਡਬੈਕ ਸਧਾਰਨ ਰਹਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਲਿੰਕ ਸਾਂਝਾ ਕਰਦੇ ਹੋ ਅਤੇ ਹਰ ਕੋਈ ਠੀਕ ਉਹੀ ਸੰਸਕਰਨ ਦੇਖ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
ਪ੍ਰੋਡਕਸ਼ਨ ਅਸਲ ਐਪ ਹੈ। ਇਹ ਉਹ ਹੈ ਜੋ ਅਸਲੀ ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ, ਅਸਲੀ ਅਕਾਂਟ, ਅਸਲੀ ਭੁਗਤਾਨ, ਅਸਲੀ ਡਾਟਾ ਅਤੇ ਉਮੀਦਾਂ ਨਾਲ। ਜੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੁਝ ਟੁਟਦਾ ਹੈ ਤਾਂ ਇਹ ਸਿਰਫ਼ ਪਰੇਸ਼ਾਨੀ ਨਹੀਂ—ਇਸ ਨਾਲ ਵਿਕਰੀ ਜਾਂ ਸਪੋਰਟ ਟਿਕਟ ਜਾਂ ਡਾਟਾ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਨਾਂ ਟੈਕਨੀਕਲ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਪ੍ਰੀवਿਊ ਸਿੱਖਣ ਲਈ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਪਰੋਸੇਸ ਕਰਨ ਲਈ।
ਚੈਟ-ਬਿਲਟ ਐਪਾਂ ਨੂੰ ਵੀ ਇਹੀ ਸੁਰੱਖਿਆ ਵਾਲੇ ਕਦਮ ਚਾਹੀਦੇ ਹਨ ਕਿਉਂਕਿ ਜੋਖਮ ਨਹੀਂ ਬਦਲਦੇ। ਭਾਵੇਂ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਚੈਟ ਕਰਕੇ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਫਿਰ ਵੀ ਕੋਡ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ ਜੋ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਚਲਦਾ ਅਤੇ ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਤਬਦੀਲੀ (ਜਿਵੇਂ ਇੱਕ ਫਾਰਮ ਫੀਲਡ ਜਾਂ ਡੇਟਾਬੇਸ ਕ੍ਵੈਰੀ) ਅਸਲ ਟ੍ਰੈਫਿਕ ਆਉਣ 'ਤੇ ਵੱਡੇ ਪ੍ਰਭਾਵ ਕਰ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰੀਵਿਊਜ਼ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਫੀਡਬੈਕ ਮਿਲਦਾ ਹੈ ਬਿਨਾਂ ਲਾਈਵ ਐਪ ਤੋੜੇ। ਤੁਸੀਂ ਸੰਦਰਭ ਵਿੱਚ ਇੱਕ ਫੀਚਰ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਆਮ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਫੜ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਹੀ ਬਦਲਾਅ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਪ੍ਰੋਮੋਟ ਕਰੋ ਜਦੋਂ ਉਹ ਠੀਕ ਦਿਸਦਾ ਹੈ।
ਚੈਟ ਟੂਲ ਵਿੱਚ ਫੀਚਰ ਤਿਆਰ ਕਰਨਾ ਲਗਭਗ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਜੋਖਮ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਜਦੋਂ ਉਹ ਤਬਦੀਲੀ ਅਸਲ ਇੰਫ੍ਰਾਸਟਰਕਚਰ 'ਤੇ ਚਲਣੀ ਹੁੰਦੀ ਹੈ, ਅਸਲ ਸਰਵਿਸز ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ ਅਤੇ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਰਵ ਕਰਦੀ ਹੈ। ਇਸੀ ਲਈ ਪ੍ਰੀਵਿਊ ਵਿਰੁੱਧ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਰਫ਼ ਹੋਸਟਿੰਗ ਚੋਣ ਨਹੀਂ—ਇਹ ਤਰੀਕਾ ਹੈ ਜੋ ਅਣਚਾਹੇ ਬਰਕਤਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਅਧਿਕਤਮ ਰਿਲੀਜ਼ ਸਮੱਸਿਆਵਾਂ “ਖਰਾਬ ਕੋਡ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਉਹ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਜੋ ਟੈਸਟ ਕੀਤਾ ਉਹ ਉਲਟ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਯੂਜ਼ਰ ਡੀਪਲੋਇਟ ਤੋਂ ਬਾਅਦ ਮਿਲਦਾ ਹੈ। ਇੱਕ ਪੇਜ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਠੀਕ ਦਿਸ ਸਕਦੀ ਹੈ ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਟੁੱਟ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਸੈਟਿੰਗਜ਼, ਵੱਖ-ਵੱਖ ਡਾਟਾ, ਅਤੇ ਕੜੀ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇਹੀ ਸਮੱਸਿਆਵਾਂ ਬਾਰ-ਬਾਰ ਆਉਂਦੀਆਂ ਹਨ:
ਪ੍ਰੀਵਿਊਜ਼ ਓਥੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਵਿਵਹਾਰ ਅਤੇ ਯੂਜ਼ਰ ਫਲੋ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਗਾਹਕਾਂ ਨੂੰ ਜੋਖਮ ਵਿੱਚ ਪਾਏ। ਇਹ ਲੇਆਉਟ, ਮੁੱਢਲਾ ਨੈਵੀਗੇਸ਼ਨ, ਫਾਰਮ ਵੈਲੀਡੇਸ਼ਨ ਅਤੇ ਟੈਸਟ ਡਾਟਾ ਨਾਲ ਫੀਚਰ ਦੇ end-to-end ਕੰਮ ਦੀ ਜਾਂਚ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹਨ।
ਕੁਝ ਗੱਲਾਂ ਪ੍ਰੀवਿਊਜ਼ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਾਬਤ ਕਰਨਾ ਵੱਧ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਜੇ ਤਕ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰੋਡਕਸ਼ਨ-ਵਾਂਗ ਸਟੇਜਿੰਗ ਸੈਟਅਪ ਨਾ ਹੋਵੇ: ਅਖ਼ੀਰਲਾ ਡੋਮੇਨ ਅਤੇ ਕੁਕੀ ਵਿਹੇਵਿਯਰ, ਲਾਈਵ ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਈਡਰ, ਅਸਲ ਈਮੇਲ ਭੇਜਣਾ, ਅਤੇ ਯਥਾਰਥ ਟ੍ਰੈਫਿਕ ਹੇਠ ਕੰਮ ਕਰਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ। ਇਹਨਾਂ ਦਾ ਨਿਰਭਰ ਪ੍ਰੋਡਕਸ਼ਨ ਕੰਫਿਗੁਰੇਸ਼ਨ ਅਤੇ ਅਸਲ ਇੰਟੇਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਹੈ।
ਉਦੇਸ਼ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀ ਰਿਲੀਜ਼ ਵਰਕਫਲੋ ਹੈ। ਉਦਾਹਰਨ ਲਈ Koder.ai ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਲਈ ਪ੍ਰੀਵਿਊ URL ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ, ਇੱਕ ਸਾਥੀ ਨਾਲ ਸਮੀਖਿਆ ਕਰੋ, ਫਿਰ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਦੇ ਬਾਅਦ ਉਸੇ ਬਿਲਡ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਪ੍ਰੋਮੋਟ ਕਰੋ। ਅਤੇ ਜੇ ਕੁਝ ਛਲ ਕਰ ਗਿਆ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਰੋਲਬੈਕ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਖਰਾਬ ਰਿਲੀਜ਼ ਇੱਕ ਛੋਟਾ ਹਾਦਸਾ ਬਣੇ ਨਾ ਕਿ ਲੰਮਾ ਆਊਟੇਜ।
ਇੱਕ ਚੰਗੀ ਪ੍ਰੀਵਿਊ ਸੈਟਅਪ ਚਾਰ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦਿੰਦੀ ਹੈ: ਕੀ ਬਦਲਿਆ, ਕਿਸ ਥਾਂ ਤੇ ਮੈਂ ਇਸਨੂੰ ਵੇਖ ਸਕਦਾ ਹਾਂ, ਮੈਂ ਕਿਸ ਸੰਸਕਰਨ ਨੂੰ ਵੇਖ ਰਿਹਾ ਹਾਂ, ਅਤੇ ਕੌਣ ਇਹ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ।
URL (ਜਾਂ ਸਬਡੋਮੇਨ ਲੇਬਲ) ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਮੈਚ ਕਰੋ ਜਿਵੇਂ ਤੁਹਾਡੀ ਟੀਮ ਕੰਮ ਬਾਰੇ ਗੱਲ ਕਰਦੀ ਹੈ: ਇੱਕ ਫੀਚਰ ਨਾਂ ਜਾਂ ਟਿਕਟ ID। ਛੋਟਾ, ਸੂਚਿਤ ਅਤੇ ਚੈਟ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਰੱਖੋ।
prv-<ticket>-<short-feature> (ਉਦਾਹਰਨ: prv-482-checkout-tax)prv-482-checkout-tax-alex)main ਅਤੇ prod ਨੂੰ ਰਿਜ਼ਰਵਡ ਸ਼ਬਦ ਮੰਨੋਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਹਰ ਪ੍ਰੀਵਿਊ URL ਨਾਲ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਜੋੜਨਾ ਪ੍ਰੀਵਿਊ ਨੂੰ ਇਸਤਾਂਬਲ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਆਗਲੇ ਕੰਮ ਹੇਠ ਜੋ ਕੁਝ ਹੋਵੇ ਉਹ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰੇ।
ਇੱਕ ਪ੍ਰੀਵਿਊ ਨੂੰ ਇੱਕ ਹੀ ਬਿਲਡ ਅਤੇ ਕੰਫਿਗ ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ “ਜੋ ਵੀ ਤਾਜ਼ਾ ਹੈ।” ਆਮ ਤੌਰ 'ਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰੀਵਿਊ URL = ਇੱਕ ਸਨੈਪਸ਼ਾਟ (ਜਾਂ commit-ਮਤਲਬ ਵਰਜ਼ਨ)।
ਜਦੋਂ ਫੀਡਬੈਕ ਆਵੇ, ਪ੍ਰੀਵਿਊ ਨੂੰ ਇੱਕ ਦਿੱਖਣਯੋਗ ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਕਰੋ: ਨਵਾਂ ਸਨੈਪਸ਼ਾਟ ਬਣਾਓ ਅਤੇ ਪ੍ਰੀਵਿਊ ਨੂੰ ਉਸ 'ਤੇ ਸਵਿੱਚ ਕਰੋ (ਜਾਂ ਨਵਾਂ ਪ੍ਰੀਵਿਊ URL ਬਣਾਓ)। ਇੱਕ ਸਾਂਝੇ ਕੀਤੇ ਲਿੰਕ ਦੇ ਵਿਖਾਵ ਨੂੰ ਚੁੱਪਚਾਪ ਬਦਲਨ ਤੋਂ ਬਚੋ।
ਇੱਕ ਡਿਫੋਲਟ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਰੱਖੋ:
ਪ੍ਰੀਵਿਊ ਆਮ ਤੌਰ 'ਤੇ ਸਕਰੀਨਸ਼ਾਟ ਜਾਂ ਫਾਰਵਰਡ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਰਾਹੀਂ ਲੀਕ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ ਵਰਤੋਂ ਜਿਵੇਂ “ਟੀਮ-ਕੇਵਲ ਜਦ ਤੱਕ ਖਾਸ ਤੌਰ 'ਤੇ ਸਾਂਝਾ ਨਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ,” ਅਤੇ ਮੁੱਲ ਨਿਯੰਤਰਣ (ਲੋਗਿਨ ਲੋੜ, allowlist, ਜਾਂ ਸਾਂਝ ਪਾਸਵਰਡ) ਨਾਲ ਇਹ ਨੂੰ ਲਾਗੂ ਕਰੋ।
ਇਸਦੇ ਨਾਲ-ਨਾਲ ਇਹ ਤੈਅ ਕਰੋ ਕਿ ਪ੍ਰੀवਿਊ ਕਿੰਨੀ der ਤੱਕ ਰਹਿਣਗੇ (ਉਦਾਹਰਨ: merge ਤੋਂ ਬਾਅਦ ਮਿਟਾ ਦਿਓ) ਤਾਂ ਜੋ ਪੁਰਾਣੇ URLs ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਗੁੰਝਲ ਨਾ ਕਰਣ।
ਇਕ ਚੰਗੀ ਪ੍ਰੀਵਿਊ ਸੈਟਅਪ ਹਰ ਬਦਲਾਅ ਨੂੰ ਅਲੱਗ ਰੱਖਦੀ ਹੈ। ਇੱਕ ਫੀਚਰ ਨੂੰ ਇੱਕ URL ਮਿਲਦਾ ਹੈ ਤਾਂ ਜੋ ਰਿਵਿਊਅਰ ਕਦੇ ਇਹ ਅਨੁਮਾਨ ਨਾ ਕਰਨ ਕਿ ਉਹ ਕਿਹੜਾ ਸੰਸਕਰਨ ਦੇਖ ਰਹੇ ਹਨ।
ਆਪਣੇ ਸਭ ਤੋਂ ਸਥਿਰ ਬਿੰਦੂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਉਹ main ਬ੍ਰਾਂਚ ਜੇ ਇਹ ਸਾਫ਼ ਰਹਿੰਦੀ ਹੈ, ਜਾਂ ਆਖਰੀ ਪ੍ਰੋਡਕਸ਼ਨ ਰਿਲੀਜ਼ ਜੇ main ਸ਼ੋਰਭਰ ਹੈ। ਇਸ ਨਾਲ ਪ੍ਰੀਵਿਊ ਫੀਚਰ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਰਹਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਗੈਰ-ਸੰਬੰਧਤ ਤਬਦੀਲੀਆਂ 'ਤੇ।
ਫੀਚਰ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਵਰਕਸਪੇਸ ਬਣਾਓ (ਉਦਾਹਰਨ: “billing-copy-update” ਜਾਂ “new-onboarding-step”)। ਉਸ ਵਰਕਸਪੇਸ ਨੂੰ ਇੱਕ ਪ੍ਰੀਵਿਊ ਵਾਤਾਵਰਣ 'ਤੇ ਡਿਪਲੋਇ ਕਰੋ ਅਤੇ ਪ੍ਰੀवਿਊ URL ਨੂੰ ਉਸ ਫੀਚਰ ਦਾ ਘਰ ਸਮਝੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਚੈਟ-ਬਿਲਟ ਟੂਲ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਰਕਫਲੋ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: ਫੀਚਰ ਨੂੰ ਆਪਣੇ ਵਿਸ਼ੇਸ਼ ਸਥਾਨ ਵਿੱਚ ਬਣਾਓ, ਫਿਰ ਇੱਕ ਅਲੱਗ ਪ੍ਰੀਵਿਊ ਐਕਸਪੋਰਟ ਜਾਂ ਡਿਪਲੋਇ ਕਰੋ ਬਿਨਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਛੂਹੇ।
ਇੱਕ ਛੋਟੀ ਜਾਂਚ ਕਰੋ ਜੋ ਸਭ ਤੋਂ ਆਮ ਟੁੱਟਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਫੜ ਲਏ। ਇਹ ਛੋਟਾ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਰੱਖੋ:
ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਟੈਸਟ ਕੀਤਾ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਸਮਾਂ ਬਚਾਉਦਾ ਹੈ।
ਪ੍ਰੀवਿਊ URL ਭੇਜੋ ਇੱਕ ਛੋਟੀ ਨੋਟ ਦੇ ਨਾਲ: ਕੀ ਬਦਲਿਆ, ਪਹਿਲਾਂ ਕਿੱਥੇ ਕਲਿੱਕ ਕਰਨਾ ਹੈ, ਅਤੇ ਕੀ “ਮੁਕੰਮਲ” ਮੰਨਿਆ ਜਾਵੇਗਾ। ਖਾਸ ਫੀਡਬੈਕ ਮੰਗੋ (ਕਾਪੀ, ਲੇਆਉਟ, ਐਡਜ ਕੇਸ) ਨਾ ਕਿ ਸਿਰਫ਼ “ਠੀਕ ਲੱਗਦਾ?”
ਫੀਡਬੈਕ ਲਗਾਓ, ਰੀ-ਡਿਪਲੋਇ ਕਰੋ, ਅਤੇ ਰਾਊਂਡਾਂ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਇਹ ਨੋਟ ਰੱਖੋ। ਜਦੋਂ ਪ੍ਰੀਵਿਊ ਮਨਜ਼ੂਰ ਹੋ ਜਾਵੇ, ਤੁਹਾਡੇ ਕੋਲ ਟੈਸਟ ਅਤੇ ਤੈਅ ਕਰਨ ਦਾ ਸਪਸ਼ਟ ਟਰੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪ੍ਰੀਵਿਊ ਪੂਰੀ QA ਮਰਾਥਨ ਲਈ ਨਹੀਂ ਹੈ। ਇਹ ਓਥੇ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਉਹ ਗਲਤੀਆਂ ਫੜਦੇ ਹੋ ਜੋ ਆਮਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਪੱਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਐਪ ਨੂੰ ਅਸਲ ਯੂਜ਼ਰ ਵਾਂਗ ਨਹੀਂ ਦੇਖਿਆ।
ਮੁੱਢ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਮੁੱਖ ਪੇਜ ਡੈਸਕਟਾਪ ਅਤੇ ਮੋਬਾਈਲ ਚੌੜਾਈਆਂ 'ਤੇ ਖੋਲ੍ਹੋ, ਨੈਵੀਗੇਸ਼ਨ 'ਚ ਕਲਿੱਕ ਕਰੋ, ਅਤੇ ਯਕੀਨ ਕਰੋ ਕਿ ਤੁਸੀਂ ਖਾਲੀ ਸਕ੍ਰੀਨ ਤੇ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਫਿਰ ਇੱਕ ਖੁਸ਼-ਪਾਥ ਫਲੋ پورا ਕਰੋ, ਥੋੜ੍ਹੇ-ਭਾੜੇ ਗਾਹਕ ਵਾਂਗ।
ਅਕਸਰ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਘੱਟੋ-ਘੱਟ ਟੈਸਟ ਸੈੱਟ:
ਜੇ ਤੁਹਾਡੀ ਐਪ ਹੋਰ ਸਿਸਟਮਾਂ ਨਾਲ ਜੁੜਦੀ ਹੈ, ਤਾਂ ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਛੋਟੀ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਚੈੱਕ ਕਰੋ। ਇੱਕ ਟੈਸਟ ਈਮੇਲ ਭੇਜੋ, ਸੈਂਡਬਾਕਸ ਮੋਡ ਵਿੱਚ ਛੋਟਾ ਭੁਗਤਾਨ ਚਲਾਓ, ਇੱਕ webhook ਟੈਸਟ ਐਂਡਪੋਇੰਟ 'ਤੇ ਭੇਜੋ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਫਾਇਲ ਅਪਲੋਡ ਕਰਕੇ ਮੁੜ ਡਾਊਨਲੋਡ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਤੁਸੀਂ ਹਰ ਐਡਜ ਕੇਸ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਕੇਵਲ ਤਾਰ-ਤੰਤਰ ਦੀ ਸਹੀ ਜੋੜਾਈ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਰਹੇ ਹੋ।
ਪ੍ਰੀਵਿਊਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਾਸ਼ਾਜਨਕ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਵੀ ਹੁੰਦੇ ਹਨ: ਗੁੰਮ ਹੋਈਆਂ ਸੈਟਿੰਗਜ਼। Environment variables ਅਤੇ ਸਿਕਰੇਟਸ ਮੌਜੂਦ ਹਨ ਜਾਂ ਨਹੀਂ ਇਹ ਪੱਕਾ ਕਰੋ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਸਹੀ ਸਰਵਿਸਿਜ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ (ਅਕਸਰ ਸੈਂਡਬਾਕਸ)। ਇੱਕ ਆਮ ਫੰਸ ਹੈ ਕਿ ਇਕ ਪ੍ਰੀਵਿਊ ਅਚਾਨਕ ਪ੍ਰੋਡਕਸ਼ਨ ਕੀਜ਼ ਜਾਂ ਅਸਲ ਡਾਟਾ ਵਰਤ ਲੈਂਦਾ ਹੈ।
ਆਖ਼ਿਰ ਵਿੱਚ, ਇੱਕ ਹਲਕੀ ਕਾਰਗੁਜ਼ਾਰੀ ਚੈੱਕ ਕਰੋ। ਸਭ ਤੋਂ ਧੀਮੀ ਪੇਜ ਲੋਡ ਕਰੋ ਅਤੇ ਸਪੱਸਟ ਸਮੱਸਿਆਵਾਂ ਵੇਖੋ: ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ, ਲੰਮੇ ਲੋਡਿੰਗ ਸਪਿਨਰ, ਵਾਰ-ਵਾਰ API ਕਾਲ। ਜੇ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਇਹ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹੋਰ ਵੀ ਬੁਰਾ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਪ੍ਰੀवਿਊ ਚੈਕ ਇੱਕ ਆਦਤ ਵਾਂਗ ਬਣਾਓ: ਪ੍ਰੀਵਿਊ URL ਖੋਲ੍ਹੋ, ਚੈੱਕਲਿਸਟ ਚਲਾਓ, ਅਤੇ ਫਿਰ ਹੀ ਪ੍ਰੋਮੋਟ ਕਰੋ। ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਮਦਦਗਾਰ ਹਨ, ਪਰ ਸਮੱਸਿਆਆਂ ਨੂੰ ਪਹਿਲਾਂ ਫੜਨਾ ਬਾਅਦ ਵਿੱਚ ਉਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।
ਪ੍ਰੋਮੋਸ਼ਨ ਦਾ ਇੱਕ ਸਧਾਰਨ ਮਤਲਬ ਹੈ: ਉਹੀ ਸੰਸਕਰਨ ਜਿਹਨੂੰ ਤੁਸੀਂ ਪ੍ਰੀवਿਊ ਵਿੱਚ ਸਮੀਖਿਆ ਕੀਤਾ ਸੀ ਹੁਣ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚਲਾ ਦਿੱਤਾ ਜਾਵੇ। ਕੋਈ ਆਖ਼ਰੀ-ਮਿੰਟ ਸੋਧ ਨਾ, ਮਨਜ਼ੂਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੋਈ “ਕੁਝ ਝੱਟ-ਫੱਟ ٹھਿਕ” ਨਾ। ਪ੍ਰੀवਿਊਜ਼ ਉਥੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਆਤਮਵਿਸ਼ਵਾਸ ਹਾਸਲ ਕਰਦੇ ਹੋ; ਪ੍ਰੋਡਕਸ਼ਨ ਉਥੇ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਦੀ ਸੁਰੱਖਿਆ ਕਰਦੇ ਹੋ।
ਇੱਕ ਛੋਟੀ ਰਿਲੀਜ਼ ਗੇਟ ਇਸਨੂੰ ਨਿਰਸ (ਅੱਛਾ ਤਰੀਕੇ ਨਾਲ) ਰੱਖਦੀ ਹੈ। ਇਹ ਨੂੰ ਕਮੇਟੀ ਦੀ ਲੋੜ ਨਹੀਂ—ਇਹ ਨੂੰ ਉਹ ਛੋਟੀ ਜਾਂਚਾਂ ਦੀ ਲੜੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਅਨੁਸਰਣ ਕਰੋ, ਭਾਵੇਂ ਤੁਸੀਂ ਜਲਦੀ ਵਿੱਚ ਹੋ:
ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਵਧੇਰੇ ਸਾਵਧਾਨੀ ਮੰਗਦੇ ਹਨ। ਇੱਕ ਤਰੀਕਾ ਜੋ ਸੁਰੱਖਿਅਤ ਹੈ ਉਹ ਹੈ “ਫੈਲਾਓ, ਫਿਰ ਸੰਕੋਚ”। ਪਹਿਲਾਂ ਉਹ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ ਜੋ ਬੈਕਵਰਡ-ਕੰਪੈਟਿਬਲ ਹੋ (ਕਾਲਮ ਜੋੜੋ, ਨਵੀਂ ਟੇਬਲ ਬਣਾਓ, ਦੋਹਾਂ ਨੂੰ ਲਿਖੋ)। ਨਵੇਂ ਵਰਜ਼ਨ ਨੂੰ ਸਥਿਰ ਹੋਣ ਦੇ ਬਾਅਦ ਹੀ ਪੁਰਾਣੇ ਕਾਲਮ ਜਾਂ ਪੁਰਾਣੀ ਕੋਡ ਪਥਸ ਨੂੰ ਹਟਾਓ। ਇਸ ਨਾਲ ਖਤਰਾ ਘਟਦਾ ਹੈ ਕਿ ਰੋਲਬੈਕ ਫੇਲ ਹੋ ਜਾਏ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਹੁਣ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਟਾਇਮਿੰਗ ਵੀ ਸੁਰੱਖਿਆ ਦਾ ਹਿੱਸਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ:
Koder.ai 'ਤੇ, ਇਹ ਸੋਝੀ-ਸਮਝੀ ਤੌਰ 'ਤੇ ਇੱਕ ਸਮੀਖਿਆ ਕੀਤੀ ਪ੍ਰੀवਿਊ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪ੍ਰੋਮੋਟ ਕਰਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਫਿਰ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣਾ ਜੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਮੋਕ ਟੈਸਟ ਕੋਈ ਛੁੱਟ ਪਈ ਐਡਜ ਕੇਸ ਪਕੜ ਲੈਂਦਾ ਹੈ।
ਅਧਿਕਤਮ ਰਿਲੀਜ਼ ਸਮੱਸਿਆਵਾਂ “ਨਵੇਂ ਬੱਗ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਪ੍ਰੀवਿਊ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹੋਰ-ਕੁਝ ਨਾ ਹੋਣ ਜਾਂ ਕਦੇ-ਕਦੇ ਸੁਰੱਖਿਆ ਜਾਲ ਨਾ ਹੋਣ ਨਾਲ ਹੁੰਦੀਆਂ ਹਨ।
ਕੁਝ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਗਲਤੀਆਂ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਚੈਟ-ਅਧਾਰਿਤ ਟੂਲ ਜਿਵੇਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੀवਿਊਜ਼ ਨੂੰ ਨਸ਼ਪਣਯੋਗ ਸਮਝੋ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਨਿਯੰਤਰਿਤ। ਉਦੇਸ਼ ਸਧਾਰਨ ਹੈ: ਹਰ ਪ੍ਰੋਮੋਸ਼ਨ ਦੁਹਰਾਵਣਯੋਗ ਹੋਵੇ, ਅਤੇ ਹਰ ਰੋਲਬੈਕ ਬੇਰੁਚੀ।
ਇੱਕ ਰੋਲਬੈਕ ਸਿਰਫ਼ “ਪੁਰਾਣਾ ਕੋਡ ਵਾਪਸ ਰੱਖਣਾ” ਨਹੀਂ ਹੈ। ਇੱਕ ਚੰਗਾ ਰੋਲਬੈਕ ਉਹ ਮੁੜ-ਹਾਲਤ ਬਹਾਲ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਯੂਜ਼ਰ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਐਪ ਵਰਜ਼ਨ, ਜੋ ਕੰਫਿਗ ਉਸ ਨੇ ਚੱਲ ਰਹੀ ਸੀ, ਅਤੇ ਡੇਟਾਬੇਸ ਸਥਿਤੀ ਜੋ ਉਸ ਵਰਜ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰੋ ਪਰ ਨਵੀਂ ਕੰਫਿਗ (ਜਿਵੇਂ API key, feature flag, ਜਾਂ background job schedule) ਜਾਰੀ ਰੱਖੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਆਊਟੇਜ ਨੂੰ ਵੱਖਰੇ ਨਾਮ ਨਾਲ ਫਿਰ ਵੇਖ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਕੋਡ ਰੋਲ ਬੈਕ ਕਰੋ ਪਰ ਡੇਟਾਬੇਸ ਦੀ ਸ਼ਕਲ ਪਹਿਲਾਂ ਹੀ ਬਦਲ ਚੁੱਕੀ ਹੋਵੇ, ਤਾ ਪੁਰਾਣਾ ਐਪ crash ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਗਲਤ ਡਾਟਾ ਦਿਖਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਮਦਦਗਾਰ ਹੈ: ਹਰ ਪ੍ਰੋਡਕਸ਼ਨ ਰਿਲੀਜ਼ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਇੱਕ ਜਾਣਿਆ-ਚੰਗਾ ਸਨੈਪਸ਼ਾਟ ਲਓ। ਉਹ ਸਨੈਪਸ਼ਾਟ ਤੁਹਾਡੀ ਸੁਰੱਖਿਆ ਰੇਖਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਇੱਕ-ਕਲਿੱਕ ਰੋਲਬੈਕ (Koder.ai ਇਸਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ) ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਇਸ ਕਦਮ ਨੂੰ ਗੈਰ-ਬਹਿਬੈਂਦੇ ਬਣਾਓ, ਭਾਵੇਂ ਇਹ “ਛੋਟੀ” ਬਦਲਾਅ ਹੋਵੇ।
ਜਦੋਂ ਕੁਝ ਗਲਤ ਜਾਵੇ, ਤੇਜ਼ੀ ਨਾਲ ਫੈਸਲਾ ਕਰੋ: ਰੋਲਬੈਕ ਕਰੋ ਜਾਂ ਅੱਗੇ ਹੌਟਫਿਕਸ ਕਰੋ।
ਉਦੇਸ਼ ਐਸੀ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਜਾਣਾ ਹੈ ਜਿੱਥੇ ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਚੱਲ ਰਿਹਾ ਸੀ:
ਇਸਨੂੰ ਇਕ ਘਟਨਾ ਮੰਨੋ, ਸਾਰੇ ਨਵੇਂ ਤਬਦੀਲੀਆਂ ਰੋਕ ਦਿਓ, ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਨਿਯੁਕਤ ਕਰੋ ਜੋ ਰਿਕਵਰੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ। ਫਿਰ ਮੁੱਖ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰੋ: ਮੁੱਖ ਪੇਜ ਲੋਡ ਹੁੰਦੇ ਹਨ, ਸਾਇਨ-ਇਨ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਆਵਸ਼ਯਕ ਕਾਰਵਾਈਆਂ ਸਫਲ ਹਨ। ਜਦੋਂ ਸਥਿਰ ਹੋ ਜਾਏ, ਲਿਖੋ ਕਿ ਰੋਲਬੈਕ ਦੀ ਸ਼ੁਰੂਆਤ ਕੀ ਸੀ ਅਤੇ ਅਗਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਕੀ ਬਦਲੋ ਗੇ।
ਰਿਲੀਜ਼ ਉਹ ਸਮੇਂ ਖਤਰਨਾਕ ਨਹੀਂ ਲੱਗਦੀ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਉਹੀ ਛੋਟੀ ਜਾਂਚਾਂ ਦੀ ਸਥਿਰ ਸੂਚੀ ਹੋਵੇ। ਇਹਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਕਰੋ, ਪਰ ਇੰਨਾ ਖਾਸ ਰੱਖੋ ਕਿ ਇਹ ਆਮ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲਏ।
ਇਹ ਵਰਤੋ ਜਦੋਂ ਇੱਕ ਫੀਚਰ ਤਿਆਰ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰੀवਿਊ URL ਹੋ:
ਪ੍ਰੋਡਕਸ਼ਨ ਲਾਈਵ ਹੋਣ ਦੇ ਪਹਿਲੇ ਮਿੰਟਾਂ ਵਿੱਚ ਇਹ ਕਰੋ, ਜਦੋਂ ਬਦਲਾਅ ਹੋਰ ਵਿਚਾਰਸ਼ੀਲ ਹੈ:
ਜੇ ਤੁਸੀਂ ਇਹ ਪ੍ਰਿੰਟ ਕਰ ਕੇ ਰਖੋ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੇ ਰਿਲੀਜ਼ ਬਟਨ ਦੇ ਕੋਲ ਰੱਖੋ। ਸਭ ਤੋਂ ਵਧੀਆ ਚੈੱਕਲਿਸਟ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਫਾਲੋ ਕਰੋ।
ਇੱਕ ਛੋਟੀ ਟੀਮ ਨਵਾਂ ਚੈਕਆਊਟ ਕਦਮ ਜੋੜਦੀ ਹੈ (ਜਿਵੇਂ “ਕੰਪਨੀ ਨਾਂ ਅਤੇ VAT”) ਜੋ ਚੈਟ ਰਾਹੀਂ ਬਣਾਇਆ ਗਿਆ। Sales ਉਨ੍ਹਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਸਲੀ ਗਾਹਕ ਕਾਲਾਂ 'ਤੇ ਇਸਨੂੰ ਕੋਸ਼ਿਸ਼ ਕਰਨ, ਪਰ ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਪ੍ਰੀवਿਊ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵੱਖ-ਵੱਖ ਸਪਸ਼ਟ ਰਹਿਣ।
ਉਹ ਫੀਚਰ ਬ੍ਰਾਂਚ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਪ੍ਰੀवਿਊ ਬਿਲਡ ਬਣਾਉਂਦੇ ਹਨ ਆਪਣੀ ਖਾਸ URL ਨਾਲ, ਉਦਾਹਰਨ checkout-vat.preview। ਪ੍ਰੀवਿਊ ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਇੱਕੋ ਡੇਟਾਬੇਸ ਸ਼ੇਪ ਵਰਤਦਾ ਹੈ ਪਰ ਟੈਸਟ ਡਾਟਾ ਨਾਲ। Sales ਨੂੰ ਪ੍ਰੀवਿਊ URL ਅਤੇ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਦਿੰਦੇ ਹਨ: “ਇੱਕ ਆਈਟਮ ਜੋੜੋ, VAT ਦਰਜ ਕਰੋ, ਟੈਸਟ ਭੁਗਤਾਨ ਪੂਰਾ ਕਰੋ।”
ਦੋ ਦਿਨਾਂ ਵਿੱਚ, ਫੀਡਬੈਕ ਆਉਂਦਾ ਹੈ: VAT ਫੀਲਡ ਅਸਪਸ਼ਟ ਹੈ, ਅਤੇ ਐਰਰ ਸੁਨੇਹਾ ਡਰਾਉਣਾ ਹੈ। ਟੀਮ UI ਨੂੰ ਠੀਕ ਕਰਦੀ ਹੈ, ਕਾਪੀ ਅਪਡੇਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰੀवਿਊ ਨੂੰ ਦੁਬਾਰਾ ਡਿਪਲੋਇ ਕਰਦੀ ਹੈ।
ਉਹ ਇੱਕ ਸਧਾਰਣ ਫਲੋ ਫਾਲੋ ਕਰਦੇ ਹਨ:
ਰਿਲੀਜ਼ 20 ਮਿੰਟ ਚੰਗੀ ਲੱਗਦੀ ਹੈ, ਫਿਰ ਭੁਗਤਾਨ ਫੇਲ ਹੋਣ ਲੱਗਦੇ ਹਨ। ਬੱਗ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਸੀ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਇੱਕ ਲੁਕਿਆ ਹੋਇਆ ਕੰਫਿਗ ਮੁੱਲ (ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਈਡਰ ਲਈ env var) ਗਾਇਬ ਸੀ।
ਦਬਾਅ 'ਚ ਹੌਟਫਿਕਸ ਕਰਨ ਦੀ ਥਾਂ, ਉਹ ਦਫ਼ਤਰੀਕ ਤੌਰ 'ਤੇ ਪਿਛਲੇ ਸਨੈਪਸ਼ਾਟ 'ਤੇ ਰੋਲਬੈਕ ਕਰਦੇ ਹਨ। ਭੁਗਤਾਨ ਫਿਰ ਤੁਰੰਤ ਠੀਕ ਹੋ ਜਾਂਦੇ ਹਨ। ਫਿਰ ਉਹ ਨਵੀਂ ਰਿਲੀਜ਼ ਨੂੰ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਵਾਪਸ بحਾਲ ਕਰਦੇ ਹਨ, ਉਥੇ ਗਾਇਬ ਕੰਫਿਗ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਰਿਲੀਜ਼ ਗੇਟ ਦੁਹਰਾਉਂਦੇ ਹਨ।
ਬਾਅਦ ਵਿੱਚ, ਉਹ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਠੀਕ ਕਰਦੇ ਹਨ:
ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੀ ਰੁਟੀਨ ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਖਾਸ ਘਟਨਾ। ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਪ੍ਰੀवਿਊ ਵਿਰੁੱਧ ਪ੍ਰੋਡਕਸ਼ਨ ਬੋਰਿੰਗ ਮਹਿਸੂਸ ਹੋਣ: ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਕਦਮ, ਇੱਕੋ ਹੀ ਚੈੱਕ, ਹਰ ਵਾਰੀ।
ਆਪਣੀਆਂ ਵਾਤਾਵਰਣ ਨੀਤੀਆਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ। ਇਸਨੂੰ ਛੋਟਾ ਤੇ ਸਪਸ਼ਟ ਰੱਖੋ: ਪ੍ਰੀवਿਊ URLs ਨੂੰ ਕਿਵੇਂ ਨਾਮ ਦੇਵੋਗੇ, ਕੌਣ ਉਨਾਂ ਨੂੰ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ, ਕਿਹੜਾ ਡਾਟਾ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਪਰ ਅਜਿਹੇ ਪ੍ਰੀਵਿਊ ਤੱਤਾਂ ਦੀ ਮੁਰੰਮਤ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ। ਡਾਟਾ ਲਈ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਪ੍ਰੀवਿਊਜ਼ ਸੈਂਪਲ ਡਾਟਾ ਜਾਂ ਮਾਸਕ ਕੀਤੀ ਕਾਪੀ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਅਸਲ ਗਾਹਕ ਰਿਕਾਰਡਸ ਨੂੰ ਕਦੇ ਛੂਹਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ ਬਿਨਾਂ ਸਪਸ਼ਟ ਕਾਰਨ ਅਤੇ ਮਨਜ਼ੂਰੀ ਦੇ।
ਇੱਕ ਆਦਤ ਗੈਰ-ਸੁਮਝੌਤੇਯੋਗ ਬਣਾਓ: ਹਰ ਪ੍ਰੋਡਕਸ਼ਨ ਰਿਲੀਜ਼ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਅਤੇ ਇੱਕ smoke ਟੈਸਟ ਨਾਲ ਖਤਮ ਹੁੰਦੀ। ਸਨੈਪਸ਼ਾਟ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਰਸਤਾ ਦਿੰਦਾ ਹੈ ਜੇ ਰਿਲੀਜ਼ ਨੇ ਕਿਸੇ ਅਣੈਕਸਪੈਕਟਡ ਚੀਜ਼ ਨੂੰ ਤੋੜ ਦਿੱਤਾ। smoke ਟੈਸਟ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਐਪ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਲਈ ਹੁਣ ਵੀ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।
ਇੱਕ ਹਲਕਾ ਡਿਫੌਲਟ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ:
ਜੋਖਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤਬਦੀਲੀਆਂ ਛੋਟੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਇਕ-ਐਸਥਿਰ ਫੀਚਰ ਜਾਂ ਫਿਕਸ ਨਾਲ ਅਕਸਰ ਰਿਲੀਜ਼ ਕਰੋ। ਜੇ ਕੁਝ ਵੱਡਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡੋ ਤਾਂ ਜੋ ਹਰ ਹਿੱਸਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕੀਤਾ ਜਾ ਸਕੇ, ਭਾਵੇਂ UI ਪਹਿਲਾਂ ਆ ਜਾਏ ਅਤੇ ਬੈਕਐਂਡ ਲਾਜਿਕ ਬਾਅਦ ਵਿੱਚ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਹਰ ਫੀਚਰ ਲਈ ਪ੍ਰੀਵਿਊ ਡਿਪਲੋਇਮੈਂਟ 'ਤੇ ਨਿਰਭਰ ਕਰੋ ਤਾਂ ਰਿਵਿਊਅਰ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਦੀ ਬਜਾਏ ਇੱਕ ਅਸਲੀ URL 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਣ। ਜਦੋਂ ਇਹ ਠੀਕ ਲੱਗੇ, ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪ੍ਰੋਮੋਟ ਕਰੋ, ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਤਿਆਰ ਰੱਖੋ ਤਾਂ ਕਿ ਇੱਕ ਖਰਾਬ ਡਿਪਲੋਇ ਇਕ ਲੰਬੇ ਆਊਟੇਜ ਦੀ ਥਾਂ ਇੱਕ ਛੋਟਾ ਘੇਰਾ ਬਣ ਜਾਵੇ।
ਇੱਕ ਪ੍ਰੀਵਿਊ ਵਾਤਾਵਰਣ ਤੁਹਾਡੇ ਐਪ ਦੀ ਉਥਾ-ਥਾਂ, ਅਲੱਗ ਨਕਲ ਹੁੰਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਖੋਲ੍ਹ ਕੇ ਫੀਡਬੈਕ ਲਈ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ। ਪ੍ਰੋਡਕਸ਼ਨ ਉਹ ਲਾਈਵ ਐਪ ਹੈ ਜਿਸ 'ਤੇ ਅਸਲੀ ਯੂਜ਼ਰ ਨਿਰਭਰ ਕਰਦੇ ਹਨ — ਅਸਲੀ ਡਾਟਾ ਅਤੇ ਅਸਲੀ ਨਤੀਜੇ ਜੇ ਕੁਝ ਟੁੱਟੇ ਤਾਂ।
ਮੁਢਲਾ ਨਿਯਮ: ਪ੍ਰੀਵਿਊ ਸਿੱਖਣ ਅਤੇ ਜਾਂਚ ਕਰਨ ਲਈ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਗਾਹਕਾਂ ਨੂੰ ਸਰਵ ਕਰਨ ਲਈ ਹੈ।
ਜੋ ਵੀ ਤਬਦੀਲੀ ਯੂਜ਼ਰ ਦੇ ਵੇਖਣ ਜਾਂ ਕਰਨ 'ਤੇ ਅਸਰ ਪਾਉਂਦੀ ਹੈ ਉਸ ਲਈ ਪ੍ਰੀਵਿਊ ਬਣਾਓ: UI ਅਪਡੇਟ, ਫਾਰਮ, ਪ੍ਰਮਾਣਿਕਤਾ, ਬਿਲਿੰਗ, ਡੇਟਾਬੇਸ ਕ੍ਵੈਰੀਜ਼, ਜਾਂ ਤੀਸਰੇ-ਪੱਖੀ ਇੰਟੇਗ੍ਰੇਸ਼ਨ।
ਜੇ ਤਬਦੀਲੀ ਗਲਤ ਹੋਣ 'ਤੇ ਸਹਾਇਤਾ ਟਿਕਟ ਬਣ ਸਕਦੇ ਹਨ ਤਾਂ ਪਹਿਲਾਂ ਉਹਨੂੰ ਪ੍ਰੀਵਿਊ ਲਿੰਕ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ, ਲਗਾਤਾਰ ਪੈਟਰਨ ਵਰਤੋ ਜੋ ਦੱਸੇ ਕਿ ਰਿਵਿਊਅਰ ਕੀ ਦੇਖ ਰਹੇ ਹਨ:
prv-<ticket>-<feature> (ਉਦਾਹਰਨ: prv-482-checkout-tax)prod ਜਾਂ main ਵਰਗੇ ਨਾਮ ਤੋਂ ਬਚੋਮੰਤਵ: ਕੋਈ ਵੀ ਚੈਟ ਵਿੱਚ URL ਪੇਸਟ ਕਰੇ ਤੇ ਸਾਰੇ ਸਮਝ ਜਾਣ।
ਇੱਕ ਪ੍ਰੀਵਿਊ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬਿਲਡ ਨਾਲ ਜੋੜਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਨਾ ਕਿ “ਹੁਣ ਜੋ ਵੀ ਅਪ-ਟੂ-ਡੇਟ ਹੈ”)।
ਪ੍ਰਯੋਗਕ ਰਸਤਾ:
ਇਸ ਨਾਲ ਫੀਡਬੈਕ ਭਰੋਸੇਯੋਗ ਬਣਦਾ ਹੈ ਕਿਉਂਕਿ ਸਾਰੇ ਇੱਕੋ ਸੰਸਕਰਨ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਨ।
ਇੱਕ ਡਿਫ਼ੌਲਟ ਚੁਣੋ ਅਤੇ ਟੀਮ ਲਈ ਲਿਖ ਕੇ ਰੱਖੋ:
ਸੂਝ-ਬੁਝ: ਜੇ ਤੱਕ ਕੋਈ ਖਾਸ ਲੋੜ ਨਾ ਹੋਵੇ, ਤਾਂ ਸੈਂਪਲ ਡਾਟਾ ਵਰਤੋ।
ਪ੍ਰੀਵਿਊ ਆਮ ਤੌਰ 'ਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਜਾਂ ਫਾਰਵਰਡ ਕੀਤੀਆਂ ਸੰਦਸ਼ਾਂ ਰਾਹੀਂ ਲੀਕ ਹੋ ਸਕਦੇ ਹਨ।
ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਆਮ ਤੌਰ 'ਤੇ:
ਡਿਫੌਲਟ: ਟੀਮ-ਕੇਵਲ ਐਕਸੈਸ, ਜਦ ਤੱਕ ਖਾਸ ਤੌਰ 'ਤੇ ਸਾਂਝ ਨਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ ।
ਇਹ ਛੋਟੀ ਤੇ ਮੁੜ-ਪ੍ਰਯੋਗ ਯਾਦੀ ਰੱਖਣ ਵਾਲੀ ਚੀਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਜਾਂਚਿਆ — ਇਸ ਨਾਲ ਰਿਵਿਊਅਰ ਨੂੰ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਕੀ ਕਵਰ ਕੀਤਾ ਗਿਆ।
Environment variables ਪ੍ਰੀਵਿਊ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਚ ਅਕਸਰ ਕਾਰਨ ਬਣਦੇ ਹਨ ਕਿ “ਪ੍ਰੀਵਿਊ 'ਚ ਚੰਗਾ, ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਫੇਲ”।
ਪ੍ਰੋਮੋਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ:
ਕਦੇ ਵੀ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਪ੍ਰੋਡਕਸ਼ਨ ਸिक्रੇਟ ਦੁਬਾਰਾ ਵਰਤੋਂ ਨਾ ਕਰੋ।
ਇੱਕ ਬੈਕਵਰਡ-ਕੰਪੈਟਿਬਲ ਪੈਟਰਨ ਵਰਤੋ:
ਇਸ ਨਾਲ ਰੋਲਬੈਕ ਦੀ ਸਥਿਤੀ ਘੱਟ ਤੇਖੀ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਹੁਣ ਪੁਰਾਣੇ ਐਪ ਵਰਜ਼ਨ ਨਾਲ ਮੇਲ ਨਾ ਖਾਂਵੇ।
ਜਦੋਂ ਯੂਜ਼ਰ ਬਲਾਕ ਹੋਏ ਹੋਣ ਜਾਂ ਕਾਰਨ ਅਸਪਸ਼ਟ ਹੋਵੇ: ਤੇਜ਼ ਰੋਲਬੈਕ ਕਰੋ ਵਾਪਸ ਜਾਣ ਲਈ ਜੋ ਆਖਰੀ ਜਾਣਿਆ-ਚੰਗਾ ਸਨੈਪਸ਼ਾਟ/ਵਰਜ਼ਨ ਸੀ।
ਹੌਟਫਿਕਸ ਓਸ ਵੇਲੇ ਵਰਤੋ ਜਦੋਂ:
ਰੋਲਬੈਕ ਤੋਂ ਬਾਅਦ ਇਕ ਛੋਟੀ ਪ੍ਰੋਡਕਸ਼ਨ ਸਮੋਕ ਟੈਸਟ ਚਲਾਓ (ਲੋਗਿਨ + ਮੁੱਖ ਕਾਰਵਾਈ) ਤਾਂ ਜੋ ਪੁਸ਼ਟੀ ਹੋ ਜਾਵੇ ਕਿ ਸਭ ਠੀਕ ਹੋ ਗਿਆ ਹੈ।