লিকুইবেস ব্যবহার করে কীভাবে নিজেকে পায়ে গুলি করবেন না

আগে কখনও ঘটেনি, এবং এখানে আমরা আবার যেতে!

আমাদের পরবর্তী প্রকল্পে, আমরা ভবিষ্যতে সমস্যা এড়াতে প্রথম থেকেই Liquibase ব্যবহার করার সিদ্ধান্ত নিয়েছি। এটি দেখা যাচ্ছে, সমস্ত তরুণ দলের সদস্যরা জানেন না কিভাবে এটি সঠিকভাবে ব্যবহার করতে হয়। আমি একটি অভ্যন্তরীণ কর্মশালা আয়োজন করেছি, যা আমি একটি নিবন্ধে পরিণত করার সিদ্ধান্ত নিয়েছি।

নিবন্ধটিতে দরকারী টিপস এবং তিনটি সবচেয়ে সুস্পষ্ট ত্রুটির একটি বিবরণ রয়েছে যা আপনি রিলেশনাল ডাটাবেস মাইগ্রেশন সরঞ্জামগুলির সাথে কাজ করার সময় পড়তে পারেন, বিশেষ করে লিকুইবেস। জুনিয়র এবং মিডল লেভেলে জাভা ডেভেলপারদের জন্য ডিজাইন করা হয়েছে; আরও অভিজ্ঞ ডেভেলপারদের জন্য এটি সম্ভবত ইতিমধ্যেই পরিচিত যা স্ট্রাকচারিং এবং পুনরাবৃত্তি করার জন্য আগ্রহী হতে পারে।

লিকুইবেস এবং ফ্লাইওয়ে হল জাভা বিশ্বে রিলেশনাল স্ট্রাকচারের সংস্করণ নিয়ন্ত্রণ সমস্যা সমাধানের জন্য প্রধান প্রতিযোগী প্রযুক্তি। প্রথমটি সম্পূর্ণ বিনামূল্যে, অনুশীলনে এটি প্রায়শই ব্যবহারের জন্য বেছে নেওয়া হয়, এই কারণেই লিকুইবেসকে প্রকাশনার নায়ক হিসাবে বেছে নেওয়া হয়েছিল। যাইহোক, আপনার অ্যাপ্লিকেশন আর্কিটেকচারের উপর নির্ভর করে, বর্ণিত কিছু অনুশীলন সর্বজনীন হতে পারে।

রিলেশনাল স্ট্রাকচারের মাইগ্রেশন রিলেশনাল ডেটা স্টোরের দুর্বল নমনীয়তা মোকাবেলা করার একটি বাধ্যতামূলক উপায়। ওওপি ফ্যাশনের যুগে, ডাটাবেসগুলির সাথে কাজ করার শৈলীর অর্থ হল আমরা স্কিমাটিকে একবার বর্ণনা করব এবং এটিকে আবার স্পর্শ করব না। কিন্তু বাস্তবতা হল যে জিনিসগুলি সবসময় পরিবর্তিত হয়, এবং টেবিলের কাঠামোর পরিবর্তনগুলি প্রায়শই প্রয়োজন হয়। স্বাভাবিকভাবেই, প্রক্রিয়া নিজেই বেদনাদায়ক এবং অপ্রীতিকর হতে পারে।

আমি আপনার প্রকল্পে একটি লাইব্রেরি যোগ করার জন্য প্রযুক্তি এবং নির্দেশাবলীর বর্ণনার গভীরে যাব না; এই বিষয়ে বেশ কয়েকটি নিবন্ধ লেখা হয়েছে:

• একটি স্প্রিং বুট অ্যাপ্লিকেশনে ডাটাবেস কাঠামো পরিচালনা করতে Liquibase ব্যবহার করে। অংশ 1
• একটি স্প্রিং বুট অ্যাপ্লিকেশনে ডাটাবেস কাঠামো পরিচালনা করতে Liquibase ব্যবহার করে। অংশ 2
• লিকুইবেস এবং মাভেন
• সংস্করণ ডাটাবেস পরিবর্তনের পদ্ধতি
• আমরা দুই লাইনে স্প্রিং এমভিসি/সিকিউরিটি, আরইএসটি, হাইবারনেট, লিকুইবেস চালু করি

এছাড়াও, দরকারী টিপসের বিষয়ে ইতিমধ্যে একটি দুর্দান্ত নিবন্ধ ছিল:

• মাথাব্যথা ছাড়াই লিকুইবেস ব্যবহার করা। বাস্তব উন্নয়ন অভিজ্ঞতা থেকে 10 টি টিপস

টিপস

আমি আমার পরামর্শ এবং মন্তব্যগুলি শেয়ার করতে চাই, যা দেশত্যাগের সাথে সমস্যা সমাধানের ঘাম, রক্ত ​​এবং বেদনার মধ্য দিয়ে জন্ম নিয়েছে।

1. কাজ শুরু করার আগে, আপনার সেরা অনুশীলন বিভাগের সাথে নিজেকে পরিচিত করা উচিত ওয়েবসাইট লিকুইবেস

সেখানে সহজ কিন্তু অত্যন্ত গুরুত্বপূর্ণ বিষয়গুলি বর্ণনা করা হয়েছে, যা ছাড়া লাইব্রেরি ব্যবহার করা আপনার জীবনকে জটিল করে তুলতে পারে। উদাহরণস্বরূপ, পরিবর্তনগুলি পরিচালনা করার জন্য একটি অসংগঠিত পদ্ধতি শীঘ্র বা পরে বিভ্রান্তি এবং ভাঙা মাইগ্রেশনের দিকে নিয়ে যাবে। আপনি যদি একই সময়ে ডাটাবেস কাঠামো এবং পরিষেবা যুক্তিতে পারস্পরিকভাবে নির্ভরশীল পরিবর্তনগুলি রোল আউট না করেন, তাহলে একটি উচ্চ সম্ভাবনা রয়েছে যে এটি লাল পরীক্ষা বা ভগ্ন পরিবেশের দিকে পরিচালিত করবে। এছাড়াও, অফিসিয়াল ওয়েবসাইটে লিকুইবেস ব্যবহারের জন্য সুপারিশগুলিতে মূল মাইগ্রেশন স্ক্রিপ্টগুলির সাথে রোলব্যাক স্ক্রিপ্টগুলির বিকাশ এবং পরীক্ষা সংক্রান্ত একটি ধারা রয়েছে৷ ভাল, নিবন্ধে https://habr.com/ru/post/178665/ মাইগ্রেশন এবং রোলব্যাক প্রক্রিয়া সম্পর্কিত কোড উদাহরণ রয়েছে।

2. আপনি মাইগ্রেশন টুল ব্যবহার করা শুরু করলে, ডাটাবেস কাঠামোতে ম্যানুয়াল সংশোধনের অনুমতি দেবেন না

প্রবাদটি বলে: "একবার পার্সিল, সর্বদা পার্সিল।" যদি আপনার আবেদনের ভিত্তি Liquibase দ্বারা পরিচালিত হতে শুরু করে, যে কোনো ম্যানুয়াল পরিবর্তন অবিলম্বে একটি অসামঞ্জস্যপূর্ণ অবস্থার দিকে নিয়ে যায় এবং পরিবর্তনসেটের বিশ্বাসের মাত্রা শূন্য হয়ে যায়। সম্ভাব্য ঝুঁকির মধ্যে রয়েছে ডাটাবেস পুনরুদ্ধার করতে বেশ কয়েক ঘন্টা ব্যয় করা; সবচেয়ে খারাপ পরিস্থিতিতে, একটি মৃত সার্ভার। আপনার দলে যদি একজন "পুরানো স্কুল" ডিবিএ আর্কিটেক্ট থাকে, ধৈর্য সহকারে এবং ভেবেচিন্তে তাকে ব্যাখ্যা করুন যে তিনি যদি শর্তসাপেক্ষ SQL বিকাশকারীর কাছ থেকে তার নিজের উপলব্ধি অনুসারে ডাটাবেস সম্পাদনা করেন তবে জিনিসগুলি কতটা খারাপ হবে।

3. যদি পরিবর্তন সেটটি ইতিমধ্যেই সংগ্রহস্থলে পুশ করা হয়ে থাকে, তাহলে সম্পাদনা এড়িয়ে চলুন

যদি অন্য কোনও বিকাশকারী একটি টান তৈরি করে এবং একটি পরিবর্তন সেট প্রয়োগ করে, যা পরে সম্পাদনা করা হবে, অ্যাপ্লিকেশন শুরু করার সময় তিনি একটি ত্রুটি পেলে তিনি অবশ্যই আপনাকে একটি সদয় শব্দের সাথে মনে রাখবেন। পরিবর্তনসেট সম্পাদনা করা কোনোভাবে বিকাশে লিক হলে, আপনাকে হটফিক্সের পিচ্ছিল ঢাল অনুসরণ করতে হবে। সমস্যার সারাংশ হ্যাশ যোগ দ্বারা পরিবর্তনের বৈধতার উপর নির্ভর করে - লিকুইবেসের প্রধান প্রক্রিয়া। চেঞ্জসেট কোড সম্পাদনা করার সময়, হ্যাশের পরিমাণ পরিবর্তিত হয়। পরিবর্তনগুলি সম্পাদনা করা তখনই সম্ভব যখন ডেটা হারানো ছাড়াই স্ক্র্যাচ থেকে সম্পূর্ণ ডাটাবেস স্থাপন করা সম্ভব। এই ক্ষেত্রে, SQL বা XML কোড রিফ্যাক্টরিং, বিপরীতভাবে, জীবনকে সহজ করে তুলতে পারে এবং মাইগ্রেশনকে আরও পাঠযোগ্য করে তুলতে পারে। একটি উদাহরণ হল এমন একটি পরিস্থিতি যেখানে, অ্যাপ্লিকেশনের শুরুতে, সোর্স ডাটাবেসের স্কিমা টিমের মধ্যে সম্মত হয়েছিল।

4. সম্ভব হলে যাচাইকৃত ডাটাবেস ব্যাকআপ রাখুন

এখানে, আমি মনে করি, সবকিছু পরিষ্কার। যদি হঠাৎ মাইগ্রেশন ব্যর্থ হয়, তাহলে সবকিছু ফেরত দেওয়া যেতে পারে। Liquibase-এ পরিবর্তনগুলি রোল ব্যাক করার জন্য একটি টুল রয়েছে, কিন্তু রোলব্যাক স্ক্রিপ্টগুলিও ডেভেলপার নিজেই লিখেছেন, এবং মূল পরিবর্তনসেটের স্ক্রিপ্টগুলির মতো একই সম্ভাবনা নিয়ে তাদের সমস্যা হতে পারে। এর মানে হল যে কোনও ক্ষেত্রে ব্যাকআপের সাথে এটি নিরাপদে চালানোর জন্য এটি কার্যকর।

5. সম্ভব হলে ডেভেলপমেন্টে প্রমাণিত ডাটাবেস ব্যাকআপ ব্যবহার করুন

যদি এটি চুক্তি এবং গোপনীয়তার বিরোধিতা না করে, তবে ডাটাবেসে কোনও ব্যক্তিগত ডেটা নেই, এবং এটির ওজন দুই সূর্যের মতো নয় - লাইভ মাইগ্রেশন সার্ভারে এটি ব্যবহার করার আগে, আপনি এটি বিকাশকারীর মেশিনে কীভাবে কাজ করবে তা পরীক্ষা করতে পারেন এবং গণনা করতে পারেন। মাইগ্রেশনের সময় প্রায় 100% সম্ভাব্য সমস্যা।

6. দলের অন্যান্য ডেভেলপারদের সাথে যোগাযোগ করুন

একটি সুসংগঠিত উন্নয়ন প্রক্রিয়ায়, দলের সবাই জানে কে কি করছে। বাস্তবে, এটি প্রায়শই হয় না, তাই, আপনি যদি আপনার টাস্কের অংশ হিসাবে ডাটাবেস কাঠামোতে পরিবর্তনগুলি প্রস্তুত করছেন, তবে অতিরিক্তভাবে পুরো দলকে এটি সম্পর্কে অবহিত করার পরামর্শ দেওয়া হয়। যদি কেউ সমান্তরালভাবে পরিবর্তন করে, তাহলে আপনাকে সাবধানে সংগঠিত করা উচিত। শুধু শুরুতেই নয়, কাজ শেষ করার পরে সহকর্মীদের সাথে যোগাযোগ করা মূল্যবান। পরিবর্তনের সাথে অনেক সম্ভাব্য সমস্যা কোড পর্যালোচনা পর্যায়ে সমাধান করা যেতে পারে।

7. আপনি কি করছেন তা ভেবে দেখুন!

এটি স্ব-প্রকাশ্য পরামর্শের মতো মনে হবে যা যেকোনো পরিস্থিতিতে প্রযোজ্য। যাইহোক, অনেক সমস্যা এড়ানো যেত যদি ডেভেলপার আবার বিশ্লেষণ করতেন যে তিনি কী করছেন এবং এটি কী প্রভাব ফেলতে পারে। মাইগ্রেশনের সাথে কাজ করার জন্য সর্বদা অতিরিক্ত মনোযোগ এবং নির্ভুলতার প্রয়োজন।

যাত্রীর সঙ্গের নিজলটবহর

আসুন এখন দেখে নেওয়া যাক যে সাধারণ ফাঁদে আপনি পড়তে পারেন যদি আপনি উপরের পরামর্শটি অনুসরণ না করেন এবং আপনার ঠিক কী করা উচিত?

পরিস্থিতি 1: দুই ডেভেলপার একই সময়ে নতুন পরিবর্তন যোগ করার চেষ্টা করছে

Vasya এবং Petya একে অপরের সম্পর্কে না জেনে একটি চেঞ্জসেট সংস্করণ 4 তৈরি করতে চায়। তারা ডাটাবেস কাঠামোতে পরিবর্তন করেছে এবং বিভিন্ন চেঞ্জসেট ফাইলের সাথে একটি পুল অনুরোধ জারি করেছে। নিম্নলিখিত কর্ম প্রক্রিয়া প্রস্তাবিত হয়:

কিভাবে সিদ্ধান্ত নিতে হবে

1. কোনো না কোনোভাবে, সহকর্মীদের অবশ্যই সম্মত হতে হবে যে ক্রমে তাদের পরিবর্তনগুলি যেতে হবে, উদাহরণস্বরূপ, পেটিন প্রথমে প্রয়োগ করা উচিত।
2. কারো নিজের সাথে দ্বিতীয়টি যোগ করা উচিত এবং ভাস্যার পরিবর্তনসেটটি সংস্করণ 5 দিয়ে চিহ্নিত করা উচিত। এটি চেরি পিক বা একটি ঝরঝরে মার্জের মাধ্যমে করা যেতে পারে।
3. পরিবর্তনের পরে, আপনার অবশ্যই নেওয়া পদক্ষেপগুলির বৈধতা পরীক্ষা করা উচিত।
   প্রকৃতপক্ষে, লিকুইবেস মেকানিজম আপনাকে রিপোজিটরিতে দুটি সংস্করণ 4 পরিবর্তনসেট রাখার অনুমতি দেবে, যাতে আপনি সবকিছু যেমন আছে তেমন রেখে যেতে পারেন। অর্থাৎ, আপনার কাছে ভিন্ন নাম সহ সংস্করণ 4-এ দুটি পরিবর্তন হবে। এই পদ্ধতির সাথে, পরবর্তীতে ডাটাবেস সংস্করণগুলি নেভিগেট করা খুব কঠিন হয়ে পড়ে।

উপরন্তু, Liquibase, hobbits বাড়ির মত, অনেক গোপন রাখে। তাদের মধ্যে একটি হল validCheckSum কী, যা 1.7 সংস্করণে উপস্থিত হয়েছে এবং ডাটাবেসে যা সংরক্ষিত আছে তা নির্বিশেষে আপনাকে একটি নির্দিষ্ট পরিবর্তনের জন্য একটি বৈধ হ্যাশ মান নির্দিষ্ট করতে দেয়। ডকুমেন্টেশন https://www.liquibase.org/documentation/changeset.html নিম্নলিখিত বলেন:

একটি চেকসাম যোগ করুন যা এই পরিবর্তনসেটের জন্য বৈধ বলে বিবেচিত হয়, ডাটাবেসে যা সংরক্ষিত থাকুক না কেন। প্রাথমিকভাবে ব্যবহার করা হয় যখন আপনার একটি চেঞ্জসেট পরিবর্তন করতে হবে এবং ডাটাবেসগুলিতে ত্রুটিগুলি নিক্ষেপ করতে চান না যেখানে এটি ইতিমধ্যেই চলছে (কোন প্রস্তাবিত পদ্ধতি নয়)

হ্যাঁ, হ্যাঁ, এই পদ্ধতিটি সুপারিশ করা হয় না। তবে কখনও কখনও একটি শক্তিশালী আলোর জাদুকরও অন্ধকার কৌশলগুলি আয়ত্ত করে

পরিস্থিতি 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