02 ਅਗ 2025·7 ਮਿੰਟ
AI ਨਾਲ ਬਣਾਈਆਂ ਐਪਾਂ ਲਈ ਫੀਚਰ ਫਲੈਗ: ਖਤਰਨਾਕ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਰਿਲੀਜ਼ ਕਰੋ
ਸਧਾਰਣ ਮਾਡਲ, ਕੋਹੋਰਟ ਟਾਰਗਟਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ ਨਾਲ AI-ਨਿਰਮਿਤ ਐਪਾਂ ਲਈ ਫੀਚਰ ਫਲੈਗ ਸਿੱਖੋ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਖਤਰਨਾਕ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰ ਸਕੋ ਬਿਨਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਏ।
AI ਨਾਲ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਵੇਲੇ ਫੀਚਰ ਫਲੈਗ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹਨ
ਫੀਚਰ ਫਲੈਗ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ ਸਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਚਾਲੂ ਹੁੰਦਾ ਹੈ ਤਾਂ ਯੂਜ਼ਰ ਨਵਾਂ ਵਿਵਹਾਰ ਵੇਖਦੇ ਹਨ। ਜਦੋਂ ਬੰਦ ਹੁੰਦਾ ਹੈ ਤਾਂ ਨਹੀਂ। ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਸਵਿੱਚ ਦੇ ਨਾਲ ਰਿਲੀਜ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਫੈਸਲਾ ਕਰੋਂ ਕਿ ਕਦੋਂ (ਅਤੇ ਕਿਸ ਲਈ) ਇਹ ਚਾਲੂ ਕਰਨਾ ਹੈ।
ਇਹ ਵੱਖਰਾ ਰੱਖਣਾ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਤੁਸੀਂ AI ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ। AI-ਸਹਾਇਤਾ ਵਾਲੀ ਡਿਵੈਲਪਮੈਂਟ ਮਿੰਟਾਂ ਵਿੱਚ ਵੱਡੇ ਬਦਲਾਅ ਕਰ ਸਕਦੀ ਹੈ: ਨਵੀਂ ਸਕ੍ਰੀਨ, ਵੱਖਰਾ API ਕਾਲ, ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਪ੍ਰਾਂਪਟ ਜਾਂ ਮਾਡਲ ਵਿੱਚ ਬਦਲਾਅ। ਤੇਜ਼ੀ ਵਧੀਆ ਹੈ, ਪਰ ਇਹ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕੁਝ "ਜ਼ਿਆਦਾ-ਠੀਕ" ਰਿਲੀਜ਼ ਕਰ ਦਿਓ ਅਤੇ ਨਾਲ ਹੀ ਅਸਲ ਯੂਜ਼ਰਾਂ ਲਈ ਕੋਈ ਮੁੱਖ ਰਾਹ ਤੋੜ ਦੇਵੋ।
ਫੀਚਰ ਫਲੈਗ ਦੋ ਕਿਰਿਆਵਾਂ ਨੂੰ ਵੰਡ ਦਿੰਦੇ ਹਨ ਜੋ ਅਕਸਰ ਮਿਲੀਆਂ ਹੋਈਆਂ ਹੁੰਦੀਆਂ ਹਨ:
- ਕੋਡ ਰਿਲੀਜ਼ ਕਰਨਾ: ਨਵਾਂ ਵਰਜਨ ਡਿਪਲੋਇ ਕਰਨਾ।
- ਫੀਚਰ ਚਾਲੂ ਕਰਨਾ: ਯੂਜ਼ਰਾਂ ਲਈ ਅਸਲ ਵਿੱਚ ਨਵੀਂ ਚੀਜ਼ ਦਿਖਾਉਣਾ।
ਇਨ੍ਹਾਂ ਦੋਨਾਂ ਦੇ ਵਿਚਕਾਰ ਜੋ ਖਾਲੀ ਜਗ੍ਹਾ ਬਣਦੀ ਹੈ ਉਹ ਤੁਹਾਡੀ ਸੁਰੱਖਿਆ ਬਫਰ ਹੈ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਸਵਿੱਚ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ (ਕਿੱਲ ਸਵਿੱਚ) ਬਿਨਾਂ ਪੂਰੇ ਰਿਲੀਜ਼ ਨੂੰ ਰੋਲਬੈਕ ਕਰਨ ਦੇ ਫਿਸਲਣ ਦੇ।
ਫਲੈਗ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਮਾਂ ਅਤੇ ਸੋਚ ਦੀ ਬਚਤ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਅਕਸਰ ਘਟਨਾ ਹੁੰਦੀ ਹੈ: ਨਵੇਂ ਯੂਜ਼ਰ ਫਲੋ (ਸਾਈਨਅਪ, ਓਨਬੋਰਡਿੰਗ, ਚੈਕਆਊਟ), ਮੁੱਲ ਅਤੇ ਪਲਾਨ ਬਦਲਾਅ, ਪ੍ਰਾਂਪਟ ਅਤੇ ਮਾਡਲ ਅੱਪਡੇਟ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਜਿਵੇਂ ਕੈਚਿੰਗ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜਾਬ। ਅਸਲ ਫਾਇਦਾ ਨਿਯੰਤ੍ਰਿਤ ਪ੍ਰਦਰਸ਼ਨ ਹੈ: ਪਹਿਲਾਂ ਛੋਟੇ ਸਮੂਹ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਨਤੀਜੇ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਕੇਵਲ ਜਦੋਂ ਮੈਟ੍ਰਿਕਸ ਠੀਕ ਲੱਗਣ ਤਾਂ ਫੈਲਾਓ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਇਹ ਤੇਜ਼ੀ ਸੁਰੱਖਿਅਤ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਹਰ “ਫਾਸਟ ਚੇਂਜ” ਦੇ ਨਾਲ ਇਕ ਬੰਦ ਕਰਨ ਵਾਲਾ ਸਵਿੱਚ ਅਤੇ ਪਹਿਲਾਂ ਕੌਣ ਵੇਖੇਗਾ ਇਸ ਲਈ ਸਪਸ਼ਟ ਯੋਜਨਾ ਹੁੰਦੀ ਹੈ।
ਇਕ ਸਧਾਰਣ ਫਲੈਗ ਮਾਡਲ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕੋ
ਫਲੈਗ ਰਨਟਾਈਮ ਸਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਇਹ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ ਬਿਨਾਂ ਨਵੀਂ ਬਿਲਡ ਰਿਲੀਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਦੇ ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੇਜ਼ ਵਾਪਸੀ ਦਿੰਦਾ ਹੈ।
ਰੱਖ-ਰਖਾਅ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਨਿਯਮ: ਫਲੈਗ ਚੈੱਕز ਨੂੰ ਹਰ ਥਾਂ ਨਾ ਛਿਟਕਾਓ। ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਫੈਸਲਾ ਨੁਕਤਾ ਚੁਣੋ (ਅਕਸਰ ਰਾਊਟਿੰਗ, ਸਰਵਿਸ ਸਿਮਾਰੇ ਜਾਂ ਇਕ UI ਐਂਟ੍ਰੀ ਨੇੜੇ) ਅਤੇ ਬਾਕੀ ਕੋਡ ਸਾਫ਼ ਰੱਖੋ। ਜੇ ਇਕੋ ਫਲੈਗ ਪੰਜ ਫਾਇਲਾਂ ਵਿੱਚ ਦਿਖ ਰਿਹਾ ਹੈ ਤਾਂ ਅਕਸਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫੀਚਰ ਬੌਂਡਰੀ ਸਪਸ਼ਟ ਨਹੀਂ ਹੈ।
ਇਹ ਵੀ ਵੱਧ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਵੱਖਰਾ ਕਰੋ:
- ਕੌਣ ਚਾਲੂ ਕਰ ਸਕਦਾ ਹੈ (ਯੋਗਤਾ): ਪਲਾਨ, ਖੇਤਰ, ਡਿਵਾਈਸ ਕਿਸਮ, ਖਾਤੇ ਦੀ ਉਮਰ, ਅੰਦਰੂਨੀ ਟੈਸਟਰ।
- ਕਦੋਂ ਚਾਹੀਦਾ ਹੈ ਚਾਲੂ ਹੋਵੇ (ਰੋਲਆਊਟ ਅਤੇ ਸੁਰੱਖਿਆ): 0%, 10%, 50%, 100%, ਨਾਲ ਹੀ ਰੋਕਣ ਜਾਂ ਤੁਰੰਤ-ਬੰਦ ਨਿਯੰਤਰਣ।
ਫਲੈਗਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ: ਹਰ ਫਲੈਗ ਲਈ ਇਕ ਹੀ ਵਿਵਹਾਰ। ਜੇ ਤੁਹਾਨੂੰ ਕਈ ਬਦਲਾਅ ਦੀ ਲੋੜ ਹੈ ਤਾਂਆਂ ਜਾਂ ਤੇ ਬਹੁ-ਫਲੈਗ ਵਰਤੋ ਜਿਸ ਦੇ ਨਾਮ ਸਪਸ਼ਟ ਹੋਣ, ਜਾਂ ਇੱਕ ਵਰਜਨ-ਫਲੈਗ ਪਿੱਛੇ ਸਮੂਹਿਕ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ onboarding_v2) ਜੋ ਪੂਰਾ ਪਾਥ ਚੁਣਦਾ ਹੈ।
ਮਾਲਕੀਅਤ ਉਮੀਦ ਤੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੌਣ ਕੀ ਫਲਿੱਪ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਦੋਂ। ਪ੍ਰੋਡਕਟ ਰੋਲਆਊਟ ਦੇ ਲਕੜੀ ਅਤੇ ਸਮਾਂ ਦੀ ਮਾਲਕੀ ਰੱਖੇ, ਇੰਜੀਨੀਅਰਿੰਗ ਡੀਫਾਲਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਫੌਲਬੈਕ ਦੀ ਮਾਲਕੀ ਰੱਖੇ, ਅਤੇ ਸਪੋਰਟ ਕੋਲ ਗਾਹਕ-ਪ੍ਰਭਾਵਿਤ ਮੁੱਦਿਆਂ ਲਈ ਸੱਚਾ ਕਿੱਲ ਸਵਿੱਚ ਹੋਵੇ। ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਪੁਰਾਣੇ ਫਲੈਗ ਸਾਫ਼ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦਿਓ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਇਹ ਚੰਗਾ ਫਿੱਟ ਹੈ: ਤੁਸੀਂ ਤੁਰੰਤ ਬਦਲਾਅ ਰਿਲੀਜ਼ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਫਿਰ ਵੀ ਕੰਟਰੋਲ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੌਣ ਉਹ ਦੇਖਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਐਪ ਦਾ ਅੱਧਾ ਹਿੱਸਾ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।
ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਫਲੈਗ ਕਿਸਮਾਂ
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਕੁਝ ਹੀ ਪੈਟਰਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਬੂਲੀਅਨ ਫਲੈਗ ਡਿਫਾਲਟ ਹੁੰਦੇ ਹਨ: ਚਾਲੂ ਜਾਂ ਬੰਦ। ਇਹ “ਨਵੀਂ ਚੀਜ਼ ਦਿਖਾਓ” ਜਾਂ “ਨਵਾਂ ਏੰਡਪੌਇੰਟ ਵਰਤੋ” ਲਈ ਬੇਹਤਰੀਨ ਹਨ। ਜੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੋ ਤੋਂ ਵੱਧ ਵਿਕਲਪ ਦੀ ਲੋੜ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ, ਤਾਂ ਮਲਟੀਵੈਰੀਏਟ ਫਲੈਗ ਵਰਤੋ (A/B/C) ਅਤੇ ਮੁੱਲਾਂ ਨੂੰ ਮਾਨਵੀ ਬਣਾਈ ਰੱਖੋ (ਜਿਵੇਂ control, new_copy, short_form) ਤਾਂ ਕਿ ਲੌਗ ਪੜ੍ਹਨਯੋਗ ਰਹਿਣ।
ਕੁਝ ਫਲੈਗ ਅਸਥਾਈ ਰੋਲਆਊਟ ਫਲੈਗ ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਖਤਰਨਾਕ ਚੀਜ਼ ਰਿਲੀਜ਼ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹੋ, ਸੱਚ ਕਰਕੇ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਫਿਰ ਫਲੈਗ ਹਟਾ ਦਿੰਦੇ ਹੋ। ਦੂਜੇ ਕਾਇਮ ਕੰਫਿਗਰੇਸ਼ਨ ਫਲੈਗ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਇਕ ਵਰਕਸਪੇਸ ਲਈ SSO ਚਾਲੂ ਕਰਨਾ ਜਾਂ ਸਟੋਰੇਜ ਰੀਜਨ ਚੁਣਨਾ। ਕਾਇਮ ਕੰਫਿਗਰੇਸ਼ਨ ਨੂੰ ਪ੍ਰੋਡਕਟ ਸੈਟਿੰਗ ਵਾਂਗ ਜ਼ਿੰਮੇਵਾਰੀ ਅਤੇ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਦੇ ਨਾਲ ਰੱਖੋ।
ਫਲੈਗ ਕਿੱਥੇ ਮੂਲਾਂਕਨ ਹੁੰਦੇ ਹਨ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ:
- ਸਰਵਰ-ਸਾਇਡ ਫਲੈਗ ਜ਼ਿਆਦਾ ਸੇਫ਼ ਹਨ ਕਿਉਂਕਿ ਫੈਸਲਾ ਤੁਹਾਡੇ ਬੈਕਐਂਡ (ਜਿਵੇਂ Go API) ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਲਾਇਂਟ ਸਿਰਫ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
- ਕਲਾਇਂਟ-ਸਾਇਡ ਫਲੈਗ (React ਜਾਂ Flutter) ਘੱਟ-ਖਤਰੇ ਵਾਲੀਆਂ UI ਬਦਲਾਵਾਂ ਲਈ ਠੀਕ ਹਨ, ਪਰ ਧਿਆਨ ਰੱਖੋ ਕਿ ਯੂਜ਼ਰ ਕਲਾਇਂਟ ਨੂੰ ਇੰਸਪੈਕਟ ਜਾਂ ਛੇੜ-ਛਾੜ ਕਰ ਸਕਦੇ ਹਨ।
ਕਦੇ ਵੀ ਗੁਪਤ ਜਾਣਕਾਰੀ, ਮੁੱਲ ਨਿਯਮ, ਜਾਂ ਅਨੁਮਤੀ ਚੈੱਕਾਂ ਨੂੰ ਕੇਵਲ ਕਲਾਇਂਟ-ਨਿਰਭਰ ਫਲੈਗ 'ਤੇ ਨਾ ਰੱਖੋ।
ਕਿੱਲ ਸਵਿੱਚ ਇਕ ਵਿਸ਼ੇਸ਼ ਬੂਲੀਅਨ ਫਲੈਗ ਹੈ ਜੋ ਤੇਜ਼ ਰੋਲਬੈਕ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਖਤਰਨਾਕ ਰਾਹ ਨੂੰ ਤੁਰੰਤ ਬੰਦ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਬਿਨਾਂ ਰੀਡਿਪਲੋਇ ਦੇ। ਉਹਨਾਂ ਬਦਲਾਅਾਂ ਲਈ ਕਿੱਲ ਸਵਿੱਚ ਜੋੜੋ ਜੋ ਲੌਗਿਨ, ਭੁਗਤਾਨ, ਜਾਂ ਡੇਟਾ ਲਿਖਾਵਟ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਸਰਵਰ-ਸਾਇਡ ਫਲੈਗ ਅਤੇ ਕਿੱਲ ਸਵਿੱਚ ਖਾਸ ਕਰਕੇ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਸਕਦੇ ਹੋ, ਪਰ ਅਸਲ ਯੂਜ਼ਰਾਂ ਦੇ ਐਜ ਕੇਸਜ਼ ਆਉਣ 'ਤੇ ਸਾਫ਼ "ਆਫ" ਬਟਨ ਮਿਲਦਾ ਹੈ।
ਕੋਹੋਰਟ ਟਾਰਗਟਿੰਗ ਬਿਨਾਂ ਜ਼ਰੂਰਤੀ ਜਟਿਲਤਾ ਦੇ ਕਿਵੇਂ ਕਰਨੀ ਹੈ
ਕੋਹੋਰਟ ਟਾਰਗਟਿੰਗ ਖਤਰੇ ਘਟਾਉਂਦੀ ਹੈ। ਕੋਡ ਤਿਆਰ ਹੈ, ਪਰ ਸਿਰਫ਼ ਕੁਝ ਲੋਕ ਹੀ ਇਸਨੂੰ ਵੇਖਦੇ ਹਨ। ਮਕਸਦ ਕੰਟਰੋਲ ਹੈ, ਪਰਫੈਕਟ ਸੈਗਮੈਂਟੇਸ਼ਨ ਸਿਸਟਮ ਨਹੀਂ।
ਇੱਕ ਮੁੱਲਾਂਕਨ ਇਕਾਈ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਲਗਾਤਾਰ ਵਰਤੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਯੂਜ਼ਰ-ਪੱਧਰੀ ਟਾਰਗਟਿੰਗ (ਇੱਕ ਵਿਅਕਤੀ ਨਵੀਂ ਚੀਜ਼ ਵੇਖੇ) ਜਾਂ ਵਰਕਸਪੇਸ/ਅਕਾਊਂਟ-ਪੱਧਰੀ ਟਾਰਗਟਿੰਗ (ਇੱਕ ਟੀਮ ਦੇ ਸਾਰੇ ਮੈਂਬਰ ਇੱਕੋ ਹੀ ਚੀਜ਼ ਵੇਖਨ) ਚੁਣਦੀਆਂ ਹਨ। ਵਰਕਸਪੇਸ ਟਾਰਗਟਿੰਗ ਅਕਸਰ ਸਾਂਝੇ ਫੀਚਰਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ ਬਿੱਲਿੰਗ, ਅਨੁਮਤੀਆਂ, ਜਾਂ ਸਹਿਯੋਗ ਕਿਉਂਕਿ ਇਹ ਇੱਕੋ ਟੀਮ ਵਿੱਚ ਮਿਲੀ-ਜੁਲੀ ਅਨੁਭਵ ਰੋਕਦੀ ਹੈ।
ਕੁਝ ਸਧਾਰਣ ਨਿਯਮ ਬਹੁਤ ਸਾਰੀਆਂ ਲੋੜਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ: ਯੂਜ਼ਰ ਐਟ੍ਰਿੱਬਿਊਟ (ਪਲਾਨ, ਖੇਤਰ, ਡਿਵਾਈਸ, ਭਾਸ਼ਾ), ਵਰਕਸਪੇਸ ਟਾਰਗਟਿੰਗ (ਵਰਕਸਪੇਸ ID, ਆਰਗ ਟੀਅਰ, ਅੰਦਰੂਨੀ ਅਕਾਊਂਟ), ਪ੍ਰਤੀਸ਼ਤ ਰੋਲਆਊਟ, ਅਤੇ ਸਧਾਰਣ allowlists/blocklists QA ਅਤੇ ਸਪੋਰਟ ਲਈ।
ਪ੍ਰਤੀਸ਼ਤ ਰੋਲਆਊਟ deterministic ਰੱਖੋ। ਜੇ ਯੂਜ਼ਰ ਰੀਫਰੈਸ਼ ਕਰੇ ਤਾਂ ਉਹ ਪੁਰਾਣੇ ਤੇ ਨਵੇਂ UI ਦੇ ਵਿਚਕਾਰ ਬਦਲਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ। ਇੱਕੋ ID ਦਾ ਸਥਿਰ ਹੈਸ਼ ਵਰਤੋ ਤਾਂ ਕਿ ਵੈਬ, ਮੋਬਾਇਲ, ਬੈਕਐਂਡ 'ਤੇ ਨਤੀਜੇ ਮਿਲਦੇ ਰਹਿਣ।
ਵਿਕਯਤ ਡਿਫਾਲਟ ਹੈ “ਪ੍ਰਤੀਸ਼ਤ ਰੋਲਆਊਟ + allowlist + kill switch।” ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਿੱਚ ਤੁਸੀਂ ਨਵੇਂ Planning Mode ਪ੍ਰਾਂਪਟ ਫਲੋ ਨੂੰ ਫ੍ਰੀ ਯੂਜ਼ਰਾਂ ਦਾ 5% ਲਈ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ, ਜਦਕਿ ਕੁਝ Pro ਵਰਕਸਪੇਸਾਂ ਨੂੰ allowlist ਵਿੱਚ ਰੱਖ ਕੇ ਸ਼ੁਰੂਆਤੀ ਪਾਵਰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦੇਖਾਉਣ ਲਈ।
ਨਵਾਂ ਟਾਰਗਟਿੰਗ ਨਿਯਮ ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ: ਕੀ ਸਾਨੂੰ ਇਹ ਵਾਧੂ ਸਲਾਈਸ จริง ਵਿੱਚ ਚਾਹੀਦੀ ਹੈ, ਇਹ ਯੂਜ਼ਰ-ਪੱਧਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਵਰਕਸਪੇਸ-ਪੱਧਰੀ, ਜੇ ਮੈਟ੍ਰਿਕਸ ਡਿੱਗਣ ਤਾਂ ਬੰਦ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਕੀ ਹੈ, ਅਤੇ ਅਸੀਂ ਕਿਹੜੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ (ਅਤੇ ਕੀ ਇਹ ਟਾਰਗਟਿੰਗ ਲਈ ਉਚਿਤ ਹੈ)?
ਖਤਰਨਾਕ ਬਦਲਾਅਾਂ ਲਈ ਕਦਮ-ਬਾਈ-ਕਦਮ ਰੋਲਆਊਟ ਯੋਜਨਾ
Avoid flag sprawl early
Keep flag checks in one place by designing clearer feature boundaries in Koder.ai.
ਖਤਰਨਾਕ ਬਦਲਾਅ ਸਿਰਫ ਵੱਡੇ ਫੀਚਰ ਨਹੀਂ ਹੁੰਦੇ। ਛੋਟਾ ਪ੍ਰਾਂਪਟ ਸੁਧਾਰ, ਨਵਾਂ API ਕਾਲ ਜਾਂ ਵੈਧਤਾ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲਾਅ ਵੀ ਅਸਲ ਯੂਜ਼ਰ ਫਲੋ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ।
ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਆਦਤ ਸਧਾਰਣ ਹੈ: ਕੋਡ ਰਿਲੀਜ਼ ਕਰੋ, ਪਰ ਸਕੁੱਤ ਰੱਖੋ।
"ਡਿਫਾਲਟ ਵਜੋਂ ਸੁਰੱਖਿਅਤ" ਦਾ ਮਤਲਬ ਹੈ ਨਵਾਂ ਪਾਥ ਇੱਕ ਡਿਸੇਬਲਡ ਫਲੈਗ ਦੇ ਪਿੱਛੇ। ਜੇ ਫਲੈਗ ਬੰਦ ਹੈ ਤਾਂ ਯੂਜ਼ਰ ਪੁਰਾਣੇ ਵਿਵਹਾਰ ਨੂੰ ਹੀ ਪਾਉਂਦੇ ਹਨ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਮਰਜ ਅਤੇ ਡਿਪਲੋਇ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਕਿਸੇ ਤੇ ਬਦਲਾਅ ਲਾਦਣ ਦੇ।
ਰੈਂਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਲਿਖੋ ਕਿ “ਚੰਗਾ” ਕੀ ਲੱਗਦਾ ਹੈ। ਦੋ ਜਾਂ ਤਿੰਨ ਸਿਗਨਲ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਦੇਖ ਸਕੋ, ਜਿਵੇਂ ਕਿ ਬਦਲੇ ਹੋਏ ਫਲੋ ਲਈ ਸੰਪੂਰਨਤਾ ਦਰ, ਐਰਰ ਦਰ, ਅਤੇ ਫੀਚਰ ਨਾਲ ਵੇਖੇ ਗਏ ਸਪੋਰਟ ਟਿਕਟ। ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਨਿਯਮ ਫਿਕਸ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, "ਜੇ ਐਰਰ ਦੋਗੁਣਾ ਹੋ ਜਾਣ, ਤਾਂ ਇਸ ਨੂੰ ਬੰਦ ਕਰ ਦਿਓ").
ਇੱਕ ਰੋਲਆਊਟ ਯੋਜਨਾ ਜੋ ਤੇਜ਼ ਬਨਦੀ ਹੈ ਪਰ ਪੈਨਿਕ ਨਹੀਂ:
- ਫਲੈਗ ਬੰਦ ਰੱਖ ਕੇ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪੁਰਾਣੇ ਰਾਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
- ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ ਟੀਮ ਲਈ ਇਹ ਚਾਲੂ ਕਰੋ, ਹਕੀਕਤੀ ਖਾਤਿਆਂ ਅਤੇ ਡੇਟਾ ਪੈਟਰਨ ਨਾਲ।
- ਛੋਟਾ ਬੇਟਾ ਕੋਹੋਰਟ ਖੋਲ੍ਹੋ (ਅਕਸਰ 1-5%) ਅਤੇ ਆਪਣੇ ਸਫਲਤਾ ਸਿਗਨਲ ਵੇਖੋ।
- ਧੀਰੇ-ਧੀਰੇ ਵਧਾਓ (10%, 25%, 50%, 100%), ਰੁਕ ਕੇ ਰੁਝਾਨ ਵੇਖੋ।
- ਇੱਕ ਕਿੱਲ ਸਵਿੱਚ ਤਿਆਰ ਰੱਖੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਗਲਤ ਲੱਗਣ ਤੇ ਤੁਰੰਤ ਫੀਚਰ ਨਿਰਸਾਰ ਕਰ ਸਕੋ।
ਰੋਲਬੈਕ ਨੂੰ ਰੁਟੀਨ ਬਣਾਓ। ਫਲੈਗ ਬੰਦ ਕਰਨ ਨਾਲ ਯੂਜ਼ਰ ਇੱਕ ਜਾਣੇ-ਪਹਚਾਣੇ-ਚੰਗੇ ਅਨੁਭਵ 'ਤੇ ਵਾਪਸ ਆ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਰੀਡਿਪਲੋਇ ਦੇ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ (Koder.ai ਕਰਦਾ ਹੈ), ਤਾਂ ਪਹਿਲੀ ਨੁੰਸ਼ ਵਿੱਚ ਸਨੈਪਸ਼ਾਟ ਲਓ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਜਲਦੀ ਬਹਾਲੀ ਮਿਲ ਸਕੇ।
ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ: ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਸ ਨੇ ਵੇਖਿਆ—ਇਹ ਜਾਣੋ
ਫਲੈਗ ਤਦ ਹੀ ਸੇਫ ਹੋਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਦੋ ਸਵਾਲ ਜਲਦੀ ਸੰਬੋਧ ਸਕੋ: ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ ਕਿਹੜਾ ਅਨੁਭਵ ਮਿਲਿਆ, ਅਤੇ ਕੀ ਇਸਨੇ ਮਦਦ ਕੀਤੀ ਜਾਂ ਨੁਕਸਾਨ ਕੀਤਾ? ਛੋਟੇ ਪ੍ਰਾਂਪਟ ਜਾਂ UI ਬਦਲਾਅ ਬੜੇ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਸਰਲ ਰੂਪ ਵਿੱਚ ਫਲੈਗ ਮੁਲਾਂਕਣ ਲੌਗ ਕਰੋ। ਪਹਿਲੇ ਦਿਨ ਤੁਹਾਨੂੰ ਭੜਕਦਾਰ ਸਿਸਟਮ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਨੂੰ ਸਤਤ ਫੀਲਡ ਲੋੜੀਂਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਫਿਲਟਰ ਅਤੇ ਤੁਲਨਾ ਕਰ ਸਕੋ:
- ਫਲੈਗ ਕੀ ਅਤੇ ਫਲੈਗ ਵਰਜਨ (ਜਾਂ ਕਨਫਿਗ ਹੈਸ਼)
- ਵੈਰੀਅਂਟ (on/off ਜਾਂ A/B ਮੁੱਲ)
- ਕੋਹੋਰਟ ਪਛਾਣਕ (ਕਿਹੜਾ ਨਿਯਮ ਮਿਲਿਆ)
- ਯੂਜ਼ਰ/ਵਰਕਸਪੇਸ ID (pseudonymous ਠੀਕ ਹੈ), ਨਾਲ ਹੀ ਮਾਹੌਲ (prod, staging)
- ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਰਿਕਵੇਸਟ ID (ਤਾਂ ਜੋ ਤੁਸੀਂ ਲੌਗਾਂ ਨੂੰ ਐਰਰਾਂ ਨਾਲ ਜੋੜ ਸਕੋ)
ਫਿਰ ਫਲੈਗ ਨੂੰ ਕੁਝ ਚੁੱਕੇ ਹੋਏ ਸਫਲਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਜੋੜੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਘੰਟਾਵਾਰੀ ਦੇਖ ਸਕਦੇ ਹੋ। ਚੰਗੇ ਡਿਫਾਲਟ ਹਨ: ਐਰਰ ਦਰ, p95 ਲੇਟੈਂਸੀ, ਅਤੇ ਇੱਕ ਪ੍ਰੋਡਕਟ ਮੈਟ੍ਰਿਕ ਜੋ ਬਦਲਾਅ ਨਾਲ ਮੇਚ ਕਰਦਾ ਹੋਵੇ (ਸਾਈਨਅਪ ਪੂਰਨਤਾ, ਚੈਕਆਊਟ ਕੰਵਰਜ਼ਨ, ਦਿਨ-1 ਰਿਟੇਨਸ਼ਨ)।
ਅਲਰਟਸ ਐਸੇ ਸੈਟ ਕਰੋ ਜੋ ਹੰਗਾਮਾ ਬਣਾਉਣ ਵਲੋਂ ਰੋਕਣ ਦੇ ਲਈ ਹਨ। ਉਦਾਹਰਨ: ਜੇ ਫਲੈਗ ਕੀਤੇ ਕੋਹੋਰਟ ਲਈ ਐਰਰ 20% ਵੱਧ ਜਾਂਦੇ ਹਨ ਤਾਂ ਰੋਲਆਊਟ ਰੋਕੋ ਅਤੇ ਕਿੱਲ ਸਵਿੱਚ ਫਲਿਪ ਕਰੋ। ਜੇ ਲੇਟੈਂਸੀ ਕਿਸੇ ਨਿਰਧਾਰਿਤ ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰ ਜਾਏ ਤਾਂ ਮੌਜੂਦਾ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ ਫ੍ਰੀਜ਼ ਕਰੋ।
ਆਖਿਰ ਵਿੱਚ, ਇੱਕ ਸਧਾਰਣ ਰੋਲਆਊਟ ਲੌਗ ਰੱਖੋ। ਹਰ ਵਾਰੀ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਤੀਸ਼ਤ ਜਾਂ ਟਾਰਗਟਿੰਗ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਕਿਸ ਨੇ, ਕੀ ਅਤੇ ਕਿਉਂ ਬਦਲਿਆ ਇਹ ਦਰਜ ਕਰੋ। ਇਹ ਆਦਤ ਤੇਜ਼ ਇਤਰਾਕ ਕਾਰਨਾਂ ਦੌਰਾਨ ਬਹੁਤ ਕੰਮ ਆਉਂਦੀ ਹੈ।
ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਨਵਾਂ ਓਨਬੋਰਡਿੰਗ ਫਲੋ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਭੇਜਣਾ
ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਚੈਟ-ਡ੍ਰਿਵਨ ਬਿਲਡਰ ਨਾਲ ਬਣੀ ਐਪ ਵਿੱਚ ਨਵਾਂ ਓਨਬੋਰਡਿੰਗ ਫਲੋ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਨਵਾਂ ਫਲੋ ਪਹਿਲੀ-ਦੌੜ UI ਬਦਲਦਾ ਹੈ, "ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉ" ਵਿਜ਼ਾਰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਟਾਰਟਰ ਕੋਡ ਬਣਾਉਣ ਵਾਲਾ ਪ੍ਰਾਂਪਟ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਇਹ ਐਕਟੀਵੇਸ਼ਨ ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਖਤਰਨਾਕ ਹੈ: ਜੇ ਇਹ ਟੁੱਟੇ ਤਾਂ ਨਵੇਂ ਯੂਜ਼ਰ ਫਸ ਸਕਦੇ ਹਨ।
ਪੂਰਾ ਨਵਾਂ ਓਨਬੋਰਡਿੰਗ ਇਕ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਰੱਖੋ, ਉਦਾਹਰਨ ਲਈ onboarding_v2, ਅਤੇ ਪੁਰਾਣਾ ਫਲੋ ਡਿਫਾਲਟ ਵਜੋਂ ਰੱਖੋ। ਅੰਦਰੂਨੀ ਟੀਮ ਅਤੇ ਬੇਟਾ-ਨਿਯੁਕਤ ਯੂਜ਼ਰਾਂ (ਉਦਾਹਰਨ ਲਈ ਖਾਤੇ beta=true) ਨਾਲ ਸਾਫ਼ ਕੋਹੋਰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।
ਜਦੋਂ ਬੇਟਾ ਫੀਡਬੈਕ ਠੀਕ ਲੱਗੇ ਤਾਂ ਪ੍ਰਤੀਸ਼ਤ ਰੋਲਆਊਟ 'ਤੇ ਜਾਓ। ਨਵੇਂ ਸਾਈਨਅਪਾਂ ਦੇ 5% ਤੇ, ਫਿਰ 20%, ਫਿਰ 50% — ਹਰ ਕਦਮ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਵੇਖੋ।
ਜੇ 20% 'ਤੇ ਕੁਝ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ: ਸਟੈਪ 2 ਤੋਂ ਬਾਅਦ ਇਨਫਿਨਿਟ ਸਪਿੰਨਰ ਦੀ ਰਿਪੋਰਟ), ਤਾਂ ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡਾਂ 'ਚ ਜਲਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ: flagged ਯੂਜ਼ਰਾਂ ਲਈ "create project" ਏਂਡਪੌਇੰਟ 'ਤੇ ਜ਼ਿਆਦਾ ਡ੍ਰਾਪ-ਆਫ਼ ਅਤੇ ਉੱਚ ਐਰਰ। ਗਰਮੀ ਵਿੱਚ ਹਾਟਫਿਕਸ ਕਰਨ ਦੀ ਥਾਂ, onboarding_v2 ਗਲੋਬਲ ਤੌਰ 'ਤੇ disable ਕਰੋ। ਨਵੇਂ ਯੂਜ਼ਰ ਤੁਰੰਤ ਪੁਰਾਣੇ ਫਲੋ 'ਤੇ ਵਾਪਸ ਆ ਜਾਣਗੇ।
ਬੱਗ ਪੈਚ ਕਰਨ ਅਤੇ ਸਥਿਰਤਾ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਮੁੜ ਰੈਂਪ ਕਰੋ: ਪਹਿਲਾਂ ਸਿਰਫ ਬੇਟਾ ਲਈ, ਫਿਰ 5%, ਫਿਰ 25%, ਅਤੇ 100% ਜਦੋਂ ਇੱਕ ਦਿਨ ਵਿੱਚ ਕੋਈ ਅਚਾਨਕ ਚੀਜ਼ ਨਾ ਵੇਖੀ ਜਾਵੇ। ਇੱਕ ਵਾਰੀ ਸਥਿਰ ਹੋ ਜਾਏ, ਫਲੈਗ ਹਟਾਓ ਅਤੇ ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਨਾਲ ਪੁਰਾਣਾ ਕੋਡ ਹਟਾਓ।
ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਜਾਲ
Keep flags on the server
Ship backend decisions server side in Go to keep pricing and permissions protected.
ਫੀਚਰ ਫਲੈਗ ਤੇਜ਼ ਰਿਲੀਜ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਕੇਵਲ ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਸਲੀ ਪ੍ਰੋਡਕਟ ਕੋਡ ਵਾਂਗ ਹੀ ਸਲੂਕ ਕਰੋ।
ਇੱਕ ਆਮ ਨਾਕਾਮੀ ਹੈ ਫਲੈਗ ਫੈਲਾਓਨ: ਅਨੇਕ ਫਲੈਗ, ਅਸਪਸ਼ਟ ਨਾਮ, ਕੋਈ ਮਾਲਕ ਨਹੀਂ, ਅਤੇ ਹਟਾਉਣ ਦੀ ਕੋਈ ਯੋਜਨਾ ਨਹੀਂ। ਇਹ ਮਿਲੀ-ਜੁਲੀ ਵਰਤੋਂ ਅਤੇ ਉਹਨਾਂ ਕੁਝ ਕੋਹੋਰਟਾਂ ਲਈ ਬੱਗ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਦੂਜਾ ਜਾਲ ਹੈ ਸੰਵੇਦਨਸ਼ੀਲ ਫੈਸਲੇ ਕਲਾਇਂਟ 'ਤੇ ਰੱਖਣਾ। ਜੇ ਫਲੈਗ ਪ੍ਰਾਈਸਿੰਗ, ਅਨੁਮਤੀਆਂ, ਡੇਟਾ ਐਕਸੈਸ ਜਾਂ ਸੁਰੱਖਿਆ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦਾ ਹੈ ਤਾਂ ਕਦੇ ਵੀ ਬਰਾਊਜ਼ਰ ਜਾਂ ਮੋਬਾਈਲ ਨੂੰ ਹੀ ਨਿਰਭਰ ਨਾ ਰੱਖੋ। ਪ੍ਰਭਾਵ ਸਰਵਰ-ਸਾਇਡ 'ਤੇ ਰੱਖੋ ਅਤੇ UI ਨੂੰ ਕੇਵਲ ਨਤੀਜਾ ਭੇਜੋ।
ਮਰਨ ਵਾਲੇ ਫਲੈਗ ਇੱਕ ਹੋਰ ਖਤਰਾ ਹਨ। ਜਦੋਂ ਇੱਕ ਰੋਲਆਊਟ 100% ਹੋ ਜਾਂਦਾ ਹੈ, ਪੁਰਾਣੇ ਪਾਥ ਅਕਸਰ "ਸਿਰਫ਼ ਦੇਖਣ ਲਈ" ਰਹਿ ਜਾਂਦੇ ਹਨ। ਮਹੀਨੇ ਬਾਅਦ, ਕੋਈ ਵੀ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ ਕਿ ਉਹ ਕਿਉਂ ਹਨ, ਅਤੇ ਕੋਈ ਰਿਫੈਕਟਰ ਉਹਨਾਂ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਰੋਲਬੈਕ ਵਿਕਲਪ ਚਾਹੀਦੇ ਹੋ ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਸਪਸ਼ਟ ਰੋਲਬੈਕ ਯੋਜਨਾ ਵਰਤੋ, ਪਰ ਫਿਰ ਵੀ ਬਦਲਾਅ ਸਥਿਰ ਹੋਣ 'ਤੇ ਕੋਡ ਸਾਫ਼ ਕਰਨ ਦੀ ਤਾਰੀਖ ਨਿਯਤ ਕਰੋ।
ਅਖ਼ੀਰ ਵਿੱਚ, ਫਲੈਗ ਟੈਸਟ ਜਾਂ ਰਿਵਿਊਜ਼ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੇ। ਇੱਕ ਫਲੈਗ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਬੁਰਾ ਲੋਜਿਕ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।
ਸਧਾਰਣ ਗਾਰਡਰੇਲਜ਼ ਬਹੁਤ ਕੁਝ ਰੋਕ ਲੈਂਦੇ ਹਨ: ਸਪਸ਼ਟ ਨਾਮਕਰਨ ਸਕੀਮ (area-purpose), ਇੱਕ ਮਾਲਕ ਅਤੇ ਮਿਆਦ ਦੀ ਤਾਰੀਖ, ਇਕ ਹਲਕਾ-ਫੁਲਕਾ ਫਲੈਗ ਰਜਿਸਟਰ (experimenting, rolling out, fully on, removed), ਅਤੇ ਫਲੈਗ ਬਦਲਾਅਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਵਾਂਗ ਲੈਣਾ (ਲੌਗ, ਰਿਵਿਊ, ਮਾਨੀਟਰ)। ਅਤੇ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਖ਼ਾਸ ਫੈਸਲੇ ਕਦੇ ਵੀ ਕਲਾਇਂਟ 'ਤੇ ਨਾ ਰੱਖੋ।
ਫਲੈਗ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਤਿਆਰੀ - ਤੇਜ਼ ਚੈੱਕਲਿਸਟ
ਤੇਜ਼ੀ ਵਧੀਆ ਹੈ ਪਰ ਛੋਟਾ ਬਦਲਾਅ ਪੂਰੀ ਵਰਤੋਂਕਾਂ ਲਈ ਮੁੱਖ ਰਾਹ ਤੋੜ ਸਕਦਾ ਹੈ। ਦੋ ਮਿੰਟ ਵਾਲਾ ਚੈੱਕ ਬਹੁਤ ਘੰਟਿਆਂ ਦੀ ਸਫਾਈ ਅਤੇ ਸਪੋਰਟ ਬਚਾ ਸਕਦਾ ਹੈ।
ਕਿਸੇ ਫਲੈਗ ਨੂੰ ਅਸਲ ਯੂਜ਼ਰਾਂ ਲਈ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ:
- ਇਸਦਾ ਸਪਸ਼ਟ ਨਾਮ ਰੱਖੋ (ਉਦਾਹਰਨ:
onboarding_new_ui_webਜਾਂpricing_calc_v2_backend). - ਇੱਕ ਮਾਲਕ ਅਤੇ ਮਿਆਦ ਨਿਯਤ ਕਰੋ ਤਾਂ ਕਿ ਅਸਥਾਈ ਫਲੈਗ ਸਦੀਵੀ ਨਾ ਰਹਿ ਜਾਣ।
- ਡਿਫਾਲਟ ਸਥਿਤੀ ਅਤੇ ਸੁਰੱਖਿਅਤ ਫੌਲਬੈਕ ਲਿਖੋ ਤਾਂ ਕਿ "off" ਸਥਿਤੀ ਵੀ ਕੰਮ ਕਰੇ ਅਤੇ ਟੈਸਟ ਹੋਏ ਰਹੇ।
- ਇਕ-ਵਾਕ ਵਿੱਚ ਰੋਲਆਊਟ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਅੰਦਰੂਨੀ ਯੂਜ਼ਰ, ਫਿਰ 5% ਨਵੇਂ ਸਾਈਨਅਪ, ਫਿਰ 25%, ਫਿਰ ਸਾਰੇ)।
- ਉੱਚ-ਖਤਰੇ वाले ਰਾਹਾਂ ਲਈ ਕਿੱਲ ਸਵਿੱਚ ਤਿਆਰ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਸ ਕੋਲ ਇਹ ਫਲਿੱਪ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਆਦਤ "ਪੈਨਿਕ ਟੈਸਟ" ਹੈ: ਜੇ ਅਦਾਇਗੀ ਦਰ ਚੱਲਣ ਦੇ ਬਾਅਦ ਤੁਰੰਤ ਚੱਲਣ 'ਤੇ ਵੱਧ ਜਾਏ, ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬੰਦ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਯੂਜ਼ਰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਾਪਸ ਆ ਜਾਵੇਗਾ? ਜੇ ਜਵਾਬ "ਸ਼ਾਇਦ" ਹੈ, ਤਾਂ ਇਸਨੂੰ ਜਨਤਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੋਲਬੈਕ ਰਸਤੇ ਨੂੰ ਠੀਕ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਫਲੈਗਾਂ ਨੂੰ ਬਿਲਡ ਦਾ ਹਿੱਸਾ ਮਾਨੋ: ਫੌਲਬੈਕ ਯੋਜਨਾ ਬਣਾਓ, ਫਿਰ ਬਦਲਾਅ ਰਿਲੀਜ਼ ਕਰੋ ਜਿਸਦੇ ਨਾਲ ਉਸਨੂੰ ਵਾਪਸ ਲੈ ਜਾਣ ਦਾ ਸਾਫ਼ ਤਰੀਕਾ ਹੋਵੇ।
ਕੋਹੋਰਟ ਟਾਰਗਟਿੰਗ ਲਈ ਸੁਰੱਖਿਆ, ਪ੍ਰਾਈਵੇਸੀ ਤੇ ਅਨੁਕੂਲਤਾ ਮੁਢਲੀ ਗੱਲਾਂ
Match rollout to compliance
Roll out by region when needed and deploy apps in the country you choose.
ਕੋਹੋਰਟ ਟਾਰਗਟਿੰਗ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਪ੍ਰਯੋਗ ਕਰਨ ਦਿੰਦੀ ਹੈ, ਪਰ ਜੇ ਧਿਆਨ ਨਾ ਰੱਖੋ ਤਾਂ ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਲੀਕ ਵੀ ਕਰ ਸਕਦੀ ਹੈ। ਚੰਗਾ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਫਲੈਗਾਂ ਦੇ ਲਈ ਨਿੱਜੀ ਡੇਟਾ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ।
ਪਸੰਦੀਦਾ ਸਧਾਰਣ ਟਾਰਗਟਿੰਗ ਇਨਪੁਟ ਹਨ: ਅਕਾਊਂਟ ID, ਪਲਾਨ ਟੀਅਰ, ਅੰਦਰੂਨੀ ਟੈਸਟ ਅਕਾਊਂਟ, ਐਪ ਵਰਜਨ, ਜਾਂ ਇੱਕ ਰੋਲਆਊਟ ਬਕੈਟ (0-99). ਸਿੱਧੇ ਈਮੇਲ, ਫੋਨ ਨੰਬਰ, ਪੂਰਾ ਪਤਾ ਜਾਂ ਕੋਈ ਵੀ ਨਿਯੰਤਰਿਤ ਡੇਟਾ ਵਰਤੋਂ ਤੋਂ ਬਚੋ।
ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਯੂਜ਼ਰ-ਸੰਬੰਧੀ ਚੀਜ਼ ਨੂੰ ਟਾਰਗਟ ਕਰਨਾ ਲਾਜਮੀ ਹੈ ਤਾਂ ਇਸਨੂੰ coarse ਲੇਬਲ ਵਜੋਂ ਸਟੋਰ ਕਰੋ ਜਿਵੇਂ beta_tester ਜਾਂ employee। ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਨਾਂ ਨੂੰ ਲੇਬਲ ਨਾ ਬਣਾਓ। ਇਹ ਵੀ ਦੇਖੋ ਕਿ ਟਾਰਗਟਿੰਗ ਆਸਾਨੀ ਨਾਲ ਯੂਜ਼ਰਾਂ ਲਈ ਅਨੁਮਾਨਯੋਗ ਤਾਂ ਨਹੀਂ ਬਣ ਜਾਂਦੀ—ਜੇ ਕਿਸੇ ਸੈਟਿੰਗ ਟੌਗਲ ਨਾਲ ਅਚਾਨਕ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਬਿਮਾਰੀ ਜਾਂ ਕੀਮਤ ਬਦਲਾਅ ਦੀ ਜਾਣਕਾਰੀ ਲੀਕ ਹੋ ਸਕਦੀ ਹੈ ਤਾਂ ਧਿਆਨ ਜ਼ਰੂਰੀ ਹੈ।
ਖੇਤਰ-ਆਧਾਰਿਤ ਰੋਲਆਊਟ ਆਮ ਹਨ, ਪਰ ਇਹ ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵੀ ਲਿਆ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਦੇਸ਼ ਵਿੱਚ ਹੀ ਫੀਚਰ ਚਾਲੂ ਕਰ ਰਹੇ ਹੋ ਕਿਉਂਕਿ ਬੈਕਐਂਡ ਉਥੇ ਹੋਸਟ ਹੈ, ਤਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਡੇਟਾ ਸੱਚਮੁੱਚ ਉਥੇ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਦੇਸ਼-ਦਰ-ਦੇਸ਼ ਡਿਪਲੋਇਮੈਂਟ ਸਮਰੱਥ ਕਰਦਾ ਹੈ (Koder.ai AWS 'ਤੇ ਇਹ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ), ਤਾਂ ਇਸਨੂੰ ਰੋਲਆਊਟ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਬਣਾਓ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ।
ਆਡਿਟ ਟਰੇਲ ਰੱਖੋ। ਤੁਹਾਨੂੰ ਇਹ ਦਰਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਸ ਨੇ ਫਲੈਗ ਬਦਲਿਆ, ਕੀ ਬਦਲਿਆ, ਕਦੋਂ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ।
ਅਗਲੇ ਕਦਮ: ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਫਲੈਗ ਵਰਕਫਲੋ ਬਣਾਓ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋ
ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਵਰਕਫਲੋ ਤੁਹਾਨੂੰ ਅੱਗੇ ਵਧਣ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਫੀਚਰ ਫਲੈਗਾਂ ਨੂੰ ਇੱਕ ਹੋਰ ਉਤਪਾਦ ਬਣਣ ਦੇ।
ਛੋਟੇ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇਕ ਨਵੀਂ UI ਲਈ ਇੱਕ, ਇਕ ਬੈਕਐਂਡ ਵਿਵਹਾਰ ਲਈ ਇੱਕ, ਅਤੇ ਇਕ ਇਮਰਜੈਂਸੀ ਕਿੱਲ ਸਵਿੱਚ। ਉਹੀ ਪੈਟਰਨ ਦੁਹਰਾਉਣ ਨਾਲ ਇਹ ਸਮਝਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਲਾਈਵ ਹੈ ਅਤੇ ਕੀ ਬੰਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਖਤਰਨਾਕ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਸੋਚੋ ਕਿ ਇਹ ਕਿੱਥੇ ਟੁੱਟ ਸਕਦੀ ਹੈ। Koder.ai ਵਿੱਚ, Planning Mode ਤੁਹਾਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਥਾਵਾਂ (auth, billing, onboarding, data writes) ਨੂੰ ਨਿਸ਼ਾਨੇ 'ਤੇ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤੈਅ ਕਰਨ ਵਿੱਚ ਕਿ ਫਲੈਗ ਨੇ ਕੀ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਹੈ। ਮਕਸਦ ਸਧਾਰਣ ਹੈ: ਜੇ ਕੁਝ ਗਲਤ ਹੋਏ ਤੁਹਾਨੂੰ ਫਲੈਗ ਬੰਦ ਕਰਨ ਤੇ ਐਪ ਕੱਲ੍ਹ ਵਾਂਗ ਹੋਵੈ।
ਹਰ ਫਲੈਗ ਕੀਤੇ ਬਦਲਾਅ ਲਈ ਇੱਕ ਨਿੱਕੀ, ਦੁਹਰਾਉਣਯੋਗ ਰਿਲੀਜ਼ ਨੋਟ ਰੱਖੋ: ਫਲੈਗ ਦਾ ਨਾਮ, ਕਿਸ ਨੂੰ ਮਿਲ ਰਿਹਾ (ਕੋਹੋਰਟ ਅਤੇ ਰੋਲਆਊਟ %), ਇਕ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ, ਇਕ ਗਾਰਡਰੇਲ ਮੈਟ੍ਰਿਕ, ਇਸਨੂੰ ਕਿਵੇਂ ਡਿਸੇਬਲ ਕਰਨਾ ਹੈ (ਕਿੱਲ ਸਵਿੱਚ ਜਾਂ ਰੋਲਆਊਟ 0%), ਅਤੇ ਕੌਣ ਨਿਗਰਾਨੀ ਕਰ ਰਿਹਾ ਹੈ।
ਜਦੋਂ ਬਦਲਾਅ ਸਥਿਰ ਸਾਬਤ ਹੋ ਜਾਵੇ, ਸੋਢੀ ਬੇਸਲਾਈਨ ਲੌਕ ਕਰਨ ਲਈ ਸੋਰਸ ਕੋਡ ਨਿਕਾਸ ਕਰੋ, ਅਤੇ ਵੱਡੇ ਰੈਂਪਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਲਓ। ਫਿਰ ਸਫਾਈ ਸ਼ੈਡਿਊਲ ਕਰੋ: ਜਦੋਂ ਫਲੈਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚਾਲੂ (ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ) ਹੋ ਜਾਵੇ, ਉਸ ਨੂੰ ਹਟਾਉਣ ਲਈ ਇੱਕ ਤਾਰੀਖ ਨਿਰਧਾਰਤ ਕਰੋ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਸਿਸਟਮ ਅਸਾਨੀ ਨਾਲ ਸਮਝ ਆਉਣਯੋਗ ਰਹੈ।