08 ਜਨ 2026·8 ਮਿੰਟ
ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ: ਵੱਡੀਆਂ ਐਪ ਬਦਲਾਵਾਂ ਲਈ ਸੇਵ-ਪਾਇੰਟ
ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸਿੱਖੋ ਤਾਂ ਜੋ auth rewrites, ਸਕੀਮਾ ਅਪਡੇਟਾਂ ਅਤੇ UI ਰੀਡਿਜ਼ਾਈਨਾਂ ਵਾਂਗ ਵੱਡੇ ਬਦਲਾਅ ਦੌਰਾਨ ਸੁਰੱਖਿਅਤ ਸੇਵ-ਪਾਇੰਟ ਬਣਾਏ ਜਾ ਸਕਣ — ਸਪਸ਼ਟ ਲੇਬਲਿੰਗ ਅਤੇ ਚੈੱਕਸ ਸਮੇਤ।
ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸਿੱਖੋ ਤਾਂ ਜੋ auth rewrites, ਸਕੀਮਾ ਅਪਡੇਟਾਂ ਅਤੇ UI ਰੀਡਿਜ਼ਾਈਨਾਂ ਵਾਂਗ ਵੱਡੇ ਬਦਲਾਅ ਦੌਰਾਨ ਸੁਰੱਖਿਅਤ ਸੇਵ-ਪਾਇੰਟ ਬਣਾਏ ਜਾ ਸਕਣ — ਸਪਸ਼ਟ ਲੇਬਲਿੰਗ ਅਤੇ ਚੈੱਕਸ ਸਮੇਤ।
ਸਨੈਪਸ਼ਾਟ ਤੁਹਾਡੇ ਐਪ ਦੀ ਇੱਕ ਸੰਭਾਲੀ ਹੋਈ ਹਾਲਤ ਹੁੰਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ। ਇਸਨੂੰ ਇਕ ਖੇਡ ਦੇ ਸੇਵ-ਪਾਇੰਟ ਵਾਂਗ ਸੋਚੋ: ਤੁਸੀਂ ਕੋਈ ਖਤਰਨਾਕ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜੇ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਉਸ ਵਕਤ ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ ਜਦੋਂ ਸਭ ਚੀਜ਼ਾਂ ਠੀਕ ਕੰਮ ਕਰ ਰਹੀਆਂ ਸਨ।
ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਬਦਲਾਅ ਅਤੇ ਵੱਧ ਵਾਰਤੋਂ ਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ। ਇਹ ਗਤੀ ਫਾਇਦੇਮੰਦ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਇਸ ਗੱਲ ਦਾ ਖਤਰਾ ਵੀ ਵਧ ਜਾਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਜੇਹੀ ਅਵਸਥਾ ਵਿੱਚ ਪਹੁੰਚ ਜਾਓ ਜਿੱਥੇ ਅਧ-ਟੁੱਟੇ ਹਾਲਤਾਂ ਹੋਣ ਅਤੇ “ਆਖਰੀ ਚੰਗਾ ਵਰਜ਼ਨ” ਕੁਝ ਸਮਝ ਨਾ ਆਵੇ। ਸਨੈਪਸ਼ਾਟ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ਼ ਰਾਹ-ਬਚਾਵ ਦਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਘਬਰਾਏ ਬਿਨਾਂ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ ਕਿਸੇ ਜਾਣੇ-ਪਹਚਾਣੇ ਚੰਗੇ ਪੁਆਇੰਟ 'ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ।
ਇਹ ਵਧੇਰੇ ਅਹਿਮ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਅਜਿਹੇ ਬਦਲਾਅ ਹੋ ਰਹੇ ਹੋਣ ਜੋ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਨਾਲ ਪੂਰੇ ਐਪ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ auth rewrite (ਨਵਾਂ ਲੌਗਿਨ ਫਲੋ, ਨਵੇਂ ਰੋਲ, ਨਵੀਂ ਟੋਕੇਨ ਹੈਂਡਲਿੰਗ), ਡੇਟਾਬੇਜ਼ ਸਕੀਮਾ ਬਦਲਾਅ (ਟੇਬਲਾਂ ਦਾ ਨਾਮ ਬਦਲਣਾ, ਕਾਲਮ ਵੰਡਣਾ, ਸੰਬੰਧਾਂ ਨੂੰ ਬਦਲਣਾ), ਜਾਂ UI ਰੀਡਿਜ਼ਾਈਨ (ਨਵੇਂ ਲੇਆਊਟ ਕੰਪੋਨੈਂਟ, ਨਵੀਂ ਰਾਊਟਿੰਗ, ਨਵੀਂ ਸਟੇਟ ਲਾਜਿਕ) ਇੱਕ ਜਗ੍ਹਾ 'ਤੇ ਠੀਕ ਦਿਸ ਸਕਦੇ ਹਨ ਪਰ ਚਪਕੇ-ਚਪਕੇ ਪੰਜ ਹੋਰ ਥਾਵਾਂ 'ਤੇ ਟੂਟ-ਫੁਟ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਅਜਿਹੇ ਨਹੀਂ ਚੈੱਕ ਕੀਤੀਆਂ।
ਰੋਲਬੈਕ ਇਸ ਵਿਚਾਰ ਦਾ ਦੂਜਾ ਹਿੱਸਾ ਹੈ। ਰੋਲਬੈਕ "ਆਖਰੀ ਕਲਿਕ ਰੱਦ ਕਰੋ" ਨਹੀਂ ਹੈ। ਇਹ "ਜਾਣੇ-ਪਹਚਾਣੇ ਚੰਗੇ ਹਾਲਤ 'ਤੇ ਵਾਪਸ ਆਓ" ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹੋਏ ਸ਼ਿਪ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਚੈਟ ਰਾਹੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਰਫਤਾਰ ਹੋਰ ਵੀ ਤੇਜ਼ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਨਾਲ ਸਨੈਪਸ਼ਾਟ ਦੀ ਕੀਮਤ ਹੋਰ ਵਧ ਜਾਂਦੀ ਹੈ: ਤੁਸੀਂ ਵੱਡਾ ਬਦਲਾਅ ਮੰਗ ਸਕਦੇ ਹੋ, ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜੇ ਠੀਕ ਨਹੀਂ ਤਾਂ ਰੋਲਬੈਕ ਕਰਕੇ ਇੱਕ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਆਪਣਾ ਕੰਮ ਖੋਏ।
ਸਨੈਪਸ਼ਾਟ ਸਭ ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਓਸ ਵੇਲੇ ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ ਹੋ ਜੋ ਵਾਪਸ ਕਰਨਾ ਔਖਾ ਹੈ। "ਪਹਾਂ ਜ਼ਿੰਮੇਵਾਰੀ ਦੀ ਲਾਈਨ" ਤੋਂ ਪਹਿਲਾਂ ਲੈਣੇ ਦੀ ਸੋਚੋ। ਅਮਲ ਵਿੱਚ, ਸਨੈਪਸ਼ਾਟ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਪਰਿਸਥਿਤੀਆਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਸਾਬਿਤ ਕਰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਹੋ ਕਿ ਕੁਝ ਕਿੰਨਾ ਖਤਰਨਾਕ ਹੈ, ਤਾਂ ਇਸ ਭਾਵ ਨੂੰ ਦੇਖੋ: “ਬਹੁਤ ਕੁਝ ਬਦਲ ਰਿਹਾ ਹੈ ਅਤੇ ਮੈਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਰਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕਰ ਸਕਦਾ।” ਅਸਪੱਸ਼ਟ ਮੰਗਾਂ, ਨਵੀਆਂ ਲਾਇਬਰੇਰੀਆਂ, ਵਿਆਪਕ ਰਿਫੈਕਟਰ, ਅਤੇ ਡੈਡਲਾਈਨ ਦਾ ਦਬਾਅ — ਇਹ ਸਾਰੇ ਸਨੈਪਸ਼ਾਟ ਲਈ ਚੰਗੇ ਕਾਰਨ ਹਨ। ਜਦੋਂ ਕਈ ਲੋਕ ਇੱਕੇ ਹੀ ਖੇਤਰ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋਣ ਤਾਂ ਵੀ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਵਾਜਬ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਪ੍ਰਗਤੀ ਹੋਰਾਂ ਨੂੰ ਰੋਕਣੀ ਨਹੀਂ ਚਾਹੀਦੀ।
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਜੋ "ਇੱਕ-ਦਿਸ਼ਾ ਦਰਵਾਜ਼ਾ" ਜਿਵੇਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਸਨੈਪਸ਼ਾਟ ਲਵੋ, ਖਾਸ ਕਰਕੇ:
ਜੇ ਕੋਈ ਬਦਲਾਅ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲੌਗ ਆਊਟ ਕਰ ਸਕਦਾ ਹੈ, ਡਬਲ-ਚਾਰਜ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਡਾਟਾ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲਵੋ। ਮੂਲ ਫਲੋ ਸਹੀ ਚੱਲਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਹੋਰ ਸਨੈਪਸ਼ਾਟ ਲਵੋ ਤਾਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ "ਨਵਾਂ ਜਾਣਿਆ-ਪਹਚਾਣਾ ਚੰਗਾ" ਪੁਆਇੰਟ ਹੋਵੇ।
ਹਰ ਛੋਟੀ-ਛੋਟੀ ਸੋਧ ਲਈ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਉਹਨਾਂ ਨੂੰ ਸ਼ੋਰ ਬਣਾਉਂਦਾ ਹੈ। ਛੋਟੇ, ਘੱਟ-ਖਤਰਨਾਕ ਸੋਧਾਂ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਛੱਡ ਦਿਓ ਜੋ ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਕਾਪੀ-ਸੰਪਾਦਨ ਜਾਂ ਛੋਟੀ-ਜਗ੍ਹਾ-ਸੰਬੰਧੀ ਸੁਧਾਰ।
ਇਸ ਤੋਂ ਬਚੋ ਕਿ ਐਪ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਖਰਾਬ ਹੋਣ 'ਤੇ ਸਨੈਪਸ਼ਾਟ ਲੈ ਲਈ ਜਾਵੇ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਸਨੂੰ 'broken' ਵਜੋਂ ਲੇਬਲ ਨਾ ਕਰੋ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਇੱਕ ਗੁੰਝਲਦਾਰ ਹਾਲਤ 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹੋ ਅਤੇ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੇ ਹੋ ਕਿ ਕਿਉਂ।
ਇੱਕ ਸਾਦਾ ਨਿਯਮ: ਹਰ ਅਰਥਪੂਰਨ ਚੈੱਕਪੋਇੰਟ 'ਤੇ ਸਨੈਪਸ਼ਾਟ ਲਵੋ। ਜੇ ਤੁਸੀਂ ਆਖਰੀ 30 ਤੋਂ 60 ਮਿੰਟ ਦਾ ਕੰਮ ਖੋ ਦੇਣਾ ਦੁਖਦਾਈ ਹੋਵੇਗਾ, ਜਾਂ ਅਗਲਾ ਕਦਮ ਪ੍ਰੋਡਕਸ਼ਨ ਬਿਹੇਵਿਅਰ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਤੁਹਾਡੀ ਇਸ਼ਾਰਾ ਹੈ।
ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੋ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਉਸਨੂੰ ਪਹਚਾਣ ਸਕੋ। ਦਬਾਅ 'ਤੇ ਹੋਣ ਸਮੇਂ ਲੇਬਲ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇੱਕ ਫਾਰਮੈਟ ਚੁਣੋ ਅਤੇ ਉਸਦਾ ਪਾਲਣ ਕਰੋ। ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫੌਲਟ ਹੈ:
YYYY-MM-DD - area - intent - status
ਤਾਰੀਖ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸਾਰਟ ਕਰਦੀ ਹੈ, ਇਲਾਕਾ ਖੋਜ ਘੱਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਰਾਦਾ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ।
ਹਫ਼ਤਿਆਂ ਬਾਅਦ ਵੀ ਮੈਨੇਅਰ ਰੱਖਣ ਵਾਲੇ ਉਦਾਹਰਣ:
2026-01-09 - auth - switch to email links - draft2026-01-09 - db - add invoices table - ready2026-01-10 - ui - new dashboard layout - release2026-01-11 - api - fix pagination bug - hotfixਯੋ ਜਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਤੋਂ ਬਚੋ: "v2", "test", "try again", ਜਾਂ "johns-fix" ਵਰਗੇ ਲੇਬਲ। ਉਹ ਲਮ੍ਹੇ ਲਈ ਤੇਜ਼ ਲੱਗਦੇ ਹਨ ਪਰ ਬਾਅਦ ਵਿੱਚ ਅਨੁਮਾਨ ਦਾ ਖੇਡ ਬਣ ਜਾਂਦੇ ਹਨ।
ਦੋ ਸਨੈਪਸ਼ਾਟ ਇੱਕੋ ਖੇਤਰ ਨੂੰ ਛੂਹ ਸਕਦੇ ਹਨ ਪਰ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਲਈ। "auth - refactor" ਢੀਲਾ ਹੈ, ਪਰ "auth - refactor to support SSO" ਸਾਫ਼ ਹੈ। ਮਕਸਦ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ ਰੀਸਟੋਰ ਕਰਨ ਉਤੇ ਕੀ ਕੰਮ ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇ ਲੇਬਲ ਬਹੁਤ ਲੰਬਾ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਲੇਬਲ ਨੂੰ ਸੰਗਠਿਤ ਰੱਖੋ ਅਤੇ ਜੇ ਤੁਹਾਡੇ ਟੂਲ ਵਿੱਚ ਨੋਟਸ ਸਹਾਇਤਾ ਹੋਵੇ ਤਾਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ: ਤੁਸੀਂ ਕੀ ਕੀਤਾ, ਕਿਉਂ ਕੀਤਾ, ਅਤੇ ਰੀਸਟੋਰ ਤੋਂ ਬਾਅਦ ਕੀ ਚੈੱਕ ਕਰਨਾ ਹੈ।
ਛੋਟੇ ਟੈਗ ਦ accidents ਬਚਾਉਂਦੇ ਹਨ:
draft - ਕੰਮ ਮੱਧ 'ਚ, ਚਲ ਸਕਦਾ/ਨਹੀਂready - ਬੁਨਿਆਦੀ ਚੈਕ ਪਾਸ ਕਰਦਾ, ਇਸ ਤੋਂ ਅੱਗੇ ਤੋਂ ਲਿਆ ਜਾ ਸਕਦਾrelease - ਜੋ ਰਿਲੀਜ਼ ਕੀਤਾ ਗਿਆ ਉਸਦਾ ਮੇਲhotfix - ਪ੍ਰੋਡਕਸ਼ਨ ਮੁੱਦੇ ਲਈ ਬਣਾਇਆ ਗਿਆਜੇ ਤੁਸੀਂ ਸਿਰਫ ਇੱਕ ਨਿਯਮ ਅਪਨਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਇਹੋ: ਕੁਝ ਵੀ release ਨਾ ਚਿੰਨ੍ਹੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਬੇਚਰਚਾ ਉਸਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਸੁਖੀ ਨਹੀਂ ਹੋ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੌਣ ਸਨੈਪਸ਼ਾਟ ਦਾ ਨਾਮ ਬਦਲ ਸਕਦਾ ਜਾਂ ਮਿਟਾ ਸਕਦਾ ਹੈ। ਨਾਂ ਬਦਲਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਜਦੋਂ ਬਦਲਾਅ ਸਮਝ ਆਉਂਦਾ ਹੈ ਤਾਂ ਲੇਬਲ ਅਕਸਰ ਸੁਧਰ ਜਾਂਦੇ ਹਨ, ਪਰ ਇਹ ਗੜਬੜ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਅਮਲੀ ਤਰੀਕ: ਕੋਈ ਵੀ ਸਨੈਪਸ਼ਾਟ ਬਣਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਇੱਕ ਛੋਟੀ ਮਾਲਕ ਗਰੁੱਪ ਨਾਮ ਬਦਲਣ ਜਾਂ ਮਿਟਾਉਣ ਲਈ ਹੋਵੇ, ਅਤੇ ਟੀਮ ਦੀ ਸਹਿਮਤੀ ਤੋਂ ਬਾਅਦ। ਇਸ ਨਾਲ ਟਾਈਮਲਾਈਨ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੀ ਹੈ ਖਾਸ ਕਰਕੇ ਵੱਡੇ ਬਦਲਾਅ ਜਿਵੇਂ auth rewrite, schema change, ਜਾਂ UI redesign ਦੌਰਾਨ।
ਸਨੈਪਸ਼ਾਟ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪੁੱਛ ਸਕੋ: "ਮੈਂ ਕਿਸੇ ਨੂੰ ਰੋਲਬੈਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਤਾਂ ਮੈਂ ਕਿਸੇ ਨੂੰ ਚੁਣਾਂ?" ਇੱਕ ਸਾਫ਼ ਟਾਈਮਲਾਈਨ ਘੱਟ ਸਨੈਪਸ਼ਾਟ ਲੈਣ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਇੱਕੋ ਸਧਾਰਨ ਪ੍ਰਣਾਲੀ ਦੇ ਉਪਯੋਗ ਬਾਰੇ ਹੈ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਨੈਪਸ਼ਾਟਾਂ ਨੂੰ ਥੀਮ ਦੇ ਅਨੁਸਾਰ ਗਰੁੱਪ ਕਰੋ, ਭਾਵੇਂ ਕਿ Auth, Database, UI, ਅਤੇ Release candidates ਵਰਗੀਆਂ bucket। ਜੇ ਤੁਸੀਂ ਇਹ buckets ਸਥਿਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਭਵਿਖ ਦਾ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ "try-3-final-final" ਨੂੰ ਡੀਕੋਡ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ।
ਤੁਸੀਂ ਊਪਰ ਦਿੱਤੇ ਨਾਂਕਰਨ ਪੈਟਰਨ ਨੂੰ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ, ਜਾਂ ਸਾਰਣੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਲਈ CAPS ਥੀਮ ਪ੍ਰੀਫਿਕਸ ਵਰਤ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ:
AUTH-2026-01-09 - session rewrite - preDB-2026-01-09 - schema v2 - known goodਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਨੋਟਸ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਓਹਨਾ ਨੂੰ ਸੰਯਮ ਨਾਲ ਵਰਤੋਂ। ਦੋ-ਤਿੰਨ ਲਾਈਨਾਂ ਕਾਫ਼ੀ ਹਨ:
ਇਹ ਵੀ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਦੋ "ਟੀਅਰ" ਸਨੈਪਸ਼ਾਟ ਰੱਖੋ:
ਜਦੋਂ ਕੋਈ ਤਜਰਬਾ ਖਤਮ ਹੋ ਜਾਵੇ, ਤਾਂ ਉਸਨੂੰ ਹਟਾਓ ਜਾਂ ਆਰਕਾਈਵ ਕਰੋ ਅਤੇ ਲੇਬਲ ਦਿਓ ਜੋ ਸਵੀਕਾਰ ਕਰਦਾ ਹੋ ਕਿ ਇਹ ਟੈਸਟ ਸੀ। ਟਾਈਮਲਾਈਨ ਉਸ ਵੇਲੇ ਹੀ ਉਪਯੋਗੀ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਹਰ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਮੰਨਦੇ।
ਆਖਿਰਕਾਰ, "ਜਾਣਿਆ-ਪਹਚਾਣਾ ਚੰਗਾ" ਸਨੈਪਸ਼ਾਟ ਜਾਣ-ਬੂਝ ਕੇ ਨਿਸ਼ਾਨ ਲਗਾਓ। ਇਹ ਸਿਰਫ਼ ਛੋਟੇ sanity ਚੈੱਕ ਤੋਂ ਬਾਅਦ ਕਰੋ (ਐਪ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਮੁੱਖ ਫਲੋ ਕੰਮ ਕਰਦਾ ਹੈ, ਕੋਈ ਅਸਪੱਸ਼ਟ ਜ਼ਰੂਰੀ ਤਰੁਟੀਆਂ ਨਹੀਂ)। ਜੇ ਬਾਅਦ ਵਿੱਚ ਸਭ ਕੁਝ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਮਾਂ ਬਰਬਾਦ ਨਹੀਂ ਕਰੋਗੇ ਕਿ ਕਿਹੜਾ ਸਨੈਪਸ਼ਾਟ ਸੁਰੱਖਿਅਤ ਹੈ।
ਵੱਡੇ ਬਦਲਾਅ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਨਵੇਂ ਕੋਡ ਨੂੰ ਅਣਪਛਾਤੇ ਸਾਈਡ-ਇਫੈਕਟਸ ਨਾਲ ਮਿਲਾ ਰਹੇ ਹੋ। ਸੁਧਾਰ ਬੋoring ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ: ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਸੇਵ-ਪਾਇੰਟ ਵਜੋਂ ਇੰTreat ਕਰੋ। ਛੋਟੇ, ਵਾਪਸੀਯੋਗ ਕਦਮਾਂ ਵਿੱਚ ਅੱਗੇ ਵਧੋ।
ਇੱਕ ਸਾਫ਼ "ਜਾਣਿਆ-ਪਹਚਾਣਾ" ਲੈਂਡਮਾਰ্ক ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਇਕ ਭਰੋਸੇਯੋਗ ਟਰੇਲ ਛੱਡੋ।
KNOWN-GOOD main 2026-01-09.ਜਿੱਥੇ ਸਨੈਪਸ਼ਾਟ ਸਸਤੇ ਹਨ ਅਤੇ ਰੋਲਬੈਕ ਤੇਜ਼ ਹੈ (Koder.ai ਸਮੇਤ), ਇਹ ਚੰਗੀਆਂ ਆਦਤਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ "ਮੈਂ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰ ਲਵਾਂਗਾ" ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦੇ ਕਿਉਂਕਿ ਸਹੀ ਢੰਗ ਨਾਲ ਰਿਕਵਰੀ ਦਰਦਨਾਕ ਨਹੀਂ ਹੁੰਦੀ।
ਚੈੱਕ ਛੋਟੇ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਯੋਗ ਰੱਖੋ। ਤੁਸੀਂ ਹਰ ਵਾਰ ਪੂਰੀ QA ਨਹੀਂ ਕਰ ਰਹੇ — ਤੁਸੀਂ ਸਾਦਾ ਰਾਹ ਵਿੱਚ ਵੱਡੀਆਂ ਖਾਮੀਆਂ ਫੜ ਰਹੇ ਹੋ।
ایک auth rewrite ਲਈ, ਕੰਮ ਨੂੰ ਸਲਾਈਸਾਂ ਵਿੱਚ ਤੋੜੋ: ਨਵੀਂ auth config ਪੇਸ਼ ਕਰੋ, ਇੱਕ ਰੂਟ ਨੂੰ ਨਵੇਂ ਗਾਰਡ 'ਤੇ ਸਵਿੱਚ ਕਰੋ, ਫਿਰ ਬਾਕੀ ਹਿਲਾਓ। ਹਰ ਸਵਿੱਚ ਤੋਂ ਬਾਅਦ ਸਨੈਪਸ਼ਾਟ ਲਵੋ। ਜੇ session ਹੈਂਡਲਿੰਗ ਟੁੱਟੇ, ਤਾਂ ਆਖਰੀ ਜਾਣੇ-ਪਹਚਾਣੇ ਚੰਗੇ ਸਨੈਪਸ਼ਾਟ 'ਤੇ ਰੋਲਬੈਕ ਕਰੋ ਅਤੇ ਛੋਟੀ ਸਲਾਈਸ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
ਸਕੀਮਾ ਬਦਲਾਅ ਲਈ, ਫੇਜ਼ਾਂ ਵਰਤੋ: ਪਹਿਲਾਂ ਨਵੀਆਂ ਟੇਬਲਾਂ ਜਾਂ ਕਾਲਮਾਂ ਜੋੜੋ (ਕੋਈ ਵਿਹੇਵਿਆ ਬਦਲਾਅ ਨਹੀਂ), ਸਨੈਪਸ਼ਾਟ ਲਵੋ, ਫਿਰ ਪੜ੍ਹਨ-ਲਿਖਨ ਅਪਡੇਟ ਕਰੋ, ਸਨੈਪਸ਼ਾਟ ਲਵੋ, ਅਤੇ ਫਿਰ ਹੀ ਪੁਰਾਣੇ ਫੀਲਡ ਹਟਾਓ। ਜੇ ਡਾਟਾ ਲਿਖਾਈ ਟੁੱਟਦੀ ਹੈ ਤਾਂ ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ ਅਣਜਾਣੇ ਬਦਲਾਅ ਤੋਂ ਬਚਾਏਗਾ।
UI ਰੀਡਿਜ਼ਾਈਨ ਲਈ, ਇੱਕ ਵਾਰੀ ਸਾਰੀਆਂ ਪੇਜਾਂ ਬਦਲਣ ਤੋਂ ਰੋਕੋ। ਇੱਕ ਮੁੱਖ ਸਕਰੀਨ redesign ਕਰੋ, ਸਨੈਪਸ਼ਾਟ ਲਵੋ, ਫਿਰ ਇੱਕੋ ਪੈਟਰਨ ਅਗਲੇ 'ਤੇ ਲਗਾਓ। UI header+nav, UI dashboard v2, ਅਤੇ UI forms cleanup ਵਰਗੇ ਲੇਬਲ ਬਾਅਦ ਵਿੱਚ "ਕਿਹੜਾ ਸਨੈਪਸ਼ਾਟ ਚੰਗਾ ਸੀ?" ਦੇ ਸਵਾਲ ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਵੱਡੇ ਬਦਲਾਅ ਬਹੁਤ ਹੀ ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਾਸ਼ ਕਰਨ ਵਾਲੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਗੁੰਮ ਹੋਇਆ ਰੀਡਾਇਰੈਕਟ, ਅੱਧੇ ਚੱਲੇ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਇੱਕ ਲੇਆਊਟ ਜੋ ਡੈਸਕਟਾਪ 'ਤੇ ਠੀਕ ਲੱਗਦਾ ਪਰ ਮੋਬਾਈਲ 'ਤੇ ਟੁੱਟ ਜਾਂਦਾ। ਸਭ ਤੋਂ ਆਸਾਨ ਸੇਫਟੀ ਨੈੱਟ ਉਹ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ ਮੋਮੈਂਟਾਂ 'ਤੇ ਸਨੈਪਸ਼ਾਟ ਲਵੋ ਜਿੱਥੇ ਤੁਸੀਂ ਇੱਕ ਰੇਖਾ ਕੱਟਦੇ ਹੋ ਜੋ ਆਸਾਨੀ ਨਾਲ ਵਾਪਸ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।
Auth ਕੰਮ ਖਤਰਨਾਕ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਸਭ ਨੂੰ ਲੌਗ ਆਊਟ ਕਰ ਸਕਦਾ ਹੈ۔ ਲੌਗਿਨ ਰਾਹ ਦੇ ਰੂਪ-ਬਦਲਾਅ 'ਤੇ ਸਨੈਪਸ਼ਾਟ ਲਵੋ:
auth | baseline | current login+signup works | status: readyauth | add provider X | status: draftauth | switch default | status: readyਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਵਰਜ਼ਨ ਨੂੰ ਤੁਲਨਾਤਮਕ ਬਣਾਈ ਰੱਖਣ ਲਈ ਹਰ ਵਾਰੀ ਉਹੀ ਟੈਸਟ ਪਾਥ ਵਰਤੋ: ਨਵਾਂ ਉਪਭੋਗੀ ਸਾਈਨਅੱਪ, ਲੌਗਆਊਟ, ਲੌਗਿਨ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ (ਜੇ ਹੈ), ਅਤੇ ਇੱਕ ਪ੍ਰੋਟੈਕਟਡ ਪੇਜ ਦੀ ਯਾਤਰਾ।
ਡੇਟਾਬੇਜ਼ ਬਦਲਾਅ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਰੋਲਬੈਕ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਅਹਿਮ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਾਫ਼ ਪ੍ਰਵਾਹ ਹੈ:
db | pre-migration | status: readydb | post-migration | status: draftdb | post-backfill | status: readydb | app updated | status: readyਯਾਦ ਰਹੇ ਕਿ ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ “ਸਮੱਸਿਆ” ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਤੁਹਾਡੀ ਸਕੀਮਾ ਅੱਗੇ ਮਾਈਗ੍ਰੇਟ ਹੋ ਗਈ, ਕੋਈ env ਵੈਰੀਏਬਲ ਬਦਲ ਗਿਆ, ਜਾਂ config ਡ੍ਰਿਫਟ ਹੋਇਆ, ਤਾਂ ਸਿਰਫ਼ ਕੋਡ ਰੀਸਟੋਰ ਕਰਨਾ ਬਰਤਾਅ ਮੁੜ ਨਹੀਂ ਲਿਆਉਂਦਾ। ਬਾਹਰੀ ਬਦਲਾਅ ਨੂੰ ਨਾਂ ਜਾਂ ਨੋਟਸ ਵਿੱਚ ਦਰਜ ਕਰੋ।
UI ਕੰਮ ਵਾਪਸੀਯੋਗ ਲੱਗਦਾ ਹੈ ਤਾਂ ਜੋ ਨਹੀਂ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਪਸ਼ਟ ਵੇਖਣ ਮੀਲ-ਸਟੋਨ ਹਾਸਲ ਕਰੋ ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਲਵੋ:
ui | baseline | status: readyui | new header+cards | status: draftui | responsive pass | status: readyਵਰਜ਼ਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਇੱਕੋ ਤੇਜ਼ ਡੈਮੋ ਸਕ੍ਰਿਪਟ ਵਰਤੋ: ਤਿੰਨ ਮੁੱਖ ਸਕਰੀਨ ਖੋਲੋ, ਮੋਬਾਈਲ ਚੌੜਾਈ ਦੇ ਲਈ ਰੀਸਾਈਜ਼ ਕਰੋ, ਅਤੇ ਇੱਕ ਪ੍ਰਮੁੱਖ ਕਾਰਵਾਈ ਪੂਰੀ ਕਰੋ (ਜਿਵੇਂ "ਪ੍ਰੋਜੈਕਟ ਬਣਾਓ" ਜਾਂ "ਚੈਕਆਊਟ")।
ਇੱਕ ਇਕੱਲਾ ਨirmaata ਇੱਕ ਛੋਟੀ subscription ਐਪ 'ਤੇ ਸ਼ਨੀਵਾਰ ਨੂੰ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ। ਯੋਜਨਾ ਸਧਾਰਨ ਲੱਗੀ: ਲੌਗਿਨ ਫਲੋ ਨੂੰ ਨਵੇਂ ਟੋਕੇਨ ਫਾਰਮੈਟ ਨਾਲ ਸਵਪ ਕਰਨਾ, ਅਤੇ Settings ਪੇਜ ਨੂੰ ਮੋਬਾਈਲ 'ਤੇ ਚੰਗਾ ਦੇਖਣ ਲਈ ਰੀਫਰੇਸ਼ ਕਰਨਾ।
ਉਹਨਾਂ ਨੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਸੇਵ-ਪਾਇੰਟ ਵਾਂਗ ਵਰਤਿਆ। ਬੜੀ ਗੱਲ ਕਰਦੇ ਹੋਏ ਵੀ ਉਨ੍ਹਾਂ ਨੇ ਪਹਿਲਾਂ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਬਣਾਇਆ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਨਿਸ਼ਾਨ ਦੇਆ ਜੋ ਉਹ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਸਨ।
ਉਹਨਾਂ ਨੇ ਹਫਤੇ ਦੇ ਦੌਰਾਨ ਇਹ ਕੈਪਚਰ ਕੀਤਾ:
fri-1900_main_green (ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਆਖਰੀ ਸ਼ਾਂਤ ਪਾਇੰਟ)sat-1030_auth_token_v2_start (auth ਬਦਲਣ ਤੋਂ ਬਿਲਕੁਲ ਪਹਿਲਾਂ)sat-1400_settings_redesign_start (UI ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ)sat-1730_pre_merge_smoke_pass (ਤੇਜ਼ ਮੈਨੂਅਲ ਚੈੱਕ ਤੋਂ ਬਾਅਦ)ਨੁਕਸਾਨ ਸ਼ਨੀਵਾਰ ਰਾਤ ਨੂੰ ਆਇਆ। auth ਬਦਲਾਅ ਅਤੇ Settings ਰੀਡਿਜ਼ਾਈਨ ਮਰਜ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਉਪਭੋਗੀ ਲੌਗਿਨ ਕਰ ਸਕਦੇ ਸਨ ਪਰ ਫਿਰ ਲੌਗਿਨ ਸਕਰੀਨ 'ਤੇ ਲੂਪ ਕਰ ਰਹੇ ਸਨ। ਕਾਰਨ ਛੋਟਾ ਸੀ: ਨਵੇਂ ਟੋਕੇਨ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਕੀ ਅਧੀਨ ਸਟੋਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ ਜੋ ਬਾਕੀ ਐਪ ਉਮੀਦ ਕਰਦੀ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਹਰ ਪੇਜ ਲੋਡ "ਲੌਗ ਆਊਟ" ਵਰਗਾ ਲੱਗਦਾ।
ਟੈਨਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਵਧੀ ਕਿਉਂਕਿ Settings ਰੀਡਿਜ਼ਾਈਨ ਨੇ ਵੀ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਫੀਲਡ ਛੇੜੀਆਂ ਅਤੇ ਇਕ ਕਿਊਰੀ ਖਾਲੀ ਡਾਟਾ ਵਾਪਸ ਕਰ ਰਹੀ ਸੀ। ਅਚਾਨਕ ਇਹ ਅਸਪਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਮਸਲਾ auth ਹੈ, ਡੀਬੀ ਕਾਲ ਹੈ, ਜਾਂ UI ਸਟੇਟ ਹੈ।
ਰੋਲਬੈਕ ਨੇ ਸਭ ਕੁਝ ਬੋਰਿੰਗ ਬਣਾ ਦਿੱਤਾ। ਉਸਨੇ sat-1030_auth_token_v2_start 'ਤੇ ਵਾਪਸ ਕੀਤਾ, ਪੁਰਾਣੀ ਲੌਗਿਨ ਪੁਸ਼ਟੀ ਕੀਤੀ, ਫਿਰ ਸਿਰਫ auth ਬਦਲਾਅ ਪ ਲਾਗੂ ਕੀਤਾ ਜਦ ਤੱਕ ਲੂਪ ਖ਼ਤਮ ਨਾ ਹੋ ਗਿਆ। ਫਿਰ ਉਹ sat-1400_settings_redesign_start ਤੋਂ ਅੱਗੇ ਵਧੇ ਅਤੇ Settings ਪੇਜ 'ਤੇ ਗੁੰਮ ਹੋਇਆ ਸਟੇਟ ਠੀਕ ਕੀਤਾ ਬਿਨਾਂ auth ਡੀਬੱਗਿੰਗ ਨਾਲ ਮਿਲਾਉਂਦੇ ਹੋਏ।
ਐਤਵਾਰ ਨੂੰ ਉਸਨੇ ਇਕ ਆਦਤ ਬਦਲੀ: ਹਰ ਸਨੈਪਸ਼ਾਟ ਨਾਮ ਵਿੱਚ (1) ਕੀ ਬਦਲ ਰਿਹਾ ਸੀ, (2) ਜੋਖਮ ਸਤਰ, ਅਤੇ (3) ਇੱਕ ਛੋਟਾ "last known good" ਟੈਸਟ ਸ਼ਾਮِل ਕੀਤਾ, ਜਿਵੇਂ ..._green_smoke। ਉਹਨਾਂ ਨੇ ਹਰ ਨਿandਕਲੀਆਂ ਟੈਸਟ ਤੋਂ ਬਾਅਦ ਇੱਕ ਵਾਧੂ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਨਾ ਕਿ ਸਿਰਫ਼ ਖਤਰਨਾਕ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ। ਇਹ ਇਕ ਨਿਯਮ ਅਗਲੇ ਰਿਲੀਜ਼ ਦੇ ਪੈਨਿਕ ਨੂੰ ਅੱਧਾ ਘਟਾ ਦਿੱਤਾ।
ਜ਼ਿਆਦਾਤਰ ਸਨੈਪਸ਼ਾਟ ਸਮੱਸਿਆਵਾਂ ਟੂਲ ਦੀ ਬਜਾਏ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹੋ, ਵਿਆਪਕ ਸੋਧ ਕਰਦੇ ਹੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਯਾਦ ਨਹੀਂ ਰੱਖਦੇ ਕਿ ਕੀ ਸਥਿਰ ਸੀ ਅਤੇ ਕੀ ਤਜਰਬੇਵੀ, ਤਾਂ ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ।
ਇਕ ਆਮ ਗਲਤੀ ਆਖਰੀ ਜਾਣੇ-ਪਹਚਾਣੇ ਚੰਗੇ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਛੱਡ ਦੇਣਾ ਹੈ। ਲੋਕ auth rewrite ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ, ਰੂਟ, ਮਿਡਲਵੇਅਰ, ਅਤੇ session ਸਟੋਰੇਜ ਛੇੜਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਹੀ ਸੇਵ ਕਰਨ ਬਾਰੇ ਸੋਚਦੇ ਹਨ। ਜੇ ਬਦਲਾਅ ਵਧ ਗਿਆ ਤਾਂ ਮੁੜ ਵਾਪਸੀ ਲਈ ਕੋਈ ਸਾਫ਼ ਥਾਂ ਨਹੀਂ ਰਹਿੰਦੀ।
ਉਸਦਾ ਉਲਟ ਵੀ ਦਰਦਨਾਕ ਹੈ: ਹਰ ਕੁਝ ਮਿੰਟ ਵਿੱਚ "test", "fix", ਜਾਂ "ok" ਵਰਗੇ ਨਾਮਾਂ ਨਾਲ ਸਨੈਪਸ਼ਾਟ ਲੈਣ। ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਸੇਵ-ਪਾਇੰਟ ਹੋ ਜਾਂਦੇ ਹਨ ਪਰ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਦਸਦਾ ਕਿ ਕੀ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਕਿਹੜਾ ਸੁਰੱਖਿਅਤ ਹੈ।
ਰੋਲਬੈਕ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਵੀ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਕਿ ਕੀ ਚੀਜ਼ ਕੋਡ ਤੋਂ ਬਾਹਰ ਹੈ। ਜੇ ਤੁਸੀਂ ਐਪ ਸਥਿਤੀ ਰੀਸਟੋਰ ਕਰਦੇ ਹੋ ਪਰ ਤੁਹਾਡੀ ਡੇਟਾਬੇਜ਼ ਸਕੀਮਾ ਪਹਿਲਾਂ ਹੀ ਅੱਗੇ ਮਾਈਗ੍ਰੇਟ ਹੋ ਚੁੱਕੀ ਹੈ, ਜਾਂ env/config ਬਦਲਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਕੇਵਲ ਕੋਡ ਰੀਸਟੋਰ ਕਰਨਾ ਵਰਹੀ ਬਰਤਾਅ ਮੁੜ ਨਹੀਂ ਲਿਆਉਂਦਾ।
ਇਕ ਹੋਰ ਆਮ ਧਾਰਨਾ ਹੈ ਫੇਲ ਸਨੈਪਸ਼ਾਟਾਂ ਨੂੰ "ਸੰਭਾਲ ਕੇ ਰੱਖਣਾ" ਫਿਰ ਭੁੱਲ ਜਾੳਣਾ ਕਿ ਉਹ ਕਦੇ ਕੰਮ ਹੀ ਨਹੀਂ ਕਰਦੇ। ਦਿਨਾਂ ਬਾਅਦ ਕੋਈ "UI ਅਪਡੇਟ ਤੋਂ ਪਹਿਲਾਂ" ਰੀਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਖਰਾਬ ਬਿਲਡ 'ਤੇ ਲੈਂਡ ਕਰਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਟੀਮਾਂ ਕਈ ਵਾਰੀ ਰੋਲਬੈਕ ਕਰਕੇ ਓਥੇ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਸਮੱਸਿਆ ਠੀਕ ਹੋ ਗਈ, ਪਰ ਮੁੱਖ smoke ਟੈਸਟ ਨਹੀਂ ਦੁਬਾਰਾ ਚਲਾਉਂਦੇ। ਇੰਝ ਤੁਸੀਂ "ਸੇਵ" ਕਰਨ ਤੋਂ ਬਾਅਦ ਇੱਕ ਵੱਖਰਾ ਬੱਗ ਜਾਰੀ ਕਰ ਦਿੰਦੇ ਹੋ।
ਕੁਝ ਗਾਰਡਰੇਲਸ ਜ਼ਿਆਦਾਤਰ ਗੁੰਝਲ ਰੋਕ ਦਿੰਦੀਆਂ ਹਨ:
auth-v2-login-ok).ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਮਦਦਗਾਰ ਆਦਤ ਇਹ ਹੈ ਕਿ ਬਦਲਾਅ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਹੀ ਸਨੈਪਸ਼ਾਟ ਲਵੋ ਪਰ ਵਿਆਪਕ ਸੋਧ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ। ਇਸ ਨਾਲ ਤੁਹਾਡੇ "ਸੇਫ ਰਿਫੈਕਟਰਸ" ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਐਸਾ ਵਰਜ਼ਨ ਵਾਪਸ ਲਾ ਸਕਦੇ ਹੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋसा ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਕੇਵਲ ਇੱਕ ਸੰਭਾਲੀ ਹੋਈ ਵਰਜ਼ਨ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਖਤਰਨਾਕ ਚੀਜ਼ ਨੂੰ ਛੇੜਣ ਜਾ ਰਹੇ ਹੋ, ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਇਕ afterthought ਨਾ ਸਮਝੋ — ਉਨ੍ਹਾਂ ਨੂੰ ਸੇਵ-ਪਾਇੰਟ ਵਜੋਂ ਵਰਤੋਂ। ਕੁਝ ਮਿੰਟ ਇੱਕ ਸਾਫ਼ ਵਾਪਸੀ ਬਿੰਦੂ ਸੈਟ ਕਰਨ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਲੂਪ ਬਣਾਉਣ ਲਈ ਲਾ ਕੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਬਾਅਦ ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ।
Baseline - known good - 2026-01-09 10:15, ਅਤੇ ਇੱਕ-ਲਾਈਨ ਨੋਟ ਜੋ ਦੱਸੇ ਕਿ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ (sign-in OK, billing page loads)।RC - auth rewrite - 2026-01-09 18:40 ਤਾਂ ਜੋ ਜੇ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਕੁਝ ਅਚਾਨਕ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਤੁਰੰਤ ਰੋਲਬੈਕ ਕਰ ਸਕੋ।ਜੇ ਤੁਸੀਂ ਕੁਝ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਬੇਸਲਾਈਨ + ਸ੍ਮੋਕ ਟੈਸਟ ਲੂਪ ਕਰੋ। ਇਹ ਅਕਸਰ ਉਹ ਸਮੱਸਿਆਵਾਂ ਰੋਕ ਦਿੰਦਾ ਹੈ ਜੋ ਕਿ "ਕਿੱਥੇ ਟੁੱਟਿਆ?" ਦੇ ਪਲ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ।
ਰੋਲਬੈਕ ਕੇਵਲ ਅਧ-ਕੰਮ ਹੈ। ਵਾਪਸ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਬੱਗ ਖਤਮ ਹੋ ਗਿਆ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ (ਉਹੀ ਸ੍ਮੋਕ ਟੈਸਟ), ਫਿਰ ਮੁੜ-ਆਖਰੀ ਚੰਗੇ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਅੱਗੇ ਹਿੱਸੇ ਇਕ-ਇਕ ਕਰਕੇ ਲੱਗਾਓ। ਟੁੱਟੇ ਹੋਏ ਹਿੱਸੇ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਟੁਕੜਿਆਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਦੁਬਾਰਾ ਲਿਆਵੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਪਤਾ ਲਗਾ ਸਕੋ ਕਿ ਕਿਹੜਾ ਚੰਕ ਮੁੱਦਾ ਪੈਦਾ ਕਰ ਰਿਹਾ ਸੀ।
ਸਨੈਪਸ਼ਾਟ ਤਦ ਹੀ ਫਲਦਾਇਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਬੋਰਿੰਗ ਅਤੇ ਸਦਾਂਤਰ ਹੋ ਜਾਣ। ਲੱਕੜੀ ਦਾ ਮਕਸਦ ਸਿਰਫ਼ ਵਧੇਰੇ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਨਹੀਂ, ਸਗੋਂ ਉਨ੍ਹਾਂ ਪਲਾਂ 'ਤੇ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਹੈ ਜੋ ਗੁੰਮ ਕਰਨ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਕਰਦੇ।
ਇੱਕ ਸਧਾਰਨ ਟੀਮ ਨਿਯਮ ਮਦਦ ਕਰਦਾ ਹੈ: ਲੌਗਿਨ, ਡਾਟਾ ਸਟ੍ਰਕਚਰ, ਜਾਂ ਸਾਂਝੇ UI ਕੰਪੋਨੈਂਟ ਤੱਕ ਛੂਹਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲੈਣ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇੱਕੱਲੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਇੱਕੋ ਹੀ ਢੰਗ ਨਾਲ Treat ਕਰੋ — ਤੁਹਾਡਾ ਭਵਿੱਖ ਦਾ ਆਪ ਤੁਹਾਡੀ ਟੀਮ ਹੈ।
ਇੱਕ ਛੋਟੀ "ਗੋਲਡਨ ਪਾਥ" ਸੂਚੀ ਰੱਖੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਹਰ ਕੋਈ ਭਰੋਸਾ ਕਰਦਾ ਹੋ: ਇਹ ਉਹ ਸੈੱਟ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਆਗ ਲੱਗਣ 'ਤੇ ਨਿਸ਼ਚਿੰਤ ਹੋ ਕੇ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਭਰੋਸੇਯੋਗ ਰਹੇ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਆਦਤ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਅਪਣਾ ਸਕਦੀਆਂ ਹਨ:
ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ Koder.ai ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਚੈਟ-ਚਲਿਤ ਫਲੋ ਤੇਜ਼ੀ ਨਾਲ ਵੱਡੀਆਂ ਸੋਧਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਵਰਕਫਲੋ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Planning Mode ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਦਲਾਅ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਪਹਿਲਾਂ ਆਪਣੇ ਸਨੈਪਸ਼ਾਟ ਪਾਇੰਟ ਡਿਫਾਈਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋਗੇ ਬਿਨਾਂ ਹਰ ਖਤਰਨਾਕ ਸੋਧ ਨੂੰ ਇਕ ਸਥਾਈ ਫੈਸਲਾ ਬਣਾਉਣ ਦੇ।
ਅਗਲਾ ਕਾਰਵਾਈ: ਇੱਕ ਆਉਣ ਵਾਲੇ ਬਦਲਾਅ (auth rewrite, schema change, ਜਾਂ UI redesign) ਚੁਣੋ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਤਿੰਨ ਸਨੈਪਸ਼ਾਟ-ਪਾਇੰਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇਕ ਵਾਰੀ ਇਹ ਕਰੋ ਅਤੇ ਇਹ ਆਟੋਮੈਟਿਕ محسوس ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗਾ।
ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਤੁਹਾਡੇ ਐਪ ਦੀ ਸੰਭਾਲੀ ਹੋਈ ਹਾਲਤ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਮੁੜ ਲੈ ਆ ਸਕਦੇ ਹੋ। ਇਸਨੂੰ ਖਤਰਨਾਕ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਭਰੋਸੇਯੋਗ “ਆਖਰੀ ਚੰਗੀ ਹਾਲਤ” ਵਾਂਗ ਵਰਤੋਂ।
ਰੋਲਬੈਕ ਉਹ ਕਾਰਵਾਈ ਹੈ ਜਿਸ ਵਿੱਚ ਉਸ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੁੱਟੀ ਹੋਈ ਚੀਜ਼ ਨੂੰ ਡੀਬੱਗ ਕਰਦੇ ਹੋਏ ਅੱਗੇ ਵਧ ਸਕੋ।
ਕਿਸੇ ਵੀ ਐਸੇ ਬਦਲਾਅ ਤੋਂ ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲਵੋ ਜੋ ਵਾਪਸ ਨਹੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਆਸਾਨੀ ਨਾਲ:
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਅਗਲਾ 30–60 ਮਿੰਟ ਖਤਮ ਹੋ ਜਾਣਾ ਨੁਕਸানਦਾਇਕ ਹੋਵੇ, ਤਾਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲਵੋ।
ਛੋਟੇ ਸੋਧਾਂ ਲਈ ਜਿਹੜੇ ਤੁਸੀਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਫਿਰ ਨਾਲ ਬਣਾ ਸਕਦੇ ਹੋ, ਸਨੈਪਸ਼ਾਟ ਨਾ ਲਵੋ (ਜਿਵੇਂ ਲਿਖਤ ਵਿੱਚ ਸੋਧ, ਛੋਟੀ spacing fixes)। ਬਹੁਤ ਸਾਰੇ ਘੱਟ-ਮੁੱਲ ਵਾਲੇ ਸਨੈਪਸ਼ਾਟ ਲੈਣ ਨਾਲ ਉਹ ਲਭਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇ ਐਪ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਟੁੱਟੀ ਹੋਵੇ ਤਾਂ ਉਸ ਹਾਲਤ ਨੂੰ ਸਨੈਪਸ਼ਾਟ ਨਾ ਚੁਣੋ, ਸਿਵਾਏ ਇਸਦੇ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ draft ਜਾਂ broken ਵਜੋਂ ਲੇਬਲ ਕਰੋ।
ਇੱਕ ਸुसੰਗਤ ਪੈਟਰਨ ਵਰਤੋਂ ਜੋ “ਕੀ/ਕਿਉਂ/ਸੁਰੱਖਿਅਤ?” ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦੱਸੇ:
YYYY-MM-DD - area - intent - status
ਉਦਾਹਰਨ: 2026-01-09 - auth - switch token storage key - ready.
test, v2, ਜਾਂ final-final ਵਰਗੇ ਨਾਂਆਂ ਤੋਂ ਬਚੋ — ਉਹ ਰੋਲਬੈਕ ਨੂੰ ਅਨੁਮਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਛੋਟੇ ਸੈਟ ਸਟੈਟਸ ਟੈਗ ਜਿਵੇਂ:
draft: ਮੱਧ-ਕੰਮ, ਹੋ ਸਕਦਾ ਹੈ ਚਲ ਨਾ ਰਿਹਾ ਹੋਵੇready: ਇੱਕ ਤੇਜ਼ ਸ੍ਮੋਕ ਟੈਸਟ ਪਾਰ ਕਰਦਾ ਹੈrelease: ਜੋ ਸੀਪ ਕੀਤਾ ਗਿਆ ਹੈ ਉਸਦੇ ਨਾਲ ਮਿਲਦਾ ਹੈhotfix: ਪ੍ਰੋਡਕਸ਼ਨ ਮੁੱਦੇ ਲਈ ਬਣਾਇਆ ਗਿਆਜੇ ਤੁਸੀਂ ਇੱਕ ਹੀ ਨਿਯਮ ਲਾਗੂ ਕਰੋ, ਤਾਂ ਇਹ ਹੋਵੇ: ਕੁਝ ਵੀ ਨਾ ਚਿੰਨ੍ਹੋ ਜਦ ਤੱਕ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਵਿਚਾਰ ਦੇ ਉਸਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਵਿੱਚ ਆਰਾਮਦਾਇਕ ਨਾ ਹੋਵੋ।
ਦੋ ਪਾਤਰ ਬਣਾਓ:
ਜਦੋਂ ਕੋਈ ਤਜਰਬਾ ਖਤਮ ਹੋ ਜਾਵੇ, ਉਸਨੂੰ ਹਟਾਓ ਜਾਂ ਇਸੇ ਰੀਲੇਬਲ ਕਰੋ ਤਾਂ ਕਿ ਕੋਈ ਇਹ ਗਲਤ ਫੈਸਲਾ ਨਾ ਕਰੇ ਕਿ ਇਹ ਸੁਰੱਖਿਅਤ ਰੀਸਟੋਰ ਪੌਇੰਟ ਹੈ।
ਇਹਨਾਂ ਨੂੰ ਛੋਟੇ, ਟੈਸਟ-ਯੋਗ ਸਲਾਈਸਾਂ ਵਿੱਚ ਬਾਝਕੇ ਚੈੱਕਪੌਇੰਟ ਵਜੋਂ ਵਰਤੋਂ:
known good ਸਨੈਪਸ਼ਾਟ ਲਵੋਇਸ ਨਾਲ ਇੱਕ ਵੱਡਾ ਬਦਲਾਅ ਛੁਪਿਆ ਹੋਇਆ ਟੁੱਟਣਾ ਨਹੀਂ ਛੱਡਦਾ।
ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਟੈਸਟਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਹਰ ਚੰਕ 'ਤੇ ਜਾਂਚ ਲਈ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਫੇਲ ਹੋਵੇ, ਤਾਂ ਠੀਕ ਕਰੋ ਜਾਂ ਰੋਲਬੈਕ ਕਰੋ।
Auth ਛੋਟੇ ਪਰ ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲੇ ਤਰੀਕਿਆਂ ਵਿੱਚ ਟੁਟਦਾ ਹੈ। ਯੂਜ਼ਰ-ਫਲੋ ਬਦਲਾਅ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਨੈਪਸ਼ਾਟ ਲਵੋ:
auth - baseline - ready)draft)ready)ਹਮੇਸ਼ਾ ਉਹੀ “ਹੈਪੀ ਪਾਥ” ਦੁਬਾਰਾ ਚਲਾਓ ਤਾਂ ਕਿ ਨਤਜੇ ਤੁਲਨਾਤਮਕ ਹੋਣ।
ਨਹੀਂ ਹਮੇਸ਼ਾ। ਰੋਲਬੈਕ ਆਮ ਤੌਰ 'ਤੇ ਐਪ ਦੀ ਹਾਲਤ ਮੁੜ ਲਿਆਉਂਦਾ ਹੈ, ਪਰ ਕੁਝ ਮੁੱਦੇ ਕੋਡ ਦੇ ਬਾਹਰ ਹੀ ਹੋ ਸਕਦੇ ਹਨ:
ਜੇ ਬਾਹਰੀ ਤਬਦੀਲੀਆਂ ਹੋਈਆਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਨੈਪਸ਼ਾਟ ਲੇਬਲ/ਨੋਟਸ ਵਿੱਚ ਦਰਜ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਲਿਆਉਣ ਜਾਂ ਮੁੜ ਲਗਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।
release