ਹੁਣ Publish ਦੋ ਵਾਰ ਦਬਾਉਣ 'ਤੇ ਵੀ ਇੱਕ ਹੀ ਵਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ

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

ਕੀ ਹੋਇਆ

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

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

ਇਸੇ ਕਰਕੇ ਇਹ ਨਜ਼ਰੋਂ ਛੁੱਟਣਾ ਆਸਾਨ ਸੀ। ਯੂਜ਼ਰ ਨੇ ਇੱਕ ਚੱਲਦੀ ਐਪ ਵੇਖੀ। ਫੇਲ੍ਹ ਸਿਰਫ਼ release-failure ਈਮੇਲਾਂ ਵਿੱਚ ਦਿਖੇ।

ਕੁਝ ਵੀ ਕਿਉਂ ਨਹੀਂ ਰੋਕ ਰਿਹਾ ਸੀ

ਪ੍ਰਕਾਸ਼ਨ ਕੋਡ ਵਿੱਚ ਇੱਕ ਕਦਮ ਸੀ ਜੋ ਪ੍ਰੋਜੈਕਟ ਦੇ ਚੱਲ ਰਹੇ ਡਿਪਲੌਇਆਂ ਨੂੰ ਵੇਖਦਾ ਸੀ। ਪਰ ਉਹ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਚੱਲ ਰਹੇ ਡਿਪਲੌਇ ਨੂੰ fail ਚਿੰਨ੍ਹਿਤ ਕਰ ਦਿੰਦਾ ਸੀ, “a new publish has superseded it”। ਇਹ ਕਰੈਸ਼ ਹੋਏ ਪ੍ਰੋਸੈਸ ਦੇ ਛੱਡੇ ਬਿਲਡਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਲਈ ਸੀ।

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

ਕਿਸੇ ਐਪ ਦੇ ਪਹਿਲੇ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਇੱਕ ਦੂਜਾ, ਹੋਰ ਅਜੀਬ ਲੱਛਣ ਵੀ ਸੀ। ਅਜੇ ਕੋਈ ਡਿਪਲੌਇਮੈਂਟ ਰਿਕਾਰਡ ਨਾ ਹੋਣ ਕਰਕੇ, ਦੋ ਇਕੱਠੇ ਪਹਿਲੇ ਪ੍ਰਕਾਸ਼ਨ ਦੋਵੇਂ ਇੱਕ ਹੀ ਰਿਕਾਰਡ ਪਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਨ। ਡੇਟਾਬੇਸ ਵਿੱਚ ਐਪ ਦੇ ਲਿੰਕ ਨਾਮ (ਉਸਦਾ slug, ਜਿਵੇਂ your-app.mythex.ai ਵਿੱਚ your-app) 'ਤੇ ਇੱਕ ਯੂਨੀਕ ਇੰਡੈਕਸ ਹੈ, ਇਸ ਲਈ ਦੂਜੀ ਇਨਸਰਟ ਫੇਲ੍ਹ ਹੋ ਗਈ। API ਨੇ ਇਸਨੂੰ “ਉਹ ਲਿੰਕ ਨਾਮ ਲਿਆ ਜਾ ਚੁੱਕਾ ਹੈ” ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਉਸ ਐਪ ਦਾ ਨਾਮ ਬਦਲਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜੋ ਉਸ ਪਲ ਉਸੇ ਨਾਮ ਹੇਠ ਸਫਲਤਾ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋ ਰਹੀ ਸੀ।

ਹੱਲ: ਦਾਅਵਾ ਹੀ ਲਾਕ ਹੈ

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

ਲਾਕ ਨੂੰ ਵੀ ਉਸਦੇ ਧਾਰਕ ਦੇ ਮਰਨ 'ਤੇ ਨਿਕਲਣ ਦਾ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ API ਪ੍ਰਕਾਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਮੁੜ ਚਾਲੂ ਹੋਵੇ, ਤਾਂ ਕਤਾਰ ਹਮੇਸ਼ਾਂ “building” ਰਹਿੰਦੀ ਅਤੇ ਐਪ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ। ਇਸ ਲਈ ਜਿਸ ਕਤਾਰ ਦਾ ਮਾਲਕ ਹੀ heartbeat ਭੇਜਣੋਂ ਰੁਕ ਜਾਵੇ (ਚੱਲ ਰਿਹਾ ਪ੍ਰਕਾਸ਼ਨ ਹਰ 30 ਸਕਿੰਟ ਵਿੱਚ ਕਤਾਰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੰਜ ਮਿੰਟ ਦੀ ਚੁੱਪ ਮਰਿਆ ਗਿਣੀ ਜਾਂਦੀ ਹੈ), ਉਸਨੂੰ ਮੁੜ ਦਾਅਵਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹ ਸੀਮਾ heartbeat ਤੋਂ ਆਉਂਦੀ ਹੈ, ਬਿਲਡ ਕਿੰਨਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਇਸਦੇ ਅੰਦਾਜ਼ੇ ਤੋਂ ਨਹੀਂ। ਯੂਜ਼ਰ ਦਾ ਆਪਣਾ Dockerfile ਬਣਾਉਣਾ ਜਾਇਜ਼ ਤੌਰ 'ਤੇ ਲੰਮਾ ਚੱਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਹੌਲੀ ਬਿਲਡ ਜੋ ਅਜੇ heartbeat ਭੇਜ ਰਿਹਾ ਹੈ ਆਪਣਾ ਦਾਅਵਾ ਰੱਖਦਾ ਹੈ।

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

ਹਾਰਨ ਵਾਲੇ ਨੂੰ ਸੱਚ ਦੱਸਣਾ

ਜਿਹੜੀ ਬੇਨਤੀ ਹਾਰਦੀ ਹੈ ਉਸਨੂੰ ਹੁਣ ਇੱਕ ਸਾਫ਼ ਜਵਾਬ ਮਿਲਦਾ ਹੈ: publish_in_progress, ਨਾਲ ਚੱਲ ਰਹੇ ਡਿਪਲੌਇ ਦਾ ID। ਹਰ ਥਾਂ ਜੋ ਪ੍ਰਕਾਸ਼ਨ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ, ਇਸਨੂੰ ਸੰਭਾਲਦੀ ਹੈ:

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

ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਜਾਂਚਿਆ

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

ਸਕ੍ਰਿਪਟ ਬਚਣ ਦੇ ਰਸਤੇ ਨੂੰ ਵੀ ਕਵਰ ਕਰਦੀ ਹੈ: ਇਹ ਐਪ ਦੀ ਕਤਾਰ ਨੂੰ ਦਸ ਮਿੰਟ ਤੱਕ heartbeat ਤੋਂ ਬਿਨਾਂ building ਚਿੰਨ੍ਹਿਤ ਕਰਦੀ ਹੈ, ਮੁੜ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਜਾਂਚਦੀ ਹੈ ਕਿ ਨਵਾਂ ਪ੍ਰਕਾਸ਼ਨ ਕਤਾਰ ਦਾ ਦਾਅਵਾ ਕਰਕੇ ਚੱਲਦਾ ਹੈ।

ਯੂਨਿਟ ਟੈਸਟ ਲਾਕ ਨੂੰ ਉਹਨਾਂ ਦੋ ਗੱਲਾਂ ਨਾਲ ਬੰਨ੍ਹਦੇ ਹਨ ਜੋ ਲਾਕ ਨੂੰ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਇੱਕੋ ਵੇਲੇ ਤਿੰਨ ਮੁੜ ਪ੍ਰਕਾਸ਼ਨਾਂ ਵਿੱਚੋਂ ਠੀਕ ਇੱਕ ਲੰਘਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਦੋ ਨੂੰ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਪ੍ਰਕਾਸ਼ਨ ਚੱਲ ਰਿਹਾ ਹੈ; ਅਤੇ ਜਿਸ ਬਿਲਡ ਦਾ ਮਾਲਕ ਮਰ ਗਿਆ, ਉਸਦਾ ਦਾਅਵਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਹੋਰ ਟੈਸਟ ਜਾਂਚਦਾ ਹੈ ਕਿ ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਪਿਛਲੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਗਲਤੀ ਸੁਨੇਹਾ ਨਾਲ ਨਹੀਂ ਲਿਆਉਂਦੀ।

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

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

ਪ੍ਰਕਾਸ਼ਨ ਬਾਰੇ ਹੋਰ ਡੌਕਸ ਵਿੱਚ: how to publish। ਅਤੇ ਇੱਕ ਸੰਬੰਧਿਤ ਸੁਧਾਰ: ਤੁਹਾਡੀ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਮੁੜ ਪ੍ਰਕਾਸ਼ਨ ਦੌਰਾਨ ਚਾਲੂ ਰਹਿੰਦੀ ਹੈ।