ਸਟੇਜਿੰਗ ਇਨਵਾਇਰਨਮੈਂਟ ਕੀ ਹੈ? ਲਾਈਵ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ

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

AI ਨਾਲ ਬਣਾਉਂਦੇ ਸਮੇਂ ਸਟੇਜਿੰਗ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ

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

ਲਾਈਵ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਾਅ ਜਾਂਚਣ ਦੀ ਇੱਕ ਥਾਂ ਤੁਹਾਡੀ ਇਹ ਮਦਦ ਕਰਦੀ ਹੈ:

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

ਰੋਜ਼ਾਨਾ ਦੀ ਮਿਸਾਲ

ਥੀਏਟਰ ਦੇ ਡ੍ਰੈੱਸ ਰਿਹਰਸਲ ਬਾਰੇ ਸੋਚੋ।

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

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

ਤਿੰਨ ਆਮ ਇਨਵਾਇਰਨਮੈਂਟ

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

ਇੱਕ ਕੰਮ ਕੀਤੀ ਮਿਸਾਲ: ਬੁਕਿੰਗ ਐਪ ਦੇ ਰੱਦ ਕਰਨ ਦੇ ਨਿਯਮ ਬਦਲਣੇ

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

1. ਡਿਵੈਲਪਮੈਂਟ ਵਿੱਚ ਬਣਾਓ। ਤੁਸੀਂ ਆਪਣੇ AI ਬਿਲਡਰ ਤੋਂ ਬਦਲਾਅ ਮੰਗਦੇ ਹੋ। ਇਹ ਰੱਦ ਕਰਨ ਦੀ ਲਾਜਿਕ ਅਤੇ ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਨੂੰ ਰਿਫ਼ੰਡ ਕਾਲ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।

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

3. ਅਸਲ ਫ਼ਲੋ ਟੈਸਟ ਕਰੋ। ਤੁਸੀਂ ਅਤੇ ਤੁਹਾਡਾ ਸਾਥੀ:

• ਕੱਲ੍ਹ ਲਈ ਟੈਸਟ ਅਪੌਇੰਟਮੈਂਟ ਬੁੱਕ ਕਰੋ ਅਤੇ 30 ਘੰਟੇ ਪਹਿਲਾਂ ਰੱਦ ਕਰੋ — ਰਿਫ਼ੰਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ;
• 10 ਘੰਟੇ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ — ਸਾਫ਼ ਸੁਨੇਹੇ ਨਾਲ ਇਨਕਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ;
• ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਦੇ ਟੈਸਟ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਰਿਫ਼ੰਡ ਵੇਖੋ;
• ਪੁਸ਼ਟੀ ਈਮੇਲ ਵਿੱਚ 48 ਦੀ ਥਾਂ 24 ਘੰਟੇ ਲਿਖੇ ਹੋਣ ਦੀ ਜਾਂਚ ਕਰੋ।

4. ਗ਼ਲਤੀ ਲੱਭੋ। ਸਟੇਜਿੰਗ ਵਿੱਚ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਕਿ ਨਿਯਮ ਸੈਲੂਨ ਦੀ ਥਾਂ ਸਰਵਰ ਦਾ ਟਾਈਮ ਜ਼ੋਨ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਕੱਟ-ਆਫ ਇੱਕ ਘੰਟਾ ਗ਼ਲਤ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕਰਦੇ ਹੋ ਅਤੇ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰਦੇ ਹੋ।

5. ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਰਿਲੀਜ਼ ਕਰੋ। ਹੁਣ ਹੀ ਇਹ ਬਦਲਾਅ ਅਸਲ ਗਾਹਕਾਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ — ਟਾਈਮ-ਜ਼ੋਨ ਦੀ ਗ਼ਲਤੀ ਪਹਿਲਾਂ ਹੀ ਫੜੀ ਜਾ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ।

ਸਟੇਜਿੰਗ ਤੋਂ ਬਿਨਾਂ, ਕਦਮ 4 ਕਿਸੇ ਅਸਲ ਗਾਹਕ ਦੇ ਰਿਫ਼ੰਡ ਨਾਲ ਹੋ ਜਾਂਦਾ।

ਮੁੱਖ ਸ਼ਬਦ

ਆਮ ਗ਼ਲਤਫ਼ਹਿਮੀਆਂ

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

ਆਪਣੇ AI ਬਿਲਡਰ ਨੂੰ ਕੀ ਮੰਗਣਾ ਹੈ

• "ਹਰ ਇਨਵਾਇਰਨਮੈਂਟ-ਖ਼ਾਸ ਸੈਟਿੰਗ — ਡੇਟਾਬੇਸ, API ਕੀਜ਼, ਸਾਈਟ URL — ਇਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲਾਂ ਤੋਂ ਲਓ।"
• "ਇੱਕ ਸੀਡ ਸਕ੍ਰਿਪਟ ਬਣਾਓ ਜੋ ਗ਼ੈਰ-ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਨੂੰ ਅਸਲ ਲੱਗਦੇ ਟੈਸਟ ਡੇਟਾ ਨਾਲ ਭਰੇ।"
• "ਜਦ ਤੱਕ ਮੈਂ ਲਾਂਚ ਦਾ ਨਾ ਕਹਾਂ, ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਦਾ ਟੈਸਟ ਮੋਡ ਵਰਤੋ।"
• "ਇਸ ਬਦਲਾਅ ਦੇ ਲਾਈਵ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਫ਼ਲੋ ਸੂਚੀਬੱਧ ਕਰੋ ਜੋ ਮੈਨੂੰ ਟੈਸਟ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।"
• "ਕੀ ਇਸ ਬਦਲਾਅ ਦਾ ਮੌਜੂਦਾ ਡੇਟਾ 'ਤੇ ਅਸਰ ਹੋਵੇਗਾ? ਪਹਿਲਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦਿਖਾਓ।"
• "ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਾਈਟ ਦੀਆਂ ਗ਼ੈਰ-ਪ੍ਰੋਡਕਸ਼ਨ ਕਾਪੀਆਂ ਸਰਚ ਇੰਜਣਾਂ ਵੱਲੋਂ ਇੰਡੈਕਸ ਨਾ ਹੋਣ।"

ਕਦਮ-ਦਰ-ਕਦਮ ਸੈਟਅੱਪ ਲਈ, ਸਟੇਜਿੰਗ ਇਨਵਾਇਰਨਮੈਂਟ ਕਿਵੇਂ ਸੈੱਟ ਕਰਨੀ ਹੈ ਦੇਖੋ। ਜਦੋਂ ਰਿਲੀਜ਼ ਵਾਰ-ਵਾਰ ਹੋਣ ਲੱਗਣ, ਤਾਂ ਕੋਡ ਤੋਂ ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਦਾ ਰਾਹ ਆਪਣੇ-ਆਪ ਚਲਾਉਣਾ CI/CD ਲਈ ਹੈ।

Mythex ਵਿੱਚ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟਿੰਗ

Mythex ਵਿੱਚ "ਸਟੇਜਿੰਗ ਬਨਾਮ ਪ੍ਰੋਡਕਸ਼ਨ" ਦਾ ਕੋਈ ਵੱਖਰਾ ਸਵਿੱਚ ਨਹੀਂ ਹੈ; ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਇੱਕ ਲਾਈਵ ਜਨਤਕ URL ਮਿਲਦਾ ਹੈ, ਅਤੇ ਡੌਕਸ ਇਹ ਸਾਫ਼ ਦੱਸਦੇ ਹਨ (ਮਲਟੀ-ਸਰਵਿਸ ਐਪਸ)। ਇਹ ਜੋ ਦਿੰਦਾ ਹੈ ਉਹ ਹੈ ਬਣਾਉਣ ਅਤੇ ਲਾਈਵ ਹੋਣ ਵਿਚਕਾਰ ਸਾਫ਼ ਲਕੀਰ:

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

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

ਸਵਾਲ