AI-ਨਿਰਮਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਕੀਮਾ ਬਦਲਾਅ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ: ਇੱਕ ਗਾਈਡ

AI-ਨਿਰਮਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ “ਸਕੀਮਾ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ

ਇੱਕ ਸਕੀਮਾ ਸਿੱਧਾ ਉਹ ਸਾਂਝਾ ਸਮਝੌਤਾ ਹੈ ਜੋ ਡੇਟਾ ਦੇ ਆਕਾਰ ਅਤੇ ਹਰੇਕ ਫੀਲਡ ਦਾ ਮਤਲਬ ਨੂੰ ਦਰਸਾਂਦਾ ਹੈ। AI-ਨਿਰਮਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ, ਇਹ ਸਮਝੌਤਾ ਕੇਵਲ ਡੇਟਾਬੇਸ ਟੇਬਲਾਂ ਵਿੱਚ ਹੀ ਨਹੀਂ ਬਣਦੀ—ਅਤੇ ਇਹ ਅਕਸਰ ਟੀਮਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀ ਹੈ।

ਸਕੀਮਾ ਸਿਰਫ ਡੇਟਾਬੇਸ ਦੀ ਚੀਜ਼ ਨਹੀਂ ਹੈ

ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਚਾਰ ਆਮ ਪਰਤਾਂ ਵਿੱਚ ਸਕੀਮਾਵਾਂ ਮਿਲਣਗੀਆਂ:

• ਡੇਟਾਬੇਸ: ਟੇਬਲ/ਕਾਲਮ ਨਾਮ, ਡੇਟਾ ਕਿਸਮਾਂ, ਪਾਬੰਦੀਆਂ, ਇੰਡੈਕਸ ਅਤੇ ਰਿਸ਼ਤੇ।
• APIs: request/response JSON ਦੀ ساخت, ਲੋੜੀਂਦੇ ਵਿਰੁੱਧ ਵਿਕਲਪਿਕ ਫੀਲਡ, enum, ਐਰਰ ਫਾਰਮੈਟ, pagination ਰਵਾਇਤਾਂ।
• ਇਵੈਂਟ ਅਤੇ ਸੁਨੇਹੇ: streams, queues ਅਤੇ webhooks ਰਾਹੀਂ ਭੇਜੇ ਜਾਣ ਵਾਲੇ ਪੇਲੋਡ (ਅਕਸਰ ਉਪਭੋਗੀਆਂ ਰਾਹੀਂ ਅਪਰੋਖਤ ਤੌਰ 'ਤੇ ਵਰਜ਼ਨ ਕੀਤੇ ਹੋਏ)।
• ਕੰਫਿਗ ਅਤੇ ਕਾਂਟਰੈਕਟ: feature flags, environment variables, YAML/JSON configs, ਅਤੇ “ਛੁਪੇ ਹੋਏ ਕਾਂਟਰੈਕਟ” ਜਿਵੇਂ ਫਾਈਲ ਫਾਰਮੈਟ ਅਤੇ ਨਾਂਕਰਨ ਰਵਾਇਤਾਂ।

ਜੇ ਸਿਸਟਮ ਦੇ ਦੋ ਹਿੱਸੇ ਡੇਟਾ ਦਾ ਐਦਲਾ-ਬੈਦਲਾ ਕਰਦੇ ਹਨ ਤਾਂ ਇੱਕ ਸਕੀਮਾ ਮੌਜੂਦ ਹੈ—ਚਾਹੇ ਕਿਸੇ ਨੇ ਇਸਨੂੰ ਲਿਖ ਕੇ ਨਾ ਦਿੱਤਾ ਹੋਵੇ।

ਕਿਉਂ AI-ਨਿਰਮਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਕੀਮਾ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ

AI-ਜਨਰੇਟਡ ਕੋਡ ਵਿਕਾਸ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ churn ਵੀ ਵਧਾਉਂਦਾ ਹੈ:

• ਜਨਰੇਟਡ ਕੋਡ ਆਖਰੀ ਪ੍ਰਾਂਪਟ ਅਤੇ ਸੰਦਰਭ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਛੋਟੇ ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ ਵੀ ਫੀਲਡ ਨਾਮ, ਨੈਸਟਿੰਗ, ਡੀਫੌਲਟ ਜਾਂ ਵੈਲਿਡੇਸ਼ਨ ਬਦਲ ਸਕਦੇ ਹਨ।
• ਜਦੋਂ ਨਵੀਂ endpoint ਜਾਂ pipeline ਕਦਮ ਸ਼ਿਪ ਕਰਨਾ ਸਸਤਾ ਹੋਵੇ ਤਾਂ ਲੋੜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ।
• ਗੈਰ-ਸੰਗਤ ਰੀਤੀ-ਰਿਵਾਜ (snake_case ਮੁਕਾਬਲੇ camelCase, id ਮੁਕਾਬਲੇ userId) ਉਹਨਾਂ ਸਮੇਂ ਉਭਰਦੇ ਹਨ ਜਦੋਂ ਵੱਖ-ਵੱਖ ਜਨਰੇਸ਼ਨਾਂ ਜਾਂ ਰਿਫੈਕਟਰਾਂ ਨੇ ਕੋਡ ਪਰਿਵਰਤਨ ਕੀਤੇ ਹੋਣ।

ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਉਤਪਾਦਕ ਅਤੇ ਉਪਭੋਗੀਆਂ ਦੇ ਵਿਚਕਾਰ “contract drift” ਵੱਧਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਗਾ ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਚੈਟ ਰਾਹੀਂ ਹੈਂਡਲਰ, DB ਐਕਸਸ ਲੇਅਰ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਜਨਰੇਟ ਕਰਨਾ), ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ ਹੈ ਕਿ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਉਸ ਵਰਕਫਲੋ ਵਿੱਚ ਸਕੀਮਾ ਅਨੁਸ਼ਾਸਨ ਠਹਿਰਾਇਆ ਜਾਵੇ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਨੂੰ React/Go/PostgreSQL ਅਤੇ Flutter ਐਪਾਂ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਜਨਰੇਟ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ—ਪਰ ਜਿੰਨਾ ਤੇਜ਼ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ, ਉਦੋਂ ਹੀ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕਰਨ, ਪੇਲੋਡਾਂ ਨੂੰ ਵੈਲਿਡੇਟ ਕਰਨ, ਅਤੇ ਬਦਲਾਅ ਦਿਲੀਰਟਲੀ ਰੋਲ ਆਉਟ ਕਰਨ ਦੀ ਮਹੱਤਤਾ ਵਧ ਜਾਂਦੀ ਹੈ।

ਇਸ ਗਾਈਡ ਦਾ ਮਕਸਦ

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

ਅਸੀਂ ਕੀ ਨਹੀਂ ਕਵਰ ਕਰਾਂਗੇ

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

AI-ਜਨਰੇਟਡ ਕੋਡ ਨਾਲ ਸਕੀਮਾ ਬਦਲਾਅ ਵੱਧ ਕਿਉਂ ਹੁੰਦੇ ਹਨ

AI-ਜਨਰੇਟਡ ਕੋਡ ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ “ਨਾਰਮਲ” ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ—ਕਿਉਂਕਿ ਇਨਪੁਟ ਜ਼ਿਆਦਾ ਵਾਰ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ ਐਪ ਭਾਗੀਦਾਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰਾਂਪਟ, ਮਾਡਲ ਵਰਜਨ, ਅਤੇ ਜਨਰੇਟ ਕੀਤੇ ਗਲੂ ਕੋਡ ਤੋਂ ਚਲਦਾ ਹੈ, ਤਾਂ ਡੇਟਾ ਦੇ ਆਕਾਰ ਵਿੱਚ ਸਮੇਂ ਦੇ ਨਾਲ ਡ੍ਰਿਫਟ ਹੋ ਸਕਦੀ ਹੈ।

ਆਮ ਟਿਗਰ ਜੋ ਤੁਸੀਂ ਅਮਲ ਵਿੱਚ ਵੇਖੋਗੇ

ਕੁਝ ਪੈਟਰਨ ਹਨ ਜੋ ਮੁੜ-ਮੁੜ ਸਕੀਮਾ churn ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ:

• ਨਵੀਆਂ ਪ੍ਰੋਡਕਟ ਫੀਚਰ: ਇਕ ਨਵਾਂ ਫੀਲਡ ਜੋੜਨਾ (ਉਦਾਹਰਨ ਲਈ risk_score, explanation, source_url) ਜਾਂ ਇੱਕ ਸੰਕਲਪ ਨੂੰ ਵੰਡਨਾ (ਉਦਾਹਰਨ ਲਈ address ਨੂੰ street, city, postal_code ਵਿੱਚ ਤੋੜਨਾ)।
• ਮਾਡਲ ਆਉਟਪੁੱਟ ਵਿੱਚ ਬਦਲਾਅ: ਨਵਾਂ ਮਾਡਲ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾ ਵਿਸਥਾਰਵਾਂ ਬਣਾਏ, ਵੱਖ-ਵੱਖ enum ਮੁੱਲ, ਜਾਂ ਹੌਲੀ-ਹੌਲੀ ਨਾਂਕਰਨ ਵਿੱਚ ਬਦਲਾਅ ਕਰੇ ("confidence" ਮੁਕਾਬਲੇ "score")।
• ਪ੍ਰਾਂਪਟ ਅਪਡੇਟ: ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਕੀਤੇ ਗਏ ਸੁਧਾਰ ਅਕਸਰ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਫਾਰਮੈਟਿੰਗ, ਲੋੜੀਂਦੇ ਫੀਲਡ, ਜਾਂ ਨੈਸਟਿੰਗ ਬਦਲ ਸਕਦੇ ਹਨ।

ਖਤਰਨਾਕ ਪੈਟਰਨ ਜੋ AI ਸਿਸਟਮਾਂ ਨੂੰ ਨਾਜ਼ੁਕ ਬਣਾਉਂਦੇ ਹਨ

AI-ਜਨਰੇਟਡ ਕੋਡ ਅਕਸਰ ਤੁਰੰਤ "ਚਲਦਾ" ਹੈ, ਪਰ ਇਹ ਨਾਜੁਕ ਅਨੁਮਾਨ ਕੈਪਸੂਲ ਕਰ ਸਕਦਾ ਹੈ:

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

ਕਿਉਂ AI ਬਦਲਾਅ ਦੀ ਆਵ੍ਰਿਤੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ

ਕੋਡ ਜਨਰੇਸ਼ਨ ਤੇਜ਼ ਇਤਰਾਟ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਹਰੇਕ ਵਾਰ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਹੈਂਡਲਰ, ਪਾਰਸਰ, ਅਤੇ ਡੇਟਾਬੇਸ ਐਕਸਸ ਲੇਅਰ ਨੂੰ ਰੀਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਗਤੀ ਲਾਭਦਾਇਕ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਛੋਟੇ ਇੰਟਰਫੇਸ ਬਦਲਾਅ ਅਕਸਰ ਬਿਨਾਂ ਨੋਟਿਸ ਦੇ ਰਿਲੀਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ।

ਸੁਰੱਖਿਅਤ ਸੋਚ ਇਹ ਹੈ ਕਿ ਹਰ ਸਕੀਮਾ ਨੂੰ ਇੱਕ ਕਾਂਟਰੈਕਟ ਵਾਂਗ ਸਮਝੋ: ਡੇਟਾਬੇਸ ਟੇਬਲ, API ਪੇਲੋਡ, ਇਵੈਂਟ, ਅਤੇ ਇੰਜਨ ਦੇ ਸੰਰਚਿਤ LLM ਉੱਤਰ — ਜੇ ਕੋਈ ਉਪਭੋਗੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, ਵੈਲਿਡੇਟ ਕਰੋ ਅਤੇ ਮਨ-ਹੋਸ਼ੀਅਰ ਤਰੀਕੇ ਨਾਲ ਬਦਲੋ।

ਸਕੀਮਾ ਬਦਲਾਅ ਦੇ ਪ੍ਰਕਾਰ: ਐਡੀਟਿਵ vs. ਬ੍ਰੇਕਿੰਗ

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

ਐਡੀਟਿਵ ਬਦਲਾਅ (ਅਕਸਰ ਸੁਰੱਖਿਅਤ)

ਐਡੀਟਿਵ ਬਦਲਾਅ ਮੌਜੂਦਾ ਮਤਲਬ ਨੂੰ ਫੈਲਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਮੌਜੂਦਾ ਮਤਲਬ ਨੂੰ ਬਦਲੇ।

ਆਮ ਡੇਟਾਬੇਸ ਉਦਾਹਰਣ:

• ਡਿਫੌਲਟ ਨਾਲ ਜਾਂ NULL ਮਨਜ਼ੂਰ ਕਰਕੇ ਕਾਲਮ ਜੋੜਨਾ (ਉਦਾਹਰਨ preferred_language)।
• ਨਵਾਂ ਟੇਬਲ ਜਾਂ ਇੰਡੈਕਸ ਜੋੜਨਾ।
• ਇੱਕ ਕਾਲਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ JSON ਬਲੱਬ ਵਿੱਚ ਇੱਕ ਵਿਕਲਪਿਕ ਫੀਲਡ ਜੋੜਨਾ।

ਗੈਰ-ਡੇਟਾਬੇਸ ਉਦਾਹਰਣ:

• API ਜਵਾਬ ਵਿੱਚ ਨਵਾਂ ਪ੍ਰਾਪਰਟੀ ਜੋੜੋ (ਕਲਾਇੰਟ ਜੋ ਅਣਜਾਣ ਫੀਲਡਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਉਹ ਕੰਮ ਜਾਰੀ ਰੱਖਦੇ ਹਨ)।
• ਸਟਰੀਮ/ਕਿਊ ਸੁਨੇਹੇ ਵਿੱਚ ਨਵਾਂ ਇਵੈਂਟ ਫੀਲਡ ਜੋੜੋ।
• ਨਵਾਂ ਫੀਚਰ ਫਲੈਗ ਮੁੱਲ ਜੋੜੋ ਜਦ ਤੱਕ ਮੌਜੂਦਾ ਬਿਹੇਵਅਰ ਡਿਫੌਲਟ ਵਜੋਂ ਰਿਹਾ।

ਐਡੀਟਿਵ ਸਿਰਫ਼ ਤਾਂ "ਸੁਰੱਖਿਅਤ" ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪੁਰਾਣੇ ਉਪਭੋਗੀ ਟੋਲਰੇਂਟ ਹੋਣ: ਉਹਨਾਂ ਨੂੰ ਅਣਜਾਣ ਫੀਲਡਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਨਵੀਆਂ ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ (ਖਤਰਨਾਕ)

ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ ਉਹ ਹਨ ਜੋ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਦਲਦੇ ਜਾਂ ਹਟਾਂਦੇ ਹਨ ਜਿਸ 'ਤੇ ਉਪਭੋਗੀ ਪਹਿਲਾਂ ਹੀ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

ਆਮ ਡੇਟਾਬੇਸ ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ:

• ਕਾਲਮ ਟਾਈਪ ਬਦਲਣਾ (string → integer, timestamp precision ਬਦਲਣਾ)।
• ਫੀਲਡ/ਕਾਲਮ ਦਾ ਨਾਮ ਬਦਲਨਾ (ਜੋ ਕੁਝ ਵੀ ਪੁਰਾਣਾ ਨਾਮ ਪੜ੍ਹ ਰਿਹਾ ਹੈ ਉਹ ਫੇਲ ਹੋ ਜਾਵੇਗਾ)।
• ਕਾਲਮ/ਟੇਬਲ ਡ੍ਰਾਪ ਕਰਨਾ ਜੋ ਅਜੇ ਵੀ query ਹੋ ਰਹੇ ਹਨ।

ਗੈਰ-ਡੇਟਾਬੇਸ ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ:

• JSON ਫੀਲਡਾਂ ਦਾ ਨਾਮ ਬਦਲਣਾ/ਹਟਾਉਣਾੋਂ।
• ਇਵੈਂਟ semantics ਬਦਲਣਾ (ਉਹੀ ਫੀਲਡ ਨਾਮ, ਵੱਖਰਾ ਮਤਲਬ)।
• webhook ਪੇਲੋਡ ਸਟ੍ਰਕਚਰ ਬਦਲਣਾ ਬਿਨਾਂ ਵਰਜ਼ਨ ਬੰਪ ਕੀਤੇ।

ਹਮੇਸ਼ਾਂ ਉਪਭੋਗੀ ਪ੍ਰਭਾਵ ਲਿਖੋ

ਮੈਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ:

• ਕੌਣ ਇਸਨੂੰ ਕਨਜ਼ਯੂਮ ਕਰਦਾ ਹੈ (ਸਰਵਿਸਾਂ, ਡੈਸ਼ਬੋਰਡ, ਡਾਟਾ ਪਾਈਪਲਾਈਨ, ਭਾਈ/ਸਾਥੀ)।
• ਕੰਪੈਟੀਬਿਲਟੀ (ਬੈਕਵਰਡ/ਫੋਰਵਰਡ, ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਲਈ)।
• ਫੇਲ ਚਾਲੂ ਹੋਣ ਦਾ ਢੰਗ (ਪਾਰਸਿੰਗ ਐਰਰ, ਚੁਪ ਚਾਪ ਡਾਟਾ ਕਰਪਸ਼ਨ, ਗਲਤ ਬਿਜ਼ਨਸ ਲਾਜਿਕ)।

ਇਹ ਛੋਟੀ "ਇਮਪੈਕਟ ਨੋਟ" ਸਪਸ਼ਟਤਾ ਮਜ਼ਬੂਤ ਕਰਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ AI-ਜਨਰੇਟਡ ਕੋਡ ਅਪਰੇਟਿਵ ਤੌਰ 'ਤੇ ਸਕੀਮਾ ਬਦਲਾਅ ਲਿਆਉਂਦਾ ਹੈ।

ਸਕੀਮਾ ਅਤੇ ਇੰਟਰਫੇਸ ਲਈ ਵਰਜ਼ਨਿੰਗ ਰਣਨੀਤੀਆਂ

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

ਸਾਦੇ-ਭਾਸ਼ਾ ਵਾਲੀ ਸੈਮਾਂਟਿਕ ਵਰਜ਼ਨਿੰਗ ਸੋਚ

Major / Minor / Patch ਦੇ ਵਿਚਾਰ ਵਿੱਚ ਸੋਚੋ, ਭਾਵੇਂ ਤੁਸੀਂ ਵਾਸਤਵ ਵਿੱਚ 1.2.3 ਪ੍ਰਕਾਸ਼ਤ ਨਾ ਕਰੋ:

• Major: ਬ੍ਰੇਕਿੰਗ ਚੇਨਜ। ਪੁਰਾਣੇ ਉਪਭੋਗੀ ਤਬਦੀਲੀ ਬਿਨਾਂ ਫੇਲ ਜਾਂ ਗਲਤ ਬਣ ਸਕਦੇ ਹਨ।
• Minor: ਸੁਰੱਖਿਅਤ ਐਡিশਨ। ਪੁਰਾਣੇ ਉਪਭੋਗੀ ਹਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ; ਨਵੇਂ ਉਪਭੋਗੀ ਨਵੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵਰਤ ਸਕਦੇ ਹਨ।
• Patch: ਬਗ ਫਿਕਸ ਜਾਂ ਸਪਸ਼ਟੀਕਰਨ ਜੋ ਮਤਲਬ ਨਹੀਂ ਬਦਲਦਾ।

ਇੱਕ ਸਾਦਾ ਨਿਯਮ ਜੋ ਟੀਮਾਂ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ: ਕੋਈ ਵੀ ਮੌਜੂਦਾ ਫੀਲਡ ਦਾ ਮਤਲਬ ਚੁਪਚਾਪ ਨਾ ਬਦਲੋ। ਜੇ status="active" ਪਹਿਲਾਂ "ਭੁਗਤਾਨ ਕਰਨ ਵਾਲਾ ਗਾਹਕ" ਮਤਲਬ ਦਿੰਦਾ ਸੀ, ਤਾਂ ਇਸਨੂੰ "account exists" ਲਈ ਮੁੜ-ਪਰਿਭਾਸ਼ਿਤ ਨਾ ਕਰੋ। ਨਵਾਂ ਫੀਲਡ ਜੋੜੋ ਜਾਂ ਨਵੀਂ ਵਰਜ਼ਨ ਬਣਾਓ।

ਵਰਜ਼ਨਡ endpoints ਮੁਕਾਬਲਾ ਵਰਜ਼ਨਡ ਫੀਲਡ

ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਪ੍ਰਾਯੋਗਿਕ ਚੋਣਾਂ ਹਨ:

1) Versioned endpoints (ਉਦਾਹਰਨ /api/v1/orders ਅਤੇ /api/v2/orders):

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

2) Versioned fields / additive evolution (ਉਦਾਹਰਨ, new_field ਜੋੜੋ, old_field ਰੱਖੋ):

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

ਇਵੈਂਟ ਸਕੀਮਾਂ ਅਤੇ ਰਜਿਸਟਰੀਜ਼

ਸਟ੍ਰੀਮ, ਕਿਊ, ਅਤੇ webhook ਲਈ, ਉਪਭੋਗੀ ਅਕਸਰ ਤੁਹਾਡੇ ਡਿਪਲੋਇਮੈਂਟ ਕੰਟਰੋਲ ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ। ਇੱਕ schema registry (ਜਾਂ ਕਿਸੇ ਕੇਂਦਰੀ ਸਕੀਮਾ ਕੈਟਾਲੌਗ ਨਾਲ ਕਨਪੈਟੀਬਿਲਟੀ ਚੈੱਕ) ਨਿਯਮ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜਿਵੇਂ "ਕੇਵਲ ਐਡੀਟਿਵ ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਹਨ" ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ ਕਿਹੜੇ ਪ੍ਰਭੁਤਾਂ ਅਤੇ ਉਪਭੋਗੀ ਕਿਸਿਸ਼ ਵਰਜ਼ਨ 'ਤੇ ਆਧਾਰਿਤ ਹਨ।

ਸੁਰੱਖਿਅਤ ਰੋਲਆਉਟ: Expand/Contract (ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ)

ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਸਰਵਿਸਾਂ, ਜੌਬਸ, ਅਤੇ AI-ਜਨਰੇਟਡ ਕੰਪੋਨੈਂਟ ਹਨ—ਉਹ ਹੈ expand → backfill → switch → contract ਪੈਟਰਨ। ਇਹ downtime ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ "ਸਾਰੇ-ਜਾਂ-ਕੁਝ-ਨਹੀਂ" ਡਿਪਲੋਇਮੈਂਟ ਤੋਂ ਬਚਾਉਂਦਾ ਜਿੱਥੇ ਇੱਕ ਦੇਰ ਨਾਲ ਅਪਡੇਟ ਹੋਇਆ ਉਪਭੋਗੀ ਪ੍ਰੋਡਕਸ਼ਨ ਟੁੱਟਦਾ ਹੈ।

ਚਾਰ ਕਦਮ (ਅਤੇ ਇਹ ਕਿਉਂ ਕੰਮ ਕਰਦੇ ਹਨ)

1) Expand: ਨਵਾਂ ਸਕੀਮਾ ਇੱਕ ਬੈਕਵਰਡ-ਕਾਂਪੈਟੀਬਿਲ ਬਹੁਲਤਰੀਕੇ ਨਾਲ ਪੇਸ਼ ਕਰੋ। ਮੌਜੂਦਾ ਰੀਡਰ ਅਤੇ ਰਾਈਟਰ ਬੇਹੱਦ ਬਦਲਾਅ ਦੇ ਬਗੈਰ ਕੰਮ ਜਾਰੀ ਰੱਖਣੇ ਚਾਹੀਦੇ ਹਨ।

2) Backfill: ਇਤਿਹਾਸਕ ਡਾਟੇ ਲਈ ਨਵੇਂ ਫੀਲਡ ਭਰੋ (ਜਾਂ ਸੁਨੇਹਿਆਂ ਨੂੰਰੀਪ੍ਰੋਸੈਸ ਕਰੋ) ਤਾਂ ਕਿ ਸਿਸਟਮ ਸੰਗਤ ਹੋ ਜਾਵੇ।

3) Switch: ਰਾਈਟਰ ਅਤੇ ਰੀਡਰ ਨੂੰ ਨਵੇਂ ਫੀਲਡ/ਫਾਰਮੈਟ ਨੂੰ ਵਰਤਣ ਲਈ ਅਪਡੇਟ ਕਰੋ। ਇਹ ਕੈਨਰੀ, ਪਰਤੀਸ਼ਤ ਰੋਲਆਉਟ ਆਦਿ ਰਾਹੀਂ تدريجي ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਸਕੀਮਾ ਦੋਹਾਂ ਨੂੰ ਸਹਾਰਦਾ ਹੈ।

4) Contract: ਪੁਰਾਣੇ ਫੀਲਡ/ਫਾਰਮੈਟ ਨੂੰ ਹਟਾਓ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਜਦੋਂ ਤੁਸੀਂ ਯਕੀਨ ਹੋ ਜਾਵੋ ਕਿ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੀ ਪਰਭਾਵਿਤ ਨਿਰਭਰਤਾ ਨਹੀਂ ਰਹੀ।

ਦੋ-ਚਰਨ (expand → switch) ਅਤੇ ਤਿੰਨ-ਚਰਨ (expand → backfill → switch) ਰੋਲਆਉਟ downtime ਘਟਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਟਾਈਟ coupling ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ: ਰਾਈਟਰ ਪਹਿਲਾਂ ਸਕਦਾ ਹੈ, ਰੀਡਰ ਬਾਅਦ ਵਿੱਚ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੰਝ ਵੀ ਵਿਕਲਪਿਕ ਹੈ।

ਉਦਾਹਰਨ: ਇੱਕ ਕਾਲਮ ਜੋੜੋ, ਬੈਕਫਿਲ ਕਰੋ, ਫਿਰ ਉਦੋਂ ਬਹਿਰਾ ਬਣਾਓ

ਮੰਨੀਏ ਤੁਸੀਂ customer_tier ਜੋੜਣਾ ਚਾਹੁੰਦੇ ਹੋ।

• Expand: customer_tier ਨੂੰ nullable ਦੇ ਤੌਰ 'ਤੇ ਜੋੜੋ ਅਤੇ ਡਿਫੌਲਟ NULL ਰੱਖੋ।
• Backfill: ਮੌਜੂਦਾ ਰੋਜ਼ ਲਈ tiers ਗਣਨਾ ਕਰਨ ਲਈ ਇੱਕ ਜੌਬ ਚਲਾਓ।
• Switch: ਐਪ ਅਤੇ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਹਮੇਸ਼ਾ customer_tier ਲਿਖਣ ਲਈ ਅਪਡੇਟ ਕਰੋ, ਅਤੇ ਰੀਡਰ ਨੂੰ ਇਸਨੂੰ ਤਰਜੀਹ ਦੇਣ ਲਈ ਅਪਡੇਟ ਕਰੋ।
• Contract: ਮਾਨੀਟਰਿੰਗ ਤੋਂ ਬਾਅਦ, ਇਸਨੂੰ NOT NULL ਬਣਾਓ (ਅਤੇ ਐਚ-ਓਪਸ਼ਨਲ ਵਰਕਰੋ_logic ਨੂੰ ਹਟਾਓ)।

ਸਹਯੋਗ: ਰਾਈਟਰ ਅਤੇ ਰੀਡਰ ਇਕਮਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ

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

ਡੇਟਾਬੇਸ ਮਾਈਗਰੇਸ਼ਨ: ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਟੁੱਟੇ ਬਿਨਾਂ ਡੇਟਾ ਕਿਵੇਂ ਬਦਲਣਾ

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

ਮਾਈਗਰੇਸ਼ਨ ਫਾਈਲਾਂ vs. ਆਟੋ-ਮਾਈਗਰੇਸ਼ਨ

ਮਾਈਗਰੇਸ਼ਨ ਫਾਈਲਾਂ (source control ਵਿੱਚ ਚੈੱਕ ਕੀਤੀਆਂ) ਅਜਿਹੇ ਵਰਣਨਾਤਮਕ ਕਦਮ ਹਨ ਜਿਵੇਂ "ਕਾਲਮ X ਜੋੜੋ," "ਇੰਡੈਕਸ Y ਬਣਾਓ," ਜਾਂ "A ਤੋਂ B ਵਿੱਚ ਡਾਟਾ ਨਕਲ ਕਰੋ।" ਉਹ ਆਡੀਟੇਬਲ, ਰਿਵਿਊਯੋਗ, ਅਤੇ ਸਟੇਜਿੰਗ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਦੁਬਾਰਾ ਚਲਾਏ ਜਾ ਸਕਦੇ ਹਨ।

ਆਟੋ-ਮਾਈਗਰੇਸ਼ਨ (ORM/framework ਦੁਆਰਾ ਜਨਰੇਟ ਕੀਤੀ) ਸ਼ੁਰੂਆਤੀ ਵਿਕਾਸ ਅਤੇ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹਨ, ਪਰ ਉਹ ਖਤਰਨਾਕ ਓਪਰੇਸ਼ਨਾਂ (ਕਾਲਮ ਡ੍ਰਾਪ ਕਰਨਾ, ਟੇਬਲ ਦੁਬਾਰਾ ਬਣਾਉਣਾ) ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ ਜਾਂ ਬਦਲਾਅ ਨੂੰ ਵੱਖ-ਵੱਖ ਕ੍ਰਮ ਵਿੱਚ ਕਰ ਸਕਦੇ ਹਨ।

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

ਆਈਡੈਂਪੋਟੈਂਸੀ ਅਤੇ ਆਰਡਰਿੰਗ

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

ਹਰ ਪਰਿਵੇਸ਼ (ਲੋਕਲ, CI, ਸਟੇਜਿੰਗ, ਪ੍ਰੋਡ) ਨੂੰ ਉਹੀ ਮਾਈਗਰੇਸ਼ਨ ਲੜੀ ਲਾਗੂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਮੈਨੂਅਲ SQL ਨਾਲ "ਠੀਕ" ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਸਨੂੰ ਮਾਈਗਰੇਸ਼ਨ ਵਿੱਚ ਬੰਦ ਨਾ ਕਰ ਲਓ।

ਲੌਂ-ਰਨਿੰਗ ਮਾਈਗਰੇਸ਼ਨ ਬਿਨਾਂ ਟੇਬਲ ਲੌਕ ਕੀਤੇ

ਕੁਝ ਸਕੀਮਾ ਬਦਲਾਅ ਵੱਡੀ ਟੇਬਲ ਨੂੰ ਲੌਕ ਕਰਨ 'ਤੇ ਲਿਖਣ (ਅਥਵਾ ਪੜ੍ਹਨ) ਨੂੰ ਬੰਦ ਕਰ ਸਕਦੇ ਹਨ। ਖ਼ਤਰੇ ਨੂੰ ਘਟਾਉਣ ਦੇ ਕੁਝ ਉੱਚ-ਸਤਹ ਤਰੀਕੇ:

• ਆਪਣੇ ਡેટਾਬੇਸ ਦੁਆਰਾ ਸਮਰਥਿਤ online/lock-minimizing operations ਵਰਤੋ (ਜਿਵੇਂ concurrent index builds)।
• ਬਦਲਾਅ ਨੂੰ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡੋ: ਨਵੀਂ ਸਟਰੱਕਚਰ ਪਹਿਲਾਂ ਜੋੜੋ, ਬੈਚਾਂ ਵਿੱਚ ਬੈਕਫਿਲ ਕਰੋ, ਫਿਰ ਐਪ ਸਵਿੱਚ ਕਰੋ।
• ਭਾਰੀ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਘਟੇ-ਟ੍ਰੈਫਿਕ ਵਿੰਡੋਜ਼ ਦੌਰਾਨ ਸ਼ੈਡਿਊਲ ਕਰੋ, ਸਮੇਂ-ਸੀਮਾਂ ਅਤੇ ਮੋਨਿਟਰਿੰਗ ਦੇ ਨਾਲ।

ਮਲਟੀ-ਟੈਨੈਂਟ ਅਤੇ ਸ਼ਾਰਡਡ ਸੈਟਅਪ

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

ਬੈਕਫਿਲ ਅਤੇ ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ: ਮੌਜੂਦਾ ਡਾਟਾ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ

Backfill ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਨਵੇਂ ਜੋੜੇ ਗਏ ਫੀਲਡਾਂ (ਜਾਂ ਸਹੀ ਕੀਤੇ ਮੁੱਲ) ਨੂੰ ਮੌਜੂਦਾ ਰਿਕਾਰਡਾਂ ਲਈ ਪੂਰਾ ਕਰਦੇ ਹੋ। Reprocessing ਉਹ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਤਿਹਾਸਕ ਡਾਟਾ ਨੂੰ ਫਿਰ ਤੋਂ pipeline ਰਾਹੀਂ ਚਲਾਉਂਦੇ ਹੋ—ਅਕਸਰ ਕਿਉਂਕਿ ਬਿਜ਼ਨਸ ਨਿਯਮ ਬਦਲੇ, ਬੱਗ ਠੀਕ ਕੀਤਾ ਗਿਆ, ਜਾਂ ਮਾਡਲ/ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਅਪਡੇਟ ਹੋਇਆ।

ਦੋਹਾਂ ਸਕੀਮਾ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਆਮ ਹਨ: ਨਵਾਂ ਆਕਾਰ ਸਿਰਫ਼ "ਨਵੇਂ ਡਾਟਾ" ਲਈ ਲਿਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਵੀ ਕਲਕਲ ਕੇ ਪਿਛਲੇ ਡੇਟੇ ਨਾਲ ਸੰਗਤ ਹੋਣ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ।

ਆਮ ਤਰੀਕੇ

ਆਨਲਾਈਨ ਬੈਕਫਿਲ (ਪ੍ਰੋਡ ਵਿੱਚ, تدريجي). ਤੁਸੀਂ ਇੱਕ ਨਿਯੰਤਰਿਤ ਜੌਬ ਚਲਾਉਂਦੇ ਹੋ ਜੋ ਛੋਟੇ ਬੈਚਾਂ ਵਿੱਚ ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਿਸਟਮ ਜਿਊ ਜ्यों ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ ਸੇਵਾਵਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਲੋਡ ਨੂੰ ਥਰਾਟਲ, ਰੋਕ, ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ।

ਬੈਚ ਬੈਕਫਿਲ (ਆਫਲਾਈਨ ਜਾਂ ਸ਼ੈਡਿਊਲ ਕੀਤੇ ਜੌਬ)। ਤੁਸੀਂ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਘੱਟ-ਟ੍ਰੈਫਿਕ ਵਿੰਡੋਜ਼ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹੋ। ਇਹ ਓਪਰੇਸ਼ਨਲੀ ਸਧਾਰਨ ਹੈ, ਪਰ ਡੇਟਾਬੇਸ ਲੋਡ ਵਿੱਚ spike ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਗਲਤੀਆਂ ਤੋਂ ਬਹਾਲੀ ਲਈ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਗ ਸਕਦਾ ਹੈ।

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

ਅਮਲ ਵਿੱਚ, ਟੀਮਾਂ ਅਕਸਰ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਵਟ ਕਰਦੀਆਂ ਹਨ: ਲੰਬੇ-ਪੂਛਲੇ ਰਿਕਾਰਡ ਲਈ lazy backfill, ਅਤੇ ਬਹੁਤ accessed ਡੈਟਾ ਲਈ ਇੱਕ ਆਨਲਾਈਨ ਜੌਬ।

ਬੈਕਫਿਲ ਨੂੰ ਕਿਵੇਂ ਵੈਰੀਫਾਈ ਕਰਨਾ

ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਪਸ਼ਟ ਅਤੇ ਮਾਪਨੀਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਕਾਉਂਟਸ: ਕਿੰਨੇ rows/events ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ ਬਨਾਮ ਕਿੰਨੇ ਅਪਡੇਟ ਹੋਏ।
• ਚੈਕਸਮ/ਏਗਰੀਗੇਟਸ: ਕੁੱਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ amounts ਦਾ ਜੋੜ, distinct IDs) ਪਹਿਲਾਂ/ਬਾਅਦ।
• ਸੈਂਪਲਿੰਗ: ਇਕ ਸਕੱਤਰਤਮਕ ਮਹੱਤਵਪੂਰਕ ਸੈਂਪਲ ਦੀ ਸਪੌਟ-ਚੈੱਕ, ਜਿਸ ਵਿੱਚ ਐਜ ਕੇਸਾਂ ਸ਼ਾਮਿਲ ਹੋਣ।

ਡਾਊਨਸਟ੍ਰੀਮ ਪ੍ਰਭਾਵਾਂ ਦੀ ਵੀ ਵੈਰਿਫਿਕੇਸ਼ਨ ਕਰੋ: ਡੈਸ਼ਬੋਰਡ, ਖੋਜ ਇੰਡੈਕਸ, ਕੈਸ਼, ਅਤੇ ਕੋਈ ਵੀ exports ਜੋ ਅਪਡੇਟ ਕੀਤੇ ਗਏ ਫੀλਡਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ।

ਲਾਗਤ, ਸਮਾਂ, ਅਤੇ ਸਵੀਕਾਰਤਾ ਮਾਪਦੰਡ

ਬੈਕਫਿਲ ਤੇਜ਼ੀ (ਤੇਜ਼ ਖਤਮ ਹੋਣਾ) ਨੂੰ ਖ਼ਤਰੇ ਅਤੇ ਲਾਗਤ (ਲੋਡ, ਕੰਪਿਊਟ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਝੰਜਟ) ਦੇ ਨਾਲ ਤਬਦੀਲ ਕਰਦਾ ਹੈ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਵੀਕਾਰਤਾ ਮਾਪਦੰਡ ਰੱਖੋ: "ਹੋ ਜਾਣਾ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਉਮੀਦ ਕੀਤੀ ਰਨਟਾਈਮ, ਵੱਧਤਮ ਮਨਜ਼ੂਰ ਕੀਤੀ ਗਲਤੀ ਦਰ, ਅਤੇ ਜੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋਏ ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ (ਰੋਕਣਾ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼, ਜਾਂ ਰੋਲਬੈਕ)।

ਇਵੈਂਟ ਅਤੇ ਸੁਨੇਹਾ ਸਕੀਮਾ ਵਿਕਾਸ (ਸਟਰੀਮ, ਕਿਊ, webhook)

ਸਕੀਮਾ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦੇ। ਜਦੋਂ ਇੱਕ ਸਿਸਟਮ ਦੂਜੇ ਨੂੰ ਡੇਟਾ ਭੇਜਦਾ ਹੈ—Kafka topics, SQS/RabbitMQ queues, webhook payloads, ਇੱਥੋਂ ਤੱਕ ਕਿ object storage 'ਤੇ ਲਿਖੇ "ਇਵੈਂਟ"—ਤੁਸੀਂ ਇੱਕ ਕਾਂਟਰੈਕਟ ਬਣਾਉਂਦੇ ਹੋ। ਪ੍ਰੋਡਿਊਸਰ ਅਤੇ ਕਨਜ਼ਯੂਮਰ ਆਜ਼ਾਦੀ ਨਾਲ ਵਿਖੇਲਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਕਾਂਟਰੈਕਟ ਜ਼ਿਆਦਾ ਅਕਸਰ ਟੁੱਟਦੇ ਹਨ।

ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ: ਇਵੈਂਟਾਂ ਨੂੰ ਬੈਕਵਰਡ-ਕਾਂਪੈਟੀਬਲੀ ਢੰਗ ਨਾਲ ਵਿਕਸਤ ਕਰੋ

ਇਵੈਂਟ ਸਟਰੀਮ ਅਤੇ webhook payloads ਲਈ, ਵਰਜ਼ਨ ਰਹਿਤ ਤਰੀਕਾ ਜੇਹੜਾ ਪੁਰਾਣੇ ਉਪਭੋਗੀਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਯੋਗ ਹੋਵੇ ਅਤੇ ਨਵੇਂ ਉਪਭੋਗੀਆਂ ਇਸਨੂੰ ਅਪਣਾਲੈਂ।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਨਿਯਮ: ਫੀਲਡ ਜੋੜੋ, ਹਟਾਓ ਨਾ ਜਾਂ ਨਾਂ ਬਦਲੋ। ਜੇ ਤੁਹਾਨੂੰ ਡੀਪ੍ਰੇਕੇਟ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਸਮਾਂ ਲਈ ਉਹ ਭੇਜਦੇ ਰਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਡੀਪ੍ਰੇਕੇਟ ਕੀਤੇ ਹੋਏ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ।

ਉਦਾਹਰਨ: OrderCreated ਇਵੈਂਟ ਵਿੱਚ ਵਿਕਲਪਿਕ ਫੀਲਡ ਜੋੜੋ।

{
  "event_type": "OrderCreated",
  "order_id": "o_123",
  "created_at": "2025-12-01T10:00:00Z",
  "currency": "USD",
  "discount_code": "WELCOME10"
}

ਪੁਰਾਣੇ ਉਪਭੋਗੀ order_id ਅਤੇ created_at ਨੂੰ ਪੜ੍ਹਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਂਦੇ ਹਨ।

ਉਪਭੋਗੀ-ਚਲਿਤ ਕਾਂਟਰੈਕਟ (ਸਧਾਰਨ-ਭਾਸ਼ਾ)

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

"ਅਣਜਾਣ ਫੀਲਡ" ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣਾ

ਪਾਰਸਰਾਂ ਨੂੰ tolerant ਬਣਾਓ:

• ਅਣਜਾਣ ਫੀਲਡਾਂ ਨੂੰ ਸਧਾਰਨ ਰੂਪ ਵਿੱਚ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ (ਨਵਾਂ ਕੀ ਆਉਣ 'ਤੇ ਫੇਲ ਨਾ ਕਰੋ)।
• ਨਵੀਆਂ ਫੀਲਡਾਂ ਨੂੰ ਵਿਕਲਪਿਕ ਮੰਨੋ ਜਦ ਤੱਕ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਹੀਂ।
• ਅਣਉਮੀਦਤ ਫੀਲਡਾਂ ਨੂੰ ਹਲਕੇ ਲੇਵਲ 'ਤੇ ਲਾਗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅਪਣਾਲਣ ਸਮੱਸਿਆਵਾਂ ਨੂੰ paging ਕੀਤੇ ਬਿਨਾਂ ਦੇਖ ਸਕੋ।

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

AI ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕ ਸਕੀਮਾ ਵਜੋਂ ਦੇਖਣਾ: ਪ੍ਰਾਂਪਟ, ਮਾਡਲ, ਅਤੇ ਸਟਰੱਕਚਰਡ ਰਿਸਪਾਂਸ

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

ਸਪਸ਼ਟ ਸਟਰੱਕਚਰ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤਾ ਕਰੋ (ਅਤੇ ਇਸਦੀ ਵੈਲਿਡੇਸ਼ਨ ਕਰੋ)

"ਸੁੰਦਰ ਟੈਕਸਟ" ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੀ ਥਾਂ, ਸੰਰਚਿਤ ਆਉਟਪੁੱਟ ਮੰਗੋ (ਆਮ ਤੌਰ 'ਤੇ JSON) ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਸਟਮ ਦੇ ਬਾਕੀ ਹਿੱਸਿਆਂ ਵਿੱਚ ਪੂਰਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੈਲਿਡੇਟ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ contract ਵੱਲ ਵਧਣਾ ਸੋਚੋ।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਾ:

• ਮਾਡਲ ਰਿਸਪਾਂਸ ਲਈ ਇੱਕ JSON schema (ਜਾਂ typed interface) ਪਰਿਭਾਸ਼ਤ ਕਰੋ।
• ਅਵੈਧ ਰਿਸਪਾਂਸ ਨੂੰ ਰਿਜੈਕਟ ਜਾਂ隔离 ਕਰੋ (ਉਨ੍ਹਾਂ ਨੂੰ ਗੁਪਤ ਤੌਰ 'ਤੇ ਬਦਲਣਾ ਨਾ ਕਰੋ)।
• ਵੈਲਿਡੇਸ਼ਨ ਐਰਰਾਂ ਨੂੰ ਲਾਗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ।

ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਜਰੂਰੀ ਹੈ ਜਦੋਂ LLM ਉੱਤਰ ਡਾਟਾ ਪਾਈਪਲਾਈਨ, ਆਟੋਮੇਸ਼ਨ, ਜਾਂ ਯੂਜ਼ਰ-ਸਮੁਖ ਸਮੱਗਰੀ ਨੂੰ ਭਰਦੇ ਹਨ।

ਮਾਡਲ ਡ੍ਰਿਫਟ ਲਈ ਯੋਜਨਾ ਬਣਾਓ

ਉਸੇ ਪ੍ਰਾਂਪਟ ਦੇ ਨਾਲ ਵੀ, ਆਉਟਪੁੱਟ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ: ਫੀਲਡ ਛੱਡੇ ਜਾ ਸਕਦੇ ਹਨ, ਵਾਧੂ ਕੁੰਜੀਆਂ ਆ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਸਮਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ ("42" vs 42, arrays vs strings)। ਇਹਨਾਂ ਨੂੰ ਸਕੀਮਾ ਵਿਕਾਸ ਘਟਨਾਵਾਂ ਵਜੋਂ ਸਲਾਹ-ਸਮਝੋ।

ਚੰਗੇ ਨਿਵਾਰਕ:

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

ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ ਨੂੰ API ਬਦਲਾਅ ਵਾਂਗ ਸਮਝੋ

ਇੱਕ ਪ੍ਰਾਂਪਟ ਇੱਕ ਇੰਟਰਫੇਸ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸੋਧਦੇ ਹੋ, ਤਾਂ ਇਸ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ। prompt_v1, prompt_v2 ਰੱਖੋ, ਅਤੇ ਮਨਝੂਰ ਕਰਨ ਲਈ ਗ੍ਰੈਜੂਅਲ ਰੋਲਆਉਟ (feature flags, canaries, ਜਾਂ ਪ੍ਰਤੀ-ਟੈਨੈਂਟ ਟੌਗਲ) ਵਰਤੋ। ਬਦਲਾਅ ਨੂੰ ਪ੍ਰੋਮੋਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ fixed evaluation set ਨਾਲ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਉਪਭੋਗੀਆਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਤੱਕ ਪੁਰਾਣੀਆਂ ਵਰਜ਼ਨਾਂ ਨੂੰ ਚਲਾਉ। ਸੇਫ ਰੋਲਆਉਟ ਮੈਕੈਨਿਕਾਂ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਆਪਣਾ ਅਪ੍ਰੋਚ "safe-rollouts-expand-contract" ਨਾਲ ਜੋੜੋ।

ਸਕੀਮਾ ਬਦਲਾਅ ਲਈ ਟੈਸਟਿੰਗ ਅਤੇ ਵੈਲਿਡੇਸ਼ਨ

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

ਟੈਸਟਾਂ ਦੇ ਤਿੰਨ ਪੱਧਰ (ਅਤੇ ਹਰੇਕ ਕੀ ਪਕੜਦਾ ਹੈ)

ਯੂਨਿਟ ਟੈਸਟ ਲੋਕਲ ਲਾਜਿਕ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ: mapping ਫੰਕਸ਼ਨ, serializers/deserializers, validators, ਅਤੇ query builders। ਜੇ ਇੱਕ ਫੀਲਡ ਨੂੰ Rename ਕੀਤਾ ਜਾਂ ਕਿਸਮ ਬਦਲੀ ਹੈ, ਤਾਂ ਯੂਨਿਟ ਟੈਸਟ ਉਸ ਕੋਡ ਦੇ ਨੇੜੇ ਫੇਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਅਪਡੇਟ ਦੀ ਲੋੜ ਹੈ।

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

ਐਂਡ-ਟੂ-ਐਂਡ ਟੈਸਟ ਉਪਭੋਗੀ ਜਾਂ ਵਰਕਫਲੋ ਨਤੀਜੇ ਸਿਮੁਲੇਟ ਕਰਦੇ ਹਨ ਸੇਵਾ-ਸਮੂਹਾਂ 'ਚ: ਡੇਟਾ ਬਣਾਓ, ਇਸਨੂੰ ਮਾਈਗਰੇਟ ਕਰੋ, APIs ਰਾਹੀਂ ਵਾਪਸ ਪੜ੍ਹੋ, ਅਤੇ ਵੇਰੋ ਕਿ ਡਾਊਨਸਟ੍ਰੀਮ ਉਪਭੋਗੀ ਅਜੇ ਵੀ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਰਹੇ ਹਨ।

ਪ੍ਰੋਡਿਊਸਰ ਅਤੇ ਕਨਜ਼ਯੂਮਰ ਲਈ ਕਾਂਟਰੈਕਟ ਟੈਸਟ

ਸਕੀਮਾ ਵਿਕਾਸ ਅਕਸਰ ਸੀਮਾਵਾਂ 'ਤੇ ਟੁੱਟਦਾ ਹੈ: ਸੇਵਾ-ਤੋਂ-ਸੇਵਾ APIs, ਸਟਰੀਮ, ਕਿਊ, ਅਤੇ webhook। ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ contract tests ਜੋੜੋ:

• ਪ੍ਰੋਡਿਊਸਰ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹ ਇੱਕ ਸਹਿਮਤ ਕਾਂਟਰੈਕਟ ਨੂੰ ਮਿਲਦੇ-ਜੁਲਦੇ events/responses ਜਾਰੀ ਕਰ ਸਕਦੇ ਹਨ।
• ਕਨਜ਼ਯੂਮਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ rollout ਦੌਰਾਨ ਉਹ ਦੋਹਾਂ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਵਰਜ਼ਨਾਂ ਨੂੰ ਪੜ੍ਹ ਸਕਦੇ ਹਨ।

ਮਾਈਗਰੇਸ਼ਨ ਟੈਸਟਿੰਗ: ਤਾਜ਼ਾ ਮਾਹੌਲਾਂ 'ਤੇ apply ਅਤੇ rollback

ਮਾਈਗਰੇਸ਼ਨਾਂ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜਿਵੇਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਡਿਪਲੋਇ ਕਰਨਗੇ:

• ਇੱਕ ਸਾਫ਼ ਡੇਟਾਬੇਸ snapshot ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।
• ਸਾਰੀਆਂ ਮਾਈਗਰੇਸ਼ਨਾਂ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਕਰੋ।
• ਯਕੀਨ ਕਰੋ ਕਿ ਐਪ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦੀ ਹੈ।
• ਇੱਕ rollback (ਜੇ ਸਮਰਥਿਤ ਹੋ) ਚਲਾਓ ਜਾਂ "down" ਮਾਈਗਰੇਸ਼ਨ ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਹਾਲਤ 'ਚ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ।

ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਸਕੀਮਾ ਵਰਜਨਾਂ ਲਈ ਫਿਕਸਚਰ

ਇੱਕ ਛੋਟੀ ਫਿਕਸਚਰ ਸੈਟ ਰੱਖੋ ਜੋ ਪ੍ਰਤਿਬਿੰਬ ਕਰੇ:

• ਪੁਰਾਣੇ ਸਕੀਮਾ ਤਹਿਤ ਲਿਖਿਆ ਡੇਟਾ (legacy rows/events)।
• ਨਵੇਂ ਸਕੀਮਾ ਹੇਠਾਂ ਲਿਖਿਆ ਡੇਟਾ।

ਏਹ ਫਿਕਸਚਰ ਰਿਗ੍ਰੈਸ਼ਨਸ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ AI-ਜਨਰੇਟਡ ਕੋਡ ਨਰਮਾ ਨੂੰ ਛੋਟੇ ਤਰੀਕੇ ਨਾਲ ਬਦਲਦਾ ਹੈ (ਫੀਲਡ ਨਾਂ, ਵਿਕਲਪਿਕਤਾ, ਜਾਂ ਫਾਰਮੈਟ)।

ਮਾਨੀਟਰੇਬਿਲਿਟੀ: ਛੇਤੀ ਤੌਰ 'ਤੇ ਟੁੱਟਣ ਨੂੰ ਪਤਾ ਲਗਾਉਣਾ

ਸਕੀਮਾ ਬਦਲਾਅ ਆਮ ਤੌਰ 'ਤੇdeploy ਦੇ ਤੇਜ਼ ਸਮੇਂ 'ਤੇ ਜ਼ੋਰ ਨਾਲ ਫੇਲ ਨਹੀਂ ਹੁੰਦੇ। ਜ਼ਿਆਦातर ਵਾਰ, ਟੁਟਣ parsing errors, "ਅਣਜਾਣ ਫੀਲਡ" ਦੀਆਂ ਚੇਤਾਵਨੀਆਂ, ਗਾਇਬ ਡਾਟਾ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਸ ਦੇ ਪਿੱਛੇ ਰਹਿਣ ਨਾਲ ਉੱਭਰਦਾ ਹੈ। ਚੰਗੀ ਮਾਨੀਟਰੇਬਿਲਿਟੀ ਉਹਨਾਂ ਕੰਨਾਂਸਾਂ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਫੀਡਬੈਕ ਵਿੱਚ بدل ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਰੋਲਆਉਟ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ।

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

ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ (ਐਪ ਹੈਲਥ) ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਸਕੀਮਾ-ਖ਼ਾਸ ਸਿਗਨਲ ਸ਼ਾਮਲ ਕਰੋ:

• ਐਰਰ: 4xx/5xx ਵਿੱਚ spike, ਪਰ ਨਾਲ ਹੀ "ਸੋਫਟ" ਐਰਰ ਜਿਵੇਂ JSON parsing ਫੇਲ, deserialization ਫੇਲ, ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼।
• ਲੇਟਨਸੀ: p95/p99 ਰਿਸਪਾਂਸ ਟਾਈਮ ਅਤੇ ਕਿਊ ਪ੍ਰੋਸੈਸਿੰਗ ਟਾਈਮ। ਸਕੀਮਾ ਬਦਲਾਅ ਜੋੜ, ਵੱਡੇ ਪੇਲੋਡ, ਜਾਂ ਵਧੀਕ ਵੈਲਿਡੇਸ਼ਨ ਲਿਆ ਸਕਦਾ ਹੈ।
• ਡਾਟਾ ਕਵਾਲਟੀ ਸਕੀਨਲ: ਮਹੱਤਵਪੂਰਨ ਕਾਲਮਾਂ ਵਿੱਚ null-rate ਵਧਣਾ, ਇਵੈਂਟ ਵਾਲੀਅਮ ਵਿੱਚ ਅਚਾਨਕ ਘਟੋਤਰੀ, ਬਹੁਤ ਵਾਰ ਨਵੀਂ "ਡਿਫੌਲਟ" ਵੈਲਿਊਜ਼ ਦਾ ਆਉਣਾ, ਜਾਂ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਪ੍ਰਸਤੁਤੀ ਵਿੱਚ ਅਸਮਾਨਤਾ।
• ਪਾਈਪਲਾਈਨ ਲੈਗ: ਸਟ੍ਰੀਮ/ਕਿਊ ਵਿੱਚ ਉਪਭੋਗੀ ਲੈਗ, webhook ਡਿਲਿਵਰੀ ਬੈਕਲੌਗ, ਅਤੇ ਮਾਈਗਰੇਸ਼ਨ ਜੌਬ throughput।

ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ vs. ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਕਲਾਇੰਟ ਵਰਜ਼ਨ, ਸਕੀਮਾ ਵਰਜ਼ਨ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਸੇਗਮੈਂਟ (ਕੈਨਰੀ vs. ਸਟੇਬਲ) ਦੇ ਅਧਾਰ 'ਤੇ ਸਲਾਈਸ ਕਰੋ।

ਐਸੇ ਡੈਸ਼ਬੋਰਡ ਜੋ ਵਰਗੇ ਮਦਦ ਕਰਦੇ ਹਨ

ਦੋ ਡੈਸ਼ਬੋਰਡ ਵਿਊ ਬਣਾਓ:

1. ਐਪਲੀਕੇਸ਼ਨ ਬਿਹੇਵਅਰ ਡੈਸ਼ਬੋਰਡ

   • Request rate, error rate, latency (RED)
   • ਟੌਪ exceptions (message ਦੁਆਰਾ ਗਰੂਪ ਕੀਤੇ ਹੋਏ)
   • Validation/parsing error count ਅਤੇ ਪ੍ਰਤੀਸ਼ਤ
   • Payload size distribution (ਅਕਸਮਾਤ ਵੱਡੇ ਮੈਸੇਜ ਫੜਨ ਲਈ)

2. ਮਾਈਗਰੇਸ਼ਨ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਡੈਸ਼ਬੋਰਡ

   • ਮਾਈਗਰੇਸ਼ਨ ਜੌਬ ਪ੍ਰਗਤੀ (% complete), rows processed/sec, ETA
   • ਫੇਲਯੂਰ ਦਰ ਅਤੇ ਰੀਟ੍ਰਾਈ ਗਿਣਤੀ
   • ਕਿਊ ਡੈਥ / ਉਪਭੋਗੀ ਲੈਗ
   • ਡੈਡ-ਲੈਟਰ ਕਿਊ ਵਾਲੀਅਮ (ਜੇ ਲਾਗੂ ਹੋਵੇ)

ਜੇ ਤੁਸੀਂ expand/contract ਰੋਲਆਉਟ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਕ ਪੈਨਲ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਪੁਰਾਣੇ vs. ਨਵੇਂ ਸਕੀਮਾ ਦੁਆਰਾ ਪੜ੍ਹਾਈ/ਲਿਖਾਈ ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਦੋਂ ਅਗਲੇ ਚਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋ।

ਸਕੀਮਾ-ਖ਼ਾਸ ਫੇਲਯੂਰ ਲਈ ਅਲਰਟ

ਉਹ ਚੀਜ਼ਾਂ 'ਤੇ ਪੇਜ ਕਰੋ ਜੋ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਡਾਟਾ ਡ੍ਰਾਪ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਗਲਤ ਪੜ੍ਹਿਆ ਜਾ ਰਿਹਾ ਹੈ:

• ਸਕ੍ਰਮਾ ਵੈਲਿਡੇਸ਼ਨ ਐਰਰ ਦਰ ਇੱਕ ਨੀਵੇਂ ਥਰੈਸ਼ਹੋਲਡ ਤੋਂ ਉੱਪਰ ਹੋਵੇ (ਅਕਸਰ <0.1% ਵੀ ਮਾਇਨੇਸ਼ਫਲ ਹੁੰਦਾ ਹੈ)
• ਪਾਰਸਿੰਗ/ਡੇਸਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਫੇਲਯੂਰ (ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਜੇ ਇੱਕ ਹੀ ਪ੍ਰੋਡਿਊਸਰ/ਕਨਜ਼ਯੂਮਰ ਵਿੱਚ ਘੱਟ ਕੇਂਦਰਿਤ ਹੋ)
• ਅਣਜਾਣ ਫੀਲਡ / ਲੋੜੀਂਦੇ ਫੀਲਡ ਗੈਰਮੌਜੂਦਗੀ ਵਾਲੀਆਂ ਚੇਤਾਵਨੀਆਂ ਜੋ ਵਧ ਰਹੀਆਂ ਹਨ
• ਮਾਈਗਰੇਸ਼ਨ ਜੌਬ ਰੁਕਿਆ ਹੋਇਆ (N ਮਿੰਟ ਲਈ ਕੋਈ ਪ੍ਰਗਤੀ ਨਹੀਂ) ਜਾਂ ਲੈਗ ਉਤਪੱਨ ਹੋ ਰਿਹਾ ਹੈ (ਥਰੂਪੁੱਟ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਘਟ ਰਿਹਾ)

ਕੱਚੇ 500s 'ਤੇ ਨੌਇਜ਼ੀ ਅਲਰਟ ਤੋਂ ਬਚੋ; ਅਲਰਟ ਨੂੰ ਸਕੀਮਾ ਰੋਲਆਉਟ ਨਾਲ ਜੋੜੋ ਜਿਵੇਂ schema version ਅਤੇ endpoint ਵਰਗੇ ਟੈਗਾਂ ਨਾਲ।

ਡਿਬੱਗ ਤੇਜ਼ੀ ਲਈ ਵਰਜ਼ਨ ਲਾਗ ਕਰੋ

ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਦੌਰਾਨ, ਲਾਗ ਵਿੱਚ ਸ਼ਾਮਲ ਅਤੇ ਲਿਖੋ:

• ਸਕੀਮਾ ਵਰਜ਼ਨ (ਉਦਾਹਰਨ X-Schema-Version ਹੈਡਰ, ਮੈਸੇਜ ਮੈਟਾਡੇਟਾ ਫੀਲਡ)
• ਪ੍ਰੋਡਿਊਸਰ ਅਤੇ ਕਨਜ਼ਯੂਮਰ ਐਪ ਵਰਜ਼ਨ
• ਮਾਡਲ ਵਰਜ਼ਨ / ਪ੍ਰਾਂਪਟ ਵਰਜ਼ਨ ਜਦੋਂ AI-ਜਨਰੇਟਡ ਆਉਟਪੁੱਟ ਸਟਰੱਕਚਰਡ ਡੇਟਾ ਨੂੰ ਭਰਦਾ ਹੈ

ਇੱਕੋ ਡੀਟੇਲ ਇਹ ਹੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ "ਇਸ ਪੇਲੋਡ ਨੇ ਫੇਲ ਕਿਉਂ ਕੀਤਾ?" ਦਾ ਜਵਾਬ ਮਿੰਟਾਂ ਵਿੱਚ ਮਿਲ ਸਕੇ, ਨਾ ਕਿ ਦਿਨਾਂ ਵਿੱਚ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਵੱਖ-ਵੱਖ ਸਰਵਿਸਾਂ (ਜਾਂ ਵੱਖ-ਵੱਖ AI ਮਾਡਲ ਵਰਜ਼ਨਾਂ) ਇਕੱਠੇ ਲਾਈਵ ਹੋਣ।

ਰੋਲਬੈਕ, ਰਿਕਵਰੀ, ਅਤੇ ਚੇਂਜ ਮੈਨੇਜਮੈਂਟ

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

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

ਵਰਤੋਂਯੋਗ ਰੋਲਬੈਕ ਵਿਕਲਪ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ

ਫੀਚਰ ਫਲੈਗ/ਕੰਫਿਗ ਗੇਟ: ਨਵੇਂ ਰੀਡਰ, ਰਾਈਟਰ, ਅਤੇ API ਫੀਲਡਾਂ ਨੂੰ ਇੱਕ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਨਵਾਂ ਬਿਹੇਵਅਰ ਬਿਨਾਂ redeploy ਕੀਤੇ ਬੰਦ ਕਰ ਸਕੋ। ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਵਧੀਆ ਹੈ ਜਦੋਂ AI-ਜਨਰੇਟਡ ਕੋਡ ਵਰਤਊ ਅਨੁਭਵ ਤੌਰ 'ਤੇ ਸਹੀ ਹੋ ਪਰ semantics ਤੌਰ 'ਤੇ ਗਲਤ ਹੋ।

ਡੁਅਲ-ਰਾਈਟ ਨੂੰ ਅਣ-ਸਕੋਗ ਕਰੋ: ਜੇ ਤੁਸੀਂ expand/contract ਰੋਲਆਉਟ ਦੌਰਾਨ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਸਕੀਮਾ ਦੋਹਾਂ 'ਤੇ ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ kill switch ਰੱਖੋ। ਨਵੇਂ ਲਿਖਣ ਵਾਲਾ ਪਾਥ ਬੰਦ ਕਰਨਾ ਹੋਰ divergence ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ।

ਰੀਡਰਾਂ ਨੂੰ ਵਾਪਸ ਘੁਮਾਓ (ਸਿਰਫ ਰਾਈਟਰ ਨਹੀਂ): ਬਹੁਤ ਸੀਆਂ ਘਟਨਾਵਾਂ ਇਸ ਲਈ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਪਭੋਗੀ ਨਵੇਂ ਫੀਲਡ ਜਾਂ ਨਵੇਂ ਟੇਬਲ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ। ਸਰਵਿਸਾਂ ਨੂੰ ਪਿੱਛਲੇ ਸਕੀਮਾ ਵਰਜ਼ਨ ਦੀਆਂ ਪੜ੍ਹਨੀਆਂ 'ਤੇ ਵਾਪਸ ਕਰਨ ਜਾਂ ਨਵੀਂ ਫੀਲਡਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਆਸਾਨ ਬਣਾਓ।

ਵਾਪਸੀਯੋਗਤਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਜਾਣੋ

ਕੁਝ ਮਾਈਗਰੇਸ਼ਨਾਂ ਨੂੰ ਸਾਫ਼-ਸੁਥਰਾ ਤਰੀਕੇ ਨਾਲ ਵਾਪਸ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ:

• ਵਿਨਾਸ਼ਕ ਤਬਦੀਲੀਆਂ (ਜਿਵੇਂ hashing, lossy normalization)।
• ਬਿਨਾਂ ਸੰਰਖਿਅਤ ਕਾਪੀ ਦੇ ਡ੍ਰਾਪ/ਰੀਨੇਮ।
• ਬੈਕਫਿਲ ਜੋ "ਸਰੋਤ-ਸਚਾਈ" ਮੁੱਲਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਦਿੰਦਾ ਹੈ।

ਇਹਨਾਂ ਲਈ, ਬੈਕਅੱਪ-ਤੋਂ-ਰਿਸਟੋਰ, ਇਵੈਂਟ ਤੋਂ ਰੀਪਲੇ, ਜਾਂ ਰਾਅ ਇਨਪੁਟਾਂ ਤੋਂ ਮੁੜ-ਗਣਨਾ ਦੀ ਯੋਜਨਾ ਬਣਾਓ—ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਉਹ ਇਨਪੁਟ ਹाली ਹੀ ਉਪਲਬਧ ਹਨ।

ਪ੍ਰੀ-ਫਲਾਈਟ ਚੈਕਲਿਸਟ (ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ)

• ਰੋਲਬੈਕ ਫੈਸਲਾ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਹੋਇਆ ("revert," "forward fix," ਜਾਂ "no rollback + restore path")।
• ਸਪਸ਼ਟ stop ਬਟਨ: ਫਲੈਗ ਅਤੇ/ਜਾਂ ਡੁਅਲ-ਰਾਈਟ disable switch।
• ਬੈਕਅੱਪ/ਸਨੇਪਸ਼ੌਟ ਯਕੀਨੀ; restore ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰੀ ਟੈਸਟ ਕੀਤਾ ਹੋਇਆ।
• ਮਾਈਗਰੇਸ਼ਨ ਆਈਡੈਂਪੋਟੈਂਟ ਹੈ; ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਡਾਟਾ ਨੂੰ ਖਰਾਬ ਨਹੀਂ ਕਰੇਗਾ।
• ਮਾਨੀਟਰੀਂਗ ਅਤੇ ਅਲਰਟਸ ਐਰਰ ਰੇਟ, ਸਕੀਮਾ ਵੈਲਿਡੇਸ਼ਨ ਫੇਲਯੂਰ, ਅਤੇ ਲੈਗ ਲਈ।
• ਜ਼ਿੰਮੇਵਾਰੀ: ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਕੌਣ ਚਲਾਂਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਰੋਲਆਉਟ ਦੌਰਾਨ on-call ਹੈ।

ਚੰਗੀ ਚੇਂਜ ਮੈਨੇਜਮੈਂਟ ਰੋਲਬੈਕ ਨੂੰ ਕਦਰ ਹੈ ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਭੁੱਲ-ਭੁੱਲਕੇ ਹੀ ਬਣਾ ਦਿੰਦੀ ਹੈ।

ਜੇ ਤੁਹਾਡੀ ਟੀਮ AI-ਸਹਾਇਤ ਵਿਕਾਸ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰਾਟ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਇਹ ਅਭਿਆਸ ਉਹਨਾਂ ਟੂਲਿੰਗ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਜੋ ਸੁਰੱਖਿਅਤ ਪ੍ਰਯੋਗ ਨੂੰ ਸਹਾਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਵਿੱਚ planning mode upfront change design ਲਈ ਅਤੇ snapshots/rollback ਤੇਜ਼ ਬਹਾਲੀ ਲਈ ਹਨ ਜਦੋਂ ਜਨਰੇਟ ਕੀਤਾ ਗਿਆ ਬਦਲਾਅ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਇੱਕ ਕਾਂਟਰੈਕਟ ਨੂੰ ਹਿਲਾਉਂਦਾ ਹੈ। ਤੇਜ਼ ਕੋਡ ਜਨਰੇਸ਼ਨ ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਸਕੀਮਾ ਵਿਕਾਸ ਨੂੰ ਇਕੱਠੇ ਵਰਤ ਕੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਟੈਸਟਿੰਗ ਵਾਤਾਵਰਣ ਵਾਂਗ ਮੰਨਣ ਦੇ।