ਉਹ Migrations ਜੋ Production ਨੂੰ ਖਰਾਬ ਨਹੀਂ ਕਰਨਗੀਆਂ

ਇੱਕ migration ਤੁਹਾਡੀ ਮਸ਼ੀਨ 'ਤੇ ਬਿਲਕੁਲ ਸਹੀ ਚੱਲਦੀ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਸ਼ੁੱਕਰਵਾਰ ਸ਼ਾਮ 6 ਵਜੇ ਡਿਪਲੋਇ ਕਰਦੇ ਹੋ ਕਿਉਂਕਿ ਇਹ ਛੋਟੀ ਲੱਗਦੀ ਹੈ। ਫਿਰ ਡਿਪਲੋਇਮੈਂਟ ਰੁਕ ਜਾਂਦੀ ਹੈ। ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, 8 ਮਿਲੀਅਨ ਰੋਅ (rows) ਵਾਲੀ ਇੱਕ ਟੇਬਲ 40 ਸੈਕਿੰਡ ਲਈ ਲਾਕ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸਾਈਟ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ।

Production ਵਿੱਚ Migrations ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਲੋਕਲ ਡੇਟਾਬੇਸ ਖਾਲੀ ਅਤੇ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ। Production ਡੇਟਾਬੇਸ ਵਿੱਚ ਅਸਲੀ ਡੇਟਾ ਅਤੇ ਸਰਗਰਮ (active) ਯੂਜ਼ਰ ਹੁੰਦੇ ਹਨ।

Production ਦੀਆਂ ਮੁਸੀਬਤਾਂ ਤੋਂ ਬਚਣ ਲਈ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ।

  • ਹਮੇਸ਼ਾ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ down method ਲਿਖੋ ਹਰ migration ਲਈ ਇੱਕ up ਅਤੇ ਇੱਕ down ਫੰਕਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। down ਫੰਕਸ਼ਨ ਨੂੰ up ਫੰਕਸ਼ਨ ਨੂੰ ਬਿਲਕੁਲ ਉਲਟਾ (reverse) ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ rollback ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੀ migration ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹੈ। ਪੁਸ਼ (push) ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ migrate ਦੇ ਨਾਲ migrate:rollback ਚਲਾ ਕੇ ਇਸਦੀ ਜਾਂਚ ਕਰੋ।

  • ਪੁਰਾਣੀਆਂ migrations ਨੂੰ ਕਦੇ ਵੀ ਐਡਿਟ ਨਾ ਕਰੋ ਤੁਸੀਂ ਕਿਸੇ ਪੁਰਾਣੀ migration ਫਾਈਲ ਵਿੱਚ ਕਾਲਮ ਦਾ ਸਾਈਜ਼ ਠੀਕ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਸਕਦੇ ਹੋ। ਅਜਿਹਾ ਨਾ ਕਰੋ। Laravel ਸਰਵਰ 'ਤੇ ਉਸ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਚਲਾਏਗਾ। ਇਸ ਦੀ ਬਜਾਏ, ਸਟ੍ਰਕਚਰ ਬਦਲਣ ਲਈ ਇੱਕ ਨਵੀਂ migration ਬਣਾਓ। Migration ਤਬਦੀਲੀਆਂ ਦਾ ਇਤਿਹਾਸ ਹੈ। ਤੁਸੀਂ ਪੁਰਾਣੇ ਅਧਿਆਏ (chapters) ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਬਜਾਏ ਨਵੇਂ ਅਧਿਆਏ ਜੋੜਦੇ ਹੋ।

  • nullable ਜਾਂ default values ਦੀ ਵਰਤੋਂ ਕਰੋ ਮੌਜੂਦਾ ਡੇਟਾ ਵਾਲੀ ਟੇਬਲ ਵਿੱਚ NOT NULL ਕਾਲਮ ਜੋੜਨ ਨਾਲ ਗਲਤੀਆਂ (errors) ਆ ਸਕਦੀਆਂ ਹਨ। ਡੇਟਾਬੇਸ ਨੂੰ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਕਿ ਪੁਰਾਣੀਆਂ ਰੋਅਜ਼ (rows) ਵਿੱਚ ਕੀ ਭਰਨਾ ਹੈ।

ਇਸ ਦੀ ਬਜਾਏ ਇਹਨਾਂ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ: • ਨਵੇਂ ਕਾਲਮ ਨੂੰ nullable ਬਣਾਓ। • ਇੱਕ default value ਸੈੱਟ ਕਰੋ। • ਜੇਕਰ ਕਾਲਮ ਲਾਜ਼ਮੀ (required) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਕਰੋ: ਇਸਨੂੰ nullable ਵਜੋਂ ਬਣਾਓ, ਡੇਟਾ ਭਰੋ, ਫਿਰ ਇਸਨੂੰ NOT NULL ਵਿੱਚ ਬਦਲ ਦਿਓ।

  • ਡੇਟਾ ਦਾ ਨੁਕਸਾਨ ਪੱਕਾ ਹੁੰਦਾ ਹੈ dropColumn ਕਮਾਂਡ ਡੇਟਾ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਡਿਲੀਟ ਕਰ ਦਿੰਦੀ ਹੈ। ਇੱਕ rollback ਕਾਲਮ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾ ਸਕਦਾ ਹੈ, ਪਰ ਅੰਦਰਲਾ ਡੇਟਾ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਾਲਮ ਨੂੰ ਡ੍ਰੌਪ (drop) ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ ਬੈਕਅੱਪ ਦੀ ਜਾਂਚ ਕਰੋ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਕਾਲਮ ਦੀ ਵਰਤੋਂ ਬੰਦ ਕਰ ਦਿਓ, ਕੁਝ ਹਫ਼ਤੇ ਉਡੀਕ ਕਰੋ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਡੇਟਾਬੇਸ ਤੋਂ ਹਟਾ ਦਿਓ।

  • schema ਤਬਦੀਲੀਆਂ ਨੂੰ data updates ਤੋਂ ਵੱਖ ਰੱਖੋ Migration ਦੇ ਅੰਦਰ User::all() ਚਲਾਉਣ ਨਾਲ ਲੱਖਾਂ ਰੋਅਜ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਡਿਪਲੋਇਮੈਂਟ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਹਾਨੂੰ migration ਦੌਰਾਨ ਡੇਟਾ ਅੱਪਡੇਟ ਕਰਨਾ ਹੀ ਪੈਣਾ ਹੈ, ਤਾਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਛੋਟੇ ਬੈਚਾਂ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ chunkById ਦੀ ਵਰਤੋਂ ਕਰੋ।

  • pipelines ਵਿੱਚ force flag ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੇਕਰ Laravel ਪੁਸ਼ਟੀ (confirmation) ਮੰਗਦਾ ਹੈ ਤਾਂ ਆਟੋਮੇਟਿਡ ਡਿਪਲੋਇਮੈਂਟ ਪਾਈਪਲਾਈਨਾਂ ਰੁਕ ਜਾਣਗੀਆਂ। ਆਪਣੇ ਡਿਪਲੋਇਮੈਂਟ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਇਸ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ: php artisan migrate --force

  • table locks ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ ਇੱਕ ਵਿਸ਼ਾਲ (massive) ਟੇਬਲ 'ਤੇ ਕਾਲਮ ਬਦਲਣ ਜਾਂ index ਜੋੜਨ ਨਾਲ ਉਹ ਟੇਬਲ ਲਾਕ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਡਾਊਨਟਾਈਮ (downtime) ਹੁੰਦਾ ਹੈ। ਬਹੁਤ ਵੱਡੀਆਂ ਟੇਬਲਾਂ ਲਈ, online schema change tools ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਾਂ ਘੱਟ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਸਮੇਂ ਦੌਰਾਨ ਤਬਦੀਲੀਆਂ ਕਰੋ।

ਪੁਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕਲਿਸਟ: • ਕੀ down method ਕੰਮ ਕਰਦਾ ਹੈ? • ਕੀ ਮੈਂ locally rollback ਦੀ ਜਾਂਚ ਕੀਤੀ ਹੈ? • ਕੀ ਮੈਂ ਪੁਰਾਣੀ migration ਨੂੰ ਐਡਿਟ ਕਰਨ ਦੀ ਬਜਾਏ ਨਵੀਂ migration ਬਣਾ ਰਿਹਾ ਹਾਂ? • ਕੀ ਨਵਾਂ ਕਾਲਮ nullable ਹੈ ਜਾਂ ਇਸਦੀ ਕੋਈ default value ਹੈ? • ਕੀ ਕਾਲਮ ਡ੍ਰੌਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੇਰੇ ਕੋਲ ਬੈਕਅੱਪ ਹੈ?

Source: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-