ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਿਲੀਜ਼ਨਾਂ ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ, ਤैनਾਤੀਆਂ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ ਅਤੇ ਟੀਮ ਵਿੱਚ ਘਫ਼ਲ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਜਾਣੋ ਕਿ ਇਹ ਕਿਵੇਂ ਰੁਕਾਵਟ ਬਣਦੇ ਹਨ ਅਤੇ ਸਕੀਮਾ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰਨੇ ਹਨ।
ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਉਹ ਕੋਈ ਵੀ ਬਦਲਾਅ ਹੈ ਜੋ ਤੁਸੀਂ ਡੇਟਾਬੇਸ 'ਤੇ ਲਗਾਉਂਦੇ ਹੋ ਤਾਂ ਜੋ ਐਪ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅੱਗੇ ਵਧੇ। ਇਸ ਵਿੱਚ ਅਕਸਰ ਸਕੀਮਾ ਬਦਲਾਅ (ਟੇਬਲ, ਕਾਲਮ, ਇੰਡੇਕਸ, constraint ਬਣਾਉਣਾ ਜਾਂ ਬਦਲਣਾ) ਅਤੇ ਕਈ ਵਾਰ ਡਾਟਾ ਬਦਲਾਅ (ਨਵਾਂ ਕਾਲਮ ਭਰਨਾ, ਮੁੱਲ ਤਬਦੀਲ ਕਰਨਾ, ਡਾਟਾ ਨਵੀਂ ਸਰਚਨਾ ਵਿੱਚ ਮੁੜ-ਟਰਾਂਸਫਰ) ਸ਼ਾਮਿਲ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਇਹ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਕੋਡ ਨਾਲੋਂ ਵੱਧ ਵੇਲਾ ਲੈਣ ਲੱਗਦੀ ਹੈ। ਫੀਚਰ ਤਿਆਰ ਹੋ ਸਕਦਾ ਹੈ, ਟੈਸਟ ਗ੍ਰੀਨ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ CI/CD ਚੱਲ ਰਿਹਾ ਹੋਵੇ—ਪਰ ਟੀਮ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੰਡੋ, DBA ਰਿਵਿਊ, ਲੰਬਾ ਸਕ੍ਰਿਪਟ ਜਾਂ “ਪੀਕ ਸਮੇਂ ਦੌਰਾਨ deploy ਨਾ ਕਰੋ” ਨਿਯਮ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੁੰਦੀ ਹੈ। ਰਿਲੀਜ਼ ਇਸ ਲਈ ਬਲੌਕ ਨਹੀਂ ਹੈ ਕਿ ਇੰਜੀਨੀਅਰ ਬਣਾਉਣ ਨਹੀਂ ਪਾ ਰਹੇ—ਪ੍ਰਸ਼ਨ ਇਹ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਬਦਲਣਾ ਖਤਰਨਾਕ, ਧੀਮਾ ਜਾਂ ਅਣਪੇਸ਼ਨਾਦਿੱਕ ਲੱਗਦਾ ਹੈ।
ਆਮ ਨਮੂਨੇ:
ਇਹ ਥਿਊਰੀ ਤੇ ਲੈਕਚਰ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਇਹ ਦਲੀਲ ਹੈ ਕਿ “ਡੇਟਾਬੇਸ ਖਰਾਬ ਹਨ।” ਇਹ ਕਾਰਜਕਾਰੀ ਗਾਈਡ ਹੈ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨ friction ਕਿਉਂ ਪੈਦਾ ਕਰਦੇ ਹਨ ਅਤੇ ਤੇਜ਼-ਚਲਦੇ ਟੀਮਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਘੱਟ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਤੁਹਾਨੂੰ ਖਾਸ ਕਾਰਨ (ਲਾਕਿੰਗ ਵਿਹਾਰ, ਬੈਕਫਿੱਲ, ਅਸੰਗਤ ਐਪ/ਸਕੀਮਾ ਵਰਜ਼ਨ) ਅਤੇ ਕਾਰਗਰ ਸੁਧਾਰ (expand/contract ਪੈਟਰਨ, ਸੁਰੱਖਿਅਤ roll-forward, ਆਟੋਮੇਸ਼ਨ, ਗਾਰਡਰੇਲ) ਦਿੱਤੇ ਜਾਣਗੇ।
ਇਹ ਉਹਨਾਂ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਲਈ ਹੈ ਜੋ ਅਕਸਰ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ—ਹਫਤਾਵਾਰੀ, ਦਿਨਾਂ ਵਿੱਚ ਜਾਂ ਇੱਕੋ ਦਿਨ ਵਿੱਚ ਕਈ ਵਾਰੀ—ਜਿੱਥੇ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਪ੍ਰਕਿਰਿਆ ਆਧੁਨਿਕ ਰਿਲੀਜ਼ ਉਮੀਦਾਂ ਨਾਲ ਗਤੀ ਰੱਖਨੀ ਚਾਹੀਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਡਿਪਲੋਇ ਨੂੰ ਉੱਤੇ-ਦਬਾਅ ਵਾਲੀ ਘਟਨਾ ਬਣਾਉਣ ਦੇ।
ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ “ਅਸੀਂ ਫੀਚਰ ਮੁਕੰਮਲ ਕੀਤਾ” ਅਤੇ “ਯੂਜ਼ਰ ਇਸਨੂੰ ਫ਼ਾਇਦਾ ਲੈ ਸਕਦੇ ਹਨ” ਦੇ ਦਰਮਿਆਨ ਆਉਂਦੀ ਹੈ। ਇੱਕ ਆਮ ਫਲੋ ਇਹ ਹੈ:
Code change → migration → deploy → verify.
ਇਹ ਲਕੀਰਵਾਰ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਅਕਸਰ ਇਹੀ ਹੁੰਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਅਕਸਰ ਕਈ ਫੀਚਰਾਂ ਲਈ ਪੈਰਲੇਲ ਬਣਕੇ, ਟੈਸਟ ਹੋਕੇ ਅਤੇ ਪੈਕੇਜ ਹੋਕੇ ਤਿਆਰ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਡੇਟਾਬੇਸ ਇੱਕ ਸਾਂਝਾ ਸਰੋਤ ਹੈ ਜਿਸ 'ਤੇ ਲਗਭਗ ਹਰ ਸਰਵਿਸ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਦਮ ਕੰਮ ਨੂੰ ਸਿਰੀਅਲਾਈਜ਼ ਕਰਦਾ ਹੈ।
ਤੇਜ਼ ਟੀਮਾਂ ਵੀ ਨਿਮਨ ਚੋੱਕ ਪਾਇੰਟਾਂ ਨੂੰ ਛੂਹਦੀਆਂ ਹਨ:
ਜਦੋਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਟੇਜ ਸਲੋ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪਿੱਛੇ ਵਾਲਾ ਸਾਰਾ ਕੰਮ—ਦੂਜੇ PRs, ਦੂਜੇ ਰਿਲੀਜ਼, ਦੂਜੇ ਟੀਮ—ਰੁਕ ਜਾਂਦੇ ਹਨ।
ਐਪ ਕੋਡ ਨੂੰ feature flags ਦੇ ਪਿੱਛੇ deploy ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਹੌਲੀ-ਹੌਲੀ ਰੋਲਆਊਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਸਰਵਿਸ ਦੇ ਅਨੁਸਾਰ ਅਜ਼ਾਦ ਰੀਲੀਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਸਕੀਮਾ ਬਦਲਾਅ ਸਾਂਝੇ ਟੇਬਲਾਂ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਡਾਟਾ ਨੂੰ ਛੂਹਦਾ ਹੈ। ਦੋ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜੇਕਰ ਇਕੋ ਹੀ ਹੌਟ ਟੇਬਲ 'ਤੇ ਤਬਦੀਲੀਆਂ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਉਹ ਇੱਕੋ ਸਮੇਂ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਨਹੀਂ ਚੱਲ ਸਕਦੀਆਂ, ਅਤੇ ਅਣਸੰਬੰਧਿਤ ਬਦਲਾਅ ਵੀ ਸਰੋਤਾਂ (CPU, I/O, ਲਾਕ) ਲਈ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡੀ ਛੁਪੀ ਲਾਗਤ ਰਿਲੀਜ਼ ਕੈਡੈਂਸ ਹੈ। ਇੱਕ ਹੀ ਧੀਮੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੈਨੀਕ ਰਿਲੀਜ਼ ਨੂੰ ਹਫਤਾਵਾਰੀ ਬੈਚਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਹਰ ਰਿਲੀਜ਼ ਦਾ ਆਕਾਰ ਵਧਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਬਦਲਾਅ ਆਖ਼ਿਰਕਾਰ ਸ਼ਿਪ ਹੁੰਦੇ ਹਨ ਤਾਂ ਪ੍ਰੋਡਕਸ਼ਨ incidents ਦੇ chance ਵੱਧ ਜਾਂਦੇ ਹਨ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਰੁਕਾਵਟ ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਇੱਕ “ਖ਼ਰਾਬ ਕੁਏਰੀ” ਨਾਲ ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਕੁਝ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਫੇਲਿਊਰ ਮੋਡਾਂ ਦਾ ਨਤੀਜਾ ਹੁੰਦੇ ਹਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਤੌਰ-ਤਰੀਕੇ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਟੀਮਾਂ ਅਕਸਰ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਡੇਟਾਬੇਸ 'ਚ ਅਸਲ ਵਾਲੀਅਮ ਹੁੰਦਾ ਹੈ।
ਕੁਝ ਸਕੀਮਾ ਬਦਲਾਅ ਡੇਟਾਬੇਸ ਨੂੰ ਪੂਰੀ ਟੇਬਲ ਰੀਰਾਈਟ ਕਰਨ ਜਾਂ 예상 ਤੋਂ ਜ਼ਿਆਦਾ ਸਮਰਥ ਲਾਕ ਲੈਣ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ। ਭਾਵੇਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਛੋਟੀ ਲੱਗੇ, ਪਰ ਪਾਸੇ ਦੇ ਪ੍ਰਭਾਵ ਲਿਖਤਾਂ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ, ਬੇਨਤੀ ਕਤਾਰਾਂ ਬਣ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਰੁਟੀਨ ਡਿਪਲੋਇਮੈਂਟ ਨੂੰ incident ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।
ਟਿੱਪਣੀ ਟ੍ਰਿੱਗਰ ਵਿੱਚ ਕਾਲਮ ਟਾਈਪ ਬਦਲਣਾ, ਵੈਧਤਾ ਲਈ constraints ਜੋੜਨਾ ਜਾਂ ਇੰਡੈਕਸ ਬਣਾਉਣਾ ਸ਼ਾਮਿਲ ਹੈ ਜੋ ਆਮ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਲੌਕ ਕਰ ਸਕਦੇ ਹਨ।
ਡਾਟਾ ਬੈਕਫਿੱਲ (ਮੌਜੂਦਾ ਰੋਜ਼ਾਂ ਲਈ ਮੁੱਲ ਸੈੱਟ ਕਰਨਾ, ਡੀਨੋਰਮਲਾਈਜ਼ੇਸ਼ਨ) ਅਕਸਰ ਟੇਬਲ ਸਾਈਜ਼ ਅਤੇ ਡਾਟਾ distribution ਦੇ ਅਨੁਸਾਰ ਵੱਧਦੀ ਹੈ। ਜੋ staging ਵਿੱਚ ਸਕਿੰਟਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, production ਵਿੱਚ ਘੰਟਿਆਂ ਲਈ ਲਗ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਇਹ ਲਾਈਵ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡਾ ਜੋਖਮ ਅਣਿਸ਼ਚਿਤਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਰਨਟਾਈਮ ਦਾ ਦਿੱਖ ਨਹੀਂ ਲਾ ਸਕਦੇ ਤਾਂ ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਪਲੋਇਮੈਂਟ ਵਿੰਡੋ ਯੋਜਨਾ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਜਦ ਨਵਾਂ ਕੋਡ ਤੁਰੰਤ ਨਵੀਂ ਸਕੀਮਾ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ (ਜਾਂ ਪੁਰਾਣਾ ਕੋਡ ਨਵੀਂ ਸਕੀਮਾ ਨਾਲ ਟੁੱਟ ਜਾਂਦਾ) ਤਾਂ ਰਿਲੀਜ਼ “ਸਾਰਾ ਜਾਂ ਕੁਝ ਨਹੀਂ” ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ coupling ਲਚਕ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ: ਤੁਸੀਂ ਐਪ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਖੁਦਮੁਖਤਾਰ ਤੌਰ 'ਤੇ deploy ਨਹੀਂ ਕਰ ਸਕਦੇ, ਅਰਾਮ ਨਾਲ ਰੋਕ ਨਹੀਂ ਸਕਦੇ, ਅਤੇ rollbacks ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਛੋਟੇ ਫਰਕ—ਖ਼ਤਮ ਕਾਲਮ, ਵਾਧੂ ਇੰਡੈਕਸ, ਮੈਨੂਅਲ ਹਾਟਫਿਕਸ, ਵੱਖ-ਵੱਖ ਡਾਟਾ ਵਾਲੀਅਮ—ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵੱਖਰਾ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। drift ਟੈਸਟਿੰਗ ਨੂੰ ਝੂਠੀ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਦੇੰਦਾ ਹੈ ਅਤੇ production ਨੂੰ ਅਸਲ ਰਿਹਰਸਲ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਕਿਸੇ ਨੂੰ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣ, ਡੈਸ਼ਬੋਰਡ ਦੇਖਣ ਜਾਂ ਟਾਈਮਿੰਗ ਕੋਆਰਡੀਨੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਹਰ ਕਿਸੇ ਦੇ ਦਿਨ ਦੇ ਕੰਮ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ। ਜਦ ਮਾਲਕੀ unclear ਹੁੰਦੀ ਹੈ (ਐਪ ਟੀਮ vs DBA vs platform), ਰਿਵਿਊ ਸਲਿਪ ਹੁੰਦੇ ਹਨ, ਚੈੱਕਲਿਸਟ ਛੱਡੇ ਜਾਂਦੇ ਹਨ ਅਤੇ “ਅਸੀਂ ਬਾਅਦ ਕਰਾਂਗੇ” ਡਿਫ਼ਾਲਟ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੀਮ ਨੂੰ ਧੀਮਾ ਕਰਨ ਲੱਗਦੇ ਹਨ, ਪਹਿਲੇ ਸੰਕੇਤ ਆਮ ਤੌਰ 'ਤੇ errors ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਕੰਮ ਨੂੰ ਯੋਜਨਾ, ਰਿਲੀਜ਼ ਅਤੇ ਰਿਕਵਰੀ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਪੈਟਰਨ ਹਨ।
ਇੱਕ ਤੇਜ਼ ਟੀਮ ਜਦ ਵੀ ਕੋਡ ਤਿਆਰ ਹੋਵੇ ਸ਼ਿਪ ਕਰਦੀ ਹੈ। ਇੱਕ ਬੋਤਲਨੈਕ ਟੀਮ ਓਸ ਵੇਲੇ ਸ਼ਿਪ ਕਰਦੀ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਉਪਲਬਧ ਹੋਵੇ।
ਤੁਸੀਂ ਸੁਣੋਗੇ “ਅਸੀਂ ਅੱਜ ਰਾਤ ਤੱਕ deploy ਨਹੀਂ ਕਰ ਸਕਦੇ” ਜਾਂ “ਘੱਟ-ਟ੍ਰੈਫਿਕ ਵਿੰਡੋ ਦਾ ਉਡੀਕ ਕਰੋ,” ਅਤੇ ਰਿਲੀਜ਼ ਚੁੱਪਚਾਪ ਬੈਚ ਨੌਕਰੀਆਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਸਮੇਂ ਨਾਲ, ਲੋਕ ਬਦਲਾਵਾਂ ਰੋਕ ਕੇ ਜ਼ਿਆਦਾ, ਜੋਖਿਮ ਵਾਲੀਆਂ ਰਿਲੀਜ਼ਾਂ ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਕਿ “ਵਿੰਡੋ ਨੂੰ ਕੀਮਤੀ ਬਣਾਇਆ ਜਾਵੇ।”
ਕੋਈ production ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ, ਫਿਕਸ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਡਿਪਲੋਇ ਨਹੀਂ ਹੋ ਸਕਦਾ ਕਿਉਂਕਿ ਕੋਈ ਅਧੂਰਾ ਜਾਂ ਅਨਰਿਵਿਊਡ ਮਾਈਗ੍ਰੇਸ਼ਨ pipeline ਵਿੱਚ ਖੜਾ ਹੈ।
ਇਹ ਓਯਥ ਹੈ ਜਿੱਥੇ ਤਾਤਕਾਲਤਾ ਅਤੇ coupling ਟਕਰਾਉਂਦੇ ਹਨ: ਐਪ ਬਦਲਾਅ ਅਤੇ ਸਕੀਮਾ ਬਦਲਾਅ ਇਕ-ਦੂਜੇ ਨਾਲ ਇੰਨੇ ਬੰਨ੍ਹੇ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿ ਬਿਨਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਕੋਈ ਵੀ ਕੰਮ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਟੀਮਾਂ ਨੂੰ ਛੋਟਾ ਹੌਟਫਿਕਸ ਰੋਕਣਾ ਜਾਂ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਨੂੰ ਜ਼ੋਰ-ਜ਼ਬਰਦਸਤੀ ਕਰਨਾ ਪੈਨਾੜਾ ਪੈਂਦਾ ਹੈ।
ਜੇ ਕਈ ਸਕੁਆਡ ਇੱਕੋ ਮੂਲ ਟੇਬਲਾਂ 'ਤੇ ਸੋਧ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਗਾਤਾਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਦੇਖੋਗੇ:
ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਬਦਲਾਅਾਂ ਦੀ ਲੜੀਬੱਧਤਾ ਬਣਾਉਣ ਦਾ overhead ਅਸਲ ਲਾਗਤ ਬਣ ਜਾਂਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਰੋਲਬੈਕ ਇਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਐਪ ਸਾਰੇ ਰਾਜਿਆਂ ਵਿੱਚ ਸੰਗਤ ਨਹੀਂ ਸਨ। ਟੀਮ deploy ਕਰਦੀ ਹੈ, error ਆਉਂਦੀ ਹੈ, roll back ਕਰਦੀ ਹੈ, ਸੁਧਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ deploy ਕਰਦੀ ਹੈ—ਕਈ ਵਾਰ ਕਈ ਵਾਰੀ।
ਇਸ ਨਾਲ ਵਿਸ਼ਵਾਸ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਮਨਸੂਥ ਪ੍ਰਵਾਨਗੀਆਂ, ਹੋਰ ਮੈਨੂਅਲ ਕਦਮ ਅਤੇ ਵੱਧ sign-offs ਉਤਪੰਨ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਵਿਅਕਤੀ (ਜਾਂ ਛੋਟੀ ਟੋਲੀ) ਹਰ ਸਕੀਮਾ ਬਦਲਾਅ ਦੀ ਸਮੀਖਿਆ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਮੈਨੁਅਲ ਚਲਾਉਣਾ ਜਾਂ ਕਿਸੇ ਵੀ ਡੇਟਾਬੇਸ-ਸੰਬੰਧੀ ਚੀਜ਼ ਲਈ ਪੇਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਲੱਛਣ ਸਿਰਫ਼ ਕੰਮ-ਭਾਰ ਨਹੀਂ—ਇਹ ਨਿਰਭਰਤਾ ਹੈ। ਜਦ ਉਹ ਮਾਹਿਰ ਗੈਰ-ਮੌਜੂਦ ਹੋਵੇ, ਰਿਲੀਜ਼ ਧੀਮੇ ਹੋ ਜਾਂਦੇ ਹਨ ਜਾਂ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹਰ ਕੋਈ ਡੇਟਾਬੇਸ ਨੂੰ ਛੇੜਣ ਤੋਂ ਬਚਦਾ ਹੈ ਜਦ ਤੱਕ ਲਾਜ਼ਮੀ ਨਾ ਹੋਵੇ।
ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਰਫ਼ “staging ਜਿਹਾ ਜ਼ਿਆਦਾ ਡਾਟਾ ਵਾਲਾ” ਨਹੀਂ ਹੈ। ਇਹ ਇਕ ਜਿਊਂਦਾ ਸਿਸਟਮ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸਲ read/write ਟ੍ਰੈਫਿਕ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਅਤੇ ਯੂਜ਼ਰਾਂ ਦੀਆਂ ਅਣਪੇਸ਼ਨੀ ਕਾਰਗੁਜਾਰੀਆਂ ਹੋਦੀਆਂ ਹਨ। ਲਗਾਤਾਰ ਸਰਗਰਮੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੇ ਵਿਹਾਰ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ: ਉਹ ਓਪਰੇਸ਼ਨਾਂ ਜੋ ਟੈਸਟ ਵਿੱਚ ਤੇਜ਼ ਸਨ, production ਵਿੱਚ ਅਚਾਨਕ active queries ਦੇ ਪਿੱਛੇ ਕਤਾਰਬੱਧ ਹੋ ਸਕਦੇ ਹਨ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ।
ਕਈ “ਨਿੱਕੇ” ਸਕੀਮਾ ਬਦਲਾਅਾਂ ਨੂੰ ਵੀ ਲਾਕ ਦੀ ਜਰੂਰਤ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਕਾਲਮ ਦਾ default ਦੇ ਕੇ ਜੋੜਨਾ, ਟੇਬਲ ਰੀਰਾਈਟ ਕਰਨਾ ਜਾਂ ਇੱਕ ਅਕਸਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਟੇਬਲ ਨੂੰ ਛੂਹਣਾ metadata update ਜਾਂ ਡਾਟਾ rewrite ਦੌਰਾਨ ਲਾਕ ਲਾ ਸਕਦਾ ਹੈ। ਜੇ ਉਹ ਟੇਬਲ checkout, login ਜਾਂ messaging ਵਰਗੇ ਕ੍ਰਿਟੀਕਲ ਪਾਥ 'ਤੇ ਹੈ ਤਾਂ ਇੱਕ ਛੋਟਾ ਲਾਕ ਵੀ ਟਾਈਮਆਉਟ ਤੱਕ ਫੈਲ ਸਕਦਾ ਹੈ।
ਇੰਡੈਕਸ ਅਤੇ constraints ਡਾਟਾ ਗੁਣਵੱਤਾ ਅਤੇ ਕੁਏਰੀ ਤੇਜ਼ੀ ਲਈ ਮਹਤਵਪੂਰਨ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਬਣਾਉਣਾ ਜਾਂ ਵੈਰੀਫਾਈ ਕਰਨਾ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਬਿਜ਼ੀ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ 'ਤੇ ਇੰਡੈਕਸ ਬਣਾਉਣਾ CPU ਅਤੇ I/O ਲਈ ਯੂਜ਼ਰ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਧੀਮਾ ਕਰ ਸਕਦਾ ਹੈ।
ਕਾਲਮ ਟਾਈਪ ਬਦਲਾਅ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਜੋਖਿਮ ਵਾਲੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਪੂਰੀ rewrite trigger ਕਰ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ ਕੁਝ ਡੇਟਾਬੇਸ ਵਿੱਚ integer type ਬਦਲਣਾ ਜਾਂ string resizing)। ਵੱਡੀਆਂ ਟੇਬਲਾਂ 'ਤੇ ਇਹ rewrite ਮਿੰਟਾਂ ਜਾਂ ਘੰਟਿਆਂ ਲਈ ਲੱਗ ਸਕਦੀ ਹੈ ਅਤੇ ਲਾਕ ਹੋਰ ਵੱਡੇ ਸਮੇਂ ਲਈ ਰੱਖ ਸਕਦੀ ਹੈ।
“ਡਾਊਨਟਾਈਮ” ਜਦ ਯੂਜ਼ਰ ਫੀਚਰ ਵਰਤ ਨਹੀਂ ਸਕਦੇ—ਰਿਕਵੇਸਟ fail, ਪੰਨੇ error, ਨੌਕਰੀਆਂ ਰੁਕ ਜਾਂਦੀਆਂ।
“ਗੁਣਵੱਤਾ ਘਟਣਾ” ਜ਼ਿਆਦਾ ਧੂਪ-ਛਾਂਵ ਵਾਲੀ ਗੱਲ ਹੈ: ਸਾਈਟ ਉੱਪ ਰਿਹਿੰਦੀਆਂ ਹਨ, ਪਰ ਸਭ ਕੁਝ ਹੌਲਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਤਾਰਾਂ ਬਣ ਜਾਂਦੀਆਂ, retries ਵਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜੋ technical ਤੌਰ 'ਤੇ ਸਫਲ ਹੋ ਗਿਆ, ਫਿਰ ਵੀ संक्रमਨ ਸਿਰਜ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਉਸਨੇ ਸਿਸਟਮ ਨੂੰ ਉਸਦੀ ਸੀਮਾਵਾਂ ਤੋਂ ਉੱਪਰ ਧੱਕ ਦਿੱਤਾ।
ਕਾਂਟੀਨਿਊਅਸ ਡਿਲਿਵਰੀ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਹਰ ਬਦਲਾਅ ਕਿਸੇ ਵੀ ਸਮੇਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕੀਤਾ ਜਾ ਸਕੇ। ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਕਸਰ ਇਸ ਵਾਅਦੇ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ "big bang" ਕੋਆਰਡੀਨੇਸ਼ਨ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰ ਦਿੰਦੇ ਹਨ: ਐਪ ਨੂੰ ਠੀਕ ਓਹੋ ਵੇਲੇ deploy ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜਦ ਸਕੀਮਾ ਬਦਲਾਅ ਹੁੰਦਾ ਹੈ।
ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਐਸਾ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਰੋਲਿੰਗ ਡਿਪਲੋਇ ਦੌਰਾਨ ਪੁਰਾਣਾ ਕੋਡ ਅਤੇ ਨਵਾਂ ਕੋਡ ਇਕੋ ਡੇਟਾਬੇਸ ਸਥਿਤੀ ਉੱਤੇ ਚੱਲ ਸਕਣ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਰੁਟੀਨ ਹੈ expand/contract (ਕਈ ਵਾਰ “parallel change” ਵੀ ਕਹਿੰਦੇ ਹਨ):
ਇਸ ਨਾਲ ਇੱਕ ਖਤਰਨਾਕ ਰਿਲੀਜ਼ ਕਈ ਛੋਟੇ ਘੱਟ-ਜੋਖਿਮ ਵਾਲੇ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ।
ਰੋਲਿੰਗ ਡਿਪਲੋਇ ਦੌਰਾਨ ਕੁਝ ਸਰਵਰ ਪੁਰਾਣੇ ਕੋਡ 'ਤੇ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਕੁਝ ਨਵੇਂ ਕੋਡ 'ਤੇ। ਤੁਹਾਡੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਧਾਰਨਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਦੋਹਾਂ ਵਰਜ਼ਨ ਇਕੱਠੇ ਜ਼ਿੰਦਾ ਹਨ।
ਇਸਦਾ ਮਤਲਬ:
NOT NULL ਕਾਲਮ ਨਾਲ ਡੀਫਾਲਟ ਪਾਉਣ ਦੀ ਬਜਾਏ (ਜੋ ਟੇਬਲ ਰੀਰਾਈਟ ਤੇ ਲਾਕ ਕਰ ਸਕਦਾ ਹੈ), ਇਹ ਕਰੋ:
ਇਸ ਤਰੀਕੇ ਨਾਲ, ਸਕੀਮਾ ਬਦਲਾਅ ਰੁਕਾਵਟ ਤੋਂ ਬਚਾ ਕੇ routine, ਸ਼ਿਪ ਕਰਨਯੋਗ ਕੰਮ ਬਣ ਜਾਂਦੇ ਹਨ।
ਤੇਜ਼ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਿਖਣ ਤੋਂ ਬਲੋਕ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ blocked ਹੁੰਦੀਆਂ ਹਨ ਜਦ ਮਾਈਗ੍ਰੇਸ਼ਨ production ਲੋਡ ਹੇਠਾਂ ਕਿਵੇਂ ਵਰਤਦੇ ਹਨ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਸਕੀਮਾ ਬਦਲਾਅ predictable, ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਅਤੇ retry ਕਰਨ ਯੋਗ ਹੋਣ।
ਪਹਲੇ additive ਬਦਲਾਅ (ਨਵੀਆਂ ਟੇਬਲਾਂ, ਕਾਲਮ, ਇੰਡੈਕਸ) ਕਰੋ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਰੀਰਾਈਟ ਤੋਂ ਬਚਦੇ ਹਨ ਅਤੇ ਮੌਜੂਦਾ ਕੋਡ ਨੂੰ ਕੰਮ ਕਰਨ ਦਿੰਦੇ ਹਨ ਜਦ ਤੁਸੀਂ ਅਪਡੇਟ ਰੋਲ ਕਰਦੇ ਹੋ।
ਜਦ ਤੁਹਾਨੂੰ ਕੁਝ ਬਦਲਣਾ ਜਾਂ ਹਟਾਉਣਾ ਪਏ, ਤਾਂ staged approach ਸੋਚੋ: ਨਵਾਂ ਸ੍ਰਢਚਨਾ ਜੋੜੋ, ਕੋਡ deploy ਕਰੋ ਜੋ ਦੋਹਾਂ ਨੂੰ ਲਿਖੇ/ਪੜ੍ਹੇ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ cleanup ਕਰੋ। ਇਸ ਨਾਲ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ ਬਿਨਾਂ risky cutover ਦੇ।
ਲੱਖਾਂ ਰੋਜ਼ਾਂ ਨੂੰ rewrite ਕਰਨ ਵਰਗੇ ਵੱਡੇ ਅਪਡੇਟ deployment bottlenecks ਦੀ ਜੜ੍ਹ ਹਨ।
ਪ੍ਰੋਡਕਸ਼ਨ incidents ਅਕਸਰ ਇਕ ਫੇਲ ਹੋਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਘੰਟਿਆਂ ਦੀ recovery ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਇਸ ਜੋਖਮ ਨੂੰ ਘਟਾਉਣ ਲਈ migrations ਨੂੰ idempotent ਬਣਾਓ (ਇਕ ਤੋਂ ਵੱਧ ਵਾਰੀ ਚਲਾਉਣ ਦੇ ਯੋਗ) ਅਤੇ ਆংশਿਕ ਪ੍ਰਗਤੀ ਨੂੰ tolerate ਕਰਨ ਵਾਲਾ ਬਣਾਓ।
ਵਿਆਹਿਕ ਉਦਾਹਰਣ:
ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਲੰਬਾਈ ਨੂੰ ਪਹਿਲ-ਰਤ ਅਹਮ ਮੈਟਰਿਕ ਸਮਝੋ। ਹਰੇਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਇੱਕ timebox ਦਿਓ ਅਤੇ staging-ਨਾਂ ਵਰਗੇ ਡੈਟਾ ਨਾਲ ਰਨ ਸਮਾਂ ਮਾਪੋ।
ਜੇ ਕੋਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੁਹਾਡੇ ਬਜਟ ਤੋਂ ਵੱਧ ਚੱਲਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਤੋੜੋ: ਹੁਣ ਸਕੀਮਾ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ ਭਾਰੀ ਡਾਟਾ ਕੰਮ ਨੂੰ ਨਿਯੰਤਰਿਤ ਬੈਚਾਂ ਵਿੱਚ ਲਿਜਾਓ। ਇਸ ਤਰ੍ਹਾਂ ਟੀਮਾਂ CI/CD ਅਤੇ migrations ਨੂੰ ਦੁਹਰਾਉਣ ਵਾਲੀ ਘਟਨਾ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ।
ਜਦੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ “ਖ਼ਾਸ” ਹੋ ਕੇ ਮੈਨੁਅਲ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ ਕਤਾਰ ਬਣ ਜਾਂਦੇ ਹਨ: ਕਿਸੇ ਨੂੰ ਯਾਦ ਕਰਨਾ ਪੈਂਦਾ, ਚਲਾਉਣਾ ਪੈਂਦਾ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਨੀ ਪੈਂਦੀ ਕਿ ਠੀਕ ਹੋਇਆ। ਸੁਧਾਰ ਸਿਰਫ਼ ਆਟੋਮੇਸ਼ਨ ਹੀ ਨਹੀਂ—ਇਹ ਆਟੋਮੇਸ਼ਨ ਨਾਲ ਗਾਰਡਰੇਲ ਹੈ, ਤਾਂ ਜੋ unsafe ਬਦਲਾਅ production ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਫਟਕਾਰ ਖਾਂ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਫਾਇਲਾਂ ਨੂੰ ਕੋਡ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ: ਉਹ merge ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕਾਂ ਪਾਸ ਕਰਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇਹ ਚੈੱਕ CI ਵਿੱਚ ਫੈਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਸਪੱਸ਼ਟ ਪੈਲਆਉਟ ਦਿਓ ਤਾਂ ਕਿ ਡਿਵੈਲਪਰ guess ਕਰਨ ਦੀ ਬਜਾਏ ਸਿੱਧਾ ਸਹੀ ਕਰ ਸਕਣ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣਾ pipeline ਵਿੱਚ ਇੱਕ ਪਹਿਲ-ਕਲਾਸ ਕਦਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਾਸੇ-ਦਾਰੀ ਕੰਮ ਨਹੀਂ। ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ ਹੈ: build → test → deploy app → run migrations (ਜਾਂ ਤੁਹਾਡੀ compatibility στραਟੇਜੀ ਦੇ ਅਨੁਸਾਰ ਉਲਟ) ਨਾਲ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ “ਕੀ migration ਚੱਲੀ?” ਵਾਲਾ ਸਵਾਲ release ਦੌਰਾਨ ਹਟ ਜਾਏ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੰਦਰੂਨੀ ਐਪ ਬਣਾ ਰਹੇ ਹੋ (ਖਾਸ ਕਰਕੇ React + Go + PostgreSQL stacks), ਤਾਂ ਇਹ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਜਦ ਤੁਹਾਡਾ dev platform "plan → ship → recover" ਲੂਪ ਨੂੰ explicit ਬਣਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai planning mode, snapshots ਅਤੇ rollback ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ, ਜੋ ਅਕਸਰ ਮਲਟੀ-ਡਿਵੈਲਪਰ iteration ਦੌਰਾਨ frequent releases ਦੇ operational friction ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਐਸੇ ਤਰੀਕੇ ਨਾਲ fail ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਆਮ ਐਪ ਮਾਨੀਟਰੀੰਗ ਨਹੀਂ ਫੜਦੀ। ਨਿਸ਼ਾਨੇ ਜੋੜੋ:
ਜੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੱਚ ਵੱਡਾ ਡਾਟਾ backfill ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ explicit, ਟ੍ਰੈਕਬਲ ਸਟੈਪ ਬਣਾਓ। ਪਹਿਲਾਂ ਐਪ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ deploy ਕਰੋ, ਫਿਰ backfill ਨੂੰ rate limiting ਅਤੇ pause/resume ਦੇ అడਾਅ ਨਾਲ ਨਿਯੰਤਰਿਤ ਜੌਬ ਵਜੋਂ ਚਲਾਓ। ਇਸ ਨਾਲ ਰਿਲੀਜ਼ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ ਬਿਨਾਂ multi-hour operation ਨੂੰ ਇੱਕ “migration” ਚੈਕਬਾਕਸ ਵਿੱਚ ਲੁਕਾਉਣ ਦੇ।
ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਜੋਖਿਮਨਾਕ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਸਾਂਝੇ ਸਟੇਟ ਨੂੰ ਬਦਲਦੇ ਹਨ। ਇੱਕ ਚੰਗਾ ਰਿਲੀਜ਼ ਯੋਜਨਾ “ਉਲਟਾ” ਨੂੰ ਇਕ ਕਾਰਜਵਿਧੀ ਸਮਝਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ SQL ਫਾਇਲ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਟੀਮ ਅਚਾਨਕ ਹੋਏ production ਮਾਮਲੇ ਵਿੱਚ ਵੀ ਅੱਗੇ ਵਧ ਸਕੇ।
“Down” ਸਕ੍ਰਿਪਟ ਕੇਵਲ ਇਕ ਹਿੱਸਾ ਹੈ—ਅਤੇ ਅਕਸਰ ਸਭ ਤੋਂ ਘੱਟ ਭਰੋਸੇਯੋਗ। ਇੱਕ ਕਾਰਜਕਾਰੀ rollback ਯੋਜਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦੀ ਹੈ:
ਕੁਝ ਬਦਲਾਅ ਸਾਫ਼-ਤੌਰ 'ਤੇ ਉਲਟ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ: ਨਾਸ਼ਕਰ ਡਾਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ, rows ਨੂੰ rewrite ਕਰਨ ਵਾਲੇ backfills, ਜਾਂ column ਟਾਈਪ ਬਦਲਾਅ ਜੋ ਜਾਣਕਾਰੀ ਹਟਾ ਦਿੰਦੇ ਹਨ। ਐਸਾ ਹਾਲਤਾਂ ਵਿੱਚ, roll-forward ਸੁਰੱਖਿਅਤ ਹੈ: ਇੱਕ follow-up migration ਜਾਂ hotfix deploy ਕਰੋ ਜੋ ਸਕੀਮਾ ਨਾਲ ਮੁੜ-ਅਨੁਕੂਲਤਾ ਬਣਾਏ ਅਤੇ ਡਾਟਾ ਨੂੰ ਠੀਕ ਕਰੇ, ਬਜਾਏ ਸਮੇਂ ਨੂੰ ਵਾਪਸ ਘੁੰਮਾਉਣ ਦੇ।
expand/contract ਪੈਟਰਨ ਇਥੇ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ: ਇੱਕ ਸਮੇਂ ਦੌਰਾਨ dual-read/dual-write ਰੱਖੋ, ਫਿਰ ਪੁਰਾਣੀਆਂ ਰਸਤੇ ਹਟਾਓ ਜਦ ਤੁਹਾਨੂੰ ਯਕੀਨ ਹੋਵੇ।
ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਿਹੇਵਿਅਰ ਬਦਲਾਅ ਨੂੰ ਵੱਖਰਾ ਕਰਕੇ blast radius ਘਟਾ ਸਕਦੇ ਹੋ। ਫੀਚਰ ਫਲੈਗਾਂ ਵਰਤੋਂ ਤਾਂ ਕਿ ਨਵੀਂ reads/writes ਹੌਲੇ-ਹੌਲੇ enable ਕੀਤੀਆਂ ਜਾਣ (ਪ੍ਰਤੀਸ਼ਤ, ਪ੍ਰਤੀ-ਟੈਨੈਂਟ ਜਾਂ ਕੋਹੋਰਟ ਵਾਰ)। ਜੇ ਮੈਟ੍ਰਿਕਸ spike ਹੋਵੇ, ਤੁਸੀਂ ਫੀਚਰ ਨੂੰ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਤੁਰੰਤ ਛੇੜੇ।
ਇੱਕ ਘਟਨਾ ਦਾ ਉਡੀਕ ਨਾ ਕਰੋ ਤਾਂ ਕਿ ਤੁਹਾਡੀਆਂ rollback steps incomplete ਨਿਕਲਣ। staging 'ਚ realistc ਡਾਟਾ ਵਾਲੀ rehearsal ਕਰੋ, ਸਮੇਂ-ਬੱਧ runbooks ਅਤੇ ਮਾਨੀਟਰੀੰਗ ਡੈਸ਼ਬੋਰਡ ਨਾਲ। ਅਭਿਆਸ ਰਨ ਇਸ ਸਵਾਲ ਦਾ ਸਾਫ਼ ਜਵਾਬ ਦੇਵੇ: “ਕੀ ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ stable ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਆ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਾਂ?”
ਜਦੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ “ਕਿਸੇ ਹੋਰ ਦੀ ਸਮੱਸਿਆ” ਵਜੋਂ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੇਜ਼ ਟੀਮਾਂ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ। ਤੇਜ਼ ਫਿਕਸ ਅਕਸਰ ਨਵਾਂ ਟੂਲ ਨਹੀਂ—instead, ਇੱਕ ਸਪੱਸ਼ਟ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਨੂੰ ਡਿਲਿਵਰੀ ਦਾ ਨਾਰਮਲ ਹਿੱਸਾ ਬਣਾਉਂਦੀ ਹੈ।
ਹਰੇਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਸਪੱਸ਼ਟ ਭੂਮਿਕਾਵਾਂ ਦਿੱਤੀਆਂ ਜਾਣ:
ਇਸ ਨਾਲ ਇੱਕ-DB ਵਿਅਕਤੀ ਦੀ ਨਿਰਭਰਤਾ ਘੱਟ ਹੁੰਦੀ ਹੈ ਪਰ ਫਿਰ ਵੀ ਟੀਮ ਨੂੰ ਇੱਕ ਸੇਫਟੀ ਨੈੱਟ ਮਿਲਦਾ ਹੈ।
ਚੈੱਕਲਿਸਟ ਇੰਨੀ ਛੋਟੀ ਰੱਖੋ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਵਰਤੀ ਜਾਵੇ। ਇੱਕ ਚੰਗੀ ਰਿਵਿਊ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਵਰ ਕਰਦੀ ਹੈ:
ਇਸਨੂੰ PR template ਵਜੋਂ ਸਟੋਰ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਤਾਂ ਕਿ ਇਹ consistent ਰਹੇ।
ਹਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ meeting ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਉੱਚ ਜੋਖਿਮ ਵਾਲੇ ਯਕੀਨਨ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਾਇਕ ਹਨ। ਇੱਕ ਸਾਂਝੀ ਕੈਲੇਂਡਰ ਜਾਂ ਸਧਾਰਨ “migration window” ਪ੍ਰਕਿਰਿਆ ਬਣਾਓ ਜਿਸ ਵਿੱਚ:
ਜੇ ਤੁਸੀਂ automation ਅਤੇ guardrails ਲਈ ਡਿਪਥ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਸਨੂੰ ਆਪਣੇ CI/CD ਨਿਯਮਾਂ ਨਾਲ tie ਕਰੋ ਅਤੇ /blog/automation-and-guardrails-in-cicd ਨੂੰ ਵੇਖੋ।
ਜੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਿਲੀਜ਼ ਨੂੰ ਧੀਮਾ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ performance ਸਮੱਸਿਆ ਵਾਂਗ ਲਵੋ: “ਧੀਮਾ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਇਸਨੂੰ ਲਗਾਤਾਰ ਮਾਪੋ ਅਤੇ ਸੁਧਾਰਾਂ ਨੂੰ ਦਿੱਖਾਓ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਦਰਦਨਾਕ ਘਟਨਾ ਠੀਕ ਕਰਕੇ ਹੀ ਫਿਰ ਉਨ੍ਹਾਂ ਪੁਰਾਣੇ ਪੈਟਰਨਾਂ 'ਤੇ ਮੁੜ ਆ ਜਾਵੋਗੇ।
ਛੋਟੀ ਡੈਸ਼ਬੋਰਡ (ਜਾਂ ਹਫਤਾਵਾਰੀ ਰਿਪੋਰਟ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: “ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਤੋਂ ਡਿਲਿਵਰੀ ਸਮੇਂ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਖਰਚ ਹੁੰਦਾ ਹੈ?” ਮਦਦਗਾਰ ਮੈਟ੍ਰਿਕਸ:
ਹਰ slow ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਇੱਕ ਛੋਟੀ ਨੋਟ ਜੋ ਕਾਰਨ ਦੱਸੇ (ਟੇਬਲ ਸਾਈਜ਼, ਇੰਡੈਕਸ build, lock contention, ਨੈੱਟਵਰਕ ਆਦਿ)। ਉਦੇਸ਼ ਪੂਰਨ ਸਹੀਤਾ ਨਹੀਂ—ਲਕੜੀ ਮੁੜਕਣ ਵਾਲੇ offenders ਨੂੰ ਪਛਾਣਨਾ ਹੈ।
ਸਿਰਫ਼ production incidents ਦਸਤਾਵੇਜ਼ ਨਾ ਕਰੋ। near-misses ਵੀ capture ਕਰੋ: ਮਾਈਗ੍ਰੇਸ਼ਨ ਜੋ ਇੱਕ ਮਿੰਟ ਲਈ ਹੌਟ ਟੇਬਲ ਨੂੰ ਲਾਕ ਕਰ ਗਿਆ, ਰਿਲੀਜ਼ ਜੋ ਰੋਕੇ ਗਏ, ਜਾਂ rollbacks ਜੋ ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਨਹੀਂ ਕੀਤੇ।
ਸਧਾਰਣ ਲੌਗ ਰੱਖੋ: ਕੀ ਹੋਇਆ, ਪ੍ਰਭਾਵ, ਯੋਗਕਾਰਕ ਕਾਰਨ ਅਤੇ ਅੱਗੇ ਕੀ ਰੋਕਥਾਮ ਕਦਮ ਹੋਣਗੇ। ਸਮੇਂ ਨਾਲ, ਇਹ ਦਰਜ ਤੁਹਾਡੀ migration “anti-pattern” ਸੂਚੀ ਬਣ ਜਾਂਦੀ ਹੈ ਅਤੇ ਵਧੀਆ defaults ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ (ਜਿਵੇਂ ਕਦੋਂ backfills ਲਾਜ਼ਮੀ ਹਨ, ਕਦੋਂ ਬਦਲਾਅ ਨੂੰ ਵੱਖਰਾ ਕਰਨਾ, ਕਦੋਂ out-of-band ਚਲਾਉਣਾ)।
ਤੇਜ਼ ਟੀਮ ਫੈਸਲੇ ਥੱਕਾਵਟ ਘਟਾ ਕੇ standards ਨਾਲ ਘੱਟ ਦਿਮਾਗੀ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਇਕ ਚੰਗਾ playbook ਸੁਰੱਖਿਅਤ ਨੁਸਖੇ ਰੱਖਦਾ ਹੈ:
ਇਸਨੂੰ ਆਪਣੀ release checklist ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਇਹ ਨਿਰਧਾਰਿਤ ਯੋਜਨਾ ਦੌਰਾਨ ਵਰਤਿਆ ਜਾਵੇ, ਨਾ ਕਿ ਗਲਤ ਹੋਣ 'ਤੇ।
ਕੁਝ stacks ਵਿੱਚ migration tables ਅਤੇ ਫਾਇਲਾਂ ਜਦ ਵੱਡੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ startup ਸਮਾਂ, diffchecks ਜਾਂ tooling timeout ਵਧ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਹ ਦੇਖੋ ਤਾਂ ਸਮਾ-ਸਮੇਂ ਤੇ maintenance ਯੋਜਨਾ (ਪੁਰਾਣੀ migration history prune ਜਾਂ archive) ਅਤੇ framework ਦੀ ਸਿਫਾਰਸ਼ੀ ਤਰੀਕੇ ਨਾਲ ਨਵੇਂ environments ਲਈ clean rebuild path verify ਕਰੋ।
ਟੂਲਿੰਗ ਇਕ ਖਰਾਬ migration ਨੀਤੀ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗੀ, ਪਰ ਢੰਗ ਦੇ ਟੂਲ ਕਾਫੀ friction ਘਟਾ ਸਕਦੇ ਹਨ: ਘੱਟ ਮੈਨੂਅਲ ਕਦਮ, ਸਪੱਸ਼ਟ ਦਿੱਖ, ਅਤੇ ਦਬਾਅ ਹੇਠ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼।
ਡੇਟਾਬੇਸ ਚੇન્જ ਪ੍ਰਬੰਧਨ ਟੂਲ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ ਉਹ ਫੀਚਰ ਤਰਜੀਹ ਦਿਓ ਜੋ deploy ਦੌਰਾਨ ਅਣਸ਼ੁਚਿਤਾ ਘਟਾਉਂਦੇ ਹਨ:
ਆਪਣੇ ਡਿਪਲੋਇਮੈਂਟ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਸ ਤੋਂ ਪਿੱਛੇ ਜਾਓ:
ਆਪਰੇਸ਼ਨਲ ਹਕੀਕਤ ਵੀ ਚੈੱਕ ਕਰੋ: ਇਹ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਇੰਜਿੰ ਦੇ ਸੀਮਾਵਾਂ (ਲਾਕ, ਲੰਬੇ DDL, replication) ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਇਹ output ਬਣਾਉਂਦਾ ਹੈ ਜੋ on-call ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਕਾਰਵਾਈ ਕਰ ਸਕੇ?
ਉਦਾਹਰਨ ਲਈ, Koder.ai source code export, hosting/deployment workflows ਅਤੇ snapshots/rollback ਮਾਡਲ देता है, ਜੋ high-frequency releases ਦੌਰਾਨ ਤੇਜ਼, ਭਰੋਸੇਯੋਗ "known good" ਵਿੱਚ ਵਾਪਸੀ ਨੂੰ ਤੀਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ।
ਸਾਡੇ ਸਾਰੇ ਓਰਗ ਦੇ workflow ਨੂੰ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਪਰਿਵਰਤਿਤ ਨਾ ਕਰੋ। ਹੋਰਦੀ ਟੇਬਲ ਜਾਂ ਇੱਕ high-churn service 'ਤੇ ਟੂਲ ਦਾ pilot ਕਰੋ।
ਸਫਲਤਾ ਪਹਿਲਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ: migration runtime, failure rate, time-to-approve, ਅਤੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ recover ਕਰਨ ਦੀ ਦੇਰ। ਜੇ pilot "release anxiety" ਘਟਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਬਿਊਰੋਕਰੇਸੀ ਵਧਾਏ, ਤਾਂ ਵਧਾਓ।
ਜੇ ਤੁਸੀਂ ਵਿਕਲਪ ਅਤੇ rollout ਰਸਤੇ ਜਾਣਚਣ ਲਈ ਤਿਆਰ ਹੋ, ਤਾਂ /pricing ਦੇਖੋ ਜਾਂ ਹੋਰ pragmatic guides ਲਈ /blog ਨੂੰ ਬ੍ਰਾਊਜ਼ ਕਰੋ।
ਜਦੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਿਲੀਜ਼ ਨੂੰ ਐਪ ਕੋਡ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਦੇਰ ਨਾਲ ਲੰਘਾਉਂਦੀ ਹੈ ਤਾਂ ਉਹ ਬੋਤਲਨੈਕ ਬਣ ਜਾਂਦੀ ਹੈ—ਉਦਾਹਰਨ ਲਈ, ਫੀਚਰ ਤੈਿਆਰ ਹਨ ਪਰ ਰਿਲੀਜ਼ maintenance window, ਲੰਬਾ ਚਲਣ ਵਾਲੇ ਸਕ੍ਰਿਪਟ, ਖਾਸ ਰਿਵਿਊਅਰ ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਲਾਕ/ਲੈਗ ਦੇ ਡਰ ਕਾਰਨ ਰੁਕਦੇ ਹਨ.
ਮੁੱਖ ਮੁੱਦਾ ਭਵਿੱਖਬਾਣੀਯੋਗਤਾ ਅਤੇ ਜੋਖਮ ਹੈ: ਡੇਟਾਬੇਸ ਇੱਕ ਸਾਂਝਾ ਸਰੋਤ ਹੈ ਅਤੇ ਉਸਨੂੰ ਪੈਰਲੇਲ ਬਣਾਉਣਾ ਔਖਾ ਹੈ, ਇਸ ਲਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਕਸਰ ਪਾਈਪਲਾਈਨ ਨੂੰ ਇੱਕ-ਲਾਈਨ 'ਤੇ ਲੈ ਆਉਂਦਾ ਹੈ।
ਅਕਸਰ pipeline ਇਹ ਬਣ ਜਾਂਦਾ ਹੈ: code → migration → deploy → verify.
ਭਾਵੇਂ ਕੋਡ ਕੰਮ ਪੈਰਲੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਦਮ ਅਕਸਰ ਨਹੀਂ:
ਆਮ ਰੂਟ ਕਾਰਨ ਸ਼ਾਮਲ ਹਨ:
ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਰਫ਼ staging ਦਾ ਵੱਡਾ ਸੰਸਕਰਣ ਨਹੀਂ ਹੈ—ਇਹ ਇੱਕ ਜਿਊਂਦਾ ਸਿਸਟਮ ਹੈ ਜਿਸ ਵਿੱਚ ਪੜ੍ਹਾਈ/ਲਿਖਾਈ ਟ੍ਰੈਫਿਕ, ਬੈਕਗ੍ਰਾਊਂਡ ਨੌਕਰੀਆਂ ਅਤੇ ਅਣਪੇਸ਼ਨਾਵਾਂ ਹੋਦੀਆਂ ਹਨ। ਇਹ ਲਗਾਤਾਰ ਸਰਗਰਮੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦਾ ਵੇਵਹਾਰ ਬਦਲ ਦਿੰਦੀ ਹੈ:
ਇਸ ਲਈ ਅਸਲੀ scalability ਟੈਸਟ ਅਕਸਰ production ਵਿੱਚ ਹੀ ਹੁੰਦਾ ਹੈ।
ਲਕੜੀ deploy ਦੌਰਾਨ ਮੁਰੰਮਤ/ਸਕੀਮਾ compatibility ਇਹ ਮੰਗਦਾ ਹੈ ਕਿ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਐਪ ਸਰਵਰ ਇਕੱਠੇ database ਸਥਿਤੀ ਤੇ ਚੱਲ ਸਕਣ।
ਅਮਲ ਵਿੱਚ:
ਇਸ ਨਾਲ “ਸਭ-ਜਾ-ਇੱਕ-ਮੁਹੂਰ” ਰਿਲੀਜ਼ਾਂ ਤੋਂ ਬਚਾਵ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਐਪ ਅਤੇ ਸਕੀਮਾ ਨੂੰ ਇਕੱਠੇ ਬਦਲਣਾ ਜ਼ਰੂਰੀ ਹੋਵੇ।
ਇਹ ਇੱਕ ਦੁਹਰਾਈ ਜਾ ਸਕਣ ਵਾਲੀ ਤਰੀਕਾ ਹੈ ਜੋ ਬੜੇ-ਬੈਂਗ ਬਦਲਾਅ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ:
ਇਹ ਇੱਕ ਖ਼ਤਰਨਾਕ ਰਿਲੀਜ਼ ਨੂੰ ਕਈ ਛੋਟੇ, ਘੱਟ ਜੋਖਿਮ ਵਾਲੇ ਕਦਮਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਕ੍ਰਮ ਇਹ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਲਾਕਿੰਗ ਦਾ ਜੋਖਮ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਰਿਲੀਜ਼ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ।
ਭਾਰੀ ਕੰਮ ਨੂੰ ਰੋਕਣਯੋਗ ਅਤੇ critical deploy ਪਾਥ ਤੋਂ ਬਾਹਰ ਰੱਖੋ:
ਇਸ ਨਾਲ ਪੈਟਰਨ ਭਵਿੱਖਬਾਣੀਯੋਗ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਕੱਲਾ ਡਿਪਲੋਇ ਸਾਰੇ ਨੂੰ ਰੋਕਣ ਦਾ ਕਾਰਨ ਘੱਟ ਹੁੰਦਾ ਹੈ।
ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਕੋਡ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ ਅਤੇ guardrails ਲਗਾਓ:
ਇਹ ਚੇਕ CI ਵਿੱਚ ਜਲਦੀ ਫੇਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਕਿ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਅਟਕਣ ਸਹੀ ਕਰ ਸਕਣ।
ਇਕ procedure 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ “down” ਸਕ੍ਰਿਪਟ:
ਇਸ ਨਾਲ ਰਿਲੀਜ਼ਜ਼ recoverable ਬਣਦੇ ਹਨ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਨੂੰ ਰੋਕਣ ਦੇ।
