CI/CD ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ: GitHub, GitLab ਅਤੇ CircleCI 'ਤੇ OTP ਅਤੇ ਸਾਈਨ-ਅਪ ਪ੍ਰਵਾਹਾਂ ਦੀ ਜਾਂਚ ਕਰੋ
ਆਟੋਮੈਟਿਕ ਟੈਸਟ ਸੂਟ ਉਸੇ ਵੇਲੇ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਉਹ ਅਸਲ ਮੇਲਬਾਕਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਸਾਂਝੇ ਇਨਬਾਕਸ ਸਮਾਨਾਂਤਰ ਰਨਾਂ ਦੌਰਾਨ ਗੜਬੜ ਨਾਲ ਭਰ ਜਾਂਦੇ ਹਨ, assertions ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ OTP ਕੋਡ ਦੀ ਮਿਆਦ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ logs ਵਿੱਚ ਲੀਕ ਹੋਏ credentials ਇੱਕ ਸਫਲ build ਨੂੰ ਸੁਰੱਖਿਆ ਘਟਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਇਹ ਗਾਈਡ ਕਦਮ-ਦਰ-ਕਦਮ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ disposable email ਨੂੰ GitHub Actions, GitLab CI/CD ਅਤੇ CircleCI ਵਿੱਚ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ। ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਹਰ build ਲਈ ਵੱਖਰੇ inboxes ਕਿਵੇਂ ਤਿਆਰ ਕਰਨੇ ਹਨ, test steps ਦੇ ਅੰਦਰ verification emails ਕਿਵੇਂ ਵਰਤਣੀਆਂ ਹਨ, token ਨੂੰ logs ਤੋਂ ਬਾਹਰ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ ਅਤੇ ਹਰ run ਤੋਂ ਬਾਅਦ ਸਫ਼ਾਈ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਭਾਵੇਂ ਤੁਸੀਂ ਸਾਈਨ-ਅਪ ਪ੍ਰਵਾਹਾਂ, OTP ਡਿਲਿਵਰੀ ਜਾਂ ਲੈਣ-ਦੇਣ ਸੰਬੰਧੀ ਸੂਚਨਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਇੱਥੇ ਦਿੱਤੇ ਪੈਟਰਨ ਇੱਕ workflow ਤੋਂ ਲੈ ਕੇ ਪੂਰੇ ਸਮਾਨਾਂਤਰ test suite ਤੱਕ scale ਕਰਦੇ ਹਨ।
ਤੇਜ਼ ਪਹੁੰਚ
ਵਿਅਸਤ DevOps ਟੀਮਾਂ ਲਈ ਮੁੱਖ ਸਿੱਖਿਆਵਾਂ
ਜੇ ਤੁਹਾਡੇ CI/CD ਟੈਸਟ ਈਮੇਲਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸੁਚੱਜੀ, ਅਸਥਾਈ ਈਮੇਲ ਇਨਬਾਕਸ ਰਣਨੀਤੀ ਦੀ ਲੋੜ ਹੈ; ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਆਖ਼ਰਕਾਰ ਬੱਗ ਜਾਰੀ ਕਰੋਗੇ, ਰਾਜ਼ ਲੀਕ ਕਰੋਗੇ ਜਾਂ ਦੋਵੇਂ।
- CI/CD ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਅਕਸਰ ਸਾਈਨ-ਅੱਪ, OTP, ਪਾਸਵਰਡ ਰੀਸੈਟ ਅਤੇ ਬਿਲਿੰਗ ਸੂਚਨਾਵਾਂ ਵਰਗੇ ਈਮੇਲ ਪ੍ਰਵਾਹ ਆਉਂਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੀ ਸਾਂਝੇ ਮਨੁੱਖੀ ਇਨਬਾਕਸਾਂ ਨਾਲ ਭਰੋਸੇਯੋਗ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।
- ਇੱਕ ਸੁਚੱਜੀ ਅਸਥਾਈ ਈਮੇਲ ਇਨਬਾਕਸ ਰਣਨੀਤੀ ਇਨਬਾਕਸ ਦੇ ਜੀਵਨ-ਚੱਕਰ ਨੂੰ ਪਾਈਪਲਾਈਨ ਦੇ ਜੀਵਨ-ਚੱਕਰ ਨਾਲ ਜੋੜਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਟੈਸਟ ਨਿਰਧਾਰਿਤ ਢੰਗ ਨਾਲ ਚੱਲਦੇ ਹਨ ਅਤੇ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਤੇ ਕਰਮਚਾਰੀਆਂ ਦੇ ਮੇਲਬਾਕਸ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੇ ਹਨ।
- GitHub Actions, GitLab CI ਅਤੇ CircleCI ਸਾਰੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਜਾਂ ਜੌਬ ਆਉਟਪੁੱਟਾਂ ਵਜੋਂ ਅਸਥਾਈ ਈਮੇਲ ਪਤੇ ਤਿਆਰ, ਪਾਸ ਅਤੇ ਵਰਤ ਸਕਦੇ ਹਨ।
- ਸੁਰੱਖਿਆ ਸਖ਼ਤ ਨਿਯਮਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ: ਕੋਈ OTP ਜਾਂ ਇਨਬਾਕਸ token ਲੌਗ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਡਾਟਾ ਰੱਖਣ ਦੀ ਮਿਆਦ ਛੋਟੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇਨਬਾਕਸਾਂ ਦੀ ਇਜਾਜ਼ਤ ਸਿਰਫ਼ ਉੱਥੇ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਜੋਖ਼ਮ-ਪ੍ਰੋਫ਼ਾਈਲ ਇਸ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।
- ਬੁਨਿਆਦੀ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਨਾਲ ਤੁਸੀਂ OTP ਡਿਲਿਵਰੀ ਸਮਾਂ, ਅਸਫਲਤਾ ਦੇ ਪੈਟਰਨ ਅਤੇ ਪ੍ਰਦਾਤਾ ਨਾਲ ਜੁੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਟਰੈਕ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸ ਨਾਲ ਈਮੇਲ-ਆਧਾਰਿਤ ਟੈਸਟ ਮਾਪਣਯੋਗ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ।
CI/CD ਨੂੰ ਈਮੇਲ-ਸੁਰੱਖਿਅਤ ਬਣਾਓ
ਈਮੇਲ ਐਂਡ-ਟੂ-ਐਂਡ ਟੈਸਟਿੰਗ ਦੇ ਸਭ ਤੋਂ ਜਟਿਲ ਹਿੱਸਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ CI/CD ਸਟੇਜਿੰਗ ਵਿੱਚ ਤੁਹਾਡੇ ਵੱਲੋਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀ ਹਰ ਇਨਬਾਕਸ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰ ਵੱਡਾ ਕਰ ਦਿੰਦਾ ਹੈ।
ਆਟੋਮੈਟਿਕ ਟੈਸਟਾਂ ਵਿੱਚ ਈਮੇਲ ਕਿੱਥੇ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ
ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਉਪਭੋਗਤਾ ਯਾਤਰਾ ਦੌਰਾਨ ਘੱਟੋ-ਘੱਟ ਕੁਝ ਲੈਣ-ਦੇਣ ਵਾਲੀਆਂ ਈਮੇਲਾਂ ਭੇਜਦੀਆਂ ਹਨ। CI/CD ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਤੁਹਾਡੇ ਆਟੋਮੈਟਿਕ ਟੈਸਟਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਖਾਤਾ ਸਾਈਨ-ਅੱਪ, OTP ਜਾਂ magic link ਦੀ ਪੁਸ਼ਟੀ, ਪਾਸਵਰਡ ਰੀਸੈਟ, ਈਮੇਲ ਪਤਾ ਬਦਲਣ ਦੀ ਪੁਸ਼ਟੀ, ਬਿਲਿੰਗ ਸੂਚਨਾਵਾਂ ਅਤੇ ਵਰਤੋਂ ਸੰਬੰਧੀ ਚੇਤਾਵਨੀਆਂ ਸ਼ਾਮਲ ਹਨ।
ਇਹ ਸਾਰੇ ਪ੍ਰਵਾਹ ਸੁਨੇਹਾ ਜਲਦੀ ਪ੍ਰਾਪਤ ਕਰਨ, token ਜਾਂ ਲਿੰਕ ਨੂੰ ਪਾਰਸ ਕਰਨ ਅਤੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਸਮਰੱਥਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ ਸਹੀ ਕਾਰਵਾਈ ਹੋਈ ਹੈ। ਓਟੀਪੀ ਤਸਦੀਕ ਲਈ ਟੈਂਪ ਮੇਲ ਵਰਗੀਆਂ ਗਾਈਡਾਂ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇਸ ਕਦਮ ਦੀ ਅਹਿਮੀਅਤ ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇਹੀ ਗੱਲ CI/CD ਦੇ ਅੰਦਰ ਤੁਹਾਡੇ ਟੈਸਟ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
QA ਵਿੱਚ ਅਸਲ ਮੇਲਬਾਕਸ ਕਿਉਂ ਨਹੀਂ ਚੱਲਦੇ
ਛੋਟੇ ਪੈਮਾਨੇ 'ਤੇ ਟੀਮਾਂ ਅਕਸਰ ਸਾਂਝੇ Gmail ਜਾਂ Outlook ਇਨਬਾਕਸ ਨਾਲ ਟੈਸਟ ਚਲਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਉਸ ਨੂੰ ਹੱਥੀਂ ਸਾਫ਼ ਕਰਦੀਆਂ ਹਨ। ਜਿਵੇਂ ਹੀ ਤੁਹਾਡੇ ਕੋਲ ਸਮਾਂਤਰ ਜੌਬਾਂ, ਕਈ ਵਾਤਾਵਰਣ ਜਾਂ ਵਾਰ-ਵਾਰ ਡਿਪਲੌਇਮੈਂਟ ਹੋਣ, ਇਹ ਤਰੀਕਾ ਨਾਕਾਮ ਹੋ ਜਾਂਦਾ ਹੈ।
ਸਾਂਝੇ ਇਨਬਾਕਸ ਜਲਦੀ ਹੀ ਫ਼ਜ਼ੂਲ ਸੁਨੇਹਿਆਂ, ਸਪੈਮ ਅਤੇ ਡੁਪਲੀਕੇਟ ਟੈਸਟ ਸੁਨੇਹਿਆਂ ਨਾਲ ਭਰ ਜਾਂਦੇ ਹਨ। Rate limits ਲਾਗੂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਡਿਵੈਲਪਰ ਟੈਸਟ ਲੌਗ ਪੜ੍ਹਨ ਨਾਲੋਂ ਫੋਲਡਰਾਂ ਵਿੱਚ ਖੋਜ ਕਰਨ 'ਤੇ ਵੱਧ ਸਮਾਂ ਲਗਾਉਂਦੇ ਹਨ। ਇਸ ਤੋਂ ਵੀ ਮਾੜੀ ਗੱਲ, ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਕਿਸੇ ਅਸਲ ਕਰਮਚਾਰੀ ਦਾ ਮੇਲਬਾਕਸ ਵਰਤ ਸਕਦੇ ਹੋ, ਜਿਸ ਨਾਲ ਟੈਸਟ ਡਾਟਾ ਨਿੱਜੀ ਸੰਚਾਰ ਵਿੱਚ ਰਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਆਡਿਟ ਲਈ ਵੱਡੀ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ।
ਜੋਖ਼ਮ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਜਦੋਂ ਅਸਥਾਈ ਈਮੇਲ ਅਤੇ ਅਸਥਾਈ ਇਨਬਾਕਸ ਉਪਲਬਧ ਹਨ, ਤਾਂ ਆਟੋਮੈਟਿਕ ਟੈਸਟਾਂ ਲਈ ਅਸਲ ਮੇਲਬਾਕਸ ਵਰਤਣ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ ਔਖਾ ਹੈ। ਈਮੇਲ ਅਤੇ ਟੈਂਪ ਮੇਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਬਾਰੇ ਗਾਈਡ ਇਹ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗਤਾ ਗੁਆਏ ਬਿਨਾਂ ਟੈਸਟ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਅਸਲ ਸੰਚਾਰ ਤੋਂ ਵੱਖ ਕਰ ਸਕਦੇ ਹੋ।
CI/CD ਵਿੱਚ ਅਸਥਾਈ ਇਨਬਾਕਸ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੇ ਹਨ
ਮੁੱਖ ਵਿਚਾਰ ਸਧਾਰਣ ਹੈ: ਹਰ CI/CD ਰਨ ਜਾਂ ਟੈਸਟ ਸੂਟ ਨੂੰ ਆਪਣਾ ਅਸਥਾਈ ਈਮੇਲ ਪਤਾ ਮਿਲਦਾ ਹੈ, ਜੋ ਸਿਰਫ਼ ਕ੍ਰਿਤ੍ਰਿਮ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਰੱਖੇ ਜਾਣ ਵਾਲੇ ਡਾਟਾ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ। ਟੈਸਟ ਅਧੀਨ ਐਪਲੀਕੇਸ਼ਨ ਉਸ ਪਤੇ 'ਤੇ OTP, ਪੁਸ਼ਟੀਕਰਨ ਲਿੰਕ ਅਤੇ ਸੂਚਨਾਵਾਂ ਭੇਜਦੀ ਹੈ। ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ API ਜਾਂ ਸਧਾਰਣ HTTP endpoint ਰਾਹੀਂ ਈਮੇਲ ਦੀ ਸਮੱਗਰੀ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਕੱਢਦੀ ਹੈ ਅਤੇ ਫਿਰ ਇਨਬਾਕਸ ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸੁਚੱਜਾ ਪੈਟਰਨ ਅਪਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਅਸਲ ਮੇਲਬਾਕਸਾਂ ਨੂੰ ਪ੍ਰਦੂਸ਼ਿਤ ਕੀਤੇ ਬਿਨਾਂ ਨਿਰਧਾਰਿਤ ਢੰਗ ਨਾਲ ਚੱਲਣ ਵਾਲੇ ਟੈਸਟ ਮਿਲਦੇ ਹਨ। ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਟੈਂਪ ਮੇਲ ਗਾਈਡ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਯੋਗਾਂ ਲਈ ਅਸਥਾਈ ਈਮੇਲ ਪਤਿਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ; CI/CD ਇਸ ਵਿਚਾਰ ਦਾ ਕੁਦਰਤੀ ਵਿਸਥਾਰ ਹੈ।
ਇੱਕ ਸੁਚੱਜੀ ਇਨਬਾਕਸ ਰਣਨੀਤੀ ਤਿਆਰ ਕਰੋ
YAML ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨੇ ਇਨਬਾਕਸ ਚਾਹੀਦੇ ਹਨ, ਉਹ ਕਿੰਨੇ ਸਮੇਂ ਤੱਕ ਸਰਗਰਮ ਰਹਿਣਗੇ ਅਤੇ ਕਿਹੜੇ ਜੋਖ਼ਮ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੋਗੇ।
ਹਰ ਬਿਲਡ ਲਈ ਬਨਾਮ ਸਾਂਝੇ ਟੈਸਟ ਇਨਬਾਕਸ
ਇੱਥੇ ਦੋ ਆਮ ਪੈਟਰਨ ਹਨ। ਹਰ ਬਿਲਡ ਵਾਲੇ ਪੈਟਰਨ ਵਿੱਚ, ਹਰ ਪਾਈਪਲਾਈਨ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਇੱਕ ਬਿਲਕੁਲ ਨਵਾਂ ਪਤਾ ਬਣਾਉਂਦੀ ਹੈ। ਇਸ ਨਾਲ ਪੂਰੀ ਅਲੱਗਤਾ ਮਿਲਦੀ ਹੈ: ਛਾਂਟਣ ਲਈ ਕੋਈ ਪੁਰਾਣੀਆਂ ਈਮੇਲਾਂ ਨਹੀਂ, ਇੱਕੋ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਰਨਾਂ ਵਿਚਕਾਰ ਕੋਈ race conditions ਨਹੀਂ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਮਾਨਸਿਕ ਮਾਡਲ। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹਰ ਵਾਰ ਨਵਾਂ ਇਨਬਾਕਸ ਬਣਾਕੇ ਪਾਸ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਇਨਬਾਕਸ ਦੀ ਮਿਆਦ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ।
ਸਾਂਝੇ ਇਨਬਾਕਸ ਵਾਲੇ ਪੈਟਰਨ ਵਿੱਚ, ਤੁਸੀਂ ਹਰ branch, ਵਾਤਾਵਰਣ ਜਾਂ ਟੈਸਟ ਸੂਟ ਲਈ ਇੱਕ ਅਸਥਾਈ ਈਮੇਲ ਪਤਾ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ। ਇਹੀ ਪਤਾ ਵੱਖ-ਵੱਖ ਰਨਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਡੀਬੱਗ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗੈਰ-ਨਾਜ਼ੁਕ ਸੂਚਨਾ ਟੈਸਟਾਂ ਲਈ ਇਹ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਤੁਹਾਨੂੰ ਮੇਲਬਾਕਸ 'ਤੇ ਸਖ਼ਤ ਨਿਯੰਤਰਣ ਰੱਖਣਾ ਪਵੇਗਾ ਤਾਂ ਜੋ ਇਹ ਲੰਬੇ ਸਮੇਂ ਦਾ ਕੂੜਾ-ਘਰ ਨਾ ਬਣ ਜਾਵੇ।
ਟੈਸਟ ਦ੍ਰਿਸ਼ਾਂ ਲਈ ਇਨਬਾਕਸ ਮੈਪ ਕਰਨਾ
ਆਪਣੇ ਇਨਬਾਕਸਾਂ ਦੀ ਵੰਡ ਨੂੰ ਟੈਸਟ ਡੇਟਾ ਡਿਜ਼ਾਈਨ ਵਜੋਂ ਸੋਚੋ। ਇੱਕ ਪਤਾ ਖਾਤਾ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਲਈ, ਦੂਜਾ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਪ੍ਰਵਾਹ ਲਈ ਅਤੇ ਤੀਜਾ ਸੂਚਨਾਵਾਂ ਲਈ ਸਮਰਪਿਤ ਹੋ ਸਕਦਾ ਹੈ। ਬਹੁ-ਕਿਰਾਏਦਾਰ ਜਾਂ ਖੇਤਰ-ਅਧਾਰਿਤ ਵਾਤਾਵਰਣਾਂ ਲਈ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾ ਕੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਡ੍ਰਿਫਟ ਪਕੜਨ ਲਈ ਪ੍ਰਤੀ ਕਿਰਾਏਦਾਰ ਜਾਂ ਪ੍ਰਤੀ ਖੇਤਰ ਇੱਕ ਇਨਬਾਕਸ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ।
ਦ੍ਰਿਸ਼ ਅਤੇ ਵਾਤਾਵਰਣ ਨੂੰ ਦਰਸਾਉਣ ਵਾਲੀਆਂ ਨਾਮਕਰਨ ਪਰੰਪਰਾਵਾਂ ਵਰਤੋ, ਜਿਵੇਂ ਕਿ signup-us-east-@example-temp.com ਜਾਂ password-reset-staging-@example-temp.com। ਇਸ ਨਾਲ ਸਮੱਸਿਆ ਆਉਣ 'ਤੇ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਖਾਸ ਟੈਸਟਾਂ ਨਾਲ ਜੋੜਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਅਸਥਾਈ ਈਮੇਲ ਗਲਤ ਟੂਲ ਹੋਵੇ
ਜਦੋਂ ਤੁਹਾਡਾ ਦਾਅਵਾ ਕਿਸੇ ਅਜਿਹੀ ਚੀਜ਼ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੋਵੇ ਜੋ ਅਸਥਾਈ ਇਨਬਾਕਸ ਨਹੀਂ ਦੇ ਸਕਦਾ—ਜਿਵੇਂ ਖੋਲ੍ਹਣ ਲਈ ਕੋਈ ਅਟੈਚਮੈਂਟ, ਇੱਕ ਦਿਨ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੱਕ ਰਹਿਣ ਵਾਲਾ ਸੁਨੇਹਾ ਇਤਿਹਾਸ, ਜਾਂ ਅਗਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਵੀ ਮੁੜ-ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਣ ਵਾਲਾ ਖਾਤਾ—ਤਾਂ ਤੁਰੰਤ ਪ੍ਰਬੰਧਿਤ ਟੈਸਟ ਇਨਬਾਕਸ ਜਾਂ ਅੰਦਰੂਨੀ ਮੇਲ-ਕੈਪਚਰ ਸੇਵਾ ਵਰਤੋ। ਅਸਥਾਈ ਇਨਬਾਕਸ ਸਿੰਥੈਟਿਕ ਸਾਈਨ-ਅਪ, OTP ਅਤੇ ਸੂਚਨਾ ਪ੍ਰਵਾਹਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹਨ। ਇਹ ਨਿਯਮ-ਅਧੀਨ, ਭੁਗਤਾਨ ਨਾਲ ਜੁੜੇ ਜਾਂ ਮਨੁੱਖੀ ਮਲਕੀਅਤ ਵਾਲੇ ਖਾਤਿਆਂ ਲਈ ਗਲਤ ਫਿਕਸਚਰ ਹਨ—ਅਜਿਹੇ ਮਾਮਲੇ ਵਿੱਚ ਇਨ੍ਹਾਂ ਦੀ ਚੋਣ ਕਰਨ ਨਾਲ ਪਾਸ ਹੋਇਆ ਟੈਸਟ ਵੀ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
CI/CD ਲਈ ਅਸਥਾਈ ਈਮੇਲ ਪ੍ਰਦਾਤਾ ਚੁਣਨਾ
CI/CD ਈਮੇਲ ਟੈਸਟਿੰਗ ਲਈ ਆਮ ਇਕ-ਵਾਰ ਵਰਤੋਂ ਨਾਲੋਂ ਕੁਝ ਵੱਖਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਤੇਜ਼ OTP ਡਿਲਿਵਰੀ, ਸਥਿਰ MX ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਅਤੇ ਉੱਚ ਡਿਲਿਵਰੇਬਿਲਿਟੀ, ਸ਼ਾਨਦਾਰ UI ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜਿਹੜੇ ਲੇਖ ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਓਟੀਪੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਦਾ ਹੈ, ਇਹ ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਵਧੀਆ ਇਨਬਾਊਂਡ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਤੁਹਾਡੀ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਸਫਲ ਜਾਂ ਅਸਫਲ ਕਰ ਸਕਦਾ ਹੈ।
ਫਿਰ ਉਨ੍ਹਾਂ 'ਤੇ ਨਿਰਮਾਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਾਵਟਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਦਾਅਵਾ ਕਰ ਸਕਦੇ ਹੋ. ਬਹੁਤ ਸਾਰੀਆਂ ਟੈਂਪ ਮੇਲ ਸੇਵਾਵਾਂ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ, ਸਿਰਫ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀਆਂ ਹਨ ਅਤੇ ਪੂਰੀ ਇਨਬਾਊਂਡ ਅਟੈਚਮੈਂਟਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦੀਆਂ ਹਨ ਹਨ - ਸੁਨੇਹਾ ਸਰੀਰ ਆਉਂਦਾ ਹੈ, ਫਾਈਲ ਨਹੀਂ ਹੁੰਦੀ. ਜੇ ਕਿਸੇ ਟੈਸਟ ਨੂੰ ਪੀਡੀਐਫ ਇਨਵੌਇਸ ਜਾਂ ਤਿਆਰ ਕੀਤੀ ਰਿਪੋਰਟ ਖੋਲ੍ਹਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਸਟਰਿੱਪਡ-ਅਟੈਚਮੈਂਟ ਇਨਬਾਕਸ ਉਸ ਦਾਅਵੇ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਚਲਾ ਸਕਦਾ, ਅਤੇ ਪੋਲਿੰਗ ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲੇਗੀ. ਧਾਰਨ ਦੀ ਜਾਂਚ ਕਰੋ: ਟਮੇਲਰ ਲਗਭਗ 24 ਘੰਟਿਆਂ ਲਈ ਇੱਕ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਬਿਲਡ ਲਈ ਕਾਫ਼ੀ ਹੈ ਅਤੇ ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਪੋਸਟਮਾਰਟਮ ਲਈ ਬੇਕਾਰ ਹੈ.
ਪਹੁੰਚ ਦੀ ਇੱਕ ਹੋਰ ਕਮੀ ਹੈ, ਜਿਸ ਦਾ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਟਮੇਲਰ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਜਨਤਕ ਏਪੀਆਈ ਪ੍ਰਕਾਸ਼ਤ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਇਹ ਟੈਸਟ ਰਨਰ ਲਈ ਸਿੱਧਾ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਰੋਤ ਨਹੀਂ ਹੈ; ਜੇ ਤੁਹਾਨੂੰ ਪ੍ਰੋਗਰਾਮੇਟਿਕ ਤਰੀਕੇ ਨਾਲ ਸੁਨੇਹੇ ਲੈਣੇ ਹਨ, ਤਾਂ ਅਜਿਹਾ ਪ੍ਰਦਾਤਾ ਚੁਣੋ ਜੋ ਇਨਬਾਊਂਡ ਐਂਡਪੌਇੰਟ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੋਵੇ ਜਾਂ ਆਪਣੀ ਨਿਗਰਾਨੀ ਹੇਠ ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ ਸੇਵਾ ਬਣਾਓ। ਕਿਸੇ ਵੀ ਪ੍ਰਦਾਤਾ ਦੇ ਰਿਕਵਰੀ token ਨੂੰ ਹਰ ਹਾਲਤ ਵਿੱਚ ਗੁਪਤ ਰੱਖੋ।
GitHub Actions ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਜੋੜਨਾ
GitHub Actions ਵਿੱਚ ਅਜਿਹੇ ਪ੍ਰੀ-ਸਟੈਪ ਜੋੜਨਾ ਆਸਾਨ ਹੈ ਜੋ ਅਸਥਾਈ ਇਨਬਾਕਸ ਬਣਾਉਣ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ environment variables ਵਜੋਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟਾਂ ਤੱਕ ਪਹੁੰਚਾਉਣ।
ਪੈਟਰਨ: ਟੈਸਟ jobs ਤੋਂ ਪਹਿਲਾਂ ਇਨਬਾਕਸ ਬਣਾਓ
ਇੱਕ ਆਮ ਵਰਕਫਲੋ ਇੱਕ ਹਲਕੇ ਭਾਰ ਵਾਲੀ ਨੌਕਰੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜੋ ਇੱਕ ਨਵਾਂ ਅਸਥਾਈ ਈਮੇਲ ਪਤਾ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਕ੍ਰਿਪਟ ਜਾਂ ਅੰਤਮ ਬਿੰਦੂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ. ਉਹ ਨੌਕਰੀ ਪਤੇ ਨੂੰ ਆਉਟਪੁੱਟ ਵੇਰੀਏਬਲ ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਰਯਾਤ ਕਰਦੀ ਹੈ ਜਾਂ ਇਸਨੂੰ ਇੱਕ ਕਲਾਕ੍ਰਿਤੀ ਵਿੱਚ ਲਿਖਦੀ ਹੈ. ਵਰਕਫਲੋ ਵਿੱਚ ਬਾਅਦ ਦੀਆਂ ਨੌਕਰੀਆਂ ਮੁੱਲ ਨੂੰ ਪੜ੍ਹਦੀਆਂ ਹਨ ਅਤੇ ਇਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਜਾਂ ਟੈਸਟ ਕੋਡ ਵਿੱਚ ਵਰਤਦੀਆਂ ਹਨ.
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਅਸਥਾਈ ਈਮੇਲ ਪਤਿਆਂ ਲਈ ਨਵੀਂ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਅਸਥਾਈ ਈਮੇਲ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਅਸਥਾਈ ਈਮੇਲ ਕਿਵੇਂ ਵਰਤਣੀ ਹੈ, ਇਸ ਬਾਰੇ ਗਾਈਡ ਦੀ ਮਦਦ ਨਾਲ ਮੈਨੂਅਲ workflow ਅਜ਼ਮਾਓ। ਜਦੋਂ ਹਰ ਕੋਈ ਸਮਝ ਲੈਂਦਾ ਹੈ ਕਿ ਇਨਬਾਕਸ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸੁਨੇਹੇ ਕਿਵੇਂ ਪਹੁੰਚਦੇ ਹਨ, ਤਾਂ ਇਸ ਨੂੰ GitHub Actions ਵਿੱਚ ਆਟੋਮੇਟ ਕਰਨਾ ਕਾਫ਼ੀ ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਟੈਸਟ ਪੜਾਵਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀਕਰਨ ਈਮੇਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
ਤੁਹਾਡੀ ਟੈਸਟ ਨੌਕਰੀ ਦੇ ਅੰਦਰ, ਟੈਸਟ ਅਧੀਨ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤਿਆਰ ਕੀਤੇ ਪਤੇ ਤੇ ਈਮੇਲ ਭੇਜਣ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ. ਤੁਹਾਡਾ ਟੈਸਟ ਕੋਡ ਫਿਰ ਡਿਸਪੋਸੇਬਲ ਇਨਬਾਕਸ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਪੋਲ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਸਹੀ ਵਿਸ਼ਾ ਲਾਈਨ ਨੂੰ ਨਹੀਂ ਵੇਖਦਾ, ਇੱਕ ਓਟੀਪੀ ਜਾਂ ਤਸਦੀਕ ਲਿੰਕ ਲਈ ਈਮੇਲ ਬਾਡੀ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਵਾਹ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਉਸ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ.
Timeouts ਅਤੇ ਸਪਸ਼ਟ error messages ਨੂੰ ਇਕਸਾਰ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰੋ। ਜੇ OTP ਵਾਜਬ ਸਮੇਂ ਅੰਦਰ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਤਾਂ test ਨੂੰ ਅਜਿਹੇ ਸੁਨੇਹੇ ਨਾਲ fail ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇ ਕਿ ਸਮੱਸਿਆ provider, app ਜਾਂ pipeline ਵਿੱਚ ਹੈ।
ਹਰੇਕ ਵਰਕਫਲੋ ਦੌੜ ਦੇ ਬਾਅਦ ਸਾਫ਼-ਸਫ਼ਾਈ ਕਰਨਾ
ਜੇ ਤੁਹਾਡਾ provider automatic expiration ਵਾਲੇ ਛੋਟੀ ਮਿਆਦ ਦੇ inboxes ਵਰਤਦਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਵੱਖਰੀ cleanup ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਨਿਰਧਾਰਤ ਸਮੇਂ ਬਾਅਦ ਅਸਥਾਈ ਪਤਾ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ test data ਵੀ ਮਿਟ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪੂਰੀ ਈਮੇਲ ਸਮੱਗਰੀ ਜਾਂ OTPs ਨੂੰ ਅਜਿਹੇ build logs ਵਿੱਚ ਦਰਜ ਕਰਨ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ inbox ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਸਮੇਂ ਤੱਕ ਮੌਜੂਦ ਰਹਿੰਦੇ ਹਨ।
ਲੌਗਾਂ ਵਿੱਚ ਸਿਰਫ ਘੱਟੋ ਘੱਟ ਮੈਟਾਡੇਟਾ ਰੱਖੋ, ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ ਕਿ ਕਿਹੜੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ, ਕੀ ਈਮੇਲ ਪ੍ਰਾਪਤ ਹੋਈ ਸੀ, ਅਤੇ ਬੁਨਿਆਦੀ ਸਮੇਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਸ਼ਾਮਲ ਹਨ. ਕਿਸੇ ਵੀ ਵਾਧੂ ਵੇਰਵਿਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਲਾਕ੍ਰਿਤੀਆਂ ਜਾਂ ਨਿਰੀਖਣ ਸਾਧਨਾਂ ਵਿੱਚ ਸਹੀ ਪਹੁੰਚ ਨਿਯੰਤਰਣਾਂ ਦੇ ਨਾਲ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ.
GitLab CI/CD ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਜੋੜਨਾ
GitLab pipelines ਅਸਥਾਈ ਇਨਬਾਕਸ ਬਣਾਉਣ ਨੂੰ ਇੱਕ ਮੁੱਖ stage ਵਜੋਂ ਮੰਨ ਸਕਦੀਆਂ ਹਨ ਅਤੇ secrets ਸਾਹਮਣੇ ਲਿਆਂਦੇ ਬਿਨਾਂ ਈਮੇਲ ਪਤੇ ਬਾਅਦ ਦੀਆਂ jobs ਤੱਕ ਪਹੁੰਚਾ ਸਕਦੀਆਂ ਹਨ।
ਈਮੇਲ-ਜਾਗਰੂਕ ਪਾਈਪਲਾਈਨ ਪੜਾਵਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ
ਇੱਕ ਸੁਚੱਜਾ GitLab ਡਿਜ਼ਾਈਨ ਇਨਬਾਕਸ ਬਣਾਉਣ, ਟੈਸਟ ਚਲਾਉਣ ਅਤੇ ਆਰਟੀਫੈਕਟ ਇਕੱਠੇ ਕਰਨ ਨੂੰ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਪਤਾ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਮਾਸਕ ਕੀਤੇ ਵੇਰੀਏਬਲ ਜਾਂ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਪੜਾਅ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਨਬਾਕਸ ਉਪਲਬਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਚੱਲਣ ਕਾਰਨ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਰੇਸ ਕੰਡੀਸ਼ਨਾਂ ਤੋਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ।
ਜੌਬਾਂ ਵਿਚਕਾਰ ਇਨਬਾਕਸ ਦੇ ਵੇਰਵੇ ਭੇਜਣਾ
ਤੁਹਾਡੀ ਸੁਰੱਖਿਆ ਨੀਤੀ ਦੇ ਆਧਾਰ 'ਤੇ, ਤੁਸੀਂ CI ਵੇਰੀਏਬਲਾਂ, ਜੌਬ ਆਰਟੀਫੈਕਟਾਂ ਜਾਂ ਦੋਵਾਂ ਰਾਹੀਂ ਜੌਬਾਂ ਵਿਚਕਾਰ ਇਨਬਾਕਸ ਪਤੇ ਭੇਜ ਸਕਦੇ ਹੋ। ਪਤਾ ਆਮ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਇਨਬਾਕਸ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ token ਨੂੰ ਪਾਸਵਰਡ ਵਾਂਗ ਸੁਰੱਖਿਅਤ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਮੁੱਲਾਂ ਨੂੰ ਮਾਸਕ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ echo ਕਰਨ ਤੋਂ ਬਚੋ। ਜੇ ਕਈ ਜੌਬਾਂ ਇੱਕੋ ਡਿਸਪੋਜ਼ੇਬਲ ਇਨਬਾਕਸ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਅਣਜਾਣੇ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤੋਂ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ ਸਾਂਝਾ ਕਰਨ ਦੀ ਵਿਵਸਥਾ ਜਾਣਬੁੱਝ ਕੇ ਤੈਅ ਕਰੋ, ਤਾਂ ਜੋ ਪਿਛਲੀਆਂ ਰਨਾਂ ਦੀਆਂ ਈਮੇਲਾਂ ਨੂੰ ਗਲਤ ਨਾ ਸਮਝਿਆ ਜਾਵੇ।
ਅਸਥਿਰ ਈਮੇਲ-ਅਧਾਰਿਤ ਟੈਸਟਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ
ਜਦੋਂ ਈਮੇਲ ਟੈਸਟ ਕਦੇ-ਕਦੇ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਪਹਿਲਾਂ ਡਿਲੀਵਰੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਟੈਸਟ ਲਾਜਿਕ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਫ਼ਰਕ ਕਰੋ। ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਉਸੇ ਸਮੇਂ ਹੋਰ OTP ਜਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਟੈਸਟ ਵੀ ਅਸਫਲ ਹੋਏ ਸਨ। QA ਲਈ OTP ਜੋਖਮ ਚੈੱਕਲਿਸਟ ਵਰਗੇ ਸਰੋਤਾਂ ਤੋਂ ਮਿਲਣ ਵਾਲੇ ਪੈਟਰਨ ਤੁਹਾਡੀ ਜਾਂਚ ਨੂੰ ਦਿਸ਼ਾ ਦੇ ਸਕਦੇ ਹਨ।
ਤੁਸੀਂ ਅਸਫਲ ਰਨਾਂ ਲਈ ਪੂਰੇ ਸੁਨੇਹੇ ਦਾ ਮੁੱਖ ਭਾਗ ਸਟੋਰ ਕੀਤੇ ਬਿਨਾਂ ਸੀਮਿਤ ਹੈਡਰ ਅਤੇ ਮੈਟਾਡੇਟਾ ਵੀ ਇਕੱਠਾ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਅਕਸਰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ ਕਿ ਮੇਲ ਦੀ ਰਫ਼ਤਾਰ ਸੀਮਿਤ ਕੀਤੀ ਗਈ, ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਜਾਂ ਦੇਰੀ ਹੋਈ ਸੀ—ਨਾਲ ਹੀ ਗੋਪਨੀਯਤਾ ਦਾ ਸਤਿਕਾਰ ਅਤੇ ਡੇਟਾ ਘੱਟੋ-ਘੱਟ ਰੱਖਣ ਦੇ ਸਿਧਾਂਤਾਂ ਦੀ ਪਾਲਣਾ ਵੀ ਹੁੰਦੀ ਹੈ।
ਸਰਕਲਸੀਆਈ ਵਿੱਚ ਵਾਇਰ ਟੈਂਪ ਮੇਲ
CircleCI ਜੌਬਾਂ ਅਤੇ orbs ਪੂਰੇ "ਇਨਬਾਕਸ ਬਣਾਓ → ਈਮੇਲ ਦੀ ਉਡੀਕ ਕਰੋ → token ਕੱਢੋ" ਪੈਟਰਨ ਨੂੰ ਸਮੇਟ ਸਕਦੇ ਹਨ, ਤਾਂ ਜੋ ਟੀਮਾਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਵਰਤ ਸਕਣ।
ਈਮੇਲ ਟੈਸਟਿੰਗ ਲਈ ਜੌਬ-ਪੱਧਰੀ ਪੈਟਰਨ
CircleCI ਵਿੱਚ ਆਮ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਇੱਕ pre-step ਤੁਹਾਡੇ ਅਸਥਾਈ ਈਮੇਲ ਪ੍ਰਦਾਤਾ ਨੂੰ ਕਾਲ ਕਰੇ, ਬਣਾਇਆ ਗਿਆ ਪਤਾ environment variable ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰੇ ਅਤੇ ਫਿਰ end-to-end ਟੈਸਟ ਚਲਾਏ। ਟੈਸਟ ਕੋਡ GitHub Actions ਜਾਂ GitLab CI ਵਾਂਗ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਈਮੇਲ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, OTP ਜਾਂ ਲਿੰਕ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਨਾਰੀਓ ਜਾਰੀ ਰੱਖਦਾ ਹੈ।
Orbs ਅਤੇ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਪਰਿਪੱਕ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਈਮੇਲ ਟੈਸਟਿੰਗ ਨੂੰ orbs ਜਾਂ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਕਮਾਂਡਾਂ ਵਿੱਚ ਸਮੇਟ ਸਕਦੇ ਹੋ। ਇਹ ਹਿੱਸੇ ਇਨਬਾਕਸ ਬਣਾਉਣ, ਪੋਲਿੰਗ ਅਤੇ ਪਾਰਸਿੰਗ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ, ਫਿਰ ਸਧਾਰਣ ਮੁੱਲ ਵਾਪਸ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੈਸਟ ਵਰਤ ਸਕਦੇ ਹਨ। ਇਸ ਨਾਲ ਕਾਪੀ-ਪੇਸਟ ਦੀ ਲੋੜ ਘਟਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਨਿਯਮ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਸਮਾਨਾਂਤਰ ਜੌਬਾਂ ਵਿੱਚ ਈਮੇਲ ਟੈਸਟਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨਾ
CircleCI ਵਿੱਚ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਮਾਨਾਂਤਰਤਾ ਆਸਾਨ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਈਮੇਲ ਦੀਆਂ ਬਾਰੀਕ ਸਮੱਸਿਆਵਾਂ ਵਧ ਸਕਦੀਆਂ ਹਨ। ਕਈ ਸਮਾਨਾਂਤਰ ਜੌਬਾਂ ਵਿੱਚ ਇੱਕੋ ਇਨਬਾਕਸ ਦੁਬਾਰਾ ਵਰਤਣ ਤੋਂ ਬਚੋ। ਇਸ ਦੀ ਬਜਾਏ, ਟੱਕਰਾਂ ਘਟਾਉਣ ਲਈ ਜੌਬ ਇੰਡੈਕਸ ਜਾਂ ਕੰਟੇਨਰ ID ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਨਬਾਕਸ ਵੰਡੋ। ਪੂਰੀਆਂ ਪਾਈਪਲਾਈਨਾਂ ਅਸਫਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂਆਤੀ ਚੇਤਾਵਨੀ ਸੰਕੇਤ ਪਛਾਣਨ ਲਈ ਈਮੇਲ ਪ੍ਰਦਾਤਾ ਵਾਲੇ ਪਾਸੇ ਗਲਤੀ ਦਰਾਂ ਅਤੇ rate limits ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ।
ਟੈਸਟ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਜੋਖਮ ਘਟਾਉਣਾ
ਡਿਸਪੋਜ਼ੇਬਲ ਇਨਬਾਕਸ ਕੁਝ ਜੋਖਮ ਘਟਾਉਂਦੇ ਹਨ, ਪਰ ਨਵੇਂ ਜੋਖਮ ਵੀ ਪੈਦਾ ਕਰਦੇ ਹਨ—ਖ਼ਾਸਕਰ secrets ਸੰਭਾਲਣ, ਲੌਗਿੰਗ ਅਤੇ ਖਾਤਾ ਮੁੜ ਪ੍ਰਾਪਤੀ ਦੇ ਵਿਹਾਰ ਨਾਲ ਜੁੜੇ।
Secrets ਅਤੇ OTP ਨੂੰ ਲੌਗਾਂ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ
ਤੁਹਾਡੇ ਪਾਈਪਲਾਈਨ ਲੌਗ ਅਕਸਰ ਮਹੀਨਿਆਂ ਤੱਕ ਸਟੋਰ ਰਹਿੰਦੇ ਹਨ, ਬਾਹਰੀ ਲੌਗ ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮਾਂ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਲੋਕਾਂ ਦੁਆਰਾ ਐਕਸੈਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ OTP ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। verification codes, magic links ਜਾਂ ਇਨਬਾਕਸ tokens ਨੂੰ ਕਦੇ ਵੀ ਸਿੱਧੇ stdout 'ਤੇ ਪ੍ਰਿੰਟ ਨਾ ਕਰੋ। ਸਿਰਫ਼ ਇਹ ਲੌਗ ਕਰੋ ਕਿ ਮੁੱਲ ਪ੍ਰਾਪਤ ਹੋਇਆ ਅਤੇ ਸਫਲਤਾਪੂਰਵਕ ਵਰਤਿਆ ਗਿਆ।
OTP ਸੰਭਾਲਣ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਸਾਵਧਾਨੀ ਕਿਉਂ ਲੋੜੀਂਦੀ ਹੈ, ਇਸ ਬਾਰੇ ਪਿਛੋਕੜ ਲਈ ਓਟੀਪੀ ਤਸਦੀਕ ਲਈ ਟੈਂਪ ਮੇਲ ਇੱਕ ਕੀਮਤੀ ਸਹਾਇਕ ਲੇਖ ਹੈ। ਆਪਣੇ ਟੈਸਟਾਂ ਨਾਲ ਅਜਿਹਾ ਵਿਹਾਰ ਕਰੋ ਜਿਵੇਂ ਉਹ ਅਸਲ ਖਾਤੇ ਹੋਣ: ਸਿਰਫ਼ ਇਸ ਲਈ ਮਾੜੀਆਂ ਪ੍ਰਥਾਵਾਂ ਨੂੰ ਆਮ ਨਾ ਬਣਾਓ ਕਿ ਡੇਟਾ ਸਿੰਥੈਟਿਕ ਹੈ।
Tokens ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇਨਬਾਕਸਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ
ਕੁਝ ਪ੍ਰਦਾਤਾ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਰਿਕਵਰੀ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਸੇ ਪਤੇ ਤੇ ਵਾਪਸ ਜਾਣ ਦਿੰਦੇ ਹਨ - ਟਮੇਲਰ ਇਸ ਨੂੰ ਐਕਸੈਸ ਟੋਕਨ ਕਹਿੰਦਾ ਹੈ - ਜੋ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੇ QA ਅਤੇ UAT ਵਾਤਾਵਰਣ ਲਈ ਲਾਭਦਾਇਕ ਹੈ. ਇਹ ਕੀ ਹੈ ਇਸ ਬਾਰੇ ਸਹੀ ਰਹੋ, ਕਿਉਂਕਿ ਟੀਮਾਂ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਗਲਤ ਕਰਦੀਆਂ ਹਨ. ਇਹ ਇੱਕ ਰਿਕਵਰੀ ਕੁੰਜੀ ਹੈ, ਪਾਸਵਰਡ ਨਹੀਂ ਅਤੇ ਨਾ ਹੀ ਇੱਕ ਤਾਲਾ:: ਇਹ ਤੁਹਾਨੂੰ ਕਿਸੇ ਪਤੇ 'ਤੇ ਮੁੜ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ, ਪਰ ਕਿਸੇ ਹੋਰ ਨੂੰ ਉਸ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਰੱਖਦੀ; ਅਤੇ ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਗੁਆ ਦਿਓ, ਤਾਂ ਕੋਈ ਵੀ ਇਸਨੂੰ ਤੁਹਾਡੇ ਲਈ ਮੁੜ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਸ ਲਈ ਇਸਨੂੰ ਆਪਣੀਆਂ API keys ਵਾਲੇ ਹੀ secret vault ਵਿੱਚ ਇਸ ਆਧਾਰ 'ਤੇ ਸਟੋਰ ਕਰੋ ਕਿ ਜਿਸ ਕੋਲ ਇਹ ਹੈ, ਉਹ ਉਸ ਇਨਬਾਕਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ—ਇਸ ਗਲਤ ਵਿਸ਼ਵਾਸ ਨਾਲ ਨਹੀਂ ਕਿ ਇਹ ਇਨਬਾਕਸ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। ਅਤੇ ਇਸਦੀ ਹੱਦ ਵੀ ਯਾਦ ਰੱਖੋ: ਇਹ ਸਿਰਫ਼ ਪਤਾ , ਡਾਕ ਨਹੀਂ। ਜੋ ਸੁਨੇਹੇ ਪਹਿਲਾਂ ਹੀ ਮਿਆਦ ਪੁੱਗਣ ਕਾਰਨ ਹਟ ਚੁੱਕੇ ਹਨ, ਉਹ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦੇ, ਇਸ ਲਈ ਮੁੜ ਵਰਤੋਂਯੋਗ ਇਨਬਾਕਸ ਪੁਰਾਲੇਖ ਨਹੀਂ ਹੁੰਦਾ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਪਤਿਆਂ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਇਸ ਗਾਈਡ ਵਿੱਚ ਦਿੱਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਿਆਂ ਦੀ ਪਾਲਣਾ ਕਰੋ ਕਿ ਕਿਸੇ ਅਸਥਾਈ ਮੇਲ ਪਤੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਦੁਬਾਰਾ ਵਰਤਣਾ। ਰੋਟੇਸ਼ਨ ਨੀਤੀਆਂ ਤੈਅ ਕਰੋ, ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਟੋਕਨ ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਸਮੱਸਿਆ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਪਹੁੰਚ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਰਜ ਕਰੋ।
ਟੈਸਟ ਡੇਟਾ ਲਈ ਪਾਲਣਾ ਅਤੇ ਡੇਟਾ ਧਾਰਣ
ਜੇ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਅਸਲ ਡੇਟਾ ਮਿਲਾ ਦਿਓ, ਤਾਂ ਕ੍ਰਿਤ੍ਰਿਮ ਉਪਭੋਗਤਾ ਵੀ ਗੋਪਨੀਯਤਾ ਅਤੇ ਪਾਲਣਾ ਦੇ ਨਿਯਮਾਂ ਦੇ ਅਧੀਨ ਆ ਸਕਦੇ ਹਨ। ਇਨਬਾਕਸ ਦੀ ਛੋਟੀ ਧਾਰਣ ਮਿਆਦ ਮਦਦ ਕਰਦੀ ਹੈ: ਸੁਨੇਹੇ ਇੱਕ ਨਿਰਧਾਰਤ ਸਮੇਂ ਬਾਅਦ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਜੋ ਡੇਟਾ ਘੱਟ ਤੋਂ ਘੱਟ ਰੱਖਣ ਦੇ ਸਿਧਾਂਤ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਇੱਕ ਸੰਖੇਪ ਨੀਤੀ ਦਰਜ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੋਵੇ ਕਿ CI/CD ਵਿੱਚ ਡਿਸਪੋਸੇਬਲ ਈਮੇਲ ਕਿਉਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਹੜਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਸੁਰੱਖਿਆ, ਜੋਖਮ ਅਤੇ ਪਾਲਣਾ ਟੀਮਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਈਮੇਲ ਟੈਸਟਿੰਗ ਨੂੰ ਮਾਪੋ ਅਤੇ ਸੁਧਾਰੋ
ਈਮੇਲ-ਆਧਾਰਿਤ ਟੈਸਟਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਭਰੋਸੇਯੋਗ ਬਣਾਈ ਰੱਖਣ ਲਈ ਡਿਲਿਵਰੀ ਸਮੇਂ, ਅਸਫਲਤਾ ਦੇ ਰੂਪਾਂ ਅਤੇ ਪ੍ਰਦਾਤਾ ਦੇ ਵਿਹਾਰ ਬਾਰੇ ਬੁਨਿਆਦੀ ਨਿਗਰਾਨੀ ਲਾਜ਼ਮੀ ਹੈ।
OTP ਦੀ ਡਿਲਿਵਰੀ ਦਾ ਸਮਾਂ ਅਤੇ ਸਫਲਤਾ ਦਰ ਟ੍ਰੈਕ ਕਰੋ
ਇਹ ਦਰਜ ਕਰਨ ਲਈ ਸਧਾਰਣ ਮੈਟ੍ਰਿਕਸ ਸ਼ਾਮਲ ਕਰੋ ਕਿ ਹਰ ਈਮੇਲ-ਆਧਾਰਿਤ ਟੈਸਟ OTP ਜਾਂ ਤਸਦੀਕੀ ਲਿੰਕ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਹਾਨੂੰ ਇੱਕ ਵੰਡ ਦਿਖਾਈ ਦੇਵੇਗੀ: ਜ਼ਿਆਦਾਤਰ ਸੁਨੇਹੇ ਜਲਦੀ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ, ਪਰ ਕੁਝ ਨੂੰ ਵਧੇਰੇ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਜਾਂ ਉਹ ਕਦੇ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੇ। ਉਹ ਲੇਖ ਜੋ ਅਧਿਐਨ ਕਰਦੇ ਹਨ ਕਿ ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਓਟੀਪੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਦਾ ਹੈ, ਇਹ ਇਹ ਕਿਉਂ ਹੁੰਦਾ ਹੈ, ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ ਡੋਮੇਨ ਬਦਲਦੇ ਰਹਿਣ ਨਾਲ ਕਿਸੇ ਇੱਕ ਖਾਸ ਡੋਮੇਨ ਉੱਤੇ ਡਿਲਿਵਰੀ ਦੀ ਖਰਾਬੀ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਇਹ ਸਪਸ਼ਟ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹੋ: ਜੇ ਕੋਈ ਖਾਸ ਡੋਮੇਨ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਤਾਂ ਨਵਾਂ ਪਤਾ ਵਰਤਣਾ ਉਚਿਤ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਡਿਲਿਵਰੀ ਦੀ ਖਰਾਬੀ ਹੈ। ਪਰ ਜੇ ਸੇਵਾ ਨੇ ਨੀਤੀ ਤਹਿਤ ਡਿਸਪੋਸੇਬਲ ਈਮੇਲ ਸਵੀਕਾਰ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਤਾਂ ਕਿਸੇ ਇੱਕ ਪਤੇ ਦੇ ਸਵੀਕਾਰ ਹੋ ਜਾਣ ਤੱਕ ਪਤੇ ਬਦਲਦੇ ਰਹਿਣਾ ਸਮੱਸਿਆ-ਨਿਵਾਰਣ ਨਹੀਂ ਹੈ—ਆਪਣੇ ਨਿਯੰਤਰਣ ਹੇਠ ਕੋਈ ਅਸਲ ਪਤਾ ਵਰਤੋ।
ਜਦੋਂ ਈਮੇਲ ਪ੍ਰਵਾਹ ਟੁੱਟ ਜਾਣ ਤਾਂ ਸੁਰੱਖਿਆ-ਸੀਮਾਵਾਂ
ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰ ਲਓ ਕਿ ਗੁੰਮ ਹੋਈ ਈਮੇਲ ਕਦੋਂ ਪੂਰੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਅਸਫਲ ਕਰੇ ਅਤੇ ਕਦੋਂ ਤੁਸੀਂ ਨਰਮ ਅਸਫਲਤਾ ਚਾਹੁੰਦੇ ਹੋ। ਮਹੱਤਵਪੂਰਨ ਖਾਤਾ-ਬਣਾਉਣ ਜਾਂ ਲੌਗਇਨ ਪ੍ਰਵਾਹਾਂ ਲਈ ਆਮ ਤੌਰ ’ਤੇ ਸਖ਼ਤ ਅਸਫਲਤਾ ਲੋੜੀਂਦੀ ਹੁੰਦੀ ਹੈ, ਜਦਕਿ ਗੌਣ ਸੂਚਨਾਵਾਂ ਨੂੰ ਡਿਪਲੌਇਮੈਂਟ ਰੋਕੇ ਬਿਨਾਂ ਅਸਫਲ ਹੋਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਪਸ਼ਟ ਨਿਯਮ ਆਨ-ਕਾਲ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਦਬਾਅ ਹੇਠ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਪ੍ਰਦਾਤਾਵਾਂ, ਡੋਮੇਨਾਂ ਅਤੇ ਪੈਟਰਨਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਸੁਧਾਰ
ਫਿਲਟਰਾਂ ਦੇ ਵਿਕਸਿਤ ਹੋਣ ਨਾਲ ਸਮੇਂ ਦੇ ਨਾਲ ਈਮੇਲ ਦਾ ਵਿਹਾਰ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ। ਰੁਝਾਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਕੇ, ਕਈ ਡੋਮੇਨਾਂ ਵਿਰੁੱਧ ਸਮੇਂ-ਸਮੇਂ ’ਤੇ ਤੁਲਨਾਤਮਕ ਟੈਸਟ ਚਲਾ ਕੇ ਅਤੇ ਆਪਣੇ ਪੈਟਰਨਾਂ ਨੂੰ ਸੁਧਾਰ ਕੇ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਛੋਟੇ ਫੀਡਬੈਕ ਲੂਪ ਸ਼ਾਮਲ ਕਰੋ। ਅਚਾਨਕ ਅਸਥਾਈ ਮੇਲ ਦੀ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਰਗੇ ਵਰਗੇ ਖੋਜਪੂਰਨ ਲੇਖ ਤੁਹਾਡੇ QA ਸੂਟ ਲਈ ਵਾਧੂ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਪ੍ਰੇਰਣਾ ਦੇ ਸਕਦੇ ਹਨ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਇਹ ਸੰਖੇਪ ਜਵਾਬ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਹਰ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਵਿੱਚ ਇੱਕੋ ਵਿਆਖਿਆ ਦੁਹਰਾਏ ਬਿਨਾਂ CI/CD ਵਿੱਚ ਡਿਸਪੋਸੇਬਲ ਇਨਬਾਕਸ ਅਪਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ।
ਕੀ ਮੈਂ ਇੱਕੋ ਡਿਸਪੋਸੇਬਲ ਇਨਬਾਕਸ ਨੂੰ ਕਈ CI/CD ਰਨਾਂ ਵਿੱਚ ਮੁੜ ਵਰਤ ਸਕਦਾ ਹਾਂ?
ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਸੋਚ-ਸਮਝ ਕੇ ਕਰੋ। ਗੈਰ-ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਵਾਹਾਂ ਲਈ ਹਰ ਬ੍ਰਾਂਚ ਜਾਂ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇੱਕ ਅਸਥਾਈ ਪਤਾ ਮੁੜ ਵਰਤਣਾ ਠੀਕ ਹੈ, ਜੇ ਸਭ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਪੁਰਾਣੀਆਂ ਈਮੇਲਾਂ ਹਾਲੇ ਵੀ ਮੌਜੂਦ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਬਿਲਿੰਗ ਵਰਗੇ ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਦ੍ਰਿਸ਼ਾਂ ਲਈ ਹਰ ਰਨ ਵਾਸਤੇ ਵੱਖਰਾ ਇਨਬਾਕਸ ਵਰਤੋ, ਤਾਂ ਜੋ ਟੈਸਟ ਡੇਟਾ ਅਲੱਗ ਰਹੇ ਅਤੇ ਉਸਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਹੋਵੇ।
ਮੈਂ OTP ਕੋਡਾਂ ਨੂੰ CI/CD ਲੌਗਾਂ ਵਿੱਚ ਲੀਕ ਹੋਣ ਤੋਂ ਕਿਵੇਂ ਰੋਕ ਸਕਦਾ ਹਾਂ?
OTP ਦੀ ਸੰਭਾਲ ਟੈਸਟ ਕੋਡ ਦੇ ਅੰਦਰ ਹੀ ਰੱਖੋ ਅਤੇ ਕਦੇ ਵੀ ਅਸਲ ਮੁੱਲ ਪ੍ਰਿੰਟ ਨਾ ਕਰੋ। ਅਸਲ ਗੁਪਤ ਮੁੱਲਾਂ ਦੀ ਬਜਾਏ “OTP ਪ੍ਰਾਪਤ ਹੋਇਆ” ਜਾਂ “ਤਸਦੀਕੀ ਲਿੰਕ ਖੋਲ੍ਹਿਆ ਗਿਆ” ਵਰਗੇ ਇਵੈਂਟ ਲੌਗ ਕਰੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀਆਂ ਲੌਗਿੰਗ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਡੀਬੱਗ ਮੋਡ ਸੰਵੇਦਨਸ਼ੀਲ ਟੋਕਨਾਂ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਜਾਂ ਜਵਾਬਾਂ ਦੇ ਬਾਡੀ ਡੇਟਾ ਨੂੰ ਲੌਗ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਨਾ ਕੀਤੇ ਗਏ ਹੋਣ।
ਕੀ ਡਿਸਪੋਸੇਬਲ ਇਨਬਾਕਸ ਟੋਕਨ ਨੂੰ CI ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ?
ਹਾਂ, ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਤਪਾਦਨ-ਪੱਧਰੀ ਹੋਰ ਗੁਪਤ ਜਾਣਕਾਰੀ ਵਾਂਗ ਸੰਭਾਲੋ। ਇਨਕ੍ਰਿਪਟ ਕੀਤੇ ਵੇਰੀਏਬਲਾਂ ਜਾਂ ਸੀਕ੍ਰੇਟ ਮੈਨੇਜਰ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਉਨ੍ਹਾਂ ਤੱਕ ਪਹੁੰਚ ਸੀਮਤ ਰੱਖੋ ਅਤੇ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਿੰਟ ਕਰਨ ਤੋਂ ਬਚੋ। ਜੇ ਕੋਈ ਟੋਕਨ ਕਦੇ ਸਾਹਮਣੇ ਆ ਜਾਵੇ, ਤਾਂ ਉਸਨੂੰ ਕਿਸੇ ਵੀ ਸਮਝੌਤਾ ਹੋਈ ਕੁੰਜੀ ਵਾਂਗ ਬਦਲ ਦਿਓ।
ਜੇ ਮੇਰੇ ਟੈਸਟ ਪੂਰੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਥਾਈ ਇਨਬਾਕਸ ਦੀ ਮਿਆਦ ਪੁੱਗ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
ਇੱਥੇ ਦੋ ਚੀਜ਼ਾਂ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਰੱਖਣ ਲਈ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ. ਟਮੇਲਰ 'ਤੇ ਇੱਕ ਸੁਨੇਹਾ ਪਹੁੰਚਣ ਤੋਂ ਲਗਭਗ 24 ਘੰਟਿਆਂ ਲਈ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਇਸ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦੀ. ਇੱਕ ਐਕਸੈਸ ਟੋਕਨ ਬਾਅਦ ਵਿੱਚ ਉਸੇ ਪਤੇ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਪਰ ਇਹ ਪਤੇ ਨੂੰ ਬਹਾਲ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਸੁਨੇਹੇ ਜੋ ਪਹਿਲਾਂ ਹੀ ਪੁਰਾਣੇ ਹੋ ਚੁੱਕੇ ਹਨ - ਇਸ ਲਈ ਇੱਕ ਬਿਲਡ ਜੋ ਵਿੰਡੋ ਨੂੰ ਪਛਾੜਦਾ ਹੈ ਮੇਲ ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਮੇਲਬਾਕਸ ਨਹੀਂ. ਫਿਕਸ ਤੁਹਾਡੇ ਪੱਖ ਵਿੱਚ ਹੈ: ਪਾਈਪਲਾਈਨ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਈਮੇਲ ਕਦਮਾਂ ਨੂੰ ਚਲਾਓ, ਦ੍ਰਿਸ਼ ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਅਤੇ ਸੁਨੇਹੇ 'ਤੇ ਜ਼ੋਰ ਦਿਓ ਜਿਵੇਂ ਹੀ ਇਹ ਇੱਕ ਲੰਮੀ ਨੌਕਰੀ ਦੇ ਅੰਤ ਵਿੱਚ ਉਤਰਦਾ ਹੈ. ਜੇ ਕਿਸੇ ਟੈਸਟ ਨੂੰ ਸੱਚਮੁੱਚ ਦਿਨਾਂ ਤੱਕ ਚੱਲਣ ਲਈ ਮੇਲ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਟੈਂਪ ਇਨਬਾਕਸ ਗਲਤ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਟੈਸਟ ਮੇਲਬਾਕਸ ਸਹੀ ਹੁੰਦਾ ਹੈ.
ਸਮਾਨਾਂਤਰ ਟੈਸਟ ਸੂਟਾਂ ਲਈ ਮੈਨੂੰ ਕਿੰਨੇ ਡਿਸਪੋਸੇਬਲ ਇਨਬਾਕਸ ਬਣਾਉਣੇ ਚਾਹੀਦੇ ਹਨ?
ਇੱਕ ਸਧਾਰਣ ਅੰਦਾਜ਼ਾ ਇਹ ਹੈ ਕਿ ਹਰ ਮੁੱਖ ਦ੍ਰਿਸ਼ ਲਈ ਹਰ ਸਮਾਨਾਂਤਰ ਵਰਕਰ ਵਾਸਤੇ ਇੱਕ ਇਨਬਾਕਸ ਹੋਵੇ। ਇਸ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਕਈ ਟੈਸਟ ਚੱਲਣ ਵੇਲੇ ਟਕਰਾਅ ਅਤੇ ਅਸਪਸ਼ਟ ਸੁਨੇਹਿਆਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਪ੍ਰਦਾਤਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਸਖ਼ਤ ਹਨ, ਤਾਂ ਥੋੜ੍ਹੀ ਵਧੇਰੇ ਜਟਿਲ ਪਾਰਸਿੰਗ ਲੌਜਿਕ ਦੀ ਕੀਮਤ ’ਤੇ ਇਨਬਾਕਸਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾਈ ਜਾ ਸਕਦੀ ਹੈ।
ਕੀ CI/CD ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਪਤੇ ਵਰਤਣ ਨਾਲ ਈਮੇਲ ਡਿਲਿਵਰੇਬਿਲਿਟੀ ਘਟਦੀ ਹੈ ਜਾਂ ਬਲਾਕ ਲੱਗ ਸਕਦੇ ਹਨ?
ਹੋ ਸਕਦਾ ਹੈ। ਸਵੀਕਾਰਤਾ ਮੰਜ਼ਿਲ ਸੇਵਾ, ਭੇਜਣ ਦੇ ਪੈਟਰਨ ਅਤੇ ਡੋਮੇਨ ਦੀ ਸਾਖ ’ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਅਤੇ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਬਦਲ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਮਾਪੋ: ਬਾਊਂਸ ਦਰਾਂ, ਡਿਲਿਵਰੀ ਵਿੱਚ ਦੇਰੀ ਅਤੇ ਉਹ ਸੁਨੇਹੇ ਦੇਖੋ ਜੋ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਕਿਸੇ ਵੀ ਟਿਊਨਿੰਗ ਨਾਲੋਂ ਇੱਕ ਸੀਮਾ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਕਿਸੇ ਸੇਵਾ ਦੀਆਂ ਸ਼ਰਤਾਂ ਡਿਸਪੋਸੇਬਲ ਈਮੇਲ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੀਆਂ, ਤਾਂ ਇਹ ਨੀਤੀ ਦਾ ਮਾਮਲਾ ਹੈ ਅਤੇ ਜਵਾਬ ਇਹ ਨਹੀਂ ਕਿ ਕਿਸੇ ਇੱਕ ਡੋਮੇਨ ਦੇ ਸਵੀਕਾਰ ਹੋਣ ਤੱਕ ਡੋਮੇਨ ਬਦਲਦੇ ਰਹੋ—ਸਗੋਂ ਆਪਣੇ ਨਿਯੰਤਰਣ ਹੇਠ ਅਸਲ, ਪ੍ਰਬੰਧਿਤ ਟੈਸਟ ਪਤਾ ਵਰਤੋ। ਡੋਮੇਨ ਬਦਲਣਾ ਬਲੌਕਲਿਸਟ ਕੀਤੇ ਡੋਮੇਨ ਦੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਹੈ, ਕਿਸੇ ਨਿਯਮ ਤੋਂ ਬਚਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ।
ਕੀ ਮੈਂ ਜਨਤਕ ਅਸਥਾਈ ਈਮੇਲ API ਤੋਂ ਬਿਨਾਂ ਈਮੇਲ-ਆਧਾਰਿਤ ਟੈਸਟ ਚਲਾ ਸਕਦਾ ਹਾਂ?
ਹਾਂ, ਅਤੇ ਤੁਹਾਨੂੰ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ. ਟਮੇਲਰ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਜਨਤਕ ਏਪੀਆਈ ਪ੍ਰਕਾਸ਼ਤ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਇੱਕ ਟੈਸਟ ਰਨਰ ਕੋਲ ਪੋਲ ਕਰਨ ਲਈ ਕੁਝ ਵੀ ਅਧਿਕਾਰਤ ਨਹੀਂ ਹੁੰਦਾ - ਇਹ ਇੱਕ ਬ੍ਰਾ browserਜ਼ਰ ਵਿੱਚ ਇਨਬਾਕਸ ਪੜ੍ਹਨ ਵਾਲੇ ਵਿਅਕਤੀ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਨਾ ਕਿ ਬਿਲਡ ਏਜੰਟ ਲਈ. ਜਿੱਥੇ ਇੱਕ ਪ੍ਰਦਾਤਾ ਇੱਕ ਇਨਬਾਉਂਡ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਤੁਹਾਡਾ ਟੈਸਟ ਕੋਡ ਇਸ ਨੂੰ ਕਿਸੇ ਹੋਰ HTTP ਸੇਵਾ ਦੀ ਤਰ੍ਹਾਂ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ. ਨਹੀਂ ਤਾਂ, ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਅੰਦਰੂਨੀ ਸੇਵਾ ਚਲਾਓ ਜੋ ਪ੍ਰਦਾਤਾ ਅਤੇ ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਜੋੜਦੀ ਹੈ, ਸਿਰਫ ਤੁਹਾਡੇ ਦਾਅਵਿਆਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦੇ ਮੈਟਾਡੇਟਾ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦੀ ਹੈ.
ਕੀ ਮੈਨੂੰ ਉਤਪਾਦਨ-ਸਮਾਨ ਡੇਟਾ ਲਈ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਸਿੰਥੈਟਿਕ ਟੈਸਟ ਉਪਭੋਗਤਾਵਾਂ ਲਈ?
ਅਸਥਾਈ ਇਨਬਾਕਸਾਂ ਦੀ ਵਰਤੋਂ ਸਿਰਫ਼ ਟੈਸਟਿੰਗ ਲਈ ਬਣਾਏ ਗਏ ਸਿੰਥੈਟਿਕ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਉਤਪਾਦਨ ਖਾਤਿਆਂ, ਅਸਲ ਗਾਹਕ ਡੇਟਾ ਅਤੇ ਪੈਸੇ ਜਾਂ ਪਾਲਣਾ ਨਾਲ ਜੁੜੀ ਕਿਸੇ ਵੀ ਜਾਣਕਾਰੀ ਲਈ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਿਤ, ਲੰਬੇ ਸਮੇਂ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਈਮੇਲ ਪਤੇ ਵਰਤੋ।
ਮੈਂ ਕਿਸੇ ਸੁਰੱਖਿਆ ਜਾਂ ਪਾਲਣਾ ਟੀਮ ਨੂੰ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਸਮਝਾਵਾਂ?
ਇਸਨੂੰ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਪੁਸ਼ਟੀਸ਼ੁਦਾ ਈਮੇਲ ਪਤਿਆਂ ਅਤੇ PII ਦੇ ਪਰਦਾਫਾਸ਼ ਨੂੰ ਘਟਾਉਣ ਦੇ ਤਰੀਕੇ ਵਜੋਂ ਪੇਸ਼ ਕਰੋ। ਡੇਟਾ-ਧਾਰਣ, ਲੌਗਿੰਗ ਅਤੇ ਸੀਕ੍ਰੇਟ ਪ੍ਰਬੰਧਨ ਬਾਰੇ ਸਪੱਸ਼ਟ ਨੀਤੀਆਂ ਸਾਂਝੀਆਂ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਹਵਾਲਾ ਦਿਓ ਜੋ ਤੁਹਾਡੇ ਵਰਤੇ ਜਾ ਰਹੇ ਇਨਬਾਊਂਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਵੇਰਵਾ ਦਿੰਦੇ ਹਨ।
ਮੈਨੂੰ ਇੱਕ ਵਾਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇਨਬਾਕਸ ਦੀ ਬਜਾਏ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਅਸਥਾਈ ਮੇਲਬਾਕਸ ਦੀ ਚੋਣ ਕਦੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?
ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਅਸਥਾਈ ਮੇਲਬਾਕਸ ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ QA ਵਾਤਾਵਰਣਾਂ, ਪ੍ਰੀ-ਪ੍ਰੋਡਕਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਜਾਂ ਮੈਨੂਅਲ ਖੋਜੀ ਟੈਸਟਾਂ ਲਈ ਢੁਕਵੇਂ ਹਨ, ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਇੱਕੋ ਪਤਾ ਲਗਾਤਾਰ ਵਰਤਣਾ ਹੋਵੇ। ਉੱਚ-ਜੋਖ਼ਮ ਵਾਲੇ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਵਾਹਾਂ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਪ੍ਰਯੋਗਾਂ ਲਈ ਇਹ ਗਲਤ ਚੋਣ ਹਨ, ਜਿੱਥੇ ਸੁਵਿਧਾ ਨਾਲੋਂ ਸਖ਼ਤ ਅਲੱਗਾਵ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਸਰੋਤ ਅਤੇ ਹੋਰ ਪਾਠ
ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਵਿਹਾਰ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕਿਸੇ ਖ਼ਾਸ ਵਿਧੀ ਬਾਰੇ ਵਿਕਰੇਤਾ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅਧਿਕਾਰਤ ਸਰੋਤ ਮੰਨੋ: job outputs ਅਤੇ masked secrets ਬਾਰੇ GitHub ਦੇ ਦਸਤਾਵੇਜ਼, masked variables ਅਤੇ secure files ਬਾਰੇ GitLab ਦੇ ਦਸਤਾਵੇਜ਼, ਅਤੇ orbs ਅਤੇ parallelism ਬਾਰੇ CircleCI ਦੇ ਦਸਤਾਵੇਜ਼। ਈਮੇਲ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇੱਥੇ ਦਿੱਤੇ ਸਹਾਇਕ ਲੇਖ ਇਸ ਗਾਈਡ ਨਾਲੋਂ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਂਦੇ ਹਨ: OTP, ਡੋਮੇਨ ਰੋਟੇਸ਼ਨ ਅਤੇ ਓਟੀਪੀ ਭਰੋਸੇਯੋਗਤਾ, ਅਤੇ QA ਲਈ ਓਟੀਪੀ ਜੋਖਮ ਚੈੱਕਲਿਸਟ ਦੇ ਨਾਲ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਅਸਫਲ ਹੁੰਦਾ।
ਨਿਸ਼ਕਰਸ਼
ਅਸਥਾਈ ਈਮੇਲ ਸਿਰਫ਼ ਸਾਈਨ-ਅਪ ਫਾਰਮਾਂ ਲਈ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਹੈ। ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤਿਆਂ, ਇਹ ਤੁਹਾਡੀਆਂ CI/CD ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਨਿਰਮਾਣ-ਘਟਕ ਬਣ ਜਾਂਦੀ ਹੈ। ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇਨਬਾਕਸ ਬਣਾ ਕੇ, ਉਹਨਾਂ ਨੂੰ GitHub Actions, GitLab CI ਅਤੇ CircleCI ਨਾਲ ਜੋੜ ਕੇ, ਅਤੇ ਸੀਕ੍ਰੇਟਾਂ ਤੇ ਲੌਗਿੰਗ ਬਾਰੇ ਸਖ਼ਤ ਨਿਯਮ ਲਾਗੂ ਕਰਕੇ, ਤੁਸੀਂ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਅਸਲ ਇਨਬਾਕਸ ਸ਼ਾਮਲ ਕੀਤੇ ਬਿਨਾਂ ਮਹੱਤਵਪੂਰਨ ਈਮੇਲ ਪ੍ਰਵਾਹਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਹੀ ਦ੍ਰਿਸ਼ ਨਾਲ ਛੋਟੀ ਸ਼ੁਰੂਆਤ ਕਰੋ, ਡਿਲਿਵਰੀ ਅਤੇ ਅਸਫਲਤਾ ਦੇ ਪੈਟਰਨ ਮਾਪੋ, ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਆਪਣੀ ਟੀਮ ਲਈ ਢੁਕਵੇਂ ਤਰੀਕੇ ਨੂੰ ਮਿਆਰੀ ਬਣਾਓ। ਸਮੇਂ ਦੇ ਨਾਲ, ਅਸਥਾਈ ਈਮੇਲ ਦੀ ਸੋਚ-ਸਮਝ ਕੇ ਬਣਾਈ ਰਣਨੀਤੀ ਤੁਹਾਡੀਆਂ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ, ਆਡਿਟਾਂ ਨੂੰ ਆਸਾਨ ਅਤੇ ਤੁਹਾਡੇ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਟੈਸਟ ਯੋਜਨਾਵਾਂ ਵਿੱਚ "ਈਮੇਲ" ਸ਼ਬਦ ਤੋਂ ਘੱਟ ਡਰਪੋਕ ਬਣਾ ਦੇਵੇਗੀ।
Marcus Lee writes Tmailor's step-by-step guides — signing up to apps and platforms with temp mail, using the mobile app and Telegram bot, custom domains, reusing addresses, and getting the most out of disposable email day to day.
