ਆਪਣੀ ਐਪ ਲਈ ਸਟੇਜਿੰਗ ਐਨਵਾਇਰਨਮੈਂਟ ਕਿਵੇਂ ਬਣਾਈਏ

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

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

ਡਿਵੈਲਪ, ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ

ਜ਼ਿਆਦਾਤਰ ਛੋਟੀਆਂ ਐਪਾਂ ਨੂੰ ਤਿੰਨ ਥਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਪਹਿਲੀ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਬਿਲਡਰ ਦਾ ਪ੍ਰੀਵਿਊ ਹੋਵੇ:

ਸਟੇਜਿੰਗ ਦਾ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਉਹ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਂਗ ਵਰਤਾਓ ਕਰੇ, ਯਾਨੀ ਉਹੀ ਕੋਡ, ਉਹੀ ਸਟੈਕ, ਉਹੀ ਕਿਸਮ ਦੀਆਂ ਸੈਟਿੰਗਾਂ, ਪਰ ਉੱਥੇ ਗਲਤੀ ਕਿਸੇ ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦੀ।

ਕਦਮ 1: ਤੈਅ ਕਰੋ ਕਿ ਸਟੇਜਿੰਗ ਨੇ ਕਿਸ ਚੀਜ਼ ਨਾਲ ਮਿਲਣਾ ਹੈ

ਸਟੇਜਿੰਗ ਉਦੋਂ ਹੀ ਕੰਮ ਦੀ ਹੈ ਜਦੋਂ ਸਮੱਸਿਆਵਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਉੱਥੇ ਦਿਸਣ। ਇਹ ਮਿਲਾਓ:

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

ਆਕਾਰ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ (ਛੋਟੀ ਮਸ਼ੀਨ ਠੀਕ ਹੈ) ਅਤੇ ਡੇਟਾ ਵੀ।

ਕਦਮ 2: ਕਾਪੀ ਬਣਾਓ

ਸਭ ਤੋਂ ਸਾਦਾ ਤਰੀਕਾ: ਉਸੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਦੂਜੀ ਡਿਪਲੌਇਮੈਂਟ, ਵੱਖਰੇ URL 'ਤੇ, ਜਿਵੇਂ staging.yourapp.com ਜਾਂ yourapp-staging.example.com।

ਇਹ ਕਿਵੇਂ ਹੋਵੇਗਾ, ਇਹ ਤੁਹਾਡੇ ਹੋਸਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ:

• ਜਿਨ੍ਹਾਂ ਹੋਸਟਾਂ ਕੋਲ ਬਿਲਟ-ਇਨ ਪ੍ਰੀਵਿਊ ਜਾਂ ਸਟੇਜਿੰਗ ਡਿਪਲੌਇਮੈਂਟ ਹਨ, ਉਹ Git ਬ੍ਰਾਂਚ ਲਈ ਆਪਣੇ ਆਪ ਇੱਕ ਬਣਾ ਸਕਦੇ ਹਨ।
• ਜਿਨ੍ਹਾਂ ਕੋਲ ਨਹੀਂ: ਉਸੇ ਕੋਡ ਤੋਂ ਇੱਕ ਦੂਜੀ ਐਪ ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਬਣਾਓ ਅਤੇ ਉਸ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਡਿਪਲੌਏ ਕਰੋ।
• Git ਵਿੱਚ ਕੋਡ: ਇੱਕ staging ਜਾਂ main ਬ੍ਰਾਂਚ ਰੱਖੋ ਜੋ ਸਟੇਜਿੰਗ 'ਤੇ ਡਿਪਲੌਏ ਹੋਵੇ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਡਿਪਲੌਏ ਕਰੋ। ਵੇਖੋ AI ਨਾਲ ਬਣੀ ਐਪ ਨਾਲ Git ਕਿਵੇਂ ਵਰਤੀਏ।

ਕਦਮ 3: ਸਟੇਜਿੰਗ ਨੂੰ ਆਪਣਾ ਡੇਟਾਬੇਸ ਦਿਓ

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

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

ਇੱਕ ਸੀਡ ਸਕ੍ਰਿਪਟ ਲਿਖੋ ਜੋ ਖਾਲੀ ਡੇਟਾਬੇਸ ਨੂੰ ਅਸਲ ਵਰਗੇ ਟੈਸਟ ਡੇਟਾ ਨਾਲ ਭਰੇ: 20 ਗਾਹਕ, ਵੱਖ-ਵੱਖ ਹਾਲਤਾਂ ਵਿੱਚ 50 ਆਰਡਰ, ਅਤੇ ਦੋ ਐਡਮਿਨ ਯੂਜ਼ਰ। ਸਾਫ਼ ਨਕਲੀ ਨਾਮ ਅਤੇ example.com ਈਮੇਲ ਪਤੇ ਵਰਤੋ।

ਸੈੱਟਅੱਪ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਪੱਕਾ ਕਰੋ ਕਿ ਹਰ ਕਾਪੀ ਕਿਹੜੇ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਦੀ ਹੈ। ਸਿੱਧਾ ਪੁੱਛੋ:

ਇਹ ਐਪ ਕਿਹੜੇ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਦੀ ਹੈ, ਅਤੇ ਇਹ ਸੈਟਿੰਗ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ? ਵੇਰੀਏਬਲ ਦਾ ਨਾਮ ਦਿਖਾਓ, ਪਾਸਵਰਡ ਨਹੀਂ।

ਕਦਮ 4: ਟੈਸਟ ਕੀਜ਼ ਅਤੇ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਵਰਤੋ

ਜੋ ਵੀ ਬਾਹਰੀ ਸੇਵਾ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ, ਉਸ ਨੂੰ ਸਟੇਜਿੰਗ ਵਿੱਚ ਟੈਸਟ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਵਰਤਣੇ ਚਾਹੀਦੇ ਹਨ:

• ਭੁਗਤਾਨ ਟੈਸਟ ਮੋਡ ਵਿੱਚ (ਜਿਵੇਂ Stripe ਟੈਸਟ ਕੀਜ਼), ਤਾਂ ਜੋ ਕਿਸੇ ਅਸਲ ਕਾਰਡ ਤੋਂ ਪੈਸੇ ਨਾ ਕੱਟੇ ਜਾਣ।
• ਈਮੇਲ ਕਿਸੇ ਸੈਂਡਬੌਕਸ ਨੂੰ ਜਾਂ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਆਪਣੇ ਪਤੇ 'ਤੇ, ਤਾਂ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਕਦੇ ਟੈਸਟ ਸੁਨੇਹਾ ਨਾ ਜਾਵੇ।
• AI ਅਤੇ ਹੋਰ ਪੇਡ API ਇੱਕ ਵੱਖਰੀ ਕੀ ਅਤੇ ਘੱਟ ਖਰਚ ਹੱਦ ਨਾਲ।
• ਵੈਬਹੁੱਕ ਸਟੇਜਿੰਗ URL 'ਤੇ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹੋਏ, ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਨਹੀਂ।

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

ਕਦਮ 5: ਸਟੇਜਿੰਗ ਨਿੱਜੀ ਰੱਖੋ

ਸਟੇਜਿੰਗ ਜਨਤਕ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ:

• ਉਸ ਨੂੰ ਲੌਗਇਨ, ਪਾਸਵਰਡ, ਜਾਂ ਟੀਮ ਈਮੇਲਾਂ ਦੀ ਇਜਾਜ਼ਤ-ਸੂਚੀ ਪਿੱਛੇ ਰੱਖੋ।
• noindex ਮੈਟਾ ਟੈਗ ਜਾਂ X-Robots-Tag ਹੈਡਰ ਨਾਲ ਸਰਚ ਇੰਜਣਾਂ ਨੂੰ ਇੰਡੈਕਸ ਕਰਨ ਤੋਂ ਰੋਕੋ।
• ਆਪਣੀ ਜਨਤਕ ਸਾਈਟ ਤੋਂ ਉਸ ਦਾ ਲਿੰਕ ਨਾ ਦਿਓ।
• ਉਸ ਨੂੰ ਵੱਖਰਾ ਦਿਖਾਓ: ਰੰਗਦਾਰ "STAGING" ਬੈਨਰ ਗਲਤ ਟੈਬ ਵਿੱਚ ਟੈਸਟ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਜਦੋਂ APP_ENV ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ "staging" ਹੋਵੇ, ਤਾਂ ਹਰ ਪੰਨੇ ਦੇ ਸਿਖਰ 'ਤੇ ਚਮਕਦਾਰ ਪੀਲਾ ਬੈਨਰ ਜੋੜੋ ਜਿਸ ਵਿੱਚ ਲਿਖਿਆ ਹੋਵੇ "STAGING — ਸਿਰਫ਼ ਟੈਸਟ ਡੇਟਾ"। ਉਸ ਹਾਲਤ ਵਿੱਚ noindex ਮੈਟਾ ਟੈਗ ਵੀ ਜੋੜੋ।

ਕਦਮ 6: ਰਿਲੀਜ਼ ਦੀ ਰੁਟੀਨ ਬਣਾਓ

ਸਟੇਜਿੰਗ ਉਦੋਂ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਹਰ ਵਾਰ ਵਰਤੋ। ਇੱਕ ਸਾਦੀ ਰੁਟੀਨ:

1. ਡਿਵੈਲਪਮੈਂਟ ਵਿੱਚ ਬਦਲਾਅ ਕਰੋ ਅਤੇ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਜਾਂਚੋ।
2. ਇਸ ਨੂੰ ਸਟੇਜਿੰਗ 'ਤੇ ਰਿਲੀਜ਼ ਕਰੋ।
3. ਆਪਣੇ ਮੁੱਖ ਫਲੋ ਚਲਾਓ: ਸਾਈਨ ਅੱਪ, ਲੌਗਇਨ, ਮੁੱਖ ਫੀਚਰ, ਭੁਗਤਾਨ, ਅਤੇ ਜੋ ਵੀ ਬਦਲਾਅ ਨੇ ਛੂਹਿਆ ਹੋਵੇ।
4. ਜੇ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਠੀਕ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਸਟੇਜਿੰਗ 'ਤੇ ਰਿਲੀਜ਼ ਕਰੋ।
5. ਉਹੀ ਵਰਜ਼ਨ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਪਬਲਿਸ਼ ਕਰੋ।
6. ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਜਲਦੀ ਜਾਂਚ ਕਰੋ: ਉਹੀ ਫਲੋ, ਥੋੜ੍ਹੇ ਵਿੱਚ।

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

ਕਦਮ 7: ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਧਿਆਨ ਨਾਲ ਸੰਭਾਲੋ

ਡੇਟਾਬੇਸ ਦੇ ਢਾਂਚੇ ਵਿੱਚ ਬਦਲਾਅ, ਜਿਵੇਂ ਕਾਲਮ ਜੋੜਨਾ ਜਾਂ ਟੇਬਲ ਦਾ ਨਾਮ ਬਦਲਣਾ, ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਟੇਜਿੰਗ ਆਪਣਾ ਖਰਚਾ ਵਸੂਲਦੀ ਹੈ।

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

ਉਦਾਹਰਨ ਪ੍ਰੌਂਪਟ

ਜੇ ਅਸੀਂ ਇਹ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਚਲਾਈਏ ਤਾਂ ਮੌਜੂਦਾ ਡੇਟਾ ਨਾਲ ਕੀ ਹੋਵੇਗਾ? ਕੀ ਕੁਝ ਮਿਟਦਾ ਜਾਂ ਨਾਮ ਬਦਲਦਾ ਹੈ?

ਸਾਰੀਆਂ ਐਨਵਾਇਰਨਮੈਂਟ-ਵਿਸ਼ੇਸ਼ ਸੈਟਿੰਗਾਂ, ਜਿਵੇਂ API URL, ਕੀਜ਼, ਈਮੇਲ ਭੇਜਣ ਵਾਲਾ, ਅਤੇ ਸਾਈਟ ਦਾ ਆਪਣਾ URL, ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲਾਂ ਤੋਂ ਲਓ, ਜਿਨ੍ਹਾਂ ਦੇ ਨਾਮ ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਇੱਕੋ ਹੋਣ। ਉਨ੍ਹਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ।

ਇਸ ਐਪ ਦੇ ਕੰਮਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਟੇਜਿੰਗ 'ਤੇ ਜਾਂਚਣ ਵਾਲੇ ਫਲੋ ਦੀ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਲਿਖੋ।

ਆਮ ਗਲਤੀਆਂ

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

ਚੈੱਕਲਿਸਟ

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

Mythex 'ਤੇ ਸਟੇਜਿੰਗ

Mythex ਦਾ Publish ਹਰ ਐਪ ਲਈ ਇੱਕ ਲਾਈਵ URL ਦਿੰਦਾ ਹੈ; ਇੱਥੇ ਕੋਈ ਵੱਖਰਾ ਸਟੇਜਿੰਗ ਟੌਗਲ ਨਹੀਂ ਹੈ। ਅਮਲ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਵਿਕਲਪ ਹਨ:

• ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਜਾਂਚ ਵਜੋਂ ਪ੍ਰੀਵਿਊ। ਹਰ ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਨਿੱਜੀ ਕਲਾਊਡ ਵਰਕਸਪੇਸ ਵਿੱਚ ਲਾਈਵ ਪ੍ਰੀਵਿਊ ਨਾਲ ਚੱਲਦਾ ਹੈ। /test ਏਜੰਟ ਨੂੰ ਇਸ ਵਿੱਚ ਯੂਜ਼ਰ ਵਾਂਗ ਕਲਿੱਕ ਕਰਵਾਉਂਦਾ ਹੈ, ਅਤੇ Share ਲਿੰਕ ਕਲਾਇੰਟ ਜਾਂ ਟੀਮ ਦੇ ਸਾਥੀ ਨੂੰ ਪਬਲਿਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਪ੍ਰੀਵਿਊ ਦੇਖਣ ਦਿੰਦਾ ਹੈ। ਵੇਖੋ Preview ਅਤੇ Code। ਬਹੁਤ ਸਾਰੇ ਇਕੱਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਇਹ ਕਾਫ਼ੀ ਹੈ।
• ਸਟੇਜਿੰਗ ਵਜੋਂ ਦੂਜਾ ਪ੍ਰੋਜੈਕਟ। Pro 'ਤੇ, ਪ੍ਰੋਜੈਕਟ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੰਪੋਰਟ ਕਰੋ, ਉਸ ਨੂੰ ਆਪਣਾ ਡੇਟਾਬੇਸ ਅਤੇ ਟੈਸਟ-ਕੀ ਸੀਕ੍ਰੇਟ ਦਿਓ, ਅਤੇ ਆਪਣੇ ਸਲੱਗ 'ਤੇ ਪਬਲਿਸ਼ ਕਰੋ। ਪ੍ਰੋਡਕਸ਼ਨ ਪ੍ਰੋਜੈਕਟ ਪਬਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ 'ਤੇ ਰਿਲੀਜ਼ ਕਰੋ।

ਦੋਵਾਂ ਤਰੀਕਿਆਂ ਵਿੱਚ, ਕੋਈ ਵੀ ਖਤਰਨਾਕ ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਏਜੰਟ ਨੂੰ ਪੁੱਛੋ ਕਿ ਪ੍ਰੀਵਿਊ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਕਿਹੜਾ ਡੇਟਾਬੇਸ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਖਰਾਬ ਬਦਲਾਅ ਹੋਵੇ ਤਾਂ ਚੈੱਕਪੌਇੰਟ ਨਾਲ ਰੋਲਬੈਕ ਕਰੋ। ਐਪ ਨੂੰ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਲਾਈਵ ਕਰਨ ਬਾਰੇ ਵੇਖੋ AI ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਲਿਜਾਈਏ।

ਸਵਾਲ