03 ਅਕਤੂ 2025·7 ਮਿੰਟ
ਸੁਰੱਖਿਅਤ ਵੱਡੇ ਬਦਲਾਅ ਲਈ ਸਨੇਪਸ਼ਾਟ-ਪਹਿਲਾਂ ਵਿਕਾਸ ਵਰਕਫਲੋ
ਸਨੇਪਸ਼ਾਟ-ਪਹਿਲਾਂ ਵਰਕਫਲੋ ਸਿੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਕੀਮਾ, auth ਅਤੇ UI ਬਦਲਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਸੇਵ-ਪੌਇੰਟ ਬਣਾਈਏ ਅਤੇ ਪ੍ਰਗਤੀ ਗੁਆਏ ਬਿਨਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕੋ।
ਸਨੇਪਸ਼ਾਟ-ਪਹਿਲਾਂ ਵਰਕਫਲੋ ਸਿੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਕੀਮਾ, auth ਅਤੇ UI ਬਦਲਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਸੇਵ-ਪੌਇੰਟ ਬਣਾਈਏ ਅਤੇ ਪ੍ਰਗਤੀ ਗੁਆਏ ਬਿਨਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕੋ।
ਸਨੇਪਸ਼ਾਟ-ਪਹਿਲਾਂ ਵਰਕਫਲੋ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਐਸੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੇਵ-ਪੌਇੰਟ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਸਨੇਪਸ਼ਾਟ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਉਸ ਸਮੇਂ ਦੀ ਜਮ੍ਹੀ ਹੋਈ ਨਕਲ ਹੁੰਦੀ ਹੈ। ਜੇ ਅਗਲਾ ਕਦਮ ਗਲਤ ਹੋ ਜਾਏ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਠੀਕ ਸਥਿਤੀ ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ ਬਜਾਏ ਕਿ ਹੱਥੋਂ ਹੱਥ ਬਿੱਜੜੀ ਗਈ ਹਾਲਤ ਨੂੰ ਵਾਪਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ।
ਵੱਡੇ ਬਦਲਾਅ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਸਕੀਮਾ ਅਪਡੇਟ ਤਿੰਨ ਸਕ੍ਰੀਨ ਦੂਰ ਦੀ ਇੱਕ ਰਿਪੋਰਟ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਇੱਕ auth ਸੋਧ ਤੁਹਾਨੂੰ ਬੰਦ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ UI ਰਿਰਾਈਟ ਨਮੂਨੇ ਵਾਲੇ ਡੇਟਾ ਨਾਲ ਠੀਕ ਲਗ ਸਕਦੀ ਹੈ, ਪਰ ਅਸਲ ਅਕੌਂਟਸ ਅਤੇ ਐਜ-ਕੇਸز ਨਾਲ ਟੁੱਟ ਸਕਦੀ ਹੈ। ਸਪੱਸ਼ਟ ਸੇਵ-ਪੌਇੰਟ ਬਿਨਾਂ, ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਰਹਿ ਜਾਂਦੇ ਹੋ ਕਿ ਕਿਸ ਬਦਲਾਅ ਨੇ ਸਮੱਸਿਆ ਪੈਦਾ ਕੀਤੀ, ਜਾਂ ਤੁਸੀਂ ਤੋਟੇ ਹੋਏ ਵਰਜ਼ਨ ਨੂੰ ਪੈਚ ਕਰਦੇ ਰਹਿੰਦੇ ਹੋ ਅਤੇ ਭੁੱਲ ਜਾਂਦੇ ਹੋ ਕਿ "ਚੱਲਦਾ" ਕਿਵੇਂ ਲੱਗਦਾ ਸੀ।
ਸਨੇਪਸ਼ਾਟਸ ਇਸ ਲਈ ਮਦਦਗਾਰ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਇੱਕ ਜਾਣ-ਪਛਾਣਯੋਗ-ਚੰਗੀ ਬੇਸਲਾਈਨ ਦਿੰਦੇ ਹਨ, ਉਹ ਬੋਲਡ ਆਈਡੀਯਿਆਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਸਸਤੀ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਟੈਸਟਿੰਗ ਸਧਾਰਣ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ: “ਕੀ ਇਹ ਅਜੇ ਵੀ Snapshot X ਤੋਂ ਬਾਅਦ ਠੀਕ ਸੀ?”
ਇਹ ਵੀ ਸਪਸ਼ਟ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਨੇਪਸ਼ਾਟ ਕੀ ਰੱਖ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਸਨੇਪਸ਼ਾਟ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਉਹੀ ਜਿਵੇਂ ਸੀ ਰੱਖਦਾ ਹੈ (ਅਤੇ ਕਈ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ, ਜਿਵੇਂ Koder.ai, ਇਹ ਪੂਰੇ ਐਪ ਸਟੇਟ ਨੂੰ ਵੀ ਸੰਭਾਲ ਸਕਦਾ ਹੈ)। ਪਰ ਇਹ ਗਲਤ ਧਾਰਣਾਂ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਜੇ ਤੁਹਾਡੇ ਨਵੇਂ ਫੀਚਰ ਨੂੰ ਉਹ ਡਾਟਾਬੇਸ ਕਾਲਮ ਚਾਹੀਦਾ ਹੈ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੋਡ ਰੋਲਬੈਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੇ ਚੱਲਣ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਕਰੇਗਾ। ਤੁਹਾਨੂੰ ਡਾਟਾ ਬਦਲਾਵਾਂ, ਅਨੁਕੂਲਤਾ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਕ੍ਰਮ ਲਈ ਇੱਕ ਯੋਜਨਾ ਦੀ ਲੋੜ ਹੋਏਗੀ।
ਮਨੋਵਿਗਿਆਨਕ ਬਦਲਾ ਇਹ ਹੈ ਕਿ ਸਨੇਪਸ਼ਾਟਿੰਗ ਨੂੰ ਇਕ ਆਦਤ ਸਮਝੋ, ਬਚਾਅ ਬਟਨ ਨਹੀਂ। ਖਤਰਨਾਕ ਕਦਮਾਂ ਤੋਂ ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਸਨੇਪਸ਼ਾਟ ਲਓ, ਨਾ ਕਿ ਕੁਝ ਟੁੱਟਣ ਤੋਂ ਬਾਅਦ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋਗੇ ਅਤੇ ਸ਼ਾਂਤ ਮਹਿਸੂਸ ਕਰੋਗੇ ਕਿਉਂਕਿ ਹਮੇਸ਼ਾ ਇੱਕ ਸਾਫ਼ “ਆਖਰੀ ਜਾਣ-ਪਛਾਣਯੋਗ-ਚੰਗਾ” ਤੁਹਾਡੇ ਕੋਲ ਮੁੜ ਆਉਣ ਲਈ ਹੋਵੇਗਾ।
ਜਦੋਂ ਕੋਈ ਬਦਲਾਅ ਇਕੱਠੇ ਕਈ ਚੀਜ਼ਾਂ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਨੇਪਸ਼ਾਟ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲਾਭਕਾਰੀ ਹੁੰਦਾ ਹੈ।
ਸਕੀਮਾ ਦਾ ਕੰਮ ਸਭ ਤੋਂ ਸਪੱਠ ਉਦਾਹਰਣ ਹੈ: ਇੱਕ ਕਾਲਮ ਦਾ ਨਾਮ ਬਦਲੋ ਅਤੇ ਤੁਸੀਂ ਚੁਪਚਾਪ APIs, background jobs, exports ਅਤੇ ਰਿਪੋਰਟਸ ਤੋੜ ਸਕਦੇ ਹੋ ਜਿੰਨ੍ਹਾਂ ਨੂੰ ਪੁਰਾਣੇ ਨਾਮ ਦੀ ਉਮੀਦ ਰਹਿੰਦੀ ਹੈ। Auth ਕੰਮ ਵੀ ਐਸਾ ਹੀ ਹੈ: ਇੱਕ ਛੋਟਾ ਨਿਯਮ ਐਡਮਿਨਜ਼ ਨੂੰ ਲਾਕ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚ ਦੇ ਸਕਦਾ ਹੈ। UI ਰਿਰਾਈਟ ਸਿਆਣੀ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਕਸਰ ਵਿਜ਼ੂਅਲ ਬਦਲਾਵਾਂ ਨੂੰ ਬਿਹੇਵਿਯਰ ਬਦਲਾਵਾਂ ਨਾਲ ਮਿਲਾਉਂਦੀ ਹੈ, ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਐਜ-ਸਟੇਟਸ ਵਿੱਚ ਛੁਪ ਜਾਂਦੇ ਹਨ।
ਸਧਾਰਨ ਨਿਯਮ: ਉਹਨਾਂ ਹਰ ਚੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਨੇਪਸ਼ਾਟ ਲਓ ਜੋ ਡਾਟਾ ਦੀ ਸ਼ਕਲ, ਪਛਾਣ ਅਤੇ ਪਹੁੰਚ, ਜਾਂ ਇਕੱਠੇ ਕਈ ਸਕ੍ਰੀਨ ਨੂੰ ਬਦਲਦਾ ਹੋਵੇ।
ਘੱਟ-ਖਤਰੇ ਵਾਲੇ ਸੋਧ ਆਮ ਤੌਰ 'ਤੇ ਰੋਕ-ਇੱਕ-ਸਨੇਪਸ਼ਾਟ ਲੈਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਕਾਪੀ ਬਦਲਾਅ, ਛੋਟੇ ਸਪੇਸਿੰਗ ਟਵਿਕਸ, ਇੱਕ ਛੋਟਾ ਵੈਲੀਡੇਸ਼ਨ ਰੂਲ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਹੈਲਪਰ ਫਂਕਸ਼ਨ ਕਲੀਨਅਪ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟਾ ਪ੍ਰਭਾਵ ਰੱਖਦੇ ਹਨ। ਫਿਰ ਵੀ, ਜੇ ਇਹ ਤੁਹਾਨੂੰ ਫੋਕਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ ਤਾਂ ਤੁਸੀਂ ਸਨੇਪਸ਼ਾਟ ਲੈ ਸਕਦੇ ਹੋ, ਪਰ ਹਰ ਛੋਟੀ ਸੋਧ ਲਈ ਰੁਕਣਾ ਜਰੂਰੀ ਨਹੀਂ।
ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਬਦਲਾਵ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਅਕਸਰ "ਹੈਪੀ ਪਾਥ" ਟੈਸਟਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ ਪਰ ਪੁਰਾਣੀਆਂ ਰੋਲਜ਼ ਵਿੱਚ null ਮੁੱਲਾਂ, ਅਜਿਹੇ ਯੂਜ਼ਰ ਜੋ ਅਸਧਾਰਣ ਰੋਲ ਸਮੀਕਰਨ ਰੱਖਦੇ ਹਨ, ਜਾਂ UI ਸਟੇਟ ਜਿੱਥੇ ਤੁਸੀਂ ਹੱਥੋਂ ਰਾਹੀਂ ਨਹੀਂ ਪਹੁੰਚਦੇ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਸਨੇਪਸ਼ਾਟ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਦਬਾਅ ਹੇਠ ਸ਼ੀਘ੍ਰੀ ਪਛਾਣ ਸਕੋ। ਨਾਮ ਅਤੇ ਨੋਟਸ ਉਹ ਹਨ ਜੋ ਰੋਲਬੈਕ ਨੂੰ ਇੱਕ ਸ਼ਾਂਤ, ਤੇਜ਼ ਫ਼ੈਸਲਾ ਬਣਾਉਂਦੇ ਹਨ।
ਚੰਗਾ ਲੇਬਲ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:
ਇਸਨੂੰ ਛੋਟਾ ਪਰ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ। "before update" ਜਾਂ "try again" ਵਰਗੇ ਅਸਪਸ਼ਟ ਨਾਮਾਂ ਤੋਂ ਬਚੋ।
ਇੱਕ ਪੈਟਰਨ ਚੁਣੋ ਅਤੇ ਉਸ ਤੇ ਟਿਕੇ ਰਹੋ। ਉਦਾਹਰਣ ਵਜੋਂ:
[WIP] Auth: add magic link (prep for OAuth)[GOLD] DB: users table v2 (passes smoke tests)[WIP] UI: dashboard layout refactor (next: charts)[GOLD] Release: billing fixes (deployed)Hotfix: login redirect loop (root cause noted)ਪਹਿਲਾਂ Status, ਫਿਰ ਏਰੀਆ, ਫਿਰ ਐਕਸ਼ਨ, ਫਿਰ ਇੱਕ ਛੋਟਾ "next"। ਉਹ ਆਖਰੀ ਹਿੱਸਾ ਹਫ਼ਤੇ ਬਾਅਦ ਬਹੁਤ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ।
ਨਾਂ ਹੀ ਕਾਫ਼ੀ ਹਨ। ਨੋਟਸ ਤੁਹਾਡੇ ਭਵਿੱਖ ਦੇ ਆਪ ਨੂੰ ਉਹ ਚੀਜ਼ਾਂ ਯਾਦ ਦਵਾਉਂਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਭੁੱਲ ਜਾਉਗੇ: ਜੋ ਧਾਰਣਾਂ ਤੁਸੀਂ ਬਣਾਈਆਂ, ਤੁਸੀਂ ਕੀ ਟੈਸਟ ਕੀਤਾ, ਕੀ ਟੁੱਟਿਆ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਚੀਜ਼ ਤੁਸੀਂ ਜਾਨ-ਬੂਝ ਕੇ ਅਣਦੇਖੀ ਕੀਤੀ।
ਚੰਗੀਆਂ ਨੋਟਸ ਆਮ ਤੌਰ 'ਤੇ ਧਾਰਣਾਵਾਂ, 2-3 ਜਲਦੀ ਟੈਸਟ ਕਦਮ, ਜਾਣੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਅਤੇ ਕਿਸੇ ਵੀ ਖਤਰਨਾਕ ਵੇਰਵੇ (ਸਕੀਮਾ ਸੁਧਾਰ, permission ਬਦਲਾਵ, routing ਬਦਲਾਅ) ਸ਼ਾਮਿਲ ਕਰਦੀਆਂ ਹਨ।
ਸਿਰਫ਼ ਉਸੇ ਸਨੇਪਸ਼ਾਟ ਨੂੰ GOLD ਮਾਰਕ ਕਰੋ ਜਦੋਂ ਉਹ ਬਿਨਾਂ ਹੈਰਾਨੀ ਦੇ ਵਾਪਸ ਆ ਕੇ ਕੰਮ ਜਾਰੀ ਰੱਖਣ ਯੋਗ ਹੋਵੇ: ਮੂਲ ਫਲੋ ਕੰਮ ਕਰ ਰਹੇ ਹੋਣ, ਏਰਰ ਸਮਝੇ ਗਏ ਹੋਣ, ਅਤੇ ਤੁਸੀਂ ਉਥੋਂ ਤੋਂ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ। ਬਾਕੀ ਸਾਰੇ WIP ਰਹਿਣ। ਇਹ ਛੋਟੀ ਆਦਤ ਰੋਲਬੈਕ 'ਤੇ ਵਾਪਸੀ ਲਈ ਇੱਕ ਐਸਾ ਬਿੰਦੂ ਦਿੰਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਵਿਸ਼ਵਾਸ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਮਜ਼ਬੂਤ ਚੱਕਰ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਜਾਣ-ਪਛਾਣਯੋਗ-ਚੰਗੇ ਬਿੰਦੂ ਤੋਂ ਹੀ ਅੱਗੇ ਵਧੋ।
ਸਨੇपਸ਼ਾਟ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਐਪ ਹਕੀਕਤ ਵਿੱਚ ਚੱਲਦੀ ਹੈ ਅਤੇ ਮੁੱਖ ਫਲੋਜ਼ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ: ਕੀ ਤੁਸੀਂ ਮੁੱਖ ਸਕ੍ਰੀਨ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ, ਲਾਗਇਨ ਕਰ ਸਕਦੇ ਹੋ (ਜੇ ਐਪ ਵਿੱਚ ਹੈ), ਅਤੇ ਇੱਕ ਮੁੱਖ ਇੱਕਸ਼ਨ ਬਿਨਾਂ ਏਰਰ ਦੇ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ? ਜੇ ਕੁਝ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਫਲੇਕੀ ਹੈ, ਪਹਿਲਾਂ ਉਸਨੂੰ ਠੀਕ ਕਰੋ—ਨਹੀਂ ਤਾਂ ਤੁਹਾਡਾ ਸਨੇਪਸ਼ਾਟ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਸੇਵ ਕਰ ਲਏਗਾ।
ਸਨੇਪਸ਼ਾਟ ਬਣਾਓ, ਫਿਰ ਇੱਕ ਇਕ-ਲਾਈਨ ਨੋਟ ਲਿਖੋ ਕਿ ਇਹ ਕਿਉਂ ਹੈ। ਆਉਣ ਵਾਲੇ ਖਤਰੇ ਦਾ ਵਰਣਨ ਕਰੋ, ਨਾ ਕਿ ਮੌਜੂਦਾ ਸਥਿਤੀ।
ਉਦਾਹਰਨ: “Before changing users table + adding organization_id” ਜਾਂ “Before auth middleware refactor to support SSO”.
ਇੱਕ iteration ਵਿੱਚ ਕਈ ਵੱਡੀਆਂ ਸੋਧਾਂ ਇਕੱਠੀਆਂ ਨਾ ਕਰੋ (ਸਕੀਮਾ ਦੇ ਨਾਲ auth ਅਤੇ UI). ਇੱਕ ਹੀ ਸਲਾਈਸ ਚੁਣੋ, ਉਸਨੂੰ ਖਤਮ ਕਰੋ, ਅਤੇ ਰੁਕੋ।
ਇੱਕ ਚੰਗਾ "ਇੱਕ ਸੋਧ" ਇਹ ਹੈ: “ਨਵਾਂ ਕਾਲਮ ਜੋੜੋ ਅਤੇ ਪੁਰਾਣਾ ਕੋਡ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖੋ” ਨਾ ਕਿ “ਸਾਰੀ ਡਾਟਾ ਮਾਡਲ ਬਦਲੋ ਅਤੇ ਹਰ ਸਕ੍ਰੀਨ ਅਪਡੇਟ ਕਰੋ”।
ਹਰ ਕਦਮ ਤੋਂ ਬਾਅਦ ਉਹੀ ਛੋਟੀ ਜਾਂਚ ਚਲਾਓ ਤਾਂ ਜੋ ਨਤੀਜੇ ਤੁਲਨਾਤਮਕ ਹੋਣ। ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਇਹ ਕਰੋ।
ਜਦੋਂ ਸੋਧ ਕੰਮ ਕਰ ਰਹੀ ਹੋਵੇ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਫਿਰ ਤੋਂ ਇੱਕ ਸਾਫ ਬੇਸਲਾਈਨ ਹੋਵੇ, ਇੱਕ ਹੋਰ ਸਨੇਪਸ਼ਾਟ ਲਓ। ਉਹ ਤੁਹਾਡੇ ਅਗਲੇ ਕਦਮ ਲਈ ਨਵਾਂ ਸੇਫ਼ ਪੌਇੰਟ ਬਣ ਜਾਂਦਾ ਹੈ।
ਡਾਟਾਬੇਸ ਬਦਲਾਅ "ਛੋਟਾ" ਲੱਗਦੇ ਹਨ ਜਦ ਤੱਕ ਉਹ ਸਾਈਨਅਪ, ਰਿਪੋਰਟਾਂ ਜਾਂ ਕਿਸੇ background job ਨੂੰ ਤੋੜ ਨਾ ਦੇਣ। ਸਕੀਮਾ ਕੰਮ ਨੂੰ ਇੱਕ ਲੜੀ ਸੇফ਼ ਚੈੱਕਪੋਇੰਟਸ ਵਜੋਂ ਵੇਖੋ, ਨਾ ਕਿ ਇੱਕ ਵੱਡੀ ਛਾਲ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਨੇਪਸ਼ਾਟ ਲਓ। ਫਿਰ ਸਧਾਰਣ-ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਬੇਸਲਾਈਨ ਲਿਖੋ: ਕਿਹੜੇ ਟੇਬਲ ਸ਼ਾਮਿਲ ਹਨ, ਕਿਹੜੀਆਂ ਸਕਰੀਨ ਜਾਂ API ਕਾਲ ਉਹ ਪੜ੍ਹਦੇ ਹਨ, ਅਤੇ "ਸਹੀ" ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ (ਜ਼ਰੂਰੀ ਫੀਲਡ, unique ਨਿਯਮ, ਉਮੀਦ ਕੀਤੀ ਰੋ-ਕਾਉਂਟ)। ਇਹ ਕੁਝ ਮਿੰਟ ਲੈਂਦਾ ਹੈ ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਵਿਵਹਾਰ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਘੰਟਿਆਂ ਬਚਾ ਸਕਦਾ ਹੈ।
ਅਕਸਰ ਵਰਤਣਯੋਗ ਸੇਵ-ਪੌਇੰਟਸ:
ਇੱਕ ਵੱਡੀ migration ਤੋਂ ਬਚੋ ਜੋ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਸਾਰੀ ਨਾਂਬਦਲੀ ਕਰ ਦੇਵੇ। ਛੋਟੇ ਯੂਨਿਟਸ ਵਿੱਚ ਵੰਡੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਅਤੇ ਰੋਲਬੈਕ ਕਰ ਸਕੋ।
ਹਰ ਚੈੱਕਪੋਇੰਟ ਤੋਂ ਬਾਅਦ, ਸਿਰਫ਼ ਹੈਪੀ ਪਾਥ ਨਹੀਂ ਵੇਰੀਫਾਈ ਕਰੋ। CRUD ਫਲੋਜ਼ ਜੋ ਬਦਲੀ ਗਈ ਟੇਬਲਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਪਰ exports (CSV ਡਾਊਨਲੋਡ, ਇਨਵੌਇਸ, ਐਡਮਿਨ ਰਿਪੋਰਟਸ) ਬਾਰੇ ਵੀ ਸੋਚੋ ਕਿਉਂਕਿ ਉਹ ਅਕਸਰ ਪੁਰਾਣੀਆਂ ਕਵੇਰੀਆਂ ਵਰਤਦੇ ਹਨ।
ਰੋਲਬੈਕ ਦਾ ਰਸਤਾ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਓ। ਜੇ ਤੁਸੀਂ ਨਵਾਂ ਕਾਲਮ ਜੋੜਦੇ ਹੋ ਅਤੇ ਉਸ 'ਤੇ ਲਿਖਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਜੇ ਤੁਸੀਂ ਵਾਪਸ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੋਵੇਗਾ: ਪੁਰਾਣਾ ਕੋਡ ਨਵੇਂ ਕਾਲਮ ਨੂੰ ਨਿਰਦੋਸ਼ੀ ਤਰੀਕੇ ਨਾਲ ਅਣਦੇਖਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਨੂੰ ਉਲਟ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਪਏਗੀ? ਜੇ ਤੁਸੀਂ ਨੈਰ-ਮਾਇਗ੍ਰੇਟਡ ਡਾਟਾ ਨਾਲ ਰਹਿਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ, ਤਾਂ ਤਯਾਰ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਉਸਨੂੰ ਡਿਟੈਕਟ ਅਤੇ ਪੂਰਾ ਕਰੋਗੇ ਜਾਂ ਕਿਵੇਂ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਛੱਡ ਦਿਓਗੇ।
Auth ਬਦਲਾਅ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਤੁਹਾਨੂੰ (ਅਤੇ ਯੂਜ਼ਰਾਂ) ਨੂੰ ਲਾਕ ਆਉਟ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਸੇਵ-ਪੌਇੰਟ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਖਤਰਨਾਕ ਸੋਧ ਆਜ਼ਮਾ ਸਕਦੇ ਹੋ, ਉਸਨੂੰ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਕਰ ਸਕਦੇ ਹੋ。
Auth ਨੂੰ ਛੁਹਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੇਪਸ਼ਾਟ ਲਓ। ਫਿਰ ਅੱਜ ਜੋ ਹੈ ਉਹ ਲਿਖ ਕੇ ਰੱਖੋ, ਭਾਵੇਂ ਇਹ ਸਾਫ਼-ਸੁੱਥਰਾ ਲੱਗੇ। ਇਹ ਰੋਕਦਾ ਹੈ “ਮੈਨੂੰ ਲੱਗਦਾ ਸੀ ਕਿ ਐਡਮਿਨ ਅਜੇ ਵੀ ਲੌਗ ਇਨ ਕਰ ਸਕਦੇ ਹਨ” ਵਾਲੀਆਂ ਹੈਰਾਨੀਆਂ।
ਨਿਊਨਤਮ ਚੀਜ਼ਾਂ ਕੈਪਚਰ ਕਰੋ:
ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਸ਼ੁਰੂ ਕਰੋ, ਤਾਂ ਇੱਕ ਵਕਤ ਵਿੱਚ ਇੱਕ ਨਿਯਮ ਮੂਵ ਕਰੋ। ਜੇ ਤੁਸੀਂ role checks, token logic ਅਤੇ login screens ਤਿੰਨਹਾਂ ਨੂੰ ਇਕੱਠੇ ਬਦਲੋਗੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕਿਸਨੇ ਮੁਸਲਿਮੀ ਪੈਦਾ ਕੀਤੀ।
ਇੱਕ ਚੰਗੀ ਰਿਥਮ ਇਹ ਹੈ: ਇੱਕ ਹਿੱਸਾ ਬਦਲੋ, ਇੱਕੋ ਜਿਹੇ ਛੋਟੇ checks ਚਲਾਓ, ਫਿਰ ਜੇ ਠੀਕ ਹੈ ਤਾਂ ਫਿਰ ਸਨੇਪਸ਼ਾਟ ਲਓ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ "editor" ਰੋਲ ਜੋੜਦੇ ਹੋਏ ਸਰਵਰ ਸਾਈਡ ਤੇ ਬਣਾਉ ਅਤੇ ਅਸਾਈਨਮੈਂਟ ਪਹਿਲਾਂ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਲੌਗਇਨ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਫਿਰ ਇੱਕ permission gate ਜੋੜੋ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ।
ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਤਿੰਨ ਕੋਣਾਂ ਤੋਂ access control ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: normal users admin-only actions ਨਾ ਦੇਖਣ, admins settings ਅਤੇ user management ਤੱਕ ਪਹੁੰਚ ਸਕਣ, ਅਤੇ edge cases ਨੂੰ ਵੀ ਕਵਰ ਕਰੋ (expired sessions, password reset, disabled accounts, ਅਤੇ ਜਿਹੜੇ ਯੂਜ਼ਰ ਤੁਸੀਂ ਟੈਸਟ ਦੌਰਾਨ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੇ ਉਹਨਾਂ ਦੇ ਨਾਲ ਸਾਈਨ-ਇਨ)।
ਲੋਕ ਇੱਕ ਗੱਲ ਭੁੱਲ ਜਾਂਦੇ ਹਨ: secrets ਅਕਸਰ ਕੋਡ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੋਡ ਰੋਲਬੈਕ ਕਰੋ ਪਰ ਨਵੇਂ ਕੀਜ਼ ਅਤੇ callback ਸੈਟਿੰਗ ਛੱਡ ਦਿਓ, ਤਾਂ auth ਅਜੀਬ ਤਰੀਕੇ ਨਾਲ ਟੁੱਟ ਸਕਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਐਨਵਾਇਰਨਮੈਂਟ ਬਦਲਾਅ بارے ਸਾਫ਼ ਨੋਟ ਛੱਡੋ ਜੋ ਤੁਸੀਂ ਕੀਤਾ ਜਾਂ ਰਿਵਰਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
UI ਰਿਰਾਈਟਸ ਖਤਰਨਾਕ ਲੱਗਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵਿਜ਼ੂਅਲ ਕੰਮ ਨੂੰ ਬਿਹੇਵਿਯਰ ਬਦਲਾਵਾਂ ਨਾਲ ਮਿਲਾਉਂਦੀਆਂ ਹਨ। UI ਜਦ ਤੱਕ ਸਥਿਰ ਅਤੇ ਭਰੋਸੇਯੋਗ ਨ ਹੋਵੇ, ਉਸ ਵੇਲੇ ਇੱਕ ਸੇਵ-ਪੌਇੰਟ ਬਣਾਓ—ਭਾਵੇਂ ਉਹ ਸੁੰਦਰ ਨਾ ਹੋਵੇ। ਉਹ ਤੁਹਾਡਾ ਵਰਕਿੰਗ ਬੇਸਲਾਈਨ ਹੋਵੇਗਾ: ਉਹ ਆਖਰੀ ਵਰਜ਼ਨ ਜੋ ਤੁਸੀਂ ਜੇਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ।
UI ਰਿਰਾਈਟਸ ਅਕਸਰ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਡੇ ਸਵਿੱਚ ਵਜੋਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕੰਮ ਨੂੰ ਅਜਿਹੇ ਸਲਾਈਸ ਵਿੱਚ ਵੰਡੋ ਜੋ ਖੁਦ-ਮੈਂ ਟਿਕ ਸਕਣ: ਇੱਕ ਸਕ੍ਰੀਨ, ਇੱਕ ਰਾਊਟ, ਜਾਂ ਇੱਕ ਕੰਪੋਨੇਟ।
ਜੇ ਤੁਸੀਂ checkout ਰਿਰਾਈਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ Cart, Address, Payment, ਅਤੇ Confirmation ਵਿੱਚ ਵੰਡੋ। ਹਰ ਸਲਾਈਸ ਤੋਂ ਬਾਅਦ, ਪਹਿਲਾਂ ਪੁਰਾਣੇ ਬਿਹੇਵਿਯਰ ਨਾਲ ਮੇਲ ਕਰੋ। ਫਿਰ ਲੇਆਉਟ, ਕਾਪੀ, ਅਤੇ ਛੋਟੇ ਇੰਟਰਐਕਸ਼ਨਾਂ ਨੂੰ ਸੁਧਾਰੋ। ਜਦੋਂ ਉਹ ਸਲਾਈਸ "ਕਾਫੀ ਠੀਕ" ਲੱਗੇ, ਉਸਦਾ ਸਨੇਪਸ਼ਾਟ ਲਓ।
ਹਰ ਸਲਾਈਸ ਤੋਂ ਬਾਅਦ, ਨਿਮਨਲਿਖਿਤ ਤੇਜ਼ ਜਾਂਚਾਂ ਚਲਾਓ:
ਆਮ ਤੌਰ 'ਤੇ ਫੇਲ੍ਹ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ: ਨਵਾਂ Profile ਸਕ੍ਰੀਨ ਲੇਆਉਟ ਠੀਕ ਹੈ, ਪਰ ਇੱਕ ਫੀਲਡ ਸੇਵ ਨਹੀਂ ਹੋ ਰਹੀ ਕਿਉਂਕਿ ਇੱਕ ਕੰਪੋਨੈਂਟ ਨੇ payload ਦਾ ਆਕਾਰ ਬਦਲ ਦਿੱਤਾ। ਇੱਕ ਚੰਗੀ ਚੈੱਕਪੋਇੰਟ ਨਾਲ, ਤੁਸੀਂ ਰੋਲਬੈਕ ਕਰਕੇ ਤੁਲਨਾ ਕਰ ਸਕੋ ਅਤੇ ਵਿਜ਼ੂਅਲ ਸੁਧਾਰ ਦੁਬਾਰਾ ਲਗਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕੰਮ ਦੇ ਦਿਨ ਗਵਾੲੇ।
ਰੋਲਬੈਕ ਨੂੰ ਨਿਰਵਿਕਾਰਤ ਮਹਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਘਬਰਾਹਟ ਨਹੀਂ। ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਪੂਰਾ ਰੋਲਬੈਕ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਉਲਟਣਾ ਹੈ।
ਪੂਰਾ ਰੋਲਬੈਕ ਓਸ ਵਕਤ ਵਰਤੋਂਯੋਗ ਹੈ ਜਦੋਂ ਐਪ ਕਈ ਸਥਾਨਾਂ 'ਤੇ ਟੁੱਟੀ ਹੋਵੇ। ਅੰਸ਼ਿਕ ਉਲਟਣਾ ਓਸ ਵੇਲੇ ਠੀਕ ਹੈ ਜਦੋਂ ਇੱਕ ਖਾਸ ਹਿੱਸਾ ਗਲਤ ਹੋਵੇ।
ਆਪਣੇ ਆਖਰੀ ਸਟੇਬਲ ਸਨੇਪਸ਼ਾਟ ਨੂੰ ਘਰ-ਦੇ-ਅਧਾਰ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ:
ਫਿਰ ਪੰਜ ਮਿੰਟ ਬੁਨਿਆਦੀ ਚੈਕਾਂ 'ਤੇ ਖਰਚ ਕਰੋ—ਰੋਲਬੈਕ ਕਰਨਾ ਆਸਾਨ ਹੈ ਪਰ ਇੱਕ ਖਾਮੋਸ਼ ਟੁੱਟ ਜਿਵੇਂ background job ਨਾ ਚਲਣਾ ਛੱਡ ਸਕਦੇ ਹੋ।
ਤੇਜ਼ ਚੈੱਕ ਜੋ ਜਿਆਦਾਤਰ ਮੁੱਦਿਆਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ:
ਉਦਾਹਰਨ: ਤੁਸੀਂ ਵੱਡਾ auth ਰੀਫੈਕਟਰ ਕੀਤਾ ਅਤੇ ਆਪਣਾ ਐਡਮਿਨ ਅਕਾਉਂਟ ਬਲੌਕ ਹੋ ਗਿਆ। ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਨੇਪਸ਼ਾਟ ਰੋਲਬੈਕ ਕਰੋ, ਲੌਗਇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ edits ਨੂੰ ਫੇਰ ਲਗਾਓ: ਪਹਿਲਾਂ roles, ਫਿਰ middleware, ਫਿਰ UI gating। ਜੇ ਫਿਰ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣੋਗੇ ਕਿ ਕਿਹੜਾ ਕਦਮ ਕਾਰਨ ਸੀ।
ਆਖ਼ਿਰ ਵਿੱਚ, ਇੱਕ ਛੋਟਾ ਨੋਟ ਛੱਡੋ: ਕੀ ਟੁੱਟਿਆ, ਤੁਸੀਂ ਕਿਵੇਂ ਨੋਟਿਸ ਕੀਤਾ, ਕੀ ਠੀਕ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਅਗਲੀ ਵਾਰੀ ਤੁਸੀਂ ਕੀ ਵੱਖਰਾ ਕਰੋ ਗੇ। ਇਹ ਰੋਲਬੈਕਸ ਨੂੰ ਸਿਖਲਾਈ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਸਮਾਂ-ਨੁਕਸਾਨ ਵਿੱਚ।
ਰੋਲਬੈਕ ਦਰਦ ਆਮ ਤੌਰ 'ਤੇ ਅਸਪਸ਼ਟ ਸੇਵ-ਪੌਇੰਟਸ, ਮਿਲਾ-ਜੁਲਾ ਬਦਲਾਅ, ਅਤੇ ਛੱਡੇ ਗਏ ਚੈੱਕਾਂ ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
ਛੋਟੀਆਂ ਪਰਪਟੀਆਂ:
ਬਹੁਤ ਰੇਅਰ ਸੇਵਿੰਗ ਇੱਕ ਕਲਾਸਿਕ ਗਲਤੀ ਹੈ। ਲੋਕ ਇੱਕ "ਉਪਰਾਂਤ ਛੇਤੀ" ਸਕੀਮਾ ਟਵੀਕ, ਇੱਕ ਛੋਟਾ auth rule, ਅਤੇ UI ਸੁਧਾਰ ਇੱਕੱਠੇ ਲਾਂਦੇ ਹਨ, ਫਿਰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਟੁੱਟਿਆ।
ਇਸ ਦੇ ਉਲਟ, ਨੋਟਸ ਤੋਂ ਬਿਨਾਂ ਬਾਰ-ਬਾਰ ਸੇਵਿੰਗ। ਦੱਸ ਸਨੇਪਸ਼ਾਟ ਜਿਨ੍ਹਾਂ ਦਾ ਨਾਮ "test" ਜਾਂ "wip" ਹੋਵੇ, ਉਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇੱਕੋ ਹੀ ਸਨੇਪਸ਼ਾਟ ਬਣ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕਿਹੜਾ ਸੁਰੱਖਿਅਤ ਹੈ।
ਕਈ ਖਤਰਨਾਕ ਬਦਲਾਵ ਇਕੱਠੇ ਮਿਲਾ ਦੇਣਾ ਇੱਕ ਹੋਰ ਜਾਲ ਹੈ। ਜੇ ਤਕਨੀਕੀ, permission, ਅਤੇ UI ਬਦਲਾਵ ਇਕੱਠੇ ਆ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਰੋਲਬੈਕ ਇੱਕ ਅਨੁਮਾਨ ਖੇਡ ਬਣ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਚੰਗੇ ਹਿੱਸੇ (ਜਿਵੇਂ UI ਸੁਧਾਰ) ਨੂੰ ਰੱਖਣ ਦੀ ਚੋਣ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਦੋਂ ਜੋਖ਼ਿਮ ਭਾਗ (ਜਿਵੇਂ migration) ਨੂੰ ਵਾਪਸ ਲਿਆਉਣੀ ਪਵੇ।
ਇਕ ਹੋਰ ਮੁੱਦਾ: ਡਾਟਾ ਧਾਰਣਾਂ ਅਤੇ ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਚੈੱਕ ਕੀਤੇ ਬਿਨਾਂ ਰੋਲਬੈਕ। ਰੋਲਬੈਕ ਤੋਂ ਬਾਅਦ ਡਾਟਾਬੇਸ ਵਿੱਚ ਨਵੇਂ ਕਾਲਮ, ਅਣਉਮੀਦ ਨੱਲ, ਜਾਂ ਅਧੂਰੇ ਮਾਈਗ੍ਰੇਟਡ ਰੋ ਹੋ ਸਕਦੇ ਹਨ। ਜਾਂ ਤੁਸੀਂ ਪੁਰਾਣੀ auth ਲਾਜਿਕ ਬਹਾਲ ਕਰ ਸਕਦੇ ਹੋ ਜਦ ਕਿ ਯੂਜ਼ਰ ਨਵੇਂ ਨਿਯਮਾਂ ਹੇਠ ਬਣਾਏ ਗਏ ਹੋਣ—ਇਹ ਅਣਮਿਲਾਪ ਇਹ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ "ਰੋਲਬੈਕ ਨੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ" ਜਦੋਂ ਅਸਲ ਵਿੱਚ ਉਸਨੇ ਕੀਤਾ।
ਸਧਾਰਨ ਤਰੀਕੇ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਦੇ ਹਨ:
ਸਨੇਪਸ਼ਾਟ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦਾ ਕਿਸੇ ਖਾਸ ਸਮੇਂ ਦਾ ਜਮਾਂ ਹੋਇਆ ਸੇਵ-ਪੌਇੰਟ ਹੁੰਦਾ ਹੈ। ਡਿਫਾਲਟ ਆਦਤ ਇਹ ਹੈ: ਖਤਰਨਾਕ ਬਦਲਾਅ ਤੋਂ ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਸਨੇਪਸ਼ਾਟ ਲਓ, ਤਾਂ ਜੋ ਜੇ ਕੁਝ ਟੁੱਟੇ ਤਾਂ ਤੁਸੀਂ ਜਾਣ-ਪਛਾਣਯੋਗ-ਚੰਗੀ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਆ ਸਕੋ।
ਇਹ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਫੇਲਯਰ ਅਪਰੋਖ ਹੁੰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਸਕੀਮਾ ਬਦਲ ਦੂਰ ਦੀ ਕਿਸੇ ਰਿਪੋਰਟ ਨੂੰ ਤੋੜ ਦੇਵੇ, ਇੱਕ auth ਬਦਲਾਵ ਨੇ ਤੁਹਾਨੂੰ ਲਾਕ ਕਰ ਦਿੱਤਾ, ਜਾਂ ਇੱਕ UI ਰਿਰਾਈਟ ਰੀਅਲ ਡੇਟਾ ਨਾਲ ਫੇਲ ਹੋ ਜਾਵੇ)।
ਉਹ ਬਦਲਾਅ ਜਿਨ੍ਹਾਂ ਦਾ ਬਲਾਸਟ-ਰੇਡੀਅਸ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਨੇਪਸ਼ਾਟ ਲਵੋ:
ਛੋਟੇ ਸੋਧ (ਕਾਪੀ ਸੰਸ਼ੋਧਨ, ਮਾਈਨਰ ਸਪੇਸਿੰਗ, ਛੋਟੇ ਰਿਫੈਕਟਰ) ਲਈ ਹਰ ਵਾਰ ਰੋਕ ਕੇ ਸਨੇਪਸ਼ਾਟ ਲੈਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੁੰਦਾ।
ਇੱਕ ਲਗਾਤਾਰ ਫਾਰਮੈਟ ਵਰਤੋ ਜੋ ਇਹ ਜਵਾਬ ਦੇ:
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਫਾਰਮੈਟ: STATUS + Area + Action (+ next step).
ਉਦਾਹਰਣ:
ਸਿਰਫ਼ ਉਹਨਾਂ ਸਨੇਪਸ਼ਾਟਸ ਨੂੰ GOLD ਮਾਰਕ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਬਿਨਾਂ ਅਚਾਨਕੀਆਂ ਦੇ ਉਸ ਤੇ ਵਾਪਸ ਆ ਕੇ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕੋ:
ਆਮ ਤੌਰ 'ਤੇ GOLD ਮਤਲਬ:
ਬਾਕੀ ਸਾਰੇ WIP ਹਨ। ਇਹ ਆਦਤ ਰੋਲਬੈਕ ਦੌਰਾਨ ਗਲਤ-ਸਥਿਰਤਾ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਟੈਸਟ ਛੋਟੇ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਹਕੀਕਤ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਕਰੋ:
ਮਕਸਦ ਪੂਰਨ ਟੈਸਟ ਨਹੀਂ—ਸਿਰਫ ਇਹ ਪ੍ਰੂਵ ਕਰਨਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸੇਫ਼ ਬੇਸਲਾਈਨ ਹੈ।
ਅਮਲੀ ਸੇਵ-ਪੌਇੰਟਸ ਦੀ ਲੜੀ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦੀ ਹੈ:
Auth ਬਦਲਾਅ ਤੁਹਾਨੂੰ ਜਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲਾਕ ਕਰ ਦੇ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਸੋਧ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਨੇਪਸ਼ਾਟ ਲਓ ਅਤੇ ਮੌਜੂਦਾ ਸਥਿਤੀ ਨੋਟ ਕਰ ਲਓ—ਇਹ ਭਾਵਨਾਵੀ ਤੌਰ 'ਤੇ ਆਮ ਗੱਲਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਮੁੱਢਲੀ ਚੀਜ਼ਾਂ ਲਿਖੋ:
ਇਕ ਵਾਰੀ ਵਿੱਚ ਇੱਕ ਨਿਯਮ ਬਦਲੋ — role checks, token logic ਅਤੇ login screens ਨੂੰ ਇਕੱਠੇ ਬਦਲਣਾ ਅਸਾਨੀ ਨਾਲ ਪਤਾ ਨਹੀਂ ਲਗਾਉਂਦਾ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਟੁੱਟਿਆ।
UI ਰਿਰਾਈਟਸ ਦਿਖਣ ਵਿੱਚ ਤਬਦੀਲੀ ਦੇ ਨਾਲ-ਨਾਲ ਬਿਹੇਵियर ਬਦਲ ਸਕਦੀਆਂ ਹਨ—ਇਸ ਲਈ UI ਸਟੇਬਲ ਅਤੇ ਅੰਦਾਜ਼ਨ-ਯੋਗ ਰਹਿਣ 'ਤੇ ਸਨੇਪਸ਼ਾਟ ਬਣਾਓ, ਭਾਵੇਂ ਉਹ ਸੁੰਦਰ ਨਾ ਹੋਵੇ। ਉਹ ਤੁਹਾਡਾ "ਆਖਰੀ ਜਿਹੜਾ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਸੰਸਕਰਣ" ਬਣੇਗਾ ਜੇ ਤੁਹਾਨੂੰ ਵਾਪਸ ਜਾਣਾ ਪਏ।
ਟੁਕੜਿਆਂ ਵਿੱਚ ਰਿਰਾਈਟ ਕਰੋ:
ਹਰ ਸਲਾਈਸ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਦੁਹਰਾਓ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਦੀਆਂ ਹਨ: ਨੈਵੀਗੇਸ਼ਨ, ਫਾਰਮ ਸਬਮਿਟ/ਵੈਲਿਡੇਸ਼ਨ, ਲੋਡਿੰਗ/ਖਾਲੀ/ਐਰਰ ਸਟੇਟਸ, ਅਤੇ ਮੋਬਾਇਲ ਵਰਤੋਂ।
ਅਚੀਕ ਸਨੇਪਸ਼ਾਟ ਨਾਲ ਤੁਸੀਂ ਵਿਕਲਪ ਰੱਖ ਸਕਦੇ ਹੋ—UI ਸੁਧਾਰਾਂ ਨੂੰ ਬਿਨਾਂ ਘੰਟਿਆਂ ਦੇ ਗੁਆਉਂਦੇ ਹੋਏ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰੋ।
ਰੋਲਬੈਕ ਨੂੰ ਘਬਰਾਹਟ ਭਰਿਆ ਕੰਮ ਸਮਝੋ ਨਹੀਂ—ਇਹ ਨਿਰਵਿਕਾਰਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਪੂਰਾ ਰੋਲਬੈਕ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਉਲਟਣਾ ਹੈ।
ਪੂਰਾ ਰੋਲਬੈਕ ਉਹ ਵਕਤ ਠੀਕ ਹੈ ਜਦੋਂ ਐਪ ਕਈ ਜਗ੍ਹਾਂ 'ਤੇ ਟੁੱਟੀ ਹੋਵੇ। ਅੰਸ਼ਿਕ ਉਲਟਣਾ ਉਚਿਤ ਹੈ ਜਦੋਂ ਇੱਕ ਖਾਸ ਹਿੱਸਾ ਖਰਾਬ ਹੋਵੇ।
ਸੁਰੱਖਿਅਤ ਰੋਲਬੈਕ ਕ੍ਰਮ:
ਰੋਲਬੈਕ ਦਰਦ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਕਾਰਨਾਂ ਕਰਕੇ ਹੁੰਦਾ ਹੈ: ਅਸਪਸ਼ਟ ਸੇਵ-ਪਾਵਿੰਟਸ, ਮਿਲੇ-ਝੁਲੇ ਬਦਲਾਅ ਅਤੇ ਛੱਡੇ ਗਏ ਚੈੱਕ।
ਆਮ ਗਲਤੀਆਂ:
[WIP] Auth: add magic link (next: OAuth)[GOLD] DB: users v2 (passes smoke tests)"test" ਜਾਂ "before update" ਵਰਗੇ ਅਸਪਸ਼ਟ ਨਾਮ ਬਚੋ—ਉਹ ਦਬਾਅ ਹੇਠਾਂ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਰਹਿੰਦੇ।
ਨਿਯਮ: ਇੱਕ ਵੱਡੀ, ਸਭ ਕੁਝ ਇੱਕ ਵਾਰੀ rename ਕਰਨ ਵਾਲੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਚੋ—ਬਦਲਾਵਾਂ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਅਤੇ ਰੋਲਬੈਕ ਕਰ ਸਕੋ।
ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਤਿੰਨ ਨਜ਼ਰੀਆਂ ਤੋਂ access control ਸੁਰੂ ਕਰੋ: normal users admin-only ਕੰਮ ਨਹੀਂ ਦੇਖਣ, admins settings/management ਤੱਕ ਪਹੁੰਚ ਸਕਣ, ਅਤੇ edge cases ਜਿਵੇਂ expired sessions ਜਾਂ password reset ਵਰਗੇ ਵੇਖੋ।
ਇੱਕ ਗੱਲ ਜਿਸ ਨੂੰ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ: secrets ਅਕਸਰ ਕੋਡ ਦੇ ਬਾਹਰ ਰੱਖੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੋਡ ਰੋਲਬੈਕ ਕਰਦੇ ਹੋ ਪਰ ਨਵੀਆਂ ਕੀਜ਼ ਜਾਂ callbacks ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ auth ਅਜੀਬ ਤਰੀਕੇ ਨਾਲ ਟੁੱਟ ਸਕਦੀ ਹੈ। ਐਨਵਾਇਰਨਮੈਂਟ ਬਦਲਾਵਾਂ ਬਾਰੇ ਸਾਫ ਨੋਟ ਛੱਡੋ।
stable-after-rollback.ਫਿਰ ਪੰਜ ਮਿੰਟ ਬੁਝਾਰਤਾਂ 'ਤੇ ਖਰਚ ਕਰੋ—ਕਈ ਵਾਰੀ ਤੁਸੀਂ ਰੋਲਬੈਕ ਕਰ ਲੈਂਦੇ ਹੋ ਪਰ ਇੱਕ ਪਿਛੋਕੜ ਨੌਕਰੀ ਜਾਂ ਡਾਟਾ ਅਜੇ ਵੀ ਟੁੱਟੀ ਰਹਿੰਦੀ ਹੈ।
ਕੁਝ ਤੇਜ਼ ਚੈੱਕ ਜੋ ਜਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੇ ਹਨ:
ਉਦਾਹਰਨ: ਤੁਸੀਂ ਵੱਡਾ auth ਰੀਫੈਕਟਰ ਆਜ਼ਮਾਇਆ ਜਿਸ ਨਾਲ ਐਡਮਿਨ ਲਾਕ ਹੋ ਗਿਆ। ਉਸ ਤੱਕ ਦਾ ਸਨੇਪਸ਼ਾਟ ਰੋਲਬੈਕ ਕਰੋ, ਲੌਗਇਨ ਜਾਂਚੋ, ਫਿਰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਫੇਰ ਲਗਾਓ — roles ਪਹਿਲਾਂ, middleware ਫਿਰ, UI gating ਆਖਿਰ।
ਕੁਝ ਆਸਾਨ ਤਰੀਕੇ ਜੋ ਜਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਰੋਕਦੇ ਹਨ: