ਬਲੂ/ਗ੍ਰੀਨ ਅਤੇ ਕੈਨੇਰੀ ਡਿਪਲੋਇਮੈਂਟ: ਇੱਕ ਸਾਫ਼ ਰਿਲੀਜ਼ ਰਣਨੀਤੀ

ਬਲੂ/ਗ੍ਰੀਨ ਅਤੇ ਕੈਨੇਰੀ ਡਿਪਲੋਇਮੈਂਟ ਦਾ ਕੀ ਮਤਲਬ ਹੈ

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

ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਬਲੂ/ਗ੍ਰੀਨ

ਬਲੂ/ਗ੍ਰੀਨ ਡਿਪਲੋਇਮੈਂਟ ਦੋ ਅਲੱਗ ਪਰ ਸਮਾਨ ਪਰਿਵੇਸ਼ (environments) ਵਰਤਦੀ ਹੈ:

• Blue: ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਅਜੇ ਸਰਵਿੰਗ ਕਰਨ ਵਾਲਾ ਵਰਜਨ ("ਲਾਈਵ" ਸੈਟਅਪ)।
• Green: ਦੂਜਾ, ਤਿਆਰ ਵਰਜਨ ਜਿੱਥੇ ਤੁਸੀਂ ਨਵਾਂ ਬਿਲਡ ਡਿਪਲੋਇ ਕਰਦੇ ਹੋ।

ਤੁਸੀਂ Green ਪਿੱਛੇ ਤਿਆਰ ਕਰਦੇ ਹੋ—ਨਵਾਂ ਬਿਲਡ ਡਿਪਲੋਇ, ਚੈੱਕ ਚਲਾਓ, ਵਾਰਮ-ਅੱਪ ਕਰੋ—ਫਿਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਭਰੋਸਾ ਹੋਵੇ ਤਾਂ Blue ਤੋਂ Green ਨੂੰ ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਕਰੋ। ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਸਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਮੁੱਖ ਵਿਚਾਰ "ਦੋ ਰੰਗ" ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਸਾਫ਼, ਵਾਪਸ ਕਰਨ ਯੋਗ ਕਟਓਵਰ ਹੈ।

ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕੈਨੇਰੀ

ਕੈਨੇਰੀ ਰਿਲੀਜ਼ ਇੱਕ تدريجی ਰੋਲਆਊਟ ਹੈ। ਇਕੱਠੇ ਸਾਰੇ ਨੂੰ ਤੁਰੰਤ ਨਵਾਂ ਵਰਜਨ ਦੇਣ ਦੀ ਥਾਂ, ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ (ਉਦਾਹਰਨ ਲਈ 1–5%) ਨੂੰ ਨਵਾਂ ਵਰਜਨ ਦਿਖਾਉਂਦੇ ਹੋ। ਜੇ ਸਭ ਠੀਕ ਲੱਗੇ, ਤਾਂ ਕਦਮ-ਦਰ-ਕਦਮ ਰੋਲਆਊਟ ਵੱਧਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦ ਤੱਕ 100% ਟ੍ਰੈਫਿਕ ਨਵੇਂ ਵਰਜਨ ਤੇ ਨਾ ਹੋ ਜਾਏ।

ਮੁੱਖ ਵਿਚਾਰ ਹੈ ਅਸਲ ਟਰੈਫਿਕ ਤੋਂ ਸਿੱਖਣਾ ਪਹਿਲਾਂ।

ਸਾਂਝਾ ਮਕਸਦ: ਘੱਟ ਡਾਊਨਟਾਈਮ ਨਾਲ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼

ਦੋਹਾਂ ਤਰੀਕਿਆਂ ਦਾ ਮਕਸਦ ਹੈ:

• ਗੜਬੜ ਹੋਣ 'ਤੇ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਘਟਾਉਣਾ
• ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਡਿਪਲੋਇ (ਜਿੰਨਾ ਨੇੜੇ ਹੋ ਸਕੇ)
• ਰੋਲਬੈਕ ਨੂੰ ਘੱਟ ਤਣਾਅਭਰਿਆ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਬਣਾਉਣਾ

ਬਲੂ/ਗ੍ਰੀਨ ਤੇਜ਼ ਸਵਿੱਚ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਕੈਨੇਰੀ ਨਿਰੀਖਣ ਅਤੇ ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟਿੰਗ ਰਾਹੀਂ ਨਿਯੰਤਰਿਤ ਐਕਸਪੋਜ਼ਰ 'ਤੇ।

ਕੋਈ ਇਕ "ਸਭ ਤੋਂ ਵਧੀਆ" ਵਿਕਲਪ ਨਹੀਂ

ਕੋਈ ਵੀ ਪদ্ধਤੀ ਸਵੈਚਾਲਿਤ ਤੌਰ ਤੇ ਬਿਹਤਰ ਨਹੀਂ। ਸਹੀ ਚੋਣ ਤੁਹਾਡੀ ਉਤਪਾਦ ਵਰਤੋਂ, ਟੈਸਟਿੰਗ ਵਿੱਚ ਭਰੋਸਾ, ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਅਤੇ ਤੁਸੀਂ ਕਿਹੜੇ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹੋ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਕਈ ਟੀਮਾਂ ਦੋਹਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੀਆਂ ਹਨ—ਸਧਾਰਣਤਾ ਲਈ Blue/Green ਅਤੇ ਉਪਭੋਗਤਾ ਐਕਸਪੋਜ਼ਰ ਲਈ Canary ਤਕਨੀਕਾਂ।

ਅਗਲੇ ਭਾਗਾਂ ਵਿੱਚ ਅਸੀਂ ਦੋਹਾਂ ਦੀ ਤੁਲਨਾ ਕਰਾਂਗੇ ਅਤੇ ਦਿਖਾਵਾਂਗੇ ਕਿ ਕਦੋਂ ਹਰ ਇੱਕ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।

ਬਲੂ/ਗ੍ਰੀਨ ਵੱਧਾਮੀਏ ਕੈਨੇਰੀ: ਇੱਕ ਤੱਤ-ਤੁਰੰਤ ਤੁਲਨਾ

ਬਲੂ/ਗ੍ਰੀਨ ਅਤੇ ਕੈਨੇਰੀ ਦੋਹਾਂ ਨੇ ਬਿਨਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਰੋਕਿਆ ਬਦਲਾਅਾਂ ਰਿਲੀਜ਼ ਕਰਨ ਦੇ ਤਰੀਕੇ ਹਨ—ਪਰ ਉਹ ਇਸ ਗੱਲ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਨਵੀਂ ਵਰਜਨ ਨੂੰ ਟ੍ਰੈਫਿਕ ਕਿਵੇਂ ਮਿਲਦੀ ਹੈ।

ਟ੍ਰੈਫਿਕ ਕਿਵੇਂ ਸਵਿੱਚ ਹੁੰਦੀ ਹੈ

ਬਲੂ/ਗ੍ਰੀਨ ਦੋ ਪੂਰੇ ਪਰਿਬੇਸ਼ ਚਲਾਉਂਦੀ ਹੈ: "Blue" (ਮੌਜੂਦਾ) ਅਤੇ "Green" (ਨਵਾਂ)। ਤੁਸੀਂ Green ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਕੇ ਫਿਰ ਸਾਰੀ ਟ੍ਰੈਫਿਕ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਵਿੱਚ ਕਰਦੇ ਹੋ—ਇਕ ਨਿਯੰਤਰਿਤ ਬਟਨ ਵਾਂਗ।

ਕੈਨੇਰੀ ਪਹਿਲਾਂ ਨਵੇਂ ਵਰਜਨ ਨੂੰ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ (ਉਦਾਹਰਨ ਲਈ 1–5%) ਨੂੰ ਦਿੰਦੀ ਹੈ, ਫਿਰ ਰੋਡਮੈਪ ਅਨੁਸਾਰ ਟ੍ਰੈਫਿਕ ਧੀਰੇ-ਧੀਰੇ ਵਧਾਇਦੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਅਸਲ-ਦੁਨੀਆ ਕਾਰਗੁਜ਼ਾਰੀ ਵੇਖਦੇ ਹੋ।

ਅਸਲ ਗੱਲਾਂ ਵਿੱਚ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ

ਇਕ ਸਧਾਰਨ ਫੈਸਲਾ-ਮਾਰਗਦਰਸ਼ਕ

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

ਨਿਸ਼ਚਿਤ ਨਾ ਹੋਵੋ ਤਾਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ Blue/Green ਨਾਲ ਸੁਚਾਲੂਤਾ ਬਣਾ ਲਵੋ, ਫਿਰ ਮਾਨੀਟਰੀੰਗ ਅਤੇ ਰੋਲਬੈਕ ਆਦਤਾਂ ਮਜ਼ਬੂਤ ਹੋਣ 'ਤੇ ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਸਰਵਿਸਾਂ ਲਈ Canary ਸ਼ਾਮਲ ਕਰੋ।

ਕਦੋਂ ਬਲੂ/ਗ੍ਰੀਨ موزੂ ਹੈ

ਬਲੂ/ਗ੍ਰੀਨ ਉਹ ਵੇਲਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਰਿਲੀਜ਼ ਨੂੰ "ਸਵਿੱਚ" ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਤੁਸੀਂ ਦੋ production-ਜਿਹੇ ਪਰਿਵੇਸ਼ ਚਲਾਉਂਦੇ ਹੋ: Blue (ਮੌਜੂਦਾ) ਅਤੇ Green (ਨਵਾਂ)। ਜਦੋਂ Green ਵੈਰੀਫਾਈ ਹੋ ਜਾਏ, ਤੁਸੀਂ ਉਥੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰਾਜ਼ੀਦੇ ਹੋ।

ਤੁਹਾਨੂੰ ਨੇੜੀ-ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਦੀ ਲੋੜ ਹੈ

ਜੇ ਤੁਹਾਡੀ ਉਤਪਾਦਿਕ ਪ੍ਰਕਿਰਿਆ maintenance windows ਸਹਿਣ ਨਹੀਂ ਕਰ ਸਕਦੀ—ਜਿਵੇਂ checkout, booking, logged-in ਡੈਸ਼ਬੋਰਡ—ਤਾਂ ਬਲੂ/ਗ੍ਰੀਨ ਮਦਦਗਾਰ ਹੈ ਕਿਉਂਕਿ ਨਵਾਂ ਵਰਜਨ ਪਹਿਲਾਂ ਸ਼ੁਰੂ, ਵਾਰਮ ਅਤੇ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ deploy ਸਮਾਂ ਗਾਹਕਾਂ ਦੇ ਸਾਹਮਣੇ ਨਹੀਂ ਹੁੰਦਾ।

ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਸਧਾਰਣ ਰੋਲਬੈਕ ਚਾਹੀਦਾ ਹੈ

Rollback ਅਕਸਰ ਸਿਰਫ਼ ਟ੍ਰੈਫਿਕ ਵਾਪਸ Blue 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਕੀਮਤੀ ਹੈ ਜਦੋਂ:

• ਰਿਲੀਜ਼ ਮਿੰਟਾਂ ਵਿੱਚ ਵਾਪਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ
• ਤੁਸੀਂ ਐਮਰਜੰਸੀ ਹਾਟਫਿਕਸ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹੋ
• ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ, ਦੋਹਰਾਏ ਜਾਣ ਯੋਗ ਫੇਲਰ ਰਿਸਪਾਂਸ ਚਾਹੀਦਾ ਹੈ

ਰੋਲਬੈਕ ਦੇ ਲਈ ਰੀ-ਬਿਲਡ ਜਾਂ ਰੀ-ਡਿਪਲੋਇ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ—ਇਹ ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਹੈ।

ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਸਾਜ਼ਗਾਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ

ਬਲੂ/ਗ੍ਰੀਨ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ ਜਦੋਂ database migrations ਪਿਛਲੇ ਵਰਜਨ ਨਾਲ ਕਾਂਪੈਟਿਬਲ ਹੋਣ, ਕਿਉਂਕਿ ਇੱਕ ਸਮੇਂ Blue ਅਤੇ Green ਦੋਹਾਂ ਮੌਜੂਦ ਰਹਿ ਸਕਦੇ ਹਨ।

ਚੰਗੇ ਮਾਮਲੇ:

• ਸੰਪੂਰਕ schema ਬਦਲਾਅ (ਨਵੇਂ nullable ਕਾਲਮ, ਨਵੀਂ ਟੇਬਲ)
• ਡੇਟਾ ਫਾਰਮੈਟ ਵਧਾਉਣਾ ਜਿਹੜਾ ਪੁਰਾਣਾ ਕੋਡ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕੇ

ਖਤਰਨਾਕ ਮਾਮਲੇ: ਕਾਲਮ ਹਟਾਉਣਾ, ਫੀਲਡ ਰੀਨੇਮ ਕਰਨਾ, ਜਾਂ ਅਰਥ ਬਦਲਣਾ—ਇਹਨਾਂ ਨਾਲ "ਵਾਪਸ ਸਵਿੱਚ" ਦਾ ਵਾਅਦਾ ਟੋਟ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ multi-step ਮਾਈਗ੍ਰੇਸ਼ਨ ਨਹੀਂ ਕਰਦੇ।

ਤੁਸੀਂ duplicate environments ਅਤੇ routing ਕਾਬੂ ਸਹਿਣ ਕਰ ਸਕਦੇ ਹੋ

ਬਲੂ/ਗ੍ਰੀਨ ਵਾਧੂ ਸਮਰੱਥਾ (ਦੋ stacks) ਅਤੇ ਟ੍ਰੈਫਿਕ ਨਿਰਦੇਸ਼ ਲਈ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਲੋਡ ਬੈਲਾਂਸਰ, ਇਨਗ੍ਰੈਸ, ਜਾਂ ਪਲੇਟਫਾਰਮ ਰੂਟਿੰਗ)। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਸਾਫ਼ ਰਾਟਿੰਗ ਲਿਵਰ ਹੈ, ਤਾਂ ਬਲੂ/ਗ੍ਰੀਨ ਉੱਚ-ਭਰੋਸੇਯੋਗ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ ਅਸਾਨ ਡਿਫੌਲਟ ਬਣ ਸਕਦਾ ਹੈ।

ਕਦੋਂ ਕੈਨੇਰੀ ਰਿਲੀਜ਼ ਵਧੀਆ ਹੁੰਦੀ ਹੈ

ਕੈਨੇਰੀ ਰੋਲਆਊਟ ਵਿੱਚ ਬਦਲਾਅ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਨਤੀਜੇ ਤੋਂ ਸਿੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਵੱਧਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਤਦੋਂ ٹھੀਕ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜੋਖਮ ਘਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਸਭ ਕੁਝ ਰੋਕੇ।

ਤੁਹਾਡੇ ਕੋਲ ਵੱਧ ਟਰੈਫਿਕ ਅਤੇ ਸਪਸ਼ਟ ਸਿਗਨਲ ਹਨ

ਕੈਨੇਰੀ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਉੱਚ-ਟਰੈਫਿਕ ਐਪਾਂ ਲਈ ਕਿਉਂਕਿ 1–5% ਟਰੈਫਿਕ ਵੀ ਜਲਦੀ ਮਾਨਯੋਗ ਡੇਟਾ ਦੇ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਮੈਟ੍ਰਿਕਸ (error rate, latency, conversion, checkout completion, API timeouts) ਟਰੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੇਸਟ ਇਨਵਾਇਰਨਮੈਂਟਾਂ 'ਤੇ ਹੀ ਨਿਰਭਰ ਰਹਿਣ ਦੀ ਥਾਂ ਅਸਲ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਰਿਲੀਜ਼ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।

ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਐਡਜ ਕੇਸਾਂ ਬਾਰੇ ਚਿੰਤਤ ਹੋ

ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਸਿਰਫ ਅਸਲ ਲੋਡ ਹੇਠਾਂ ਸਮਣਦੀਆਂ ਹਨ: ਧੀਮੀ DB ਕਵੈਰੀਜ਼, cache misses, ਖੇਤਰੀ ਲੇਟੈਂਸੀ, ਨਿਸ਼ਚਿਤ ਡਿਵਾਈਸ ਜਾਂ ਦੁਲਭ ਯੂਜ਼ਰ ਫਲੋਜ਼। ਕੈਨੇਰੀ ਨਾਲ ਤੁਸੀਂ ਇਹ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਕਿ ਨਵਾਂ ਬਦਲਾਅ ਗਲਤੀਆਂ ਨਹੀਂ ਵਧਾ ਰਿਹਾ।

ਤੁਹਾਨੂੰ ਸਟੇਜਡ ਰੋਲਆਊਟ ਚਾਹੀਦੇ ਹਨ

ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਬਾਰ-ਬਾਰ ਸ਼ਿਪਿੰਗ ਹੁੰਦੀ ਹੈ, ਕਈ ਟੀਮਾਂ ਯੋਗਦਾਨ ਦਿੰਦੀਆਂ ਹਨ, ਜਾਂ ਬਦਲਾਅ ਨੂੰ ਗ੍ਰੇਡਿ੍ਯੂਅਲ ਤੌਰ ਤੇ ਪੇਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਕੈਨੇਰੀ ਮਿਲਦੀ-ਝਲਦੀ ਹੈ। ਤੁਸੀਂ 1% → 10% → 50% → 100% ਤੱਕ ਵਧ ਸਕਦੇ ਹੋ।

ਫੀਚਰ ਫਲੈਗਜ਼ ਤੁਹਾਡੇ ਟੂਲਕਿੱਟ ਦਾ ਹਿੱਸਾ ਹਨ

ਕੈਨੇਰੀ ਫਲੈਗਸ ਨਾਲ ਖਾਸ ਤੌਰ 'ਤੇ ਚੰਗਾ ਮਿਲਦਾ ਹੈ: ਤੁਸੀਂ ਕੋਡ ਸੇਫ਼ ਤਰ੍ਹਾਂ ਡਿਪਲੋਇ ਕਰਦੇ ਹੋ, ਫਿਰ ਕੁਝ ਉਪਭੋਗਤਾਵਾਂ, ਖੇਤਰਾਂ ਜਾਂ ਖਾਤਿਆਂ ਲਈ ਫੰਕਸ਼ਨਲਟੀ enable ਕਰਦੇ ਹੋ। ਰੋਲਬੈਕ ਘਟਨਾ ਅਕਸਰ ਸਿਰਫ ਫਲੈਗ ਬੰਦ ਕਰਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ progressive delivery ਵੱਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਕੈਨੇਰੀ ਅਕਸਰ ਸਭ ਤੋਂ ਲਚਕੀਲਾ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੁੰਦਾ ਹੈ।

See also: /blog/feature-flags-and-progressive-delivery

ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟਿੰਗ ਬੁਨਿਆਦੀ ਗੱਲਾਂ (ਜਰਗਨ ਤੋਂ ਬਿਨਾਂ)

ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟਿੰਗ ਦਾ ਸਿੱਧਾ ਮਤਲਬ ਹੈ ਇਹ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਕਿ "ਕੌਣ" ਨਵਾਂ ਵਰਜਨ ਪਾਉਂਦਾ ਹੈ ਅਤੇ "ਕਦੋਂ"। ਸਾਰੇ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਫਲਿੱਪ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਰਿਕੁਐਸਟਾਂ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ (ਜਾਂ ਚੁਣਿੰਦਾ) ਤੌਰ ਤੇ ਪੁਰਾਣੇ ਤੋਂ ਨਵੇਂ ਵੱਲ ਮੋੜਦੇ ਹੋ। ਇਹੀ ਦੋਨੋ ਬਲੂ/ਗ੍ਰੀਨ ਓਰ ਕੈਨੇਰੀ ਦਾ ਲੋੜੀਦਾ ਹਿਰਦਾ ਹੈ—ਅਤੇ ਇਹੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਡਿਪਲੋਇ ਹਕੀਕਤ ਵਿੱਚ ਸਾਫ਼ ਲਗੇ।

"ਸਟੇਅਰਿੰਗ ਵ੍ਹੀਲ": ਕਿੱਥੇ ਟ੍ਰੈਫਿਕ ਰੋਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਟ੍ਰੈਫਿਕ ਨੂੰ ਤੁਸੀਂ ਸਟੈਕ ਦੇ ਕੁਝ ਆਮ ਸਥਾਨਾਂ 'ਤੇ ਸਵੀਚ ਕਰ ਸਕਦੇ ਹੋ। ਠੀਕ ਚੋਣ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚਲਾ ਰਹੇ ਹੋ ਅਤੇ ਤੁਹਾਨੂੰ ਕਿੰਨੀ ਬਾਰੀਕੀ ਨਾਲ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੈ।

• ਲੋਡ ਬੈਲਾਂਸਰ: ਆਉਣ ਵਾਲੀਆਂ ਰਿਕੁਐਸਟਾਂ ਨੂੰ ਦੋ environments ਜਾਂ ਸਰਵਰ ਸਮੂਹਾਂ ਦੇ ਵਿੱਚ ਵੰਡਦਾ ਹੈ।
• Ingress controller (Kubernetes): ਨਿਯਮਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ Services ਨੂੰ ਰੋਟ ਕਰਦਾ ਹੈ।
• Service mesh: ਸੇਵਾਵਾਂ ਦਰਮਿਆਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੁਖੜ ਨਿਯਮਾਂ ਨਾਲ ਕਾਬੂ ਕਰਦਾ ਹੈ ਅਤੇ ਵਧੀਆ ਵਿਸ਼ਿਬਿਲਿਟੀ ਦਿੰਦਾ ਹੈ।
• CDN / edge routing: ਜੇ ਤੁਸੀਂ ਰੂਟਿੰਗ ਫੈਸਲੇ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨਜ਼ਦੀਕ ਚਾਹੁੰਦੇ ਹੋ, ਤਦ ਇਹ ਲਾਭਦਾਇਕ ਹੈ।

ਹਰ ਲੇਅਰ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ "source of truth" ਪਿਕ ਕਰੋ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਰਿਲੀਜ਼ ਮੈਨੇਜਮੈਂਟ ਅਣਵਿਸ਼ਵਾਸਯੋਗ ਨਾ ਬਣੇ।

ਆਮ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਟ੍ਰੈਫਿਕ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ

• ਪ੍ਰਤੀਸ਼ਤ-ਆਧਾਰਿਤ: 1% → 5% → 25% → 50% → 100%। ਇਹ ਕੈਨੇਰੀ ਪੈਟਰਨ ਹੈ।
• ਹੈਡਰ-ਆਧਾਰਿਤ: ਨਿਰਧਾਰਿਤ ਹੈਡਰ ਵਾਲੀਆਂ ਰਿਕੁਐਸਟਾਂ ਨਵੀਂ ਵਰਜਨ ਨੂੰ ਰੋਟ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ QA ਟੂਲ ਜਾਂ ਅੰਦਰੂਨੀ ਟੀਮ)।
• ਯੂਜ਼ਰ ਕੋਹੋਰਟਸ: ਪਹਿਲਾਂ ਖਾਸ ਸਮੂਹ—ਕਰਮਚਾਰੀ, ਬੀਟਾ ਯੂਜ਼ਰ, ਖੇਤਰ, ਜਾਂ ਕਠੈਗਰੀ— ਨੂੰ ਰੋਲਆਊਟ ਕਰੋ।

ਪ੍ਰਤੀਸ਼ਤ ਸਮਝਾਉਣ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ, ਪਰ ਕੋਹੋਰਟਸ ਅਕਸਰ ਸੁਰੱਖਿਅਤ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਯੂਜ਼ਰ ਬਦਲਾਅ ਵੇਖਣਗੇ।

ਸੈਸ਼ਨ ਅਤੇ ਕੈਸ਼: ਦੋ "ਗੌਟਚਾਜ਼"

Sticky sessions (session affinity). ਜੇ ਸਿਸਟਮ ਕਿਸੇ ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਸਰਵਰ/ਵਰਜਨ ਨਾਲ ਬੰਨ੍ਹਦਾ ਹੈ, ਤਾਂ 10% ਟ੍ਰੈਫਿਕ ਵੰਡ 10% ਵਰਗੀ ਨਹੀਂ ਰਹੇਗੀ। ਇਹ ਵੀੜ-ਪਰਿਵਰਤਨ ਦੌਰਾਨ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਸਾਂਝੀ session ਸਟੋਰੇਜ ਵਰਤੋ ਜਾਂ ਯੂਜ਼ਰ ਨੂੰ ਇਕ-ਸੁਰਤ ਵਰਜਨ 'ਤੇ ਰੱਖੋ।

Cache warming. ਨਵੇਂ ਵਰਜਨ ਅਕਸਰ ਠੰਢੇ ਕੈਸ਼ ਨੂੰ ਮਾਰਦਾ ਹੈ। ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਘਟਾਵੇ ਵਾਂਗ ਲੱਗ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਕੋਡ ਠੀਕ ਹੋਵੇ। ਵਧੀਆ ਹੈ ਕਿ ਰੈਂਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ ਵਾਰਮ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਹਾਈ-ਟਰੈਫਿਕ ਪੇਜਾਂ ਅਤੇ ਮਹਿੰਗੇ ਏਂਡਪੌਇੰਟਾਂ ਲਈ।

ਟ੍ਰੈਫਿਕ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਨਿਯੰਤ੍ਰਿਤ ਕਾਰਵਾਈ ਮੰਨੋ

ਰਾਊਟਿੰਗ ਬਦਲਾਅ ਨੂੰ production ਬਦਲਾਅ ਵਾਂਗ ਹੀ ਦਿਖੋ, ਨਾ ਕਿ ਢਿੱਲੇ-ਢਾਲੇ ਬਟਨ ਕਲਿੱਕ ਵਾਂਗ।

ਦਸਤਾਵੇਜ਼:

• ਕੌਣ ਟ੍ਰੈਫਿਕ ਸਪਲਿਟ ਬਦਲ ਸਕਦਾ ਹੈ
• ਕਿਵੇਂ ਇਸ ਦੀ ਮਨਜ਼ੂਰੀ ਹੁੰਦੀ ਹੈ (on-call? release manager? change ticket?)
• ਕਿੱਥੇ ਇਹ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (load balancer config, ingress rules, mesh policy)
• "ਰੋਕ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਰੋਲਆਊਟ ਰੋਕਣ ਦੇ ਟ੍ਰਿਗਰ ਅਤੇ ਰੋਲਬੈਕ ਪਲਾਨ)

ਇਹ ਛੋਟੀ ਗਵਰਨੈਂਸ ਇਸ ਗੱਲ ਤੋਂ ਬਚਾਏਗੀ ਕਿ ਕੋਈ ਵਿਅਕਤੀ "ਸਿਰਫ਼ 50% ਤੇ ਧੱਕ ਦੇ ਦੇਵੇ" ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਕੈਨੇਰੀ ਦੀ ਹੇਲਥ ਚੈੱਕ ਕਰ ਰਹੇ ਹੋ।

ਰੋਲਆਊਟ ਦੌਰਾਨ ਕੀ ਮਾਨੀਟਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਰੋਲਆਊਟ ਸਿਰਫ "ਕੀ ਡਿਪਲੋਇ ਸਫਲ ਹੋਇਆ?" ਨਹੀਂ—ਇਹ ਹੈ "ਕੀ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬੁਰਾ ਅਨੁਭਵ ਮਿਲ ਰਿਹਾ ਹੈ?" ਸਿੱਧਾ ਤਰੀਕਾ ਹੈ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸੈੱਟ ਸਿਗਨਲਾਂ ਨੂੰ ਦੇਖਣਾ ਜੋ ਦੱਸਣਗੇ: ਕੀ ਸਿਸਟਮ ਸਿਹਤਮੰਦ ਹੈ, ਅਤੇ ਕੀ ਬਦਲਾਅ ਗਾਹਕਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਰਿਹਾ ਹੈ?

ਚਾਰ ਮੁੱਖ ਸਿਗਨਲ: errors, latency, saturation, user impact

Error rate: HTTP 5xx, request failures, timeouts, ਅਤੇ dependency errors (DB, payments, ਤੀਜੀਆਂ ਪਾਰਟੀਆਂ) ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ। ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਵੀ ਸਹਾਇਤਾ ਬੋਝ ਵਧਾ ਸਕਦੀਆਂ ਹਨ।

Latency: p50 ਅਤੇ p95 (ਅਤੇ ਜੇ ਹੈ ਤਾਂ p99) ਦੇਖੋ। ਕਿਸੇ ਬਦਲਾਅ ਨਾਲ ਔਸਤ ਠੀਕ ਰਹਿ ਸਕਦਾ ਹੈ ਪਰ ਲੰਬੇ-ਟੇਲ ਸਲੋਡਾਓਨਠ ਬਣ ਸਕਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰਨਗੇ।

Saturation: CPU, memory, disk IO, DB connections, queue depth, thread pools—ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਸਿਸਟਮ ਕਿੰਨਾ ਭਰਿਆ ਹੋਇਆ ਹੈ। Saturation ਆਮ ਤੌਰ 'ਤੇ outage ਤੋਂ ਪਹਿਲਾਂ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ।

User-impact signals: ਜੋ ਕੁਝ ਯੂਜ਼ਰ ਅਨੁਭਵ ਕਰਦੇ ਹਨ—checkout failures, sign-in rates, search results, app crash rate, ਮੁੱਖ ਪੇਜ ਲੋਡ ਸਮਾਂ—ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੰਫ਼ਰਾਸਟਰਕਚਰ ਅੰਕੜਿਆਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।

ਇੱਕ "ਰਿਲੀਜ਼ ਡੈਸ਼ਬੋਰਡ" ਬਣਾਓ ਜੋ ਹਰ ਕੋਈ ਪੜ੍ਹ ਸਕੇ

ਇੱਕ ਛੋਟਾ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ ਜੋ ਇੱਕ ਸਕ੍ਰੀਨ 'ਤੇ ਫਿੱਟ ਹੋਵੇ ਅਤੇ ਰਿਲੀਜ਼ ਚੈਨਲ 'ਚ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕੇ। ਹਰ ਰੋਲਆਊਟ ਲਈ ਇਹ ਇੱਕਸਾਰ ਰੱਖੋ ਤਾਂ ਕਿ ਲੋਕ ਗ੍ਰਾਫਾਂ ਦੀ ਖੋਜ ਵਿੱਚ ਸਮਾਂ ਗਵਾਂ ਨਾ ਦੇਣ।

ਸ਼ਾਮਿਲ ਕਰੋ:

• error rate (ਓਵਰਆਲ + ਮੁੱਖ endpoints)
• latency (p50/p95 ਸੰਕਟਮਾਰਗ)
• saturation (ਸਟੈਕ ਲਈ ਟੌਪ 3 ਬਾਧਾਵਾਂ)
• user-impact KPIs (ਤੁਹਾਡੇ 1–3 ਬਿਜ਼ਨਸ-ਮਹੱਤਵਪੂਰਨ ਫਲੋ)

ਕੈਨੇਰੀ ਲਈ, ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਵਰਜਨ/ਇੰਸਟੈਂਸ ਗਰੁੱਪ ਅਨੁਸਾਰ ਸੈਗਮੈਂਟ ਕਰੋ ਤਾਂ ਤੁਸੀਂ canary vs baseline ਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ। ਬਲੂ/ਗ੍ਰੀਨ ਲਈ, cutover ਵਿੰਡੋ ਦੌਰਾਨ ਨਵਾਂ ਅਤੇ ਪੁਰਾਣਾ ਵਾਤਾਵਰਨ ਤੁਲਨਾ ਕਰੋ।

pause/rollback ਫੈਸਲਿਆਂ ਲਈ ਸਪਸ਼ਟ ਥ੍ਰੇਸ਼ਹੋਲਡ

ਟਰੈਫਿਕ ਸ਼ਿਫਟਿੰਗ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਤੈਅ ਕਰੋ। ਉਦਾਹਰਨ:

• error rate baseline ਨਾਲੋਂ X% ਵਧੇ for Y минут
• p95 latency ਇੱਕ ਨਿਰਧਾਰਿਤ ਸੀਮਾ ਉੱਤੇ ਜਾਂ baseline ਨਾਲ X% ਵਧੇ
• user-impact KPI ਨਿਰਧਾਰਿਤ ਹੱਦ ਤੋਂ ਘਟੇ

ਅੰਕ ਸੇਵਾ 'ਤੇ ਨਿਰਭਰ ਕਰਨਗੇ, ਪਰ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਭ ਤਿਆਰ ਹੋਣ। ਜੇ ਸਭ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਰੋਲਬੈਕ ਕਦੋਂ ਕਰਨਾ ਹੈ, ਤਾਂ ਗਾਹਕ ਪ੍ਰਭਾਵ ਦੌਰਾਨ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਨਹੀਂ ਹੋਵੇਗਾ।

ਰੋਲਆਊਟ ਵਿੰਡੋ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਅਲਰਟ

ਰੋਲਆਊਟ ਦੌਰਾਨ ਅਲਰਟ ਸ਼ਾਮਿਲ ਕਰੋ ਜਾਂ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਟਾਈਟ ਕਰੋ:

• 5xx/timeouts ਵਿੱਚ ਅਚਾਨਕ ਚੜ੍ਹਾਵ
• ਮੁੱਖ ਰੂਟਾਂ 'ਤੇ ਲੈਟੈਂਸੀ ਵਿੱਚ ਰੈਗ੍ਰੈਸ਼ਨ
• saturation ਸਿਗਨਲਾਂ ਵਿੱਚ ਤੇਜ਼ ਵਾਧਾ

ਅਲਰਟਾਂ actionable ਰੱਖੋ: "ਕੀ ਬਦਲਿਆ, ਕਿੱਥੇ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ"। ਜੇ ਅਲਰਟ ਸ਼ੋਰ-ਭਰੇ ਹੋਣਗੇ ਤਾਂ ਲੋਕ ਸੰਕੇਤ ਗੁਆ ਦੇਣਗੇ ਜੋ ਰੋਲਆਊਟ ਦੌਰਾਨ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਚੈੱਕ ਜੋ ਮੁੱਦਿਆਂ ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦੇ ਹਨ

ਅਕਸਰ ਰੋਲਆਊਟ ਫੇਲਿਅਰ ਵੱਡੇ ਬੱਗਾਂ ਕਰਕੇ ਨਹੀਂ, ਬਲਕਿ ਛੋਟੀ ਗਲਤੀਆਂ (ਗੁੰਮ/config, ਨਵੀਂ DB migration, ਮਿਆਦ-ਪੂਰੇ ਸਟੀਕਰ) ਕਾਰਨ ਹੁੰਦੇ ਹਨ। ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਚੈੱਕ ਉਹ ਮੌਕਾ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਇਹ ਸਮੱਸਿਆਵਾਂ ਛੋਟੇ ਹਿੱਸੇ 'ਤੇ ਫੜ ਸਕਦੇ ਹੋ।

ਹੈਲਥ ਚੈੱਕ ਅਤੇ ਸਮੋਕ ਟੈਸਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਕਿਸੇ ਵੀ ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟ ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਂ ਵਰਜਨ ਦੀ ਬੁਨਿਆਦੀ ਸਿਹਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:

• ਐਪ ਹੈਲਥ ਐਂਡਪੌਇੰਟ OK ਦਿਖਾਉਂਦੇ ਹਨ
• ਡੀਪੈਂਡੇੰਸੀ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰੋ: DB, cache, queue, object storage, email/SMS ਪ੍ਰੋਵਾਈਡਰ
• ਸੀਕ੍ਰੇਟਸ ਅਤੇ environment variables ਮੌਜੂਦ ਹਨ ਅਤੇ ਠੀਕ ਸਕੋਪ ਕੀਤੇ ਗਏ ਹਨ

ਨਵੇਂ ਵਾਤਾਵਰਨ 'ਤੇ ਛੋਟੇ end-to-end ਟੈਸਟ ਚਲਾਓ

ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੇ ਬਾਵਜੂਦ, ਡਿਪਲੋਇਡ ਸਿਸਟਮ ਕੰਮ ਕਰਦਾ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੀ automated end-to-end suite ਚਲਾ ਕਰੋ ਜੋ ਮਿੰਟਾਂ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਵੇ।

ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਫਲੋਜ਼ ਜੋ ਸਰਵਿਸਾਂ ਨੂੰ ਪਾਰ ਕਰਦੇ ਹਨ (web → API → DB → ਤੀਜੀ ਪਾਰਟੀ) 'ਤੇ ਧਿਆਨ ਦਿਓ ਅਤੇ ਪ੍ਰਤੀਕਤੀਕ ਇੱਕ "ਅਸਲ" ਬੇਨਤੀ ਸ਼ਾਮਿਲ ਕਰੋ।

ਆਮਦਨ ਵਾਲੀਆਂ ਯਾਤਰਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਆਟੋਮੇਟੇਡ ਟੈਸਟ ਸਭ ਕੁਝ ਨਹੀਂ ਫੜਦੇ। ਮੁੱਖ ਵਰਤੋਂਕਾਰ ஜਾ਼ਈ-ਜੋੜ-ਚੁੱਕੀ ਵਰਕਫਲੋਜ਼ ਦਾ ਮਨੁੱਖੀ ਜਾਂ ਨਿਸ਼ਚਿਤ ਵੇਰੀਫਿਕੇਸ਼ਨ ਕਰੋ:

• ਲੌਗਿਨ ਅਤੇ ਪਾਸਵਰਡ ਰੀਸੈੱਟ
• ਚੈਕਆਊਟ ਜਾਂ ਭੁਗਤਾਨ ਫਲੋ (ਫੇਲਿਯਰ ਪਾਥ ਸਮੇਤ)
• ਮੁੱਖ "create/update/delete" ਕਾਰਵਾਈਆਂ

ਜੇ ਤੁਸੀਂ ਕਈ ਰੋਲ ਸਹਾਇਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਹਰ ਰੋਲ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਯਾਤਰਾ ਨਮੂਨਾ ਕਰੋ।

ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਰੈਡੀਨੈੱਸ ਚੈਕਲਿਸਟ ਰੱਖੋ

ਚੈਕਲਿਸਟ ਤਿਆਰੀਯਾਂ ਨੂੰ ਰੀਪੀਟੇਬਲ ਬਣਾਉਂਦਾ ਹੈ:

• DB migrations ਲਾਗੂ ਅਤੇ ਰੀਵਰਸਿਬਲ (ਜਾਂ ਸਪੱਠ ਸੁਰੱਖਿਅਤ)
• ਦਿਖਾਈਪਣ ਤਿਆਰ: logs, dashboards, alerts
• ਰੋਲਬੈਕ ਪਲਾਨ ਸਮੀਖਿਆ (ਕੌਣ, ਕਿਵੇਂ, ਅਤੇ "ਰੋਕ" ਦਾ ਕੀ ਮਤਲਬ)

ਜਦੋਂ ਇਹ ਚੈਕ ਆਮ ਹੁੰਦੇ ਹਨ, ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟਿੰਗ ਇਕ ਨਿਯੰਤਰਿਤ ਕਦਮ ਬਣ ਜਾਂਦੀ ਹੈ—ਭਰੋਸੇ ਦੀ ਛਾਲ ਨਹੀਂ।

ਬਲੂ/ਗ੍ਰੀਨ ਰੋਲਆਊਟ: ਵਰਤੋਂ-ਯੋਗ ਪਲੇਬੁਕ

ਬਲੂ/ਗ੍ਰੀਨ ਰੋਲਆਊਟ ਨੂੰ ਚੈੱਕਲਿਸਟ ਵਾਂਗ ਚਲਾਉਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ: ਤਿਆਰੀ, ਡਿਪਲੋਇ, ਵੈਰੀਫਾਈ, ਸਵਿੱਚ, ਨਿਰੀਖਣ, ਫਿਰ ਸਫਾਈ।

1) Green 'ਤੇ ਡਿਪਲੋਇ ਕਰੋ (ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ)

ਨਵਾਂ ਵਰਜਨ Green environment 'ਤੇ ਸ਼ਿਪ ਕਰੋ ਜਦਕਿ Blue ਅਸਲ ਟ੍ਰੈਫਿਕ ਸਰਵ ਕਰ ਰਿਹਾ ਹੋਵੇ। configs ਅਤੇ secrets ਮੈਚ ਕਰੋ ਤਾਂ ਕਿ Green ਸੱਚਮੁੱਚ ਨਕਲ ਹੋਵੇ।

2) ਕਿਸੇ ਵੀ ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਤੋਂ ਪਹਿਲਾਂ Green ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

਼ਉੱਚ-ਸਿਗਨਲ ਚੈੱਕ ਕਰੋ: ਐਪ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਸਟਾਰਟ ਹੋ ਰਿਹਾ ਹੈ, ਮੁੱਖ ਪੇਜ ਲੋਡ ਹੋ ਰਹੇ ਹਨ, payments/login ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਲੌਗਜ਼ ਨਾਰਮਲ ਲੱਗ ਰਹੇ ਹਨ। automated smoke tests ਚਲਾਓ ਅਤੇ Green ਲਈ ਮਾਨੀਟਰੀੰਗ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਅਲਰਟ ਸੱਕਰੀਆ ਹਨ ਇਹ ਵੇਰਾਭ ਕਰੋ।

3) DB migrations ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਯੋਜਨਾ ਕਰੋ (expand/contract)

ਬਲੂ/ਗ੍ਰੀਨ 'ਚ DB ਬਦਲਾਅ ਮੁਸ਼ਕਲ ਹੁੰਦੇ ਹਨ। expand/contract ਤਰੀਕੇ ਵਰਤੋ:

• Expand: ਨਵੇਂ ਕਾਲਮ/ਟੇਬਲ ਪਿਛਲੇ ਕੋਡ ਨਾਲ ਕਾਂਪੈਟਿਬਲ ਤਰੀਕੇ ਨਾਲ ਜੋੜੋ।
• Green ਨੂੰ ਐਸਾ deploy ਕਰੋ ਕਿ ਉਹ ਪੁਰਾਣੀ ਅਤੇ ਨਵੀਂ schema ਦੋਹਾਂ ਨਾਲ ਕੰਮ ਕਰ ਸਕੇ।
• Contract: Blue ਰਿਟਾਇਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣੇ ਫੀਲਡ ਹਟਾਓ ਜਦ ਤੱਕ ਨਵਾਂ ਕੋਡ ਸਥਿਰ ਨਜ਼ਰ ਆਵੇ।

ਇਸ ਨਾਲ "Green ਚੰਗਾ ਹੈ ਪਰ Blue ਟੁੱਟ ਗਿਆ" ਵਾਲੀ ਸਥਿਤੀ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।

4) ਕੈਸ਼ ਵਾਰਮਿੰਗ ਅਤੇ background jobs ਸੰਭਾਲੋ

ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਤੋਂ ਪਹਿਲਾਂ ਖਾਸ ਕੈਸ਼ ਵਾਰਮ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ "cold start" ਦਾ ਖ਼ਰਚ ਨਾ ਭੁਗਤਣਾ ਪਏ।

ਬੈਕਗ੍ਰਾਊਂਡ ਨੌਕਰੀਆਂ/ਕ੍ਰੋਨ ਵਰਕਰਾਂ ਲਈ ਫੈਸਲਾ ਕਰੋ:

• ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਹੀ environment 'ਚ ਚਲਾਓ ਕਟਓਵਰ ਦੌਰਾਨ ਤਾਂ ਕਿ double-processing ਨਾ ਹੋਵੇ

5) ਟ੍ਰੈਫਿਕ ਸਵਿੱਚ ਕਰੋ, ਫਿਰ ਨਿਰੀਖਣ ਕਰੋ

Blue ਤੋਂ Green ਨੂੰ ਫਲਿਪ ਕਰੋ (load balancer/DNS/ingress)। error rate, latency ਅਤੇ ਬਿਜ਼ਨਸ ਮੈਟਰਿਕਸ ਇੱਕ ਛੋਟੇ ਵਿੰਡੋ ਦੌਰਾਨ ਦੇਖੋ।

6) ਪੋਸਟ-ਸਵਿੱਚ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਸਫਾਈ

ਰੀਅਲ ਯੂਜ਼ਰ-ਸਟਾਇਲ spot check ਕਰੋ, ਫਿਰ Blue ਨੂੰ ਬੈਕਅੱਪ ਵਜੋਂ ਕੁਝ ਸਮਾਂ ਲਈ ਰੱਖੋ। ਜੇ ਸਥਿਰ ਹੋਵੇ, Blue ਕੰਮ ਬੰਦ ਕਰੋ, ਲੌਗਸ ਆਰਕਾਈਵ ਕਰੋ ਅਤੇ Blue ਦੇ ਪ੍ਰੋਵੀਜਨ ਨੂੰ ਰੀਮੂਵ ਕਰਕੇ ਲਾਗਤ ਘਟਾਓ।

ਕੈਨੇਰੀ ਰੋਲਆਊਟ: ਵਰਤੋਂ-ਯੋਗ ਪਲੇਬੁਕ

ਕੈਨੇਰੀ ਰੋਲਆਊਟ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖਣ ਬਾਰੇ ਹੈ। ਨਵੇਂ ਵਰਜਨ ਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਦੇਖੋ, ਨਜ਼ਦੀਕੀ ਤੌਰ 'ਤੇ ਨਿਰੀਖਣ ਕਰੋ, ਫਿਰ ਹੀ ਵਧਾਓ। ਲਕਸ਼ ਇਹ ਨਹੀਂ "ਧੀਮੇ ਜਾਓ"—ਬਲਕਿ ਹਰ ਕਦਮ 'ਤੇ ਸਬੂਤ ਨਾਲ ਸੁਰੱਖਿਆ ਸਾਬਤ ਕਰੋ।

ਇੱਕ ਸਧਾਰਨ ਰੈਂਪ ਯੋਜਨਾ (1–5% → 25% → 50% → 100%)

1. ਕੈਨੇਰੀ ਤਿਆਰ ਕਰੋ

ਨਵਾਂ ਵਰਜਨ ਮੌਜੂਦਾ ਸਥਿਰ ਵਰਜਨ ਨਾਲ ਨਾਲ deploy ਕਰੋ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਹਰ ਵਰਜਨ ਲਈ ਨਿਰਧਾਰਿਤ ਪ੍ਰਤੀਸ਼ਤ ਟ੍ਰੈਫਿਕ ਰੂਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਦੋਹਾਂ ਵਰਜਨਾਂ ਨੂੰ ਮਾਨੀਟਰੀੰਗ ਵਿੱਚ ਵੱਖਰਾ ਵੇਖ ਸਕਦੇ ਹੋ।

2. ਸਟੇਜ 1: 1–5%

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

ਇਸ ਸਟੇਜ ਲਈ ਨੋਟ ਰੱਖੋ:

• ਇਸ ਰਿਲੀਜ਼ ਵਿੱਚ ਕੀ ਬਦਲਿਆ
• ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕੀਤੀ ਸੀ
• ਜੋ ਤੁਸੀਂ ਦੇਖਿਆ (errors, latency, user-impact)

3. ਸਟੇਜ 2: 25%

ਜੇ ਪਹਿਲਾ ਸਟੇਜ ਠੀਕ ਰਹੇ, ਤਾਂ ਲਗਭਗ ਇੱਕ ਚੌਥਾਈ ਟ੍ਰੈਫਿਕ ਤੱਕ ਵਧਾਓ। ਹੁਣ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰ ਬਿਹੇਵਿਅਰ, ਲੰਬੇ-ਟੇਲ ਡਿਵਾਈਸ, ਐਡਜ ਕੇਸ ਅਤੇ ਵੱਧ concurrency ਦੇਖੋਗੇ।

4. ਸਟੇਜ 3: 50%

ਅੱਧੀ ਟ੍ਰੈਫਿਕ ਉੱਥੇ ਬਣਨ 'ਤੇ capacity ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਵਧਕੇ ਸਾਫ਼ ਹੁੰਦੀਆਂ ਹਨ।

5. ਸਟੇਜ 4: 100% (promotion)

ਜਦੋਂ ਮੈਟ੍ਰਿਕਸ ਸਥਿਰ ਹੋਣ ਤੇ user-impact ਮਨੋਯੋਗ ਹੋਵੇ, ਸਾਰੀ ਟ੍ਰੈਫਿਕ ਨਵੀਂ ਵਰਜਨ ਤੇ ਸ਼ਿਫਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ promote ਘੋਸ਼ਿਤ ਕਰੋ।

ਰੈਂਪ ਇੰਟਰਵਲ ਚੁਣੋ (ਹਰ ਸਟੇਜ 'ਤੇ ਕਿੰਨਾ ਇੰਤਜ਼ਾਰ)

ਟਾਈਮ ਦੀ ਲੰਬਾਈ ਰਿਸਕ ਅਤੇ ਟਰੈਫਿਕ ਵਾਲੀਅਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:

• ਉੱਚ-ਰਿਸਕ ਜਾਂ ਘੱਟ ਟਰੈਫਿਕ: ਹਰ ਸਟੇਜ 'ਤੇ ਲੰਮਾ ਇੰਤਜ਼ਾਰ (ਉਦਾਹਰਨ 30–60 ਮਿੰਟ ਜਾਂ ਹੋਰ) ਤਾਂ ਕਿ ਕੁਝ ਸਿਗਨਲ ਆ ਸਕਣ। ਘੱਟ-ਟਰੈਫਿਕ ਸਰਵਿਸਾਂ ਨੂੰ ਮੈਟ੍ਰਿਕਸ ਵੇਖਣ ਲਈ ਕਈ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ।
• ਘੱਟ-ਰਿਸਕ ਅਤੇ ਉੱਚ-ਟਰੈਫਿਕ: ਛੋਟੀ ਮਿਆਦ (5–15 ਮਿੰਟ) ਠੀਕ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਡਾਟਾ ਜਲਦੀ ਮਿਲਦਾ ਹੈ।

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

ਪ੍ਰੋਮੋਸ਼ਨ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ

ਮੈਨੂਅਲ ਰੋਲਆਊਟ ਹੇਚਕਿਚਾਹਟ ਅਤੇ ਅਸੰਗਤਤਾ ਲਿਆਉਂਦੇ ਹਨ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਆਟੋਮੇਟ:

• ਪ੍ਰੋਮੋਟ ਕਰੋ ਜਦੋਂ ਕੁੰਜੀ ਮੈਟ੍ਰਿਕਸ ਠੀਕ ਰਹਿਣ ਦੀ ਇੱਕ ਪਰਿਭਾਸ਼ਤ ਖਿੜਕੀ ਲਈ ਰਹਿੰਦੀਆਂ ਹਨ
• ਰੋਲਬੈਕ ਕਰੋ ਜਦੋਂ ਥ੍ਰੇਸ਼ਹੋਲਡ ਉਲੰਘਣ ਹੁੰਦੇ ਹਨ

ਆਟੋਮੇਸ਼ਨ ਮਨੁੱਖੀ ਫੈਸਲੇ ਨਹੀਂ ਹਟਾਉਂਦੀ—ਇਹ ਦੇਰੀ ਹਟਾਂਦੀ ਹੈ।

ਹਰ ਸਟੇਜ ਨੂੰ ਇਕ ਪ੍ਰਯੋਗ ਵਾਂਗ ਮੰਨੋ

ਹਰ ramp ਕਦਮ ਲਈ ਲਿਖੋ:

• ਚੇਂਜ ਸਾਰ (ਕੀ ਵੱਖਰਾ ਹੈ)
• ਸਕਸੈਸ ਮਾਪਦੰਡ (ਕਿਹੜੇ ਮੈਟ੍ਰਿਕ ਸਥਿਰ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ)
• ਦੇਖਿਆ ਨਤੀਜਾ (ਕੀ ਦੇਖਿਆ ਗਿਆ)
• ਫੈਸਲਾ (ਪ੍ਰੋਮੋਟ, ਰੋਕੋ, ਜਾਂ ਰੋਲਬੈਕ) ਤੇ ਇੰਝ ਕਿਉਂ

ਇਹ ਨੋਟਸ ਤੁਹਾਡੇ ਰੋਲਆਊਟ ਇਤਿਹਾਸ ਨੂੰ ਅਗਲੇ ਰਿਲੀਜ਼ ਲਈ ਪਲੇਬੁਕ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਭਵਿੱਖੀ ਘਟਨਾਵਾਂ ਦਾ ਨਿਰਾਕਰਨ ਆਸਾਨ ਕਰਦੀਆਂ ਹਨ।

ਰੋਲਬੈਕ ਯੋਜਨਾਵਾਂ ਅਤੇ ਫੇਲ੍ਹਰ ਹੈਂਡਲਿੰਗ

ਰੋਲਬੈਕ ਤਦੋਂ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ "ਬੁਰਾ" ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ ਅਤੇ ਕੌਣ ਬਟਨ ਦਬਾ ਸਕਦਾ ਹੈ। ਰੋਲਬੈਕ ਪਲਾਨ ਨਿਰਾਸ਼ਾਵਾਦ ਨਹੀਂ—ਇਹ ਤਰੀਕਾ ਹੈ ਛੋਟੇ ਮੁੱਿਆਂ ਨੂੰ ਲੰਬੇ ਆਉਟੇਜ ਨਾਲੋਂ ਪਹਿਲਾਂ ਰੋਕਣ ਦਾ।

ਸਪਸ਼ਟ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ ਤੈਅ ਕਰੋ

ਛੋਟੀ ਸੂਚੀ ਚੁਣੋ ਅਤੇ ਨਿਰਧਾਰਤ ਥ੍ਰੇਸ਼ਹੋਲਡ ਰਖੋ ਤਾਂ ਕਿ ਘਟਨਾ ਦੌਰਾਨ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਨਾ ਹੋਵੇ। ਆਮ ਟ੍ਰिगਰ:

• error rate: 5xx ਵਾਲੀਆਂ ਗੜਬੜਾਂ, failed checkouts, login failures
• latency: p95/p99 ਇੱਕ ਮੰਨਿਆ ਹੋਇਆ ਸੀਮਾ ਤੋਂ ਉੱਤੇ ਰਹੇ ਲੰਬੇ ਸਮੇਂ ਲਈ
• ਬਿਜ਼ਨਸ KPI: conversion ਵਿੱਚ ਅਚਾਨਕ ਘਟ, payment success ਘਟ, sign-ups ਵਿੱਚ ਘਟ

ਟ੍ਰਿਗਰ ਮਾਪਯੋਗ ਹੋਣ ("p95 > 800ms for 10 minutes") ਅਤੇ ਇੱਕ ਮਾਲਕ ਨਾਲ ਜੁੜੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ (on-call, release manager) ਜਿਸਨੂੰ ਤੁਰੰਤ ਕਾਰਵਾਈ ਦੀ ਇਜਾਜ਼ਤ ਹੋਵੇ।

ਰੋਲਬੈਕ ਤੇਜ਼ (ਅਤੇ ਸਧਾਰਨ) ਰੱਖੋ

ਸਪੀਡ ਸੋਭਾਵਾਨੀ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਤੁਹਾਡਾ ਰੋਲਬੈਕ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਟ੍ਰੈਫਿਕ ਵਾਪਸ ਸਵਿੱਚ ਕਰੋ (ਬਲੂ/ਗ੍ਰੀਨ ਅਤੇ ਕੈਨੇਰੀ ਲਈ ਆਮ)
• ਪਿਛਲਾ ਸਥਿਰ ਵਰਜਨ ਰੀ-ਡਿਪਲੋਇ ਕਰੋ: ਜੇ ਇਨਫਰਾਸ਼ਟਰਕਚਰ ਬਦਲਾ ਹੋਇਆ, ਪਿਛਲਾ ਸਥਿਰ ਬਿਲਡ ਧੱਕੋ ਅਤੇ ਹੈਲਥ ਚੈੱਕ ਚਲਾਓ

"ਮੈਨੂਅਲ ਫਿਕਸ ਫਿਰ ਜਾਰੀ ਰੋਲਆਊਟ" ਨੂੰ ਪਹਿਲੀ ਚੋਣ ਨਾ ਬਣਾਓ। ਪਹਿਲਾਂ ਸਥਿਰ ਕਰੋ, ਫਿਰ ਜਾਂਚ ਕਰੋ।

ਹਿੱਸਕ-ਵਾਰ ਰੋਲਆਊਟ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

ਕੈਨੇਰੀ ਨਾਲ, ਕੁਝ ਯੂਜ਼ਰਾਂ ਨੇ ਨਵੀਂ ਵਰਜਨ 'ਤੇ ਡੇਟਾ ਬਣਾਇਆ ਹੋ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ:

• ਕੀ "ਕੈਨੇਰੀ" ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੁਰੰਤ ਵਾਪਸ ਰੁਟੀੰਗ ਕੀਤਾ ਜਾਵੇਗਾ ਜਾਂ ਉਹਨਾਂ ਨੂੰ canary ਤੇ ਰੱਖ ਕੇ ਅਸੈੱਸ ਕੀਤਾ ਜਾਵੇਗਾ?
• ਜੇ ਡੇਟਾ ਫਾਰਮੈਟ ਬਦਲੇ ਹਨ, ਡੇਟਾਬੇਸ ਪਿਛਲੇ ਵਰਜਨ ਨਾਲ ਕਾਂਪੈਟਿਬਲ ਹੈ? ਨਹੀਂ ਤਾਂ ਰੋਲਬੈਕ ਲਈ ਵੱਖਰੀ ਰਣਨੀਤੀ ਲੋੜੀਂਦੀ ਹੋ ਸਕਦੀ ਹੈ।

ਬਾਅਦ-ਕਾਰਵਾਈ ਸਮੀਖਿਆ (after-action) ਜੋ ਅਗਲੇ ਰਿਲੀਜ਼ ਨੂੰ ਸੁਧਾਰੇ

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

ਫੀਚਰ ਫਲੈਗਸ ਅਤੇ ਪ੍ਰੋਗਰੇਸਿਵ ਡਿਲਿਵਰੀ

ਫੀਚਰ ਫਲੈਗਸ ਤੁਹਾਨੂੰ deploy (ਕੋਡ production 'ਤੇ ਲਾਉਣ) ਅਤੇ release (ਉਹ ਲੋਕਾਂ ਲਈ ਚਲੂ ਕਰਨਾ) ਨੂੰ ਵੱਖਰਾ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਮੁੱਖ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਉਹੀ ਡਿਪਲੋਇਮੈਂਟ ਪਾਈਪਲਾਈਨ—ਬਲੂ/ਗ੍ਰੀਨ ਜਾਂ ਕੈਨੇਰੀ—ਵਰਤ ਕੇ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਸੁਇਚ ਨਾਲ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਬਿਨਾਂ ਦਬਾਅ ਦੇ deploy ਕਰੋ, ਨੀਅਤ ਨਾਲ release ਕਰੋ

ਫਲੈਗਸ ਨਾਲ ਤੁਸੀਂ ਮਰਜ ਅਤੇ ਡਿਪਲੋਇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ ਭਾਵੇਂ ਫੀਚਰ ਹਰੇਕ ਲਈ ਤਿਆਰ ਨਾ ਹੋਵੇ। ਕੋਡ ਮੌਜੂਦ ਹੈ ਪਰ ਅਰਾਮਕ ਹੈ। ਜਦੋਂ ਭਰੋਸਾ ਹੋਵੇ, ਫਲੈਗ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ enable ਕਰੋ—ਅਕਸਰ ਨਵੀਂ build ਪੁਸ਼ ਕਰਨ ਨਾਲੋਂ ਤੇਜ਼—ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ, ਫਲੈਗ ਨੂੰ ਬੰਦ ਕਰ ਕੇ ਤੁਰੰਤ ਰوکਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਨਿਸ਼ਾਨਾਬੰਦੀ (targeted enablement)

ਪਰੋਗਰੇਸਿਵ ਡਿਲਿਵਰੀ ਅਰਥ ਹੈ ਜੁੜਾਈ ਨੂੰ ਨਿਯਤ ਕਦਮਾਂ ਵਿੱਚ ਵਧਾਉਣਾ। ਫਲੈਗ enable ਹੋ ਸਕਦਾ ਹੈ:

• ਕਿਸੇ ਖਾਸ ਯੂਜ਼ਰ ਗਰੁੱਪ ਲਈ (ਅੰਦਰੂਨੀ ਸਟਾਫ, ਬੀਟਾ ਯੂਜ਼ਰ, ਭੁਗਤਾਨ ਟੀਅਰ)
• ਕਿਸੇ ਖੇਤਰ ਲਈ (ਇੱਕ ਦੇਸ਼ ਜਾਂ ਡੇਟਾ ਸੈਂਟਰ)
• ਯੂਜ਼ਰਾਂ ਦੇ ਪ੍ਰਤੀਸ਼ਤ ਲਈ (1% → 10% → 50% → 100%)

ਜੇਕਰ ਕੈਨੇਰੀ ਦੱਸਦਾ ਹੈ ਕਿ ਨਵੀਂ ਵਰਜਨ ਸਿਹਤਮੰਦ ਹੈ, ਪਰ ਤੁਸੀਂ ਫੀਚਰ-ਖਤਰੇ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸੰਭਾਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ।

"Flag debt" ਰੋਕਣ ਲਈ ਗਾਰਡਰੇਲਜ਼

ਫੀਚਰ ਫਲੈਗਪਾਵਰਫੁਲ ਹਨ ਪਰ ਸਹੀ ਗਵਰਨੈਂਸ ਲੋੜੀਂਦੀ ਹੈ:

• ਮਾਲਕੀ: ਹਰ ਫਲੈਗ ਦਾ ਇੱਕ ਜਵਾਬਦੇਹ ਟੀਮ ਜਾਂ ਵਿਅਕਤੀ ਹੋਵੇ
• ਮਿਆਦ: ਹਟਾਉਣ/ਸਮੀਖਿਆ ਦੀ ਤਾਰੀਖ ਰੱਖੋ ਤਾਂ ਪੁਰਾਣੇ ਫਲੈਗ ਇਕੱਠੇ ਨਾ ਹੋ ਜਾਣ
• ਦਸਤਾਵੇਜ਼ੀ: ਲਿਖੋ ਕਿ ਫਲੈਗ ਕੀ ਕਰਦਾ ਹੈ, ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਰੋਲਬੈਕ ਕਿਵੇਂ ਕੀਤਾ ਜਾਵੇ

ਪ੍ਰਯੋਗੀ ਨਿਯਮ: ਜੇ ਕੋਈ ਇਸਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ "ਇਹ ਬੰਦ ਕਰਨ 'ਤੇ ਕੀ ਹੁੰਦਾ?" ਤਾਂ ਫਲੈਗ ਤਿਆਰ ਨਹੀਂ ਹੈ।

For deeper guidance on using flags as part of a release strategy, see /blog/feature-flags-release-strategy.

ਤੁਹਾਡੀ ਰਣਨੀਤੀ ਕਿਵੇਂ ਚੁਣੀਏ ਅਤੇ ਸ਼ੁਰੂਆਤ ਕਿਵੇਂ ਕਰੋ

ਬਲੂ/ਗ੍ਰੀਨ ਤੇ ਕੈਨੇਰੀ ਵਿੱਚ ਚੋਣ "ਕਿਹੋ ਜਿਹਾ ਵਧੀਆ" ਨਹੀਂ—ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਕਿਸਮ ਦੇ ਜੋਖਮ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਟੀਮ ਅਤੇ ਟੂਲਿੰਗ ਨਾਲ ਹਕੀਕਤ 'ਚ ਕੀ ਚਲਾ ਸਕਦੇ ਹੋ।

ਇੱਕ ਤੇਜ਼ ਫੈਸਲਾ-ਰੂਪ

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

ਪ੍ਰਯੋਗੀ ਨਿਯਮ: ਉਸ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਰਾਤ 2 ਵਜੇ ਸਥਿਰਤਾ ਨਾਲ ਚਲਾ ਸਕੋ।

ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ ਪਾਇਲਟ

ਇੱਕ ਸਰਵਿਸ (ਜਾਂ ਇਕ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਵਰਕਫਲੋ) ਪਿਕ ਕਰੋ ਅਤੇ ਕੁਝ ਰਿਲੀਜ਼ਾਂ ਲਈ ਪਾਇਲਟ ਕਰੋ। ਉਹ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਪਰ ਬਹੁਤ ਜਰੂਰੀ ਨਾ ਕਿ ਹਰ ਕੋਈ ਹਿੱਲ ਜਾਏ। ਟੀਚਾ ਹੈ ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟਿੰਗ, ਮਾਨੀਟਰੀੰਗ, ਅਤੇ ਰੋਲਬੈਕ 'ਤੇ ਮਾਸਪੇਸ਼ੀ ਬਣਾਉਣਾ।

ਇੱਕ ਸਧਾਰਨ ਰਨਬੁੱਕ ਲਿਖੋ (ਅਤੇ ਬਦਲੀਦਾਰੀ ਨਿਰਧਾਰਤ ਕਰੋ)

ਇੱਕ ਪੰਨਾ ਕਾਫੀ ਹੈ:

• "ਚੰਗਾ" ਕੀ ਹੈ (ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਥ੍ਰੇਸ਼ਹੋਲਡ)
• ਰੋਲਆਊਟ ਦੌਰਾਨ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ
• ਰੋਕਣਾ, ਰੋਲਬੈਕ, ਅਤੇ ਸੰਚਾਰ ਕਿਵੇਂ ਹੋਵੇ

ਮਾਲਕ ਰੱਖੋ—ਇੱਕ ਰਣਨੀਤੀ ਬਿਨਾਂ ਮਾਲਕ ਇੱਕ ਸੁਝਾਵ ਹੀ ਰਹਿ ਜਾਂਦੀ ਹੈ।

ਪਹਿਲਾਂ ਉਹੀ ਉਪਯੋਗ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ

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

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਨਵੀਂ ਸਰਵਿਸ ਬਣਾਉਂਦੇ ਅਤੇ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਪਲੇਟਫਾਰਮز ਜੋ ਐਪ ਜਨਰੇਸ਼ਨ ਅਤੇ ਡਿਪਲੋਇ ਕੰਟਰੋਲ ਇਕੱਠੇ ਦਿੰਦੇ ਹਨ, ਆਪਰੇਸ਼ਨਲ ਮਿਹਨਤ ਘਟਾ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਇੰਟਰਨਫ਼ੇਸ ਤੋਂ ਵੈਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦਾ—ਅਤੇ ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਡਿਪਲੋਇ ਅਤੇ ਹੋਸਟ ਕਰਨ ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ practical safety features ਜਿਵੇਂ snapshots and rollback, custom domains, ਅਤੇ source code export ਦੀ ਸਮਰਥਾ ਹੈ। ਇਹ ਸੁਵਿਧਾਵਾਂ ਇਸ ਲੇਖ ਦੇ ਮੁੱਖ ਲਕਸ਼ ਨੂੰ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ: ਰਿਲੀਜ਼ ਨੂੰ ਰੀਪੀਟੇਬਲ, ਨਿਰੀਖਣਯੋਗ ਅਤੇ ਵਾਪਸ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ।

ਸੁਝਾਏਗੇ ਅਗਲੇ ਕਦਮ

ਜੇ ਤੁਸੀਂ ਨਿਰਦੇਸ਼ਕ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿਕਲਪ ਅਤੇ ਸਮਰਥਿਤ ਵਰਕਫਲੋਜ਼ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, review /pricing and /docs/deployments। ਫਿਰ ਆਪਣਾ ਪਹਿਲਾ ਪਾਇਲਟ ਰਿਲੀਜ਼ ਸ਼ਡਿਊਲ ਕਰੋ, ਜੋ ਚੰਗਾ ਚੱਲਿਆ ਉਸਨੂੰ ਕੈਪਚਰ ਕਰੋ, ਅਤੇ ਹਰ ਰੋਲਆਊਟ ਤੋਂ ਬਾਅਦ ਆਪਣੇ ਰਨਬੁੱਕ ਨੂੰ ਦੁਹਰਾਓ।