Liquibase ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਪੈਰਾਂ ਵਿੱਚ ਗੋਲੀ ਮਾਰਨ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ

ਪਹਿਲਾਂ ਕਦੇ ਨਹੀਂ ਹੋਇਆ, ਅਤੇ ਇੱਥੇ ਅਸੀਂ ਦੁਬਾਰਾ ਜਾਂਦੇ ਹਾਂ!

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

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

Liquibase ਅਤੇ Flyway Java ਸੰਸਾਰ ਵਿੱਚ ਰਿਲੇਸ਼ਨਲ ਬਣਤਰਾਂ ਦੇ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਮੁੱਖ ਪ੍ਰਤੀਯੋਗੀ ਤਕਨਾਲੋਜੀਆਂ ਹਨ। ਪਹਿਲਾ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁਫਤ ਹੈ, ਅਭਿਆਸ ਵਿੱਚ ਇਸਨੂੰ ਅਕਸਰ ਵਰਤੋਂ ਲਈ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ, ਇਸੇ ਕਰਕੇ Liquibase ਨੂੰ ਪ੍ਰਕਾਸ਼ਨ ਦੇ ਨਾਇਕ ਵਜੋਂ ਚੁਣਿਆ ਗਿਆ ਸੀ। ਹਾਲਾਂਕਿ, ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਵਰਣਿਤ ਕੁਝ ਅਭਿਆਸ ਯੂਨੀਵਰਸਲ ਹੋ ਸਕਦੇ ਹਨ।

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

ਮੈਂ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਜੋੜਨ ਲਈ ਤਕਨਾਲੋਜੀ ਅਤੇ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਵਰਣਨ ਵਿੱਚ ਡੂੰਘਾਈ ਵਿੱਚ ਨਹੀਂ ਜਾਵਾਂਗਾ; ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਕੁਝ ਲੇਖ ਲਿਖੇ ਗਏ ਹਨ:

• ਸਪਰਿੰਗ ਬੂਟ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਲਿਕਵੀਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਭਾਗ 1
• ਸਪਰਿੰਗ ਬੂਟ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਲਿਕਵੀਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਭਾਗ 2
• Liquibase ਅਤੇ Maven
• ਡਾਟਾਬੇਸ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੰਸਕਰਣ ਕਰਨ ਲਈ ਪਹੁੰਚ
• ਅਸੀਂ ਸਪਰਿੰਗ MVC/ਸੁਰੱਖਿਆ, REST, ਹਾਈਬਰਨੇਟ, Liquibase ਨੂੰ ਦੋ ਲਾਈਨਾਂ ਵਿੱਚ ਲਾਂਚ ਕਰਦੇ ਹਾਂ

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਉਪਯੋਗੀ ਸੁਝਾਵਾਂ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸ਼ਾਨਦਾਰ ਲੇਖ ਸੀ:

• ਬਿਨਾਂ ਸਿਰ ਦਰਦ ਦੇ ਲਿਕਵੀਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਅਸਲ ਵਿਕਾਸ ਅਨੁਭਵ ਤੋਂ 10 ਸੁਝਾਅ

ਸੁਝਾਅ

ਮੈਂ ਆਪਣੀ ਸਲਾਹ ਅਤੇ ਟਿੱਪਣੀਆਂ ਸਾਂਝੀਆਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਜੋ ਪਰਵਾਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਪਸੀਨੇ, ਖੂਨ ਅਤੇ ਦਰਦ ਦੁਆਰਾ ਪੈਦਾ ਹੋਏ ਸਨ.

1. ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਵਾਲੇ ਭਾਗ ਤੋਂ ਜਾਣੂ ਕਰਵਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਸਾਈਟ Liquibase

ਉੱਥੇ ਸਧਾਰਨ ਪਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਤੋਂ ਬਿਨਾਂ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਤੁਹਾਡੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤਬਦੀਲੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਗੈਰ-ਸੰਗਠਿਤ ਪਹੁੰਚ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਉਲਝਣ ਅਤੇ ਟੁੱਟੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵੱਲ ਲੈ ਜਾਵੇਗੀ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਅਤੇ ਸੇਵਾ ਤਰਕ ਵਿੱਚ ਆਪਸੀ ਨਿਰਭਰ ਤਬਦੀਲੀਆਂ ਨੂੰ ਰੋਲ ਆਊਟ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਉੱਚ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਇਹ ਲਾਲ ਟੈਸਟਾਂ ਜਾਂ ਇੱਕ ਟੁੱਟੇ ਵਾਤਾਵਰਣ ਵੱਲ ਲੈ ਜਾਵੇਗਾ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਧਿਕਾਰਤ ਵੈੱਬਸਾਈਟ 'ਤੇ Liquibase ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਵਿੱਚ ਮੁੱਖ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਨਾਲ ਰੋਲਬੈਕ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਬਾਰੇ ਇੱਕ ਧਾਰਾ ਸ਼ਾਮਲ ਹੈ। ਨਾਲ ਨਾਲ, ਲੇਖ ਵਿਚ https://habr.com/ru/post/178665/ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਰੋਲਬੈਕ ਵਿਧੀ ਸੰਬੰਧੀ ਕੋਡ ਉਦਾਹਰਨਾਂ ਹਨ।

2. ਜੇਕਰ ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਡਾਟਾਬੇਸ ਢਾਂਚੇ ਵਿੱਚ ਦਸਤੀ ਸੁਧਾਰਾਂ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦਿਓ

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

3. ਜੇਕਰ ਬਦਲਾਵ ਪਹਿਲਾਂ ਹੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਧੱਕਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਸੰਪਾਦਨ ਤੋਂ ਬਚੋ

ਜੇਕਰ ਕਿਸੇ ਹੋਰ ਡਿਵੈਲਪਰ ਨੇ ਇੱਕ ਖਿੱਚ ਲਿਆ ਅਤੇ ਇੱਕ ਤਬਦੀਲੀ ਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਜਿਸ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸੰਪਾਦਿਤ ਕੀਤਾ ਜਾਵੇਗਾ, ਤਾਂ ਉਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਦਿਆਲੂ ਸ਼ਬਦ ਨਾਲ ਯਾਦ ਕਰੇਗਾ ਜਦੋਂ ਉਸਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ ਕੋਈ ਗਲਤੀ ਮਿਲਦੀ ਹੈ। ਜੇਕਰ ਬਦਲਾਅ ਸੈੱਟ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਵਿਕਾਸ ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਹੌਟਫਿਕਸ ਦੀ ਤਿਲਕਣ ਢਲਾਣ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਪਵੇਗੀ। ਸਮੱਸਿਆ ਦਾ ਸਾਰ ਹੈਸ਼ ਸਮ ਦੁਆਰਾ ਤਬਦੀਲੀਆਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ - ਲਿਕਵੀਬੇਸ ਦੀ ਮੁੱਖ ਵਿਧੀ. ਚੇਂਜਸੈੱਟ ਕੋਡ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਸਮੇਂ, ਹੈਸ਼ ਦੀ ਮਾਤਰਾ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਉਦੋਂ ਹੀ ਸੰਭਵ ਹੈ ਜਦੋਂ ਡੇਟਾ ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ ਸਕ੍ਰੈਚ ਤੋਂ ਪੂਰੇ ਡੇਟਾਬੇਸ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਸੰਭਵ ਹੋਵੇ। ਇਸ ਕੇਸ ਵਿੱਚ, SQL ਜਾਂ XML ਕੋਡ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨਾ, ਇਸਦੇ ਉਲਟ, ਜੀਵਨ ਨੂੰ ਆਸਾਨ ਬਣਾ ਸਕਦਾ ਹੈ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਵਧੇਰੇ ਪੜ੍ਹਨਯੋਗ ਬਣਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਉਦਾਹਰਨ ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਹੋਵੇਗੀ ਜਿੱਥੇ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਟੀਮ ਦੇ ਅੰਦਰ ਸਰੋਤ ਡੇਟਾਬੇਸ ਦੀ ਸਕੀਮਾ 'ਤੇ ਸਹਿਮਤੀ ਦਿੱਤੀ ਗਈ ਸੀ।

4. ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਪ੍ਰਮਾਣਿਤ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਲਵੋ

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

5. ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਵਿਕਾਸ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਦੀ ਵਰਤੋਂ ਕਰੋ

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

6. ਟੀਮ 'ਤੇ ਹੋਰ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰੋ

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

7. ਇਸ ਬਾਰੇ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ!

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

ਜਾਲ

ਆਓ ਹੁਣ ਉਹਨਾਂ ਖਾਸ ਜਾਲਾਂ ਨੂੰ ਵੇਖੀਏ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਤੁਸੀਂ ਫਸ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਉਪਰੋਕਤ ਸਲਾਹ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਸਥਿਤੀ 1: ਦੋ ਡਿਵੈਲਪਰ ਇੱਕੋ ਸਮੇਂ ਨਵੇਂ ਬਦਲਾਅ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ

ਵਾਸਿਆ ਅਤੇ ਪੇਟਿਆ ਇੱਕ ਦੂਜੇ ਬਾਰੇ ਜਾਣੇ ਬਿਨਾਂ, ਇੱਕ ਪਰਿਵਰਤਨ ਸੰਸਕਰਣ 4 ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ। ਉਹਨਾਂ ਨੇ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਪਰਿਵਰਤਨਸ਼ੀਲ ਫਾਈਲਾਂ ਦੇ ਨਾਲ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਜਾਰੀ ਕੀਤੀ। ਕਾਰਵਾਈ ਦੀ ਹੇਠ ਦਿੱਤੀ ਵਿਧੀ ਪ੍ਰਸਤਾਵਿਤ ਹੈ:

ਫੈਸਲਾ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

1. ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਸਹਿਕਰਮੀਆਂ ਨੂੰ ਉਸ ਕ੍ਰਮ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦੇ ਬਦਲਾਅ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਪੇਟੀਨ ਨੂੰ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਕਿਸੇ ਨੂੰ ਦੂਜੇ ਨੂੰ ਆਪਣੇ ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਵਾਸਿਆ ਦੇ ਬਦਲਾਵ ਨੂੰ ਸੰਸਕਰਣ 5 ਦੇ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਚੈਰੀ ਪਿਕ ਜਾਂ ਇੱਕ ਸਾਫ਼-ਸੁਥਰੇ ਮਿਲਾਨ ਦੁਆਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
3. ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕੀਤੀਆਂ ਗਈਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
   ਵਾਸਤਵ ਵਿੱਚ, Liquibase ਵਿਧੀ ਤੁਹਾਨੂੰ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦੋ ਸੰਸਕਰਣ 4 ਤਬਦੀਲੀਆਂ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗੀ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਛੱਡ ਸਕੋ। ਭਾਵ, ਤੁਹਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਨਾਵਾਂ ਦੇ ਨਾਲ ਸੰਸਕਰਣ 4 ਵਿੱਚ ਦੋ ਬਦਲਾਅ ਹੋਣਗੇ। ਇਸ ਪਹੁੰਚ ਨਾਲ, ਬਾਅਦ ਵਿੱਚ ਡੇਟਾਬੇਸ ਸੰਸਕਰਣਾਂ ਨੂੰ ਨੈਵੀਗੇਟ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਲਿਕਵੀਬੇਸ, ਹੌਬਿਟਸ ਦੇ ਘਰ ਵਾਂਗ, ਬਹੁਤ ਸਾਰੇ ਰਾਜ਼ ਰੱਖਦਾ ਹੈ. ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੈਧCheckSum ਕੁੰਜੀ ਹੈ, ਜੋ ਕਿ ਸੰਸਕਰਣ 1.7 ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਈ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਖਾਸ ਤਬਦੀਲੀ ਲਈ ਇੱਕ ਵੈਧ ਹੈਸ਼ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਭਾਵੇਂ ਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੀ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਦਸਤਾਵੇਜ਼ੀਕਰਨ https://www.liquibase.org/documentation/changeset.html ਹੇਠ ਲਿਖਿਆ ਹੈ:

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

ਹਾਂ, ਹਾਂ, ਇਸ ਵਿਧੀ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਪਰ ਕਈ ਵਾਰ ਇੱਕ ਮਜ਼ਬੂਤ ​​​​ਲਾਈਟ ਜਾਦੂਗਰ ਵੀ ਹਨੇਰੇ ਤਕਨੀਕਾਂ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰਦਾ ਹੈ

ਸਥਿਤੀ 2: ਮਾਈਗ੍ਰੇਸ਼ਨ ਜੋ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ

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

ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਸੰਭਵ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਇਸ ਤੋਂ ਮੁਕਤ ਨਹੀਂ ਹੈ. ਇਹ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜੇਕਰ ਟੇਬਲ ਢਾਂਚੇ ਵਿੱਚ ਸੋਧਾਂ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਡੇਟਾਬੇਸ ਦੇ ਖਾਸ ਡੇਟਾ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਜੇ ਪੇਟੀਆ ਦਾ ਡੇਟਾਬੇਸ ਸਿਰਫ ਟੈਸਟ ਡੇਟਾ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਇਹ ਸਾਰੇ ਸਮੱਸਿਆ ਦੇ ਮਾਮਲਿਆਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਾਰਣੀ ਨੂੰ ਮਿਟਾਉਂਦੇ ਸਮੇਂ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਦੁਆਰਾ ਹੋਰ ਟੇਬਲਾਂ ਵਿੱਚ ਰਿਕਾਰਡ ਹਨ ਜੋ ਮਿਟਾਏ ਜਾ ਰਹੇ ਰਿਕਾਰਡਾਂ ਨਾਲ ਸਬੰਧਤ ਹਨ। ਜਾਂ ਕਾਲਮ ਦੀ ਕਿਸਮ ਨੂੰ ਬਦਲਣ ਵੇਲੇ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ 100% ਡੇਟਾ ਨੂੰ ਨਵੀਂ ਕਿਸਮ ਵਿੱਚ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ।

ਫੈਸਲਾ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

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

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

ਸਥਿਤੀ 3. ਲਿਕਵੀਬੇਸ ਉਤਪਾਦਨ ਵਿੱਚ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵਰਤਿਆ ਜਾਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ

ਮੰਨ ਲਓ ਕਿ ਟੀਮ ਲੀਡ ਨੇ ਪੇਟੀਆ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਲਿਕਵੀਬੇਸ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਕਿਹਾ, ਪਰ ਪ੍ਰੋਜੈਕਟ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਨ ਵਿੱਚ ਹੈ ਅਤੇ ਇੱਕ ਮੌਜੂਦਾ ਡਾਟਾਬੇਸ ਢਾਂਚਾ ਹੈ।

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

ਫੈਸਲਾ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

ਕਈ ਤਰੀਕੇ ਵੀ ਹਨ:

• ਪਹਿਲਾ ਅਤੇ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇੱਕ ਵੱਖਰੀ ਸਕ੍ਰਿਪਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਇੱਕ ਨਵੇਂ ਵਾਤਾਵਰਣ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ ਹੱਥੀਂ ਲਾਗੂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
• ਦੂਜਾ ਘੱਟ ਸਪੱਸ਼ਟ ਹੈ, ਇੱਕ Liquibase ਮਾਈਗ੍ਰੇਸ਼ਨ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ Liquibase ਸੰਦਰਭ ਵਿੱਚ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ। ਤੁਸੀਂ ਇੱਥੇ Liquibase ਸੰਦਰਭ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ: https://www.liquibase.org/documentation/contexts.html. ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਇੱਕ ਦਿਲਚਸਪ ਵਿਧੀ ਹੈ ਜੋ ਸਫਲਤਾਪੂਰਵਕ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜਾਂਚ ਲਈ.
• ਤੀਜੇ ਮਾਰਗ ਵਿੱਚ ਕਈ ਕਦਮ ਹਨ। ਪਹਿਲਾਂ, ਮੌਜੂਦਾ ਟੇਬਲ ਲਈ ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਇਸ ਨੂੰ ਕੁਝ ਵਾਤਾਵਰਣ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇਸਦਾ ਹੈਸ਼ ਜੋੜ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਅਗਲਾ ਕਦਮ ਸਾਡੇ ਗੈਰ-ਖਾਲੀ ਸਰਵਰ 'ਤੇ ਖਾਲੀ ਲਿਕਵੀਬੇਸ ਟੇਬਲ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ, ਅਤੇ ਪਰਿਵਰਤਨਸੈਟਾਂ ਦੀ ਵਰਤੋਂ ਦੇ ਇਤਿਹਾਸ ਦੇ ਨਾਲ ਸਾਰਣੀ ਵਿੱਚ, ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਤਬਦੀਲੀਆਂ ਦੇ ਨਾਲ "ਜਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ" ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਦਸਤੀ ਰਿਕਾਰਡ ਰੱਖ ਸਕਦੇ ਹੋ। . ਇਸ ਤਰ੍ਹਾਂ, ਮੌਜੂਦਾ ਸਰਵਰ 'ਤੇ, ਇਤਿਹਾਸ ਦੀ ਕਾਊਂਟਡਾਊਨ ਸੰਸਕਰਣ 2 ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇਗੀ, ਅਤੇ ਸਾਰੇ ਨਵੇਂ ਵਾਤਾਵਰਣ ਇੱਕੋ ਜਿਹੇ ਵਿਹਾਰ ਕਰਨਗੇ।
  

ਸਥਿਤੀ 4. ਪਰਵਾਸ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੂਰਾ ਕਰਨ ਲਈ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ

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

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

ਫੈਸਲਾ ਕਿਵੇਂ ਕਰਨਾ ਹੈ

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

ਸਟੈਂਡਅਲੋਨ ਮੋਡ ਵਿੱਚ, ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਆਪਣੇ CI/CD ਵਾਤਾਵਰਣ ਜਾਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਅਤੇ ਤੈਨਾਤੀ ਮਾਹਿਰਾਂ ਦੇ ਮਜ਼ਬੂਤ ​​ਮੋਢਿਆਂ 'ਤੇ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ। ਅਜਿਹਾ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ Liquibase ਕਮਾਂਡ ਲਾਈਨ ਦੀ ਲੋੜ ਪਵੇਗੀ https://www.liquibase.org/documentation/command_line.html. ਇਸ ਮੋਡ ਵਿੱਚ, ਸਾਰੇ ਲੋੜੀਂਦੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਂਚ ਕਰਨਾ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸਿੱਟਾ

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

ਸਰੋਤ: www.habr.com