ਚੈਟ-ਆਧਾਰਿਤ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼ਾਂ ਲਈ ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ

ਕਿਉਂ ਚੈਟ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਬਦਲਾਵਾਂ ਨੂੰ ਹਜੇ ਵੀ ਰਿਲੀਜ਼ ਵਰਕਫਲੋ ਦੀ ਲੋੜ ਹੈ

ਚੈਟ-ਆਧਾਰਿਤ ਬਣਾਉਣਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਵੇਰਵਾ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਰੰਤ ਐਪ ਵਿੱਚ ਬਦਲਾਅ ਵੇਖਦੇ ਹੋ। ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ “ਤੇਜ਼” "ਅਸਪੱਸ਼ਟ" ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ ਜਦ ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕੀ ਬਦਲਿਆ, ਕੀ ਚੈੱਕ ਕਰਨਾ ਹੈ, ਜਾਂ ਕੌਣ ਪ੍ਰਯੋਗਕਰਤਿਆਂ ਨੂੰ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰ ਕਹੇ।

ਹੈਂਡਆਫ਼ ਨਾ ਹੋਣ ਤੇ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਸਲਿੱਪ ਕਰ ਜਾਂਦੀਆਂ ਹਨ। ਬਦਲਾਅ ਤੁਹਾਡੇ ਮਨ ਵਿੱਚ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਐਪ ਉਹੀ ਕਰੇਗੀ ਜੋ ਤੁਸੀਂ ਬੋਲਿਆ, ਨਾਲ ਹੀ ਜਨਰੇਟਰ ਨੇ ਜੋ ਧਾਰਣਾ ਕੀਤੀ। ਇਸ ਲਈ ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇਹ ਤੇਜ਼ੀ ਰੱਖਦਾ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਰੁਕਾਵਟ ਜੋੜਦਾ ਹੈ ਤਾਂ ਕਿ ਬਦਲਾਅ ਸੁਰੱਛਿਤ ਹੋਵੇ।

ਹੇਠਾਂ ਅਜਿਹੇ ਆਮ ਤਰੀਕੇ ਦਿੱਤੇ ਗਏ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਚੈਟ-ਚਲਿਤ ਅੱਪਡੇਟਸ ਵਾਸਤਵਿਕ ਉਤਪਾਦਾਂ ਵਿੱਚ ਗਲਤ ਹੋ ਜਾਂਦੀਆਂ ਹਨ:

• ਮੁੱਖ ਜਗ੍ਹਾ 'ਤੇ ਗਲਤ ਕਾਪੀ (ਕੀਮਤ, ਕਾਨੂੰਨੀ ਟੈਕਸਟ, ਔਨਬੋਰਡਿੰਗ ਕਦਮ)
• "ਛੋਟਾ" UI ਬਦਲਾਅ ਬਾਅਦ ਲੌਗਿਨ ਜਾਂ ਸਾਈਨਅਪ ਟੁੱਟਣਾ
• ਫਾਰਮ ਜਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਗੁਆਂਢੇ ਫੀਲਡਾਂ ਦੀ ਗੈਰ-ਹਾਜ਼ਰੀ ਜਾਂ ਉਪਭੋਗਤਾ ਡੇਟਾ ਛੱਡਣਾ
• ਗਲਤ ਪਰਮਿਸ਼ਨਾਂ (ਇੱਕ ਐਡਮਿਨ-ਕੇਵਲ ਪੰਨਾ ਹਰ ਕਿਸੇ ਲਈ ਦਿਖਣ ਲੱਗ ਪੈਂਦਾ ਹੈ)
• ਨਵਾਂ ਫੀਚਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਪੁਰਾਣਾ ਫਲੋ ਟੁੱਟ ਜਾਂਦਾ ਹੈ (ਪਾਸਵਰਡ ਰੀਸੈਟ, ਚੈਕਆਊਟ, ਐਕਸਪੋਰਟ)

ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਨੂੰ ਰੋਕਣਾ ਹੈ। ਮਕਸਦ ਤੇਜ਼ ਬਦਲਾਅ ਬਿਨਾਂ ਅਚਾਨਕੀਆਂ ਦੇ ਹੈ। ਇੱਕ ਸਪਸ਼ਟ “ਪ੍ਰਸਤਾਵ → ਸਮੀਖਿਆ → ਮਰਜ → ਡਿਪਲੋ” ਪ੍ਰਵਾਹ ਹਰ ਕਿਸੇ ਨੂੰ ਉਹੀ ਚੈੱਕਪੌਇਂਟ ਦਿੰਦਾ ਹੈ: ਕੀ ਮਨੱਸੂਬਾ ਸੀ, ਕੀ ਬਦਲਿਆ, ਕੀ ਚੈੱਕ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਕਿਸ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ।

ਇਹ ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ ਜਿਵੇਂ Koder.ai, ਜਿੱਥੇ ਇਕੱਲੀ ਚੈਟ UI, ਬੈਕਐਂਡ APIs ਅਤੇ ਡੇਟਾਬੇਸ 'ਤੇ ਅਪਡੇਟ ਜਨਰੇਟ ਕਰ ਸਕਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਹਰ ਇੱਕ ਕੋਡ ਲਾਈਨ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਸਹੀ ਫਾਇਲਾਂ ਬਦਲੀਆਂ ਅਤੇ ਖਤਰਨਾਕ ਹਿੱਸੇ (auth, ਡੇਟਾ, ਭੁਗਤਾਨ) ਬੇਧਿਆਨ ਤਰੀਕੇ ਨਾਲ ਡਰਿਫਟ ਨਹੀਂ ਹੋਏ।

ਉਮੀਦ ਸੈੱਟ ਕਰੋ: ਇਹ ਵਰਕਫਲੋ ਛੋਟੇ ਤੋਂ درمیانے ਬਦਲਾਅ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ, ਜਿਵੇਂ ਇਕ ਨਵਾਂ ਫਾਰਮ ਫੀਲਡ, ਡੈਸ਼ਬੋਰਡ ਟਵੀਕ, ਜਾਂ ਨਵਾਂ ਸੈਟਿੰਗ ਪੰਨਾ। ਡੂੰਘੀ ਰੀਰਾਈਟਾਂ ਨੂੰ ਹੋਰ ਯੋਜਨਾ, ਲੰਬੀਆਂ ਸਮੀਖਿਆਵਾਂ ਅਤੇ ਵਾਧੂ ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹਲਕਾ ਫਲੋ ਰੋਜ਼ਾਨਾ ਦੇਫੌਲਟ ਹੈ ਸੁਰੱਖਿਅਤ, ਅਕਸਰ ਰਿਲੀਜ਼ਾਂ ਲਈ।

propose-review-merge-deploy ਪ੍ਰਵਾਹ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ

ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਸਿਰਫ਼ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਹੈ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਚੈਟ-ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਬਦਲਾਵ ਸਮਝਣ ਯੋਗ ਹਨ, ਕਿਸੇ ਹੋਰ ਵਿਅਕਤੀ ਦੁਆਰਾ ਚੈੱਕ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਇਰਾਦੇ ਨਾਲ ਸ਼ਿਪ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ (ਭੁਲਵਸ਼ ਨਹੀਂ)। ਤੁਹਾਨੂੰ ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਚਾਰ ਸਪਸ਼ਟ ਕਦਮ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰ ਕੋਈ ਫਾਲੋ ਕਰੇ।

4 ਕਦਮ

ਪ੍ਰਸਤਾਵ: ਇੱਕ ਵਿਅਕਤੀ ਬਦਲਾਅ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਰਵਾ ਕਰਦਾ ਹੈ ਅਤੇ ਕਾਮਯਾਬੀ ਕੀ ਹੈ ਇਹ ਦੱਸਦਾ ਹੈ। ਇਹ ਇੱਕ ਪੇਜ਼ ਨੋਟਾਂ ਤੱਕ ਹੀ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ, ਕਿੱਥੇ ਦਿਖਦਾ ਹੈ, ਕਿਵੇਂ ਟੈਸਟ ਕਰਨਾ ਹੈ, ਅਤੇ ਕੋਈ ਜੋਖਮ (ਉਦਾਹਰਨ ਲਈ, “ਲੌਗਿਨ ਨੂੰ ਛੂਹਦਾ ਹੈ” ਜਾਂ “ਕੀਮਤ ਪੰਨਾ ਬਦਲਦਾ ਹੈ”)।

ਸਮੀਖਿਆ: ਕੋਈ ਹੋਰ ਨੋਟਾਂ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਜਨਰੇਟ ਕੀਤੇ ਡਿਫਸ ਨੂੰ ਚੈੱਕ ਕਰਦਾ ਹੈ। ਮਕਸਦ ਹਰ ਲਾਈਨ ਦਾ ਆਡੀਟ ਕਰਨਾ ਨਹੀਂ, ਪਰ ਅਚਾਨਕੀਆਂ ਫੜਨੀਆਂ ਹਨ: ਬਦਲੇ ਵਰਤਾਰ, ਗੁੰਮ ਹੋਏ ਐਜ ਕੇਸ, ਜਾਂ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਬੇਸਬਰੀ ਨਾਲ ਬੇਤਰਤੀਬ ਲੱਗੇ। ਛੋਟਾ ਸਮੀਖਿਆ ਵਿੰਡੋ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ (ਛੋਟੇ ਬਦਲਾਅ ਲਈ ਆਮ ਤੌਰ 'ਤੇ 15 ਤੋਂ 30 ਮਿੰਟ)।

ਮਰਜ: ਤੁਸੀਂ ਇੱਕ ਸਪਸ਼ਟ ਫੈਸਲਾ ਕਰੋ: ਮਨਜ਼ੂਰ ਕੀਤਾ ਜਾਂ ਨਹੀਂ। ਜੇ ਮਨਜ਼ੂਰ ਹੈ, ਤਾਂ ਪ੍ਰਸਤਾਵ ਨਾਲ ਮਿਲਦੀ ਛੋਟੀ ਮੇਸੇਜ ਦੇ ਕੇ ਮਰਜ ਕਰੋ (ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਲੱਭ ਸਕੋ)। ਜੇ ਮਨਜ਼ੂਰ ਨਹੀਂ, ਤਾਂ ਇੱਕ ਜਾਂ ਦੋ ਨਿਰਦੇਸ਼ੀ ਸੁਧਾਰਾਂ ਨਾਲ ਵਾਪਸ ਭੇਜੋ।

ਡਿਪਲੋ: ਇੱਕ ਤੇਜ਼ smoke test ਅਤੇ ਇੱਕ ਰੋਲਬੈਕ ਯੋਜਨਾ ਨਾਲ ਰਿਲੀਜ਼ ਕਰੋ। ਡਿਪਲੋ ਇਕ ਜਾਣ-ਬੁਝ ਕੇ ਕਦਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਕੁਝ ਜੋ ਸਿਰਫ਼ ਕੋਡ ਮੌਜੂਦ ਹੋਣ ਨਾਲ ਹੀ ਹੋ ਜਾਏ।

ਹਰ ਕਦਮ 'ਤੇ “ਮੁਕੰਮਲ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ

• ਪ੍ਰਸਤਾਵ ਮੁਕੰਮਲ ਹੈ ਜਦ ਬਦਲਾਅ ਦਾ ਸਪਸ਼ਟ ਲਕਸ਼, ਟੈਸਟ ਕਦਮ, ਅਤੇ ਨਾਮਦਾਰ ਮਾਲਕ ਹੋਵੇ।
• ਸਮੀਖਿਆ ਮੁਕੰਮਲ ਹੈ ਜਦ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਮੀਖਿਆਕਾਰ “ਮਨਜ਼ੂਰ” ਕਹਿੰਦਾ ਹੈ ਅਤੇ ਕੋਈ ਜੋਖਮ ਦਰਸਾਉਂਦਾ ਹੈ।
• ਮਰਜ ਮੁਕੰਮਲ ਹੈ ਜਦ ਫੈਸਲਾ ਸਧਾਰਨ ਟਰੇਲ (ਨੋਟ + ਅਖੀਰਲਾ ਸੁਨੇਹਾ) ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।
• ਡਿਪਲੋ ਮੁਕੰਮਲ ਹੈ ਜਦ ਬਦਲਾਅ ਲਾਈਵ ਹੋ ਕੇ ਸਧਾਰਨ ਜਾਂਚ ਪਾਰ ਕਰ ਲੈ।

ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਇਸ ਫਲੋ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦਾ ਹੈ: ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਮੀਖਿਆਕਾਰ ਬਿਨਾਂ ਡਿਪਲੋ ਨਹੀਂ। ਛੋਟੀ ਟੀਮਾਂ 'ਤੇ ਵੀ, ਉਹ ਇਕ ਰੁਕਾਵਟ ਜਿਆਦਾਤਰ ਖਰਾਬ ਰਿਲੀਜ਼ਾਂ ਰੋਕ ਦਿੰਦੀ ਹੈ।

ਕੌਣ ਕੀ ਕਰਦਾ ਹੈ (ਤਾਂ ਜੋ ਸਮੀਖਿਆ ਰੁਕੀ ਨਾ ਰਹੇ)

ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਸਿਰਫ਼ ਹਲਕਾ ਰਹਿੰਦਾ ਹੈ ਜਦ ਹਰ ਕੋਈ ਆਪਣਾ ਕੰਮ ਜਾਣਦਾ ਹੈ। ਜੇ ਭੂਮਿਕਾਵਾਂ ਧੁੰਦਲੀ ਹਨ, ਸਮੀਖਿਆ ਲੰਬੀਆਂ ਚੈਟਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ, ਜਾਂ ਹੋਰ ਖਤਰਨਾਕ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੋਈ “ਹਾਂ” ਕਹਿਣ ਲਈ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਦਾ।

ਤਿੰਨ ਸਧਾਰਨ ਭੂਮਿਕਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਛੋਟੀ ਟੀਮਾਂ ਵਿੱਚ ਇੱਕ ਵਿਅਕਤੀ ਦੋ ਟੋਪੀਆਂ ਪਹਿਨ ਸਕਦਾ ਹੈ, ਪਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵੱਖਰੀਆਂ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

• ਪ੍ਰਸਤਾਵਕ (Proposer): ਬਦਲਾਅ ਨੂੰ ਵੇਰਵਾ ਕਰਦਾ, ਜਨਰੇਟ ਕਰਦਾ, ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਪੈਕੇਜ ਕਰਦਾ (ਸਪਸ਼ਟ ਸੰਖੇਪ, ਸਕਰੀਨਸ਼ੌਟ ਜੇ ਲੋੜ ਹੋਵੇ, ਅਤੇ ਡਿਫ)।
• ਸਮੀਖਿਆਕਾਰ (Reviewer): ਡਿਫ ਚੈੱਕ ਕਰਦਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਬਦਲਾਅ ਨੂੰ ਟੈਸਟ ਕਰਦਾ। ਉਹਨਾਂ ਦਾ ਨਜ਼ਰ ਅਚਾਨਕੀਆਂ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਨਾਕਿ ਪੂਰਨਤਾ 'ਤੇ।
• ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ (Approver): ਮਰਜ ਅਤੇ ਡਿਪਲੋ ਦਾ ਫੈਸਲਾ ਕਰਦਾ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਖਤਰੇ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦਾ ਹੈ।

ਮਾਲਕੀਦਾਰੀ ਹੀ ਸਮੀਖਿਆਵਾਂ ਨੂੰ ਤੇਜ਼ ਰੱਖਦੀ ਹੈ। ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੌਣ ਸਾਈਨ ਕਰਦਾ ਹੈ:

• ਉਤਪਾਦ ਵਰਤਾਰਾ (ਕੀ ਇਹ ਉਪਭੋਗਤਿਆਂ ਲਈ ਸਹੀ ਕੰਮ ਕਰਦਾ?)
• ਡੇਟਾ ਸੁਰੱਖਿਆ (ਕੀ ਇਹ ਡੇਟਾ ਮਿਟਾ ਸਕਦਾ, ਖੋਲ ਸਕਦਾ, ਜਾਂ ਖਰਾਬ ਕਰ ਸਕਦਾ?)
• ਬਰਾਂਡਿੰਗ ਅਤੇ ਟੋਨ (ਕਾਪੀ, ਰੰਗ, ਕਾਨੂੰਨੀ ਟੈਕਸਟ, ਈਮੇਲ)

ਮਨਜ਼ੂਰੀ ਨੂੰ ਜੋਖਮ ਦੇ ਆਕਾਰ ਨਾਲ ਮਿਲਾਉ। ਇਕ ਛੋਟੀ UI ਸੋਧ ਸ਼ਾਇਦ ਉਤਪਾਦ ਮਾਲਕ ਦੁਆਰਾ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੋ ਕੁਝ ਵੀ auth, payments, permissions, ਜਾਂ ਗ੍ਰਾਹਕ ਡੇਟਾ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਉਸ ਨੂੰ ਵੱਧ ਤਾਕਤਵਰ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੇ ਦੀ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਕਦਾਚਿਤ ਦੂਜਾ ਸਮੀਖਿਆਕਾਰ ਵੀ)।

ਟਾਈਮਬੌਕਸ ਲੰਮਾ "ਉਡੀਕ ਕਰਨਾ" ਰੋਕਦੇ ਹਨ। ਇੱਕ ਪ੍ਰਯੋਗੀ ਨਿਯਮ ਘੱਟ-ਖਤਰੇ ਬਦਲਾਅ ਲਈ ਇਕੋ-ਦਿਨ ਦੀ ਸਮੀਖਿਆ ਹੈ, ਅਤੇ ਖਤਰਨਾਕ ਬਦਲਾਅ ਲਈ ਲੰਬਾ ਸਮਾਂ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਹਰ ਪ੍ਰਸਤਾਵ ਵਿਚ ਛੋਟਾ ਸੰਖੇਪ + ਜਨਰੇਟ ਕੀਤਾ ਡਿਫ ਸ਼ਾਮਲ ਕਰਨ 'ਤੇ ਸਹਿਮਤ ਹੋ ਕੇ ਇਹ ਅਸਾਨ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਕਿ ਸਮੀਖਿਆਕਾਰਾਂ ਨੂੰ ਚੈਟ ਇਤਿਹਾਸ ਤੋਂ ਬਦਲਾਅ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਾ ਪਵੇ।

ਕਦਮ 1 - ਇੱਕ ਐਸਾ ਪ੍ਰਸਤਾਵ ਬਣਾਉ ਜੋ ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ ਹੋਵੇ

ਇੱਕ ਚੰਗਾ ਪ੍ਰਸਤਾਵ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਛੋਟੇ ਟਿਕਟ ਵਾਂਗ ਪੜ੍ਹਨਯੋਗ ਹੁੰਦਾ ਹੈ। 2-3 ਵਾਕਾਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਭਾਸ਼ਾ ਵਿੱਚ ਸੰਖੇਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਉਪਭੋਗਤਾ ਨੂੰ ਕੀ ਮਹਿਸੂਸ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਉਹ ਸੰਖੇਪ ਚੈਟ ਵਿੱਚ ਪੇਸਟ ਕਰੋ ਤਾਂ ਕਿ ਜਨਰੇਟ ਹੋਇਆ ਕੋਡ ਅਤੇ ਡਿਫ ਫੋਕਸ ਵਿੱਚ ਰਹੇ।

ਅਗਲੇ, ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਸਧਾਰਨ ਚੈੱਕਬਾਕਸ ਵਜੋਂ ਲਿਖੋ। ਇਹ ਉਹੀ ਚੀਜ਼ਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਬਦਲਾਅ ਬਣਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਸਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰਨੀ ਹੈ।

• ਉਪਭੋਗਤਾ ਟਾਸਕ ਨੂੰ ਆਖ਼ਰੀ ਤੱਕ ਬਿਨਾਂ ਐਰਰ ਦੇ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ
• ਸਕਰੀਨ ਟੈਕਸਟ ਨਵੇਂ ਸ਼ਬਦਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ (ਕੋਈ ਪੁਰਾਣੀ ਕਾਪੀ ਨਾ ਰਹਿ ਜਾਵੇ)
• ਮੌਜੂਦਾ ਉਪਭੋਗਤਾ ਅਜੇ ਵੀ ਲੌਗ ਇਨ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਆਪਣਾ ਡੇਟਾ ਵੇਖ ਸਕਦੇ ਹਨ
• ਬਦਲਾਅ ਮੋਬਾਇਲ ਅਤੇ ਡੈਸਕਟਾਪ ਦੋਹਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ
• ਜੇ ਕੁਝ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਐਪ ਸੁੱਟਪੇਟ ਪੰਨਾ ਦੀ ਥਾਂ ਸਾਫ਼ ਸੁਨੇਹਾ ਦਿਖਾਏ

ਫਿਰ ਸਕੋਪ ਇੱਕ ਛੋਟੀ ਪੈਰਾ ਵਿੱਚ ਦਰਸਾਓ: ਕੀ ਇਰਾਦੀ ਨਾਲ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਰਿਹਾ। ਇਹ ਅਚਾਨਕ ਡਿਫਸ ਜਿਵੇਂ ਵਾਧੂ UI ਸੋਧ, ਨਵੇਂ ਫੀਲਡ, ਜਾਂ "ਜਦੋਂ ਮੈਂ ਇੱਥੇ ਸੀ" ਰੀਫੈਕਟਰ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਇੱਕ ਤੇਜ਼ ਜੋਖਮ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ। ਇਸ ਨੂੰ ਪ੍ਰਾਇਗਿਆਤਕ ਰੱਖੋ: ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ, ਅਤੇ ਆਮ ਉਪਭੋਗਤਾ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰੇਗਾ। ਉਦਾਹਰਨ: “जोਖਮ: ਨਵਾਂ ਲਾਜ਼ਮੀ ਫੀਲਡ ਗੁੰਮ ਹੋਣ 'ਤੇ ਸਾਈਨ-ਅਪ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਵੈਧਤਾ ਐਰਰ ਦਿੱਖੇਗਾ ਅਤੇ ਅਕਾਊਂਟ ਨਹੀਂ ਬਣੇਗਾ।”

ਉਦਾਹਰਣ ਪ੍ਰਸਤਾਵ:

“ਚੈਕਆਊਟ ਬਟਨ ਲੇਬਲ ਨੂੰ ‘Pay now’ ਤੋਂ ‘Place order’ ਵਿੱਚ ਬਦਲੋ ਤਾਂ ਕਿ ਡ੍ਰੌਪ-ਆਫ ਘਟੇ। ਕੀਮਤ, ਟੈਕਸ ਜਾਂ ਪੇਮੈਂਟ ਪ੍ਰੋਵਾਇਡਰ ਨਾ ਬਦਲੋ। ਜੋਖਮ: ਜੇ ਇਕ ਜਗ੍ਹਾ ਤੇ ਬਟਨ ਨਾਂਮ ਬਦਲਿਆ ਗਿਆ ਪਰ ਦੂਜੀ ਜਗ੍ਹਾ ਨਹੀਂ, ਤਾਂ ਮੋਬਾਇਲ 'ਤੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਅਸਮਰੂਪ ਲੇਬਲਾਂ ਮਿਲ ਸਕਦੀਆਂ ਹਨ।”

ਕਦਮ 2 - ਜਨਰੇਟ ਕੀਤੇ ਡਿਫਸ ਦੀ ਸਮੀਖਿਆ (ਕੀ ਵੇਖਣਾ ਹੈ)

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਪਭੋਗਤਾ ਦੀ ਨਜ਼ਰ ਤੋਂ ਬਦਲਾਅ ਨੂੰ ਪੜ੍ਹੋ। ਕਿਹੜੀਆਂ ਸਕ੍ਰੀਨਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਕਿਹੜੇ ਬਟਨ ਕਲਿਕ ਵੱਖਰੇ ਹੋ ਰਹੇ ਹਨ, ਅਤੇ ਸਫਲਤਾ ਜਾਂ ਅਸਫਲਤਾ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ? ਜੇ ਤੁਸੀਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗੋ। ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਹਰ ਸਮੀਖਿਆ ਦਾ ਇੱਕ ਸਪਸ਼ਟ, ਮਨੁੱਖ-ਪ੍ਰਮਾਣ ਰੱਖਣਯੋਗ ਲਕਸ਼ ਹੋਵੇ।

ਅਗਲੇ, ਕਿਸੇ ਵੀ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਫ਼ਾਇਲ ਸੂਚੀ ਨੂੰ ਸਕੈਨ ਕਰੋ। ਭਾਵੇਂ ਤੁਸੀਂ ਇੰਜੀਨੀਅਰ ਨਾ ਹੋਵੋ, ਫਾਇਲ ਦੇ ਨਾਂ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਜੋਖਮ ਲਈ ਤਿਆਰ ਹੋ। ਕੇਵਲ ਇੱਕ React ਪੰਨਾ ਛੂਹਣ ਵਾਲਾ ਬਦਲਾਅ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਤੋਂ ਸੌਖਾ ਹੁੰਦਾ ਹੈ ਜੋ Go ਸਰਵਿਸਿਜ਼, ਡੇਟਾਬੇਸ ਮਾਈਗਰੇਸ਼ਨ, ਇਨਵਾਇਰਨਮੈਂਟ ਕੰਫਿਗ, ਜਾਂ ਕਿਸੇ ਵੀ ਗੁਪਤ ਜਾਣਕਾਰੀ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਵੀ ਛੂਹਦਾ ਹੈ।

ਖਤਰਨਾਕ ਖੇਤਰਾਂ ਲਈ ਤੇਜ਼ ਸਕੈਨ

ਉਹਨਾਂ ਡਿਫਸ ਨੂੰ ਲੱਭੋ ਜੋ ਹੇਠਾਂ ਦਿੱਤੇ ਖੇਤਰਾਂ ਨੂੰ ਛੂਹਦੇ ਹਨ ਅਤੇ ਜੇ ਮਿਲਣ ਤਾਂ ਧੀਰੇ ਚਲੋ:

• ਲੌਗਿਨ, ਪਰਮਿਸ਼ਨ, ਰੋਲ, ਐਡਮਿਨ ਰੂਟ ਜਾਂ auth ਮਿਡਲਵੇਅਰ
• ਭੁਗਤਾਨ, ਕੀਮਤਾਂ, ਕ੍ਰੈਡਿਟ, ਇਨਵਾਇਸ ਜਾਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਾਜ਼ਿਕ
• ਈਮੇਲ ਭੇਜਣਾ, SMS, ਨੋਟੀਫਿਕੇਸ਼ਨ ਜਾਂ webhook callback
• ਡੇਟਾਬੇਸ ਬਦਲਾਅ (ਨਵੀਆਂ ਟੇਬਲਾਂ, ਮਾਈਗਰੇਸ਼ਨ, ਇੰਡੈਕਸ, ਵੱਡੇ ਬੈਕਫਿੱਲ)
• ਕੰਫਿਗ ਅਤੇ ਕੀਜ਼ (env ਫਾਇਲਾਂ, ਟੋਕਨ ਨਾਮ, ਤੀਜੇ ਧਿਰ ਦੀਆਂ ਸਹੂਲਤਾਂ)

ਇਸ ਤੋਂ ਬਾਅਦ, ਡਿਫ ਵਿੱਚ ਉਪਭੋਗਤਾ-ਸਮਨਾ ਵਾਲੀਆਂ ਵਿਵਰਣਾਂ ਨੂੰ ਚੈੱਕ ਕਰੋ। ਲੇਬਲ, ਹੇਲਪਰ ਟੈਕਸਟ, ਐਰਰ ਸੁਨੇਹੇ, ਅਤੇ ਖਾਲੀ ਸਥਿਤੀਆਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ “ਛੋਟੇ” ਬਦਲਾਅ ਖਰਾਬ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਨਵੀਨ ਕਾਪੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਰਾਦੇ ਨਾਲ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਐਰਰ ਉਪਭੋਗਤਾ ਨੂੰ ਅੱਗੇ ਕੀ ਕਰਨ ਦੱਸਦੀ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਲੁਕਵੀਂ ਲਾਗਤਾਂ ਲਈ ਵੇਖੋ। ਹਰ ਪੇਜ ਲੋਡ 'ਤੇ ਨਵੀਆਂ API ਕਾਲਾਂ, ਭਾਰੀ ਕੁਏਰੀਆਂ, ਜਾਂ ਵੰਞੇ ਪਿੱਛੇ ਕੰਮ ਵੱਡੀ ਖ਼ਰਚਾ ਅਤੇ ਸਲੋ ਪੇਜ ਬਣਾ ਸਕਦੇ ਹਨ। ਜੇ ਡਿਫ ਵਿੱਚ polling ਲੂਪ, ਵੱਡੀ “select all” ਕੁਏਰੀ, ਜਾਂ ਕੋਈ ਨਵੀਂ ਨੌਕਰੀ ਜੋ ਅਕਸਰ ਚਲਦੀ ਹੈ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਪੁੱਛੋ: “ਇਹ ਕਿੰਨੀ ਵਾਰੀ ਚੱਲੇਗਾ, ਅਤੇ ਪੈਮਾਣੇ 'ਤੇ ਇਸ ਦੀ ਕੀ ਲਾਗਤ ਹੋਵੇਗੀ?”

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਲੇਖਕ ਨੂੰ ਆਖੋ ਕਿ ਡਿਫ ਨਾਲ ਇੱਕ ਛੋਟੀ ਨੋਟ ਸ਼ਾਮਲ ਕਰੇ: ਕੀ ਬਦਲਿਆ, ਕੀ ਨਹੀਂ ਬਦਲਿਆ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਕਿਵੇਂ ਟੈਸਟ ਕੀਤਾ। ਉਹ ਇਕ ਨੋਟ ਸਮੀਖਿਆਵਾਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ ਹੈ।

ਡਿਫ ਡੀਪ ਚੈਕਸ ਸੁਰੱਖਿਆ ਲਈ (ਬਿਨਾਂ ਇੰਜੀਨੀਅਰ ਹੋਏ)

ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਸਮੀਖਿਆਕਾਰ ਜਾਣਦੇ ਹਨ ਕਿ ਕੀ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਟੁੱਟ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਕੋਡ ਦੀ ਵਿਆਖਿਆ ਨਾ ਕਰ ਸਕਣ। ਜਦ ਤੁਸੀਂ ਜਨਰੇਟ ਕੀਤਾ ਡਿਫ ਖੋਲ੍ਹਦੇ ਹੋ, ਤਾਂ ਉਹ ਬਦਲਾਅ ਲੱਭੋ ਜੋ ਡੇਟਾ, ਪਹੁੰਚ, ਅਤੇ ਇਨਪੁਟਾਂ ਨੂੰ ਛੂਹਦੇ ਹਨ। ਇਹ ਉਹ ਥਾਵਾਂ ਹਨ ਜਿੱਥੇ ਛੋਟੇ ਸੋਧ ਵੱਡੇ ਅਚਾਨਕੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ।

1) ਬੈਕਐਂਡ ਅਤੇ ਡੇਟਾ: ਉਹ ਬਦਲਾਅ ਜੋ ਹਰ ਉਪਭੋਗਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ

ਜੇ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਮਾਈਗਰੇਸ਼ਨ ਫਾਇਲਾਂ ਜਾਂ ਮਾਡਲਾਂ ਵਿੱਚ ਸੋਧ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਧੀਰੇ ਚਲੋ। ਜਾਂਚੋ ਕਿ ਨਵੀਆਂ ਫੀਲਡਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹਨ ਜਾਂ ਨਹੀਂ, ਜਿਨ੍ਹਾਂ ਫੀਲਡਾਂ ਨੂੰ ਪਹਿਲਾਂ ਜ਼ਰੂਰੀ ਸਨ ਉਹnullable ਹੋ ਗਏ ਹਨ ਜਾਂ ਉਲਟ, ਅਤੇ ਕੋਈ ਇੰਡੈਕਸ ਜੋ ਖੋਜ ਜਾਂ ਫਿਲਟਰ ਲਈ ਜੋੜਿਆ ਗਿਆ ਹੈ ਕਿ ਨਹੀਂ।

ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਬਦਲਾਅ ਮੌਜੂਦਾ ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਪੁੱਛੋ “ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪਹਿਲਾਂ ਮੌਜੂਦ ਡੇਟਾ ਨਾਲ ਕੀ ਹੋਵੇਗਾ?” ਜੇ ਜਵਾਬ ਅਸਪਸ਼ਟ ਹੋਵੇ, PR ਵੇਰਵਾ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਨੋਟ ਮੰਗੋ।

2) ਸੁਰੱਖਿਆ ਜਾਂਚ: ਸੁਰੱਖਿਆ, ਵੈਧਤਾ, ਅਤੇ ਪਰਮਿਸ਼ਨ

ਇਸ ਤੇਜ਼ ਸਕੈਨ ਨਾਲ ਸਭ ਤੋਂ ਆਮ ਰਿਲੀਜ਼ ਖਤਰਿਆਂ ਨੂੰ ਫੜੋ:

• ਸੁਰੱਖਿਆ: ਨਵੇਂ ਐਂਡਪਾਇੰਟ, ਐਡਮਿਨ-ਕੇਵਲ ਰੂਟ, CORS ਜਾਂ auth ਬਦਲਾਅ, ਅਤੇ ਕੋਈ ਵੀ ਗੁਪਤ ਚੀਜ਼ (API ਕੀਜ਼, ਟੋਕਨ) ਜੋ ਸਾਫ਼ ਟੈਕਸਟ ਵਿੱਚ ਦਿੱਖੇ।
• ਵੈਧਤਾ: ਲਾਜ਼ਮੀ ਫੀਲਡ, ਇਨਪੁਟ ਲੰਬਾਈ ਸੀਮਾਵਾਂ, ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਚੈੱਕ (ਕੇਵਲ UI ਚੈੱਕ ਨਹੀਂ)।
• ਐਰਰ ਹੈਂਡਲਿੰਗ: ਉਪਭੋਗਤਾ ਸੁਨੇਹੇ ਜੋ ਮਤਲਬ ਰੱਖਦੇ ਹਨ, ਨਾਲ ਹੀ ਲੌਗ ਜਿਹੜੇ ਪਾਸਵਰਡ, ਟੋਕਨ, ਜਾਂ ਪੂਰਾ ਨਿੱਜੀ ਡੇਟਾ ਸ਼ਾਮਿਲ ਨਾ ਕਰਨ।
• ਐਕਸੈਸ ਕੰਟਰੋਲ: ਹਰ ਰਿਸੋਰਸ ਲਈ ਪੜ੍ਹਨ, ਬਣਾਉਣ, ਅਪਡੇਟ ਅਤੇ ਮਿਟਾਉਣ ਕੌਣ ਕਰ ਸਕਦਾ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ।
• ਕਾਰਗੁਜ਼ਾਰੀ ਇਸ਼ਾਰੇ: ਕੋਈ ਨਵੀਂ “list all” ਕੁਏਰੀ ਜਾਂ ਰਿਕਾਰਡਾਂ ਉੱਤੇ ਲੂਪ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਵਧ ਸਕਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਲੇਖਕ ਨੂੰ ਆਖੋ ਕਿ ਉਹ ਦਿਖਾਏ ਕਿ ਇਹ ਬਦਲਾਅ ਕਿਸ ਐਪ ਸਕਰੀਨ ਜਾਂ API ਕਾਲ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਡਿਫ ਉਸ ਇਰਾਦੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇੱਕ ਚੰਗੀ ਸਮੀਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ “ਅਸੀਂ ਜੋ ਮੰਗਿਆ ਸੀ” ਨੂੰ “ਜੋ ਬਦਲਿਆ” ਨਾਲ ਮਿਲਾਉਣ ਹੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਪਹੁੰਚ ਵਧਾਉਂਦੀ ਜਾਂ ਮੌਜੂਦਾ ਡੇਟਾ ਨੂੰ ਛੂਹਦੀ ਹੈ ਉਸ ਨੂੰ ਝੰਡਾ ਓਠਾਓ।

ਕਦਮ 3 - ਸਪਸ਼ਟ ਫੈਸਲੇ ਟਰੇਲ ਨਾਲ ਮਰਜ ਕਰੋ

ਮਰਜ ਕਰਨਾ ਉਹ ਸਮਾਂ ਹੈ ਜਦ ਤੁਸੀਂ “ਛੰਗੀ ਸੋਚ” ਨੂੰ “ਨਵਾਂ ਸੱਚ” ਬਣਾਉਂਦੇ ਹੋ। ਇਹ ਨਿਰਸ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਰੱਖੋ। ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਅਖੀਰਲਾ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਸਮੀਖਿਆ ਵਿੱਚ ਕਈ ਆਵਾਜ਼ਾਂ ਹੋਣ।

ਸ਼ੁਰੂ ਕਰੋ ਇੱਕ ਤਿੰਨ ਨਤੀਜਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣ ਕੇ: ਮਨਜ਼ੂਰ, ਬਦਲਾਅ ਮੰਗੋ, ਜਾਂ ਕੰਮ ਨੂੰ ਵੰਡੋ। ਜਦੋਂ ਚੈਟ-ਜਨਰੇਟ ਕੀਤੀ ਅਪਡੇਟ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਛੂਹਦੀ ਹੈ ਜਾਂ ਅਲੱਗ-ਅਲੱਗ ਲਕਸ਼ ਮਿਲਾਉਂਦੀ ਹੈ (ਉਦਾਹਰਨ: ਇੱਕ UI ਟਵੀਕ ਅਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਬਦਲਾਅ), ਵੰਡਣਾ ਅਕਸਰ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੁੰਦੀ ਹੈ।

ਇੱਕ ਛੋਟੀ ਮਰਜ ਨੋਟ ਲਿਖੋ ਜੋ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਤੁਸੀਂ ਕੀ ਚੈੱਕ ਕੀਤਾ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਨਹੀ ਚੈੱਕ ਕੀਤਾ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਡੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜਦ ਕੋਈ ਪੁੱਛੇ, "ਅਸੀਂ ਇਹ ਕਿਉਂ ਸ਼ਿਪ ਕੀਤਾ?" ਇਹ ਉਮੀਦਾਂ ਸੈਟ ਕਰਦਾ ਹੈ ਜੇ ਕਿਸੇ ਖਤਰੇ ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਸਵੀਕਾਰ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇੱਕ ਸਧਾਰਨ ਮਰਜ ਨੋਟ ਇਉਂ ਹੋ ਸਕਦੀ ਹੈ:

• ਫੈਸਲਾ: ਮਨਜ਼ੂਰ / ਬਦਲਾਅ ਮੰਗੇ ਗਏ / ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ
• ਚੈੱਕ ਕੀਤਾ: ਮੁੱਖ ਉਪਭੋਗਤਾ ਫਲੋ, ਐਰਰ ਸੁਨੇਹੇ, env vars, ਮਾਈਗਰੇਸ਼ਨ ਯੋਜਨਾ
• ਨਾ ਚੈੱਕ ਕੀਤਾ: ਲੋਡ ਤਹਿਤ ਪ੍ਰਦਰਸ਼ਨ, ਟਿਕਟ ਤੋਂ ਬਾਹਰ ਦੇ ਐਜ ਕੇਸ
• ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ: 1-2 ਵਾਕਾਂ ਵਿੱਚ ਦੁਹਰਾਓ
• ਪ੍ਰਸਤਾਵ ਤੋਂ ਬਦਲਾਅ: 2-4 ਬੁਲਟ

ਜੇ ਤੁਸੀਂ ਬਦਲਾਅ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੁਹਰਾਓ। “ਇसे ਠੀਕ ਕਰਦੇ ਹੋ” ਜਾਂ “ਇਸਨੂੰ ਬਿਹਤਰ ਬਣਾਓ” ਵਰਗੇ ਅਣਸਪਸ਼ਟ ਹੁਕਮਾਂ ਤੋਂ ਬਚੋ। ਕਹੋ ਕਿ “ਮੁਕੰਮਲ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਉਦਾਹਰਨ: “ਸਾਈਨਅਪ ਫਾਰਮ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਐਰਰ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜੇ ਈਮੇਲ ਪਹਿਲਾਂ ਵਰਤੀ ਜਾ ਚੁਕੀ ਹੋਵੇ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਕੋਈ ਨਵਾਂ ਯੂਜ਼ਰ ਰਿਕਾਰਡ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ”)।

ਇੱਕ ਛੋਟਾ ਚੇਂਜ ਲੌਗ ਰੱਖੋ ਜੋ ਮੂਲ ਪ੍ਰਸਤਾਵ ਤੋਂ ਕੀ ਬਦਲਿਆ ਇਹ ਟ੍ਰੈਕ ਕਰੇ। Koder.ai 'ਤੇ ਇਹ ਸਧਾਰਨ ਹੋ ਸਕਦਾ ਹੈ: ਕਿਹੜਾ snapshot ਜਾਂ ਡਿਫ ਸੈਟ ਪਹਿਲੇ ਵਾਲੇ ਦੀ ਥਾਂ ਆਇਆ, ਅਤੇ ਕਾਰਨ (ਉਦਾਹਰਨ: "ਗੈਰ-ਵਰਤਿਆ ਗਿਆ API ਕਾਲ ਹਟਾਇਆ ਗਿਆ; ਵੈਧਤਾ ਸੁਨੇਹਾ ਜੋੜਿਆ; ਬਟਨ ਲੇਬਲ ਨਾਂ ਬਦਲੀ")।

ਕਦਮ 4 - ਬਿਨਾਂ ਅਚਾਨਕੀਆਂ ਦੇ ਡਿਪਲੋ ਕਰੋ (ਅਤੇ ਰੋਲਬੈਕ ਲਈ ਤਿਆਰ ਰਹੋ)

ਡਿਪਲੋ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਜਨਤਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ, ਬੇਹਦ ਤੇਜ਼ੀ ਨਾਲ ਮੁੱਖ ਚੈਕ ਕਰੋ, ਅਤੇ ਵਾਪਸ ਜਾਣ ਦਾ ਸਪਸ਼ਟ ਤਰੀਕਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਕਦਮ ਲਗਾਤਾਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ ਹਲਕਾ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਸ਼ਾਂਤ ਰਹਿੰਦਾ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਰਹੇ ਹੋ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਾਤਾਵਰਣ (ਪ੍ਰਿਵਿਊ ਜਾਂ ਸਟੇਜਿੰਗ) ਹੈ, ਪਹਿਲਾਂ ਉੱਥੇ ਡਿਪਲੋ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ ਡਰੈਸ ਰਿਹਰਸਲ ਸਮਝੋ: ਇੱਕੋ ਹੀ ਸੈਟਿੰਗਾਂ, ਇੱਕੋ ਹੀ ਡੇਟਾ ਸ਼ੇਪ (ਜਿੰਨਾ ਹੋ ਸਕੇ ਨੇੜੇ), ਅਤੇ ਉਹੀ ਕਦਮ ਜੋ ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਵਰਤੋਂਗੇ। Koder.ai 'ਤੇ, ਇਹ ਵੀ ਬਦੀਆ ਸਮਾਂ ਹੈ ਕਿ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੈਪਸ਼ੌਟ ਲਓ ਤਾਂ ਕਿ ਤੁਸੀਂ ਜਾਣ-ਮਾਨੂ ਹਾਲਤ 'ਤੇ ਵਾਪਸ ਜਾ ਸਕੋ।

ਡਿਪਲੋ ਦੇ ਬਾਅਦ ਤੁਰੰਤ 5-ਮਿੰਟ ਦਾ smoke test ਕਰੋ। ਇਸਨੂੰ ਬੋoring਼ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਯੋਗ ਰੱਖੋ:

• ਕੀ ਤੁਸੀਂ ਲੌਗਇਨ ਅਤੇ ਲੌਗਆਉਟ ਕਰ ਸਕਦੇ ਹੋ?
• ਕੀ ਤੁਸੀਂ ਮੁੱਖ ਪੰਨਿਆਂ ਤੱਕ ਬਿਨਾਂ ਐਰਰ ਦੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ?
• ਕੀ ਮੁੱਖ ਫਾਰਮ 제출 ਹੁੰਦਾ ਹੈ (ਅਤੇ ਸਫਲਤਾ ਸੁਨੇਹਾ ਦਿਖਦਾ ਹੈ)?
• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਭੁਗਤਾਨ ਹਨ, ਕੀ ਤੁਸੀਂ ਇੱਕ ਟੈਸਟ ਖਰੀਦ ਜਾਂ ਭੁਗਤਾਨ ਕਦਮ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ?
• ਕੀ ਤੁਸੀਂ ਐਡਮਿਨ ਜਾਂ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਉਮੀਦ ਕੀਤਾ ਗਿਆ ਰਿਕਾਰਡ/ਅਪਡੇਟ ਦੇਖਦੇ ਹੋ?

ਇੱਕ ਘੱਟ-ਖਤਰੇ ਸਮਾਂ ਵਿਂਡੋ ਚੁਣੋ (ਅਕਸਰ ਦਿਨ ਦੀ ਸ਼ੁਰੂਆਤ), ਅਤੇ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ ਮਾਲਕ ਨਾਮਿਤ ਕਰੋ। ਉਹ ਮਾਲਕ ਪਹਿਲੇ ਸੰਕੇਤਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ।

ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲੋ ਦੇ ਬਾਅਦ ਅਸਲੀ ਸੰਕੇਤਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਸਿਰਫ਼ "ਪੰਨਾ ਲੋਡ ਹੋ ਰਿਹਾ ਹੈ" ਨਹੀਂ। ਨਵੇਂ ਸਬਮਿਸ਼ਨ ਅਜੇ ਵੀ ਆ ਰਹੇ ਹਨ, ਭੁਗਤਾਨ ਘਟਨਾਵਾਂ ਹੋ ਰਹੀਆਂ ਹਨ, ਈਮੇਲ ਭੇਜੇ ਜਾ ਰਹੇ ਹਨ, ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਰਿਪੋਰਟਸ ਅਪਡੇਟ ਹੋ ਰਹੀਆਂ ਹਨ ਇਹ ਚੈਕ ਕਰੋ। ਇਨਬੌਕਸ, ਭੁਗਤਾਨ ਪ੍ਰੋਵਾਇਡਰ ਦੇ ਵਿਊ ਅਤੇ ਐਪ ਦੇ ਐਡਮਿਨ ਸਕਰੀਨ ਵਿੱਚ ਇੱਕ ਤੇਜ਼ ਸਪਾਟ-ਚੈਕ ਆਟੋਮੈਟਿਕ ਜਾਂਚਾਂ ਨੂੰ ਛੱਡ ਦੇਂਦਾ ਹੈ।

ਡਿਪਲੋ ਬਾਹਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਰੋਲਬੈਕ ਯੋਜਨਾ ਰੱਖੋ: ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ "ਖਰਾਬ" ਕੀ ਦਿਖਦਾ ਹੈ (ਐਰਰਾਂ ਵਿੱਚ spike, ਸਾਈਨਅਪ ਵਿੱਚ ਘਾਟ, ਗਲਤ ਟੋਟਲ), ਅਤੇ ਤੁਸੀਂ ਕੀ ਵਾਪਸ ਕਰੋਗੇ। ਜੇ ਤੁਸੀਂ snapshot ਜਾਂ rollback Koder.ai 'ਤੇ ਵਰਤਿਆ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ, ਫਿਰ ਕਿਸੇ ਛੋਟੇ ਫਾਲੋਅਪ ਚੇਂਜ ਨਾਲ ਅੱਗੇ ਫਿਕਸ ਕਰੋ ਜਿਸ ਵਿੱਚ ਨੋਟਾਂ ਰਹਿਣ।

ਆਮ ਫੰਦ ਜੋ ਹਲਕੇ ਵਰਕਫਲੋ ਨੂੰ ਨਾਕਾਮ ਕਰਦੇ ਹਨ

ਅਧਿਕਤਰ “ਹਲਕੇ” ਵਰਕਫਲੋ ਇੱਕੋ ਹੀ ਕਾਰਨ ਲਈ ਟੁੱਟਦੇ ਹਨ: ਕਦਮ ਸਧਾਰਨ ਹਨ, ਪਰ ਉਮੀਦਾਂ ਸਪਸ਼ਟ ਨਹੀਂ। ਜਦ ਲੋਕ unsure ਹੁੰਦੇ ਹਨ ਕਿ “ਮੁਕੰਮਲ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਸਮੀਖਿਆ बहस ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਆਮ ਵਿਫਲਤਾ ਸਾਫ acceptance criteria ਛੱਡ ਦੇਣਾ ਹੈ। ਜੇ ਪ੍ਰਸਤਾਵ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕੀ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੀ ਨਹੀਂ ਬਦਲਣਾ, ਅਤੇ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਨੀ ਹੈ, ਤਾਂ ਸਮੀਖਿਆਕਾਰ ਪਸੰਦਾਂ ਬਾਰੇ बहਸ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਵਾਕ ਜਿਵੇਂ “ਉਪਭੋਗਤਾ ਲੌਗਿਨ ਸਕਰੀਨ ਤੋਂ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਮੌਜੂਦਾ ਲੌਗਿਨ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ” ਬਹੁਤ ਸਾਰਾ ਬਹਿਸ ਰੋਕ ਸਕਦਾ ਹੈ।

ਦੂਜਾ ਫੰਦ ਕੇਵਲ ਜੋ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਉਸ ਦੀ ਸਮੀਖਿਆ ਕਰਨਾ ਹੈ। ਇੱਕ ਚੈਟ-ਜਨਰੇਟ ਕੀਤਾ ਬਦਲਾਅ ਇੱਕ ਛੋਟਾ UI ਸੋਧ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਬੈਕਐਂਡ ਲਾਜਿਕ, ਪਰਮਿਸ਼ਨ, ਜਾਂ ਡੇਟਾ ਨੂੰ ਵੀ ਛੂਹ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਡਿਫਸ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਸਕ੍ਰੀਨ ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਫਾਇਲਾਂ ਲਈ ਸਕੈਨ ਕਰੋ (API ਰੂਟ, ਡੇਟਾਬੇਸ ਕੋਡ, auth ਨਿਯਮ)। ਜੇ ਤੁਸੀਂ ਅਣਉਮੀਦ ਖੇਤਰਾਂ ਦੇ ਬਦਲਾਅ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਠਹਿਰੋ ਅਤੇ ਪੁੱਛੋ ਕਿਉਂ।

ਵੱਡੇ ਮਿਲੇ-ਜੁਲੇ ਬਦਲਾਅ ਵੀ ਵਰਕਫਲੋ ਨੂੰ ਨਾਸ਼ ਕਰ ਦਿੰਦੇ ਹਨ। ਜਦ ਇਕ ਬਦਲਾਅ UI ਅਪਡੇਟ, auth ਬਦਲਾਅ ਅਤੇ ਡੇਟਾਬੇਸ ਮਾਈਗਰੇਸ਼ਨ ਇੱਕਠੇ ਹੋਵੇ, ਤਾਂ ਇਸਨੂੰ ਸਮੀਖਿਆ ਕਰਨਾ ਅਤੇ ਰੋਲਬੈਕ ਕਰਨਾ ਦੋਹਾਂ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਬਦਲਾਅ ਛੋਟੇ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰ ਸਕੋ। ਨਹੀਂ ਤੇ, ਉਹਨਾਂ ਨੂੰ ਵੰਡੋ।

"ਇਹ ਠੀਕ ਲੱਗਦਾ ਹੈ" ਨਾਲ ਮਨਜ਼ੂਰ ਕਰਨਾ ਬਿਨਾਂ ਤੇਜ਼ smoke test ਦੇ ਖਤਰਨਾਕ ਹੈ। ਮਰਜ ਜਾਂ ਡਿਪਲੋ ਤੋਂ ਪਹਿਲਾਂ, ਮੁੱਖ ਰਸਤਾ ਕੰਮ ਕਰਦਾ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ: ਪੰਨਾ ਖੋਲ੍ਹੋ, ਮੁੱਖ ਐਕਸ਼ਨ ਕਰੋ, ਰਿਫ੍ਰੈਸ਼ ਕਰੋ, ਅਤੇ ਇੱਕ ਨਿੱਜੀ/ਇਨਕੋਗਨਿਟੋ ਵਿੰਡੋ ਵਿੱਚ ਇੱਕ ਵਾਰੇ ਦੁਹਰਾਓ। ਜੇ ਇਹ ਭੁਗਤਾਨ, ਲੌਗਿਨ, ਜਾਂ ਸਾਈਨ-ਅਪ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ।

ਅੰਤ ਵਿੱਚ, ਡਿਪਲੋਜ਼ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦ ਕੋਈ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਉਸ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ deploy owner ਬਣਾਓ। ਉਹ ਡਿਪਲੋ ਨੂੰ ਦੇਖਦਾ, ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ smoke test ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ, ਅਤੇ ਤੇਜ਼ ਫੈਸਲਾ ਲੈਂਦਾ: ਅਗੇ ਫਿਕਸ ਕਰਨਾ ਜਾਂ ਰੋਲਬੈਕ (snapshots ਅਤੇ rollback Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇਹ ਬਹੁਤ ਘੱਟ ਤਣਾਓ ਵਾਲਾ ਬਣਾਉਂਦਾ ਹੈ)।

ਇੱਕ ਤੇਜ਼ pre-deploy ਚੈੱਕਲਿਸਟ (ਕਾਪੀ ਅਤੇ ਪੇਸਟ ਲਈ)

ਇਸ ਨੂੰ ਆਪਣੀ ਰਿਲੀਜ਼ ਨੋਟ ਜਾਂ ਚੈਟ ਧਾਗੇ ਵਿੱਚ ਕਾਪੀ ਕਰੋ ਅਤੇ ਭਰੋ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਜਾਵੇ।

ਪ੍ਰਸਤਾਵ (2-3 ਵਾਕ):

• ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ?
• ਇਹ ਕਿਸ ਲਈ ਹੈ?
• ਇਹ ਕਿਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ?

ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ (3-7):

• [ ]
• [ ]
• [ ]

ਡਿਪਲੋ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਜਨਰੇਟ ਡਿਫ 'ਤੇ ਇੱਕ ਤੇਜ਼ ਨਜ਼ਰ ਮਾਰੋ। ਤੁਸੀਂ ਕੋਡ ਸਟਾਈਲ ਦਾ ਨਿਰਣਾ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਸੀਂ ਜੋਖਮ ਲਈ ਚੈੱਕ ਕਰ ਰਹੇ ਹੋ।

ਡਿਫ ਸਮੀਖਿਆ (ਤੁਸੀਂ ਜੋ ਚੈੱਕ ਕੀਤਾ ਉਸ 'ਤੇ ਟਿਕ ਕਰੋ):

• ਪਰਮਿਸ਼ਨ ਅਤੇ ਪਹੁੰਚ: ਇਸ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕੌਣ ਦੇਖ/ਸੰਪਾਦਨ/ਮਿਟਾ ਸਕਦਾ ਹੈ?
• ਡੇਟਾ ਬਦਲਾਅ: ਨਵੀਆਂ ਫੀਲਡਾਂ, ਮਿਟਾਈ ਹੋਈ ਫੀਲਡਾਂ, ਮਾਈਗਰੇਸ਼ਨ, ਡਿਫਾਲਟ, ਡੇਟਾ ਬੈਕਫਿੱਲ
• ਕੰਫਿਗ ਅਤੇ ਸਿੱਟੇ: ਵਾਤਾਵਰਣ ਵੈਰੀਏਬਲ, API ਕੀਜ਼, ਫੀਚਰ ਫਲੈਗ, CORS, ਰੇਟ ਲਿਮਿਟ
• ਬਾਹਰੀ ਇੰਟੀਗਰੇਸ਼ਨ: ਭੁਗਤਾਨ, ਈਮੇਲ, ਐਨਾਲਿਟਿਕਸ, webhook, SSO, ਸਟੋਰੇਜ ਬਕੈਟ

ਫਿਰ ਉਹ ਜੋ ਉਪਭੋਗਤਾ ਪੜ੍ਹੇਗੇ ਉਸ ਨੂੰ ਚੈੱਕ ਕਰੋ। ਛੋਟੀਆਂ ਕਾਪੀ ਦੀਆਂ ਗਲਤੀਆਂ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਖ਼ਰਾਬ ਮਹਿਸੂਸ ਕਰਾਉਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹਨ।

ਕਾਪੀ ਸਮੀਖਿਆ:

• ਮੁੱਖ ਸਕਰੀਨ: ਸਿਰਲੇਖ, ਬਟਨ ਟੈਕਸਟ, ਖਾਲੀ ਸਥਿਤੀਆਂ, ਐਰਰ
• ਈਮੇਲ/ਨੋਟੀਫਿਕੇਸ਼ਨ: ਵਿਸ਼ਾ ਲਾਈਨ, ਭੇਜਣ ਵਾਲੇ ਦਾ ਨਾਮ, ਲਿੰਕ, ਅਨਸਬਸਕ੍ਰਾਈਬ ਜਾਂ ਪਸੰਦਾਂ ਟੈਕਸਟ (ਜੇ ਲਾਗੂ)

ਇੱਕ ਛੋਟਾ smoke test ਯੋਜਨਾ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਤਿਆਰ ਨਹੀਂ ਹੋ ਸ਼ਿਪ ਕਰਨ ਲਈ।

Smoke tests (3-5):

• [ ]
• [ ]
• [ ]

ਅੰਤ ਵਿੱਚ, ਰੋਲਬੈਕ ਪਾਥ ਅਤੇ ਉਸ ਵਿਅਕਤੀ ਦਾ ਨਾਮ ਦਿਓ ਜੋ ਇਹ ਕਰੇਗਾ। Koder.ai 'ਤੇ, ਇਹ "ਪਿਛਲੇ ਸਨੈਪਸ਼ੌਟ 'ਤੇ ਰੋਲਬੈਕ" ਵਰਗਾ ਸਾਦਾ ਹੋ ਸਕਦਾ ਹੈ।

Rollback ਯੋਜਨਾ:

• ਮਾਲਕ: @________
• ਰੋਲਬੈਕ ਲਈ trigger (ਸਾਨੂੰ ਕਿਹੜੀ ਚੀਜ਼ ਵਾਪਸ ਲੈਣ 'ਤੇ ਮਜਬੂਰ ਕਰੇਗੀ?): ________
• ਕਿਵੇਂ ਰੋਲਬੈਕ ਕਰਨਾ ਹੈ: ________
• ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਾਂਗੇ ਕਿ recovery ਹੋ ਗਈ: ________

ਉਦਾਹਰਨ: ਇੱਕ ਗੈਰ-ਇੰਜੀਨੀਅਰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ ਅੰਤ ਤੱਕ ਭੇਜਦਾ ਹੈ

Maya ਇਕ ਮਾਰਕੇਟਿੰਗ ਮੈਨੇਜਰ ਹੈ। ਉਸਨੂੰ ਸਾਈਟ 'ਤੇ ਤਿੰਨ ਅੱਪਡੇਟਾਂ ਦੀ ਲੋੜ ਹੈ: ਕੀਮਤ ਟੇਬਲ ਰਿਫਰੇਸ਼, Pricing ਪੰਨਾ 'ਤੇ ਲੀਡ ਫਾਰਮ ਜੋੜਨਾ, ਅਤੇ ਨਵੇਂ ਲੀਡਾਂ ਨੂੰ ਮਿਲਣ ਵਾਲੀ ਪੁਸ਼ਟੀਕਰਨ ਈਮੇਲ ਅਪਡੇਟ ਕਰਨੀ। ਉਹ Koder.ai ਵਰਤਦੀ ਹੈ ਬਦਲਾਅ ਕਰਨ ਲਈ, ਪਰ ਫਿਰ ਵੀ ਹਲਕੇ ਅਨੁਮੋਦਨ ਵਰਕਫਲੋ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਰਿਲੀਜ਼ ਸੁਰੱਖਿਅਤ ਰਹੇ।

1) ਪ੍ਰਸਤਾਵ (ਇਰਾਦਾ ਸਮੀਖਿਆਯੋਗ ਬਣਾਓ)

Maya ਇੱਕ ਛੋਟਾ ਪ੍ਰਸਤਾਵ ਇਕ ਸੁਨੇਹੇ ਵਿੱਚ ਲਿਖਦੀ ਹੈ: ਕੀ ਬਦਲਣਾ ਚਾਹੀਦਾ, ਕੀ ਨਹੀਂ ਬਦਲਣਾ, ਅਤੇ ਐਜ ਕੇਸ। ਉਦਾਹਰਨ ਲਈ: ਕੀਮਤ ਨੰਬਰ ਤਾਜ਼ੀ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋਣ, ਲੀਡ ਫਾਰਮ ਨੂੰ ਇੱਕ ਵਾਸ਼ਤ ਈਮੇਲ ਲਾਜ਼ਮੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਸਬਸਕ੍ਰਾਈਬਰਾਂ ਨੂੰ ਡੁਪਲਿਕੇਟ ਪੁਸ਼ਟੀਆਂ ਨਹੀਂ ਮਿਲਣੀਆਂ।

ਉਹ ਓਖੇ ਮਾਮਲੇ ਵੀ ਦਰਸਾਈਦੀ ਹੈ: ਗੁੰਮ ਈਮੇਲ, ਝੱਟ ਪੜਨ ਵਾਲਾ ਸਪੈਮ ਟੈਕਸਟ, ਅਤੇ ਇਕੋ ਪਤੇ ਤੋਂ ਦੁਹਰਾਈ ਜਮਾਵਟ।

2) ਜਨਰੇਟ ਡਿਫਸ ਦੀ ਸਮੀਖਿਆ (ਜੋਖਮ 'ਤੇ ਧਿਆਨ)

ਉਸ ਦਾ ਸਮੀਖਿਆਕਾਰ ਹਰ ਲਾਈਨ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹ ਉਹ ਹਿੱਸੇ ਵੇਖਦਾ ਜੋ ਰੇਵਨਿਊ ਜਾਂ ਭਰੋਸੇ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹਨ:

• ਫਾਰਮ ਵੈਧਤਾ: ਲਾਜ਼ਮੀ ਫੀਲਡ, ਸਾਫ਼ ਐਰਰ ਸੁਨੇਹੇ, ਮੂਲ ਸਪੈਮ ਰੋਕਥਾਮ
• ਈਮੇਲ ਭੇਜਣਾ: ਸਹੀ ਟੈਮਪਲੇਟ, ਵਿਸ਼ਾ, ਅਤੇ "from" ਨਾਮ; ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਭੇਜ ਨਾ ਹੋਵੇ
• ਡੇਟਾ ਸਟੋਰੇਜ: ਜਿੱਥੇ ਜਮਾਵਟ ਸੇਵ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਹੜੀਆਂ ਫੀਲਡਾਂ ਇਕੱਠੀਆਂ ਹੋ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਕੋਈ ਸੰਵੇਦਨਸ਼ੀਲ ਚੀਜ਼ ਗਲਤੀ ਨਾਲ ਸਟੋਰ ਤਾਂ ਨਹੀਂ ਹੋ ਰਹੀ
• ਡੁਪਲਿਕੇਟ: ਜੇ ਇੱਕੋ ਈਮੇਲ ਦੁਹਰਾਈ ਦੇਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ

ਜੇ ਕੁਝ ਅਸਪਸ਼ਟ ਹੋਵੇ, ਸਮੀਖਿਆਕਾਰ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗਦਾ ਹੈ ਜੋ ਡਿਫ ਨੂੰ ਸਮਝਣ ਯੋਗ ਬਣਾਏ (ਉਦਾਹਰਨ: data2 ਨੂੰ leadSubmission ਨਾਮ ਦੇਣਾ)।

3) ਮਰਜ ਅਤੇ ਡਿਪਲੋ (ਉਪਭੋਗਤਾ ਵਾਂਗ ਪੜ੍ਹ ਕੇ ਪੁਸ਼ਟੀ)

ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ, Maya ਡਿਪਲੋ ਕਰਦੀ ਅਤੇ ਇੱਕ ਤੇਜ਼ ਹਕੀਕਤ-ਚੈੱਕ ਚਲਾਉਂਦੀ:

• ਇੱਕ ਅਸਲੀ ਅਤੇ ਇੱਕ ਨਕਲੀ ਈਮੇਲ ਨਾਲ ਫਾਰਮ ਸਬਮਿਟ ਕਰੋ
• ਪੁਸ਼ਟੀਕਰਨ ਈਮੇਲ ਆਉਂਦੀ ਹੈ ਅਤੇ ਠੀਕ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ
• ਐਡਮਿਨ ਲਿਸਟ (ਜਾਂ ਸੇਵ ਕੀਤੇ ਐਂਟ੍ਰੀ) ਚੈਕ ਕਰੋ ਕਿ ਸਬਮਿਸ਼ਨ ਇੱਕ ਵਾਰੀ ਹੀ ਦਰਜ ਹੈ

ਜੇ ਸਬਮਿਸ਼ਨਾਂ ਵਿੱਚ ਅਚਾਨਕ ਘਟੋਤਰੀ ਜਾਂ ਪੁਸ਼ਟੀਕਰਨ ਈਮੇਲ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਉਹ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ ਹੁੰਦਾ ਹੈ। Koder.ai ਸਨੈਪਸ਼ੌਟ ਅਤੇ ਰੋਲਬੈਕ ਨਾਲ, ਉਹ ਪਹਿਲਾਂ ਪਿਛਲੇ ਜਾਣ-ਚੰਗੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਕਰਦੀ ਅਤੇ ਫਿਰ ਛੋਟੀ follow-up ਸੋਧ ਦੇ ਨਾਲ ਅੱਗੇ ਵਧਦੀ ਹੈ।

ਅਗਲੇ ਕਦਮ: ਇਸਨੂੰ ਆਪਣੀ ਟੀਮ ਲਈ ਡੀਫੌਲਟ ਫਲੋ ਬਣਾਓ

ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਕੇ ਵਰਕਫਲੋ ਨੂੰ ਅਦਤ ਬਣਾਓ। ਹਰ ਲਿਖਤ ਦੀ ਸੋਧ ਲਈ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਸ਼ੁਰੂਆਤ ਕਰੋ ਇਹਮਾਤਰ ਦੂਜੇ ਵਿਅਕਤੀ ਦੀ ਜਾਂਚ ਦੀ ਲੋੜ ਤਾਂ ਹੀ ਜਦ ਬਦਲਾਅ ਲੌਗਿਨ, ਪੈਸਾ, ਜਾਂ ਡੇਟਾ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਤੇਜ਼ੀ ਤੇਜ਼ੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਜੋਖਮ ਹੇਠਾਂ ਰਹਿੰਦੇ ਹਨ।

ਟੀਂ ਨਿਯਮ ਜੋ ਟੀਮਾਂ ਪਾਲਨ ਕਰਦੀਆਂ ਹਨ:

• ਬੈਕਐਂਡ ਲਾਜਿਕ, ਡੇਟਾਬੇਸ ਬਦਲਾਅ, auth, ਅਤੇ ਭੁਗਤਾਨ ਲਈ ਸਮੀਖਿਆ ਜ਼ਰੂਰੀ
• ਕਾਪੀ, ਲੇਆਊਟ ਟਵੀਕ, ਅਤੇ ਛੋਟੇ UI ਪੋਲਿਸ਼ ਲਈ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਨਹੀਂ
• ਜੇ ਅਣਿਸ਼ਚਿਤ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਸਮੀਖਿਆ-ਲਾਜ਼ਮੀ ਸਮਝੋ

ਬੇਵਕੂਫ਼ੀ ਭਰੀ ਬੇਨਤੀ ਘਟਾਉਣ ਲਈ, ਕਿਸੇ ਵੀ ਬਣਾਉਣ ਦੇ ਕੰਮ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਤੀ ਪ੍ਰਸਤਾਵ ਦੀ ਲੋੜ ਰੱਖੋ। Koder.ai 'ਤੇ, Planning Mode ਇੱਕ ਵਧੀਆ ਫੋਰਸਿੰਗ ਫੰਕਸ਼ਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਚੈਟ ਬਿਨੈ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਜੋ ਕੋਈ ਹੋਰ ਪੜ੍ਹ ਕੇ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕੇ। ਪ੍ਰਸਤਾਵ ਛੋਟਾ ਰੱਖੋ: ਕੀ ਬਦਲ ਰਿਹਾ, ਕੀ ਇਕੋ ਹੀ ਰਹਿੰਦਾ, ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਟੈਸਟ ਕਰੋਗੇ।

ਡਿਪਲੋ ਸਮੇਂ ਸੁਰੱਖਿਆ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਓ, ਨਾ ਕਿ ਇੱਕ ਬਾਅਦ ਵਾਲੀ ਸੋਚ। ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ੌਟ ਵਰਤੋ, ਅਤੇ ਇਹ ਮੰਨ ਲਓ ਕਿ ਰੋਲਬੈਕ ਇੱਕ ਨਾਕਾਮੀ ਨਹੀਂ ਹੈ—ਜਦ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ ਠੀਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ। ਜੇ ਕਿਸੇ ਡਿਪਲੋ ਨੇ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਦਿੱਤਾ, ਪਹਿਲਾਂ ਰੋਲਬੈਕ ਕਰੋ, ਫਿਰ ਜਾਂਚ ਕਰੋ।

ਅਖੀਰ ਵਿੱਚ, ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਦੁਹਰਾਏ ਜਾ ਸਕਨ ਯੋਗ ਰੱਖੋ। ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨ ਨਾਲ ਆਡੀਟ, ਵੇਂਡਰ ਸਮੀਖਿਆ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਵਾਤਾਵਰਣ 'ਚ ਕੰਮ ਮੂਵ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਰਹਿੰਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਟੀਮ ਵਜੋਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਸ ਫਲੋ ਨੂੰ ਆਪਣੇ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਕਾਰਜ ਵਿੱਚ ਲਿਖੋ (ਕਿਸੇ ਵੀ ਟੀਅਰ: free, pro, business, ਜਾਂ enterprise)। ਇੱਕ ਸਾਂਝੀ ਆਦਤ ਲੰਬੀ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ ਤੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ।