ਅਸਫ਼ਲ ਰੀਪਬਲਿਸ਼ ਕਦੇ ਵੀ ਕੰਮ ਕਰਦੇ ਬੈਕਐਂਡ ਨੂੰ ਨਹੀਂ ਮਿਟਾਉਂਦਾ

25 ਸਤੰਬਰ ਨੂੰ, ਇੱਕ ਅਸਫ਼ਲ ਰੀਪਬਲਿਸ਼ ਨੇ ਇੱਕ ਐਪ ਦਾ ਬੈਕਐਂਡ ਮਿਟਾ ਦਿੱਤਾ, ਜੋ ਲਗਭਗ ਢਾਈ ਘੰਟਿਆਂ ਤੋਂ ਲਾਈਵ ਅਤੇ ਠੀਕ ਚੱਲ ਰਿਹਾ ਸੀ। ਅਸਫ਼ਲ ਪਬਲਿਸ਼ ਨੂੰ ਉਲਟਾਉਣ ਵਾਲਾ ਕੋਡ ਹਰ ਉਸ ਸਰਵਰ ਐਪ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਸੀ ਜਿਸਨੂੰ ਪਬਲਿਸ਼ ਨੇ ਛੂਹਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਉਹ ਐਪਾਂ ਵੀ ਸ਼ਾਮਲ ਸਨ ਜੋ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਹੀਆਂ ਸਨ। ਹੁਣ ਸਿਰਫ਼ ਉਹੀ ਐਪਾਂ ਮਿਟਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਪਬਲਿਸ਼ ਨੇ ਬਣਾਈਆਂ ਹੋਣ; ਜੋ ਐਪ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸੀ, ਉਹ ਆਪਣੇ ਪਹਿਲਾਂ ਵਾਲੇ ਵਰਜਨ 'ਤੇ ਵਾਪਸ ਰੱਖੀ ਜਾਂਦੀ ਹੈ। ਉਸੇ ਦਿਨ ਦੇ ਦੋ ਹੋਰ ਸੁਧਾਰਾਂ ਨੇ ਯਕੀਨੀ ਬਣਾਇਆ ਕਿ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ਦਾ ਆਪਣਾ ਡਿਪਲੌਏ ਟੂਲ ਫ਼ੇਲ੍ਹ ਹੋਣ 'ਤੇ ਵੀ ਇਹ ਉਲਟਾਉਣਾ ਚੱਲੇ, ਅਤੇ ਕਿਸੇ ਠੀਕ ਐਪ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ ਫ਼ੇਲ੍ਹ ਨਾ ਮੰਨਿਆ ਜਾਵੇ ਕਿ ਉਹ ਸੁੱਤੀ ਹੋਈ ਸੀ।

ਬੈਕਐਂਡ ਕਿਵੇਂ ਪਬਲਿਸ਼ ਹੁੰਦਾ ਹੈ

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

ਜੇ ਰਸਤੇ ਵਿੱਚ ਕੁਝ ਵੀ ਫ਼ੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਉਸਨੂੰ ਉਲਟਾਉਣ ਲਈ ਰੋਲਬੈਕ ਚੱਲਦਾ ਹੈ। ਇਹ ਰੋਲਬੈਕ ਸਹੀ ਹੋਣਾ ਪਬਲਿਸ਼ਿੰਗ ਵਿੱਚ ਲਗਭਗ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਗੱਲ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਵੇਲੇ ਚੱਲਦਾ ਹੈ ਜਦੋਂ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਗਲਤ ਹੋ ਰਿਹਾ ਹੋਵੇ।

ਸਮੱਸਿਆ 1: ਰੋਲਬੈਕ ਉਹ ਮਿਟਾ ਰਿਹਾ ਸੀ ਜੋ ਉਸਨੇ ਬਹਾਲ ਕਰਨਾ ਸੀ

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

ਰੀਪਬਲਿਸ਼ ਲਈ ਇਹ ਬਿਲਕੁਲ ਗਲਤ ਸੀ। ਐਪ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸੀ ਅਤੇ ਅਸਲ ਵਿਜ਼ਿਟਰਾਂ ਨੂੰ ਸੇਵਾ ਦੇ ਰਹੀ ਸੀ। 25 ਸਤੰਬਰ ਨੂੰ, ਇੱਕ ਐਪ ਦੀ API, ਜੋ ਲਗਭਗ ਢਾਈ ਘੰਟਿਆਂ ਤੋਂ ਲਾਈਵ ਸੀ, ਇੱਕ ਅਸਫ਼ਲ ਰੀਪਬਲਿਸ਼ ਨੇ ਮਿਟਾ ਦਿੱਤੀ।

ਇਸੇ ਕੋਡ ਵਿੱਚ ਇੱਕ ਹੋਰ ਅਸਫ਼ਲਤਾ ਵੀ ਲੁਕੀ ਹੋਈ ਸੀ। ਜਿੱਥੇ ਮਿਟਾਉਣਾ ਸਫ਼ਲ ਨਹੀਂ ਹੁੰਦਾ ਸੀ, ਉੱਥੇ ਟੁੱਟੀ ਹੋਈ ਨਵੀਂ ਇਮੇਜ ਮਸ਼ੀਨਾਂ 'ਤੇ ਹੀ ਰਹਿ ਜਾਂਦੀ ਸੀ, ਜਦਕਿ ਅਸੀਂ ਮਾਲਕ ਨੂੰ ਦੱਸ ਰਹੇ ਸੀ ਕਿ ਉਸਦੀ ਮੌਜੂਦਾ ਸਾਈਟ ਅਜੇ ਵੀ ਲਾਈਵ ਹੈ। ਜਦੋਂ ਤੱਕ ਹੈਲਥ ਚੈੱਕ ਫ਼ੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ, ਨਵੀਂ ਇਮੇਜ ਹਰ ਮਸ਼ੀਨ 'ਤੇ ਰੋਲ ਹੋ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਨਾ ਕਰਨਾ ਉਲਟਾਉਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦਾ।

ਹੱਲ: ਸਿਰਫ਼ ਉਹ ਮਿਟਾਓ ਜੋ ਤੁਸੀਂ ਬਣਾਇਆ, ਬਾਕੀ ਬਹਾਲ ਕਰੋ

ਹੁਣ ਹਰ ਪਬਲਿਸ਼ ਹਰ ਉਸ ਸਰਵਰ ਐਪ ਲਈ ਇਹ ਦਰਜ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਉਹ ਛੂਹਦਾ ਹੈ:

• ਕੀ ਇਸ ਪਬਲਿਸ਼ ਨੇ ਇਸਨੂੰ ਬਣਾਇਆ ਹੈ, ਅਤੇ
• ਜੇ ਨਹੀਂ, ਤਾਂ ਪਬਲਿਸ਼ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਕਿਹੜੀ ਇਮੇਜ ਚੱਲ ਰਹੀ ਸੀ।

ਫ਼ੇਲ੍ਹ ਹੋਣ 'ਤੇ, ਹਰ ਐਪ ਨੂੰ ਤਿੰਨ ਵਿੱਚੋਂ ਇੱਕ ਇਲਾਜ ਮਿਲਦਾ ਹੈ:

1. ਇਸ ਪਬਲਿਸ਼ ਨੇ ਬਣਾਈ: ਪਹਿਲਾਂ ਵਾਂਗ ਮਿਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
2. ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ, ਪੁਰਾਣੀ ਇਮੇਜ ਪਤਾ ਹੈ: ਉਹੀ ਪੁਰਾਣੀ ਇਮੇਜ ਉਸੇ ਸੰਰਚਨਾ ਨਾਲ ਦੁਬਾਰਾ ਡਿਪਲੌਏ ਹੁੰਦੀ ਹੈ। ਕੋਈ ਬਿਲਡ ਨਹੀਂ ਹੁੰਦਾ, ਸਿਰਫ਼ ਇਮੇਜ ਵਾਪਸ ਜਾਂਦੀ ਹੈ।
3. ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ, ਪੁਰਾਣੀ ਇਮੇਜ ਪਤਾ ਨਹੀਂ: ਉਸਨੂੰ ਇਕੱਲਾ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਮੌਜੂਦਾ ਐਪ ਕਦੇ ਵੀ ਨਹੀਂ ਮਿਟਾਈ ਜਾਂਦੀ, ਭਾਵੇਂ ਅਸੀਂ ਉਸਨੂੰ ਬਹਾਲ ਨਾ ਕਰ ਸਕੀਏ।

ਇਹ ਨਿਯਮ ਇੱਕ ਛੋਟੇ ਸ਼ੁੱਧ ਫੰਕਸ਼ਨ ਵਿੱਚ ਹਨ ਜਿਸਦੇ ਆਪਣੇ ਟੈਸਟ ਹਨ, ਤਾਂ ਜੋ ਫ਼ੈਸਲਾ "ਸਭ ਕੁਝ ਮਿਟਾ ਦਿਓ" ਵਾਲੇ ਪਾਸੇ ਬਿਨਾਂ ਕਿਸੇ ਟੈਸਟ ਦੇ ਫ਼ੇਲ੍ਹ ਹੋਏ ਵਾਪਸ ਨਾ ਖਿਸਕ ਸਕੇ।

ਸਮੱਸਿਆ 2: ਡਿਪਲੌਏ ਟੂਲ ਇਹ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਫ਼ੇਲ੍ਹ ਹੋ ਸਕਦਾ ਸੀ ਕਿ ਉਲਟਾਉਣਾ ਕਿਵੇਂ ਹੈ

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

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

ਹੱਲ: ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਲਟਾਉਣ ਦਾ ਤਰੀਕਾ ਦਰਜ ਕਰੋ

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

ਸਮੱਸਿਆ 3: ਸੁੱਤੀ ਐਪ ਨੂੰ "ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਈ" ਵਜੋਂ ਫ਼ੇਲ੍ਹ ਕਰ ਦਿੱਤਾ ਗਿਆ

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

25 ਸਤੰਬਰ ਨੂੰ, ਉਹ ਇੱਕ ਸ਼ੁਰੂਆਤ ਦੀ ਬੇਨਤੀ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚੀ। ਇੱਕ ਠੀਕ API ਪੂਰੀ ਪੰਜ ਮਿੰਟ ਦੀ ਹੈਲਥ ਚੈੱਕ ਦੌਰਾਨ ਰੁਕੀ ਰਹੀ ਅਤੇ "1 machine never started (last state: stopped)" ਨਾਲ ਫ਼ੇਲ੍ਹ ਕਰ ਦਿੱਤੀ ਗਈ।

ਪਲੇਟਫਾਰਮ ਕਈ ਵਾਰ ਸ਼ੁਰੂਆਤ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਇਸਨੇ ਬਿਨਾਂ ਕੁਝ ਕੀਤੇ "lease currently held" ਟਕਰਾਅ ਦਿੱਤਾ, ਅਤੇ ਜਦੋਂ ਮਸ਼ੀਨ ਅੱਪਡੇਟ ਹੋ ਰਹੀ ਹੁੰਦੀ ਹੈ ਤਾਂ ਵੀ ਸ਼ੁਰੂਆਤ ਰੱਦ ਕਰਦਾ ਹੈ।

ਹੱਲ: ਪੁੱਛਦੇ ਰਹੋ, ਅਤੇ ਦਰਵਾਜ਼ਾ ਖੜਕਾਓ

ਹੁਣ ਹੈਲਥ ਚੈੱਕ:

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

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

ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ

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

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