پہلے کبھی نہیں ہوا، اور یہاں ہم پھر جاتے ہیں!
اپنے اگلے پروجیکٹ پر، ہم نے مستقبل میں مسائل سے بچنے کے لیے شروع سے ہی Liquibase استعمال کرنے کا فیصلہ کیا۔ جیسا کہ یہ پتہ چلتا ہے، تمام نوجوان ٹیم کے ارکان نہیں جانتے کہ اسے صحیح طریقے سے کیسے استعمال کرنا ہے۔ میں نے ایک اندرونی ورکشاپ کا انعقاد کیا، جسے میں نے پھر ایک مضمون میں تبدیل کرنے کا فیصلہ کیا۔
مضمون میں مفید نکات اور تین سب سے واضح خرابیوں کی تفصیل شامل ہے جن میں آپ متعلقہ ڈیٹا بیس کی منتقلی کے ٹولز، خاص طور پر Liquibase کے ساتھ کام کرتے وقت گر سکتے ہیں۔ جونیئر اور مڈل لیول پر جاوا ڈیولپرز کے لیے ڈیزائن کیا گیا ہے؛ زیادہ تجربہ کار ڈویلپرز کے لیے یہ اس چیز کی ساخت اور دہرانے کے لیے دلچسپی کا باعث ہو سکتا ہے جو پہلے سے ہی معلوم ہے۔
Liquibase اور Flyway جاوا کی دنیا میں رشتہ دار ڈھانچے کے ورژن کنٹرول کے مسائل کو حل کرنے کے لیے مقابلہ کرنے والی اہم ٹیکنالوجیز ہیں۔ پہلا مکمل طور پر مفت ہے، عملی طور پر اسے اکثر استعمال کے لیے منتخب کیا جاتا ہے، اسی لیے Liquibase کو اشاعت کا ہیرو منتخب کیا گیا تھا۔ تاہم، آپ کی درخواست کے فن تعمیر کے لحاظ سے بیان کردہ کچھ طرز عمل عالمگیر ہوسکتے ہیں۔
رشتہ دار ڈھانچے کی منتقلی رشتہ دار ڈیٹا اسٹورز کی کمزور لچک سے نمٹنے کا ایک زبردست طریقہ ہے۔ OOP فیشن کے دور میں، ڈیٹا بیس کے ساتھ کام کرنے کے انداز کا مطلب یہ تھا کہ ہم اسکیما کو ایک بار بیان کریں گے اور اسے دوبارہ ہاتھ نہیں لگائیں گے۔ لیکن حقیقت یہ ہے کہ چیزیں بدل جاتی ہیں، اور میز کے ڈھانچے میں اکثر تبدیلیوں کی ضرورت ہوتی ہے۔ قدرتی طور پر، عمل خود دردناک اور ناخوشگوار ہو سکتا ہے.
میں آپ کے پروجیکٹ میں لائبریری شامل کرنے کے لیے ٹیکنالوجی اور ہدایات کی تفصیل میں مزید گہرائی میں نہیں جاؤں گا؛ اس موضوع پر بہت سے مضامین لکھے گئے ہیں:
اس کے علاوہ، مفید تجاویز کے موضوع پر پہلے سے ہی ایک بہترین مضمون تھا:
Советы
میں اپنے مشورے اور تبصرے شیئر کرنا چاہتا ہوں، جو ہجرت کے ساتھ مسائل کے حل کے پسینے، خون اور درد سے پیدا ہوئے تھے۔
1. کام شروع کرنے سے پہلے، آپ کو اپنے آپ کو بہترین طریقوں کے سیکشن سے واقف کرانا چاہیے۔ Liquibase
سادہ مگر انتہائی اہم چیزیں بیان کی گئی ہیں، جن کے بغیر لائبریری کا استعمال آپ کی زندگی کو پیچیدہ بنا سکتا ہے۔ مثال کے طور پر، تبدیلیوں کے انتظام کے لیے ایک غیر منظم انداز جلد یا بدیر الجھن اور ٹوٹی ہوئی نقل مکانی کا باعث بنے گا۔ اگر آپ ایک ہی وقت میں ڈیٹا بیس کے ڈھانچے اور سروس منطق میں باہمی منحصر تبدیلیاں نہیں لاتے ہیں، تو اس بات کا بہت زیادہ امکان ہے کہ یہ سرخ ٹیسٹ یا خراب ماحول کا باعث بنے گا۔ اس کے علاوہ، آفیشل ویب سائٹ پر Liquibase استعمال کرنے کی سفارشات میں مرکزی منتقلی اسکرپٹ کے ساتھ رول بیک اسکرپٹس کی ترقی اور جانچ کے بارے میں ایک شق بھی شامل ہے۔ ٹھیک ہے، مضمون میں نقل مکانی اور رول بیک میکانزم کے حوالے سے کوڈ کی مثالیں موجود ہیں۔
2. اگر آپ نقل مکانی کے اوزار استعمال کرنا شروع کرتے ہیں، تو ڈیٹا بیس کے ڈھانچے میں دستی اصلاحات کی اجازت نہ دیں۔
جیسا کہ کہاوت ہے: "ایک بار پرسیل، ہمیشہ پرسیل۔" اگر آپ کی درخواست کی بنیاد Liquibase کے زیر انتظام ہونا شروع ہو جاتی ہے، تو کوئی بھی دستی تبدیلی فوری طور پر متضاد حالت کی طرف لے جاتی ہے، اور تبدیلیوں پر اعتماد کی سطح صفر ہو جاتی ہے۔ ممکنہ خطرات میں ڈیٹا بیس کو بحال کرنے میں صرف کیے گئے کئی گھنٹے شامل ہیں؛ بدترین صورت حال میں، ایک مردہ سرور۔ اگر آپ کی ٹیم میں "پرانا اسکول" ڈی بی اے آرکیٹیکٹ ہے، تو صبر اور سوچ سمجھ کر اسے سمجھائیں کہ اگر وہ صرف ایک مشروط SQL ڈویلپر سے اپنی سمجھ کے مطابق ڈیٹا بیس میں ترمیم کرتا ہے تو چیزیں کتنی بری ہوں گی۔
3. اگر تبدیلی سیٹ کو پہلے ہی ذخیرہ میں دھکیل دیا گیا ہے، تو ترمیم کرنے سے گریز کریں۔
اگر کسی اور ڈویلپر نے ایک پل بنایا اور ایک تبدیلی کا اطلاق کیا، جس میں بعد میں ترمیم کی جائے گی، تو وہ یقینی طور پر آپ کو ایک مہربان لفظ کے ساتھ یاد رکھے گا جب اسے ایپلی کیشن شروع کرتے وقت کوئی غلطی موصول ہوگی۔ اگر تبدیلی سیٹ میں ترمیم کرنے سے کسی طرح ترقی میں رساؤ آجاتا ہے، تو آپ کو ہاٹ فکسز کی پھسلتی ڈھلوان پر عمل کرنا پڑے گا۔ مسئلہ کا نچوڑ ہیش سم کے ذریعہ تبدیلیوں کی توثیق پر منحصر ہے - Liquibase کا بنیادی طریقہ کار۔ چینج سیٹ کوڈ میں ترمیم کرتے وقت، ہیش کی رقم بدل جاتی ہے۔ تبدیلیوں کی تدوین اسی وقت ممکن ہے جب ڈیٹا کو کھوئے بغیر شروع سے پورے ڈیٹا بیس کو تعینات کرنا ممکن ہو۔ اس صورت میں، ایس کیو ایل یا ایکس ایم ایل کوڈ کو ری فیکٹر کرنا، اس کے برعکس، زندگی کو آسان بنا سکتا ہے اور نقل مکانی کو مزید پڑھنے کے قابل بنا سکتا ہے۔ ایک مثال ایسی صورت حال ہوگی جہاں، درخواست کے آغاز میں، ٹیم کے اندر ذریعہ ڈیٹا بیس کے اسکیما پر اتفاق کیا گیا تھا۔
4. اگر ممکن ہو تو تصدیق شدہ ڈیٹا بیس بیک اپ حاصل کریں۔
یہاں، میرے خیال میں، سب کچھ واضح ہے۔ اگر اچانک ہجرت ناکام ہو گئی تو سب کچھ واپس کیا جا سکتا ہے۔ Liquibase کے پاس تبدیلیوں کو واپس لانے کے لیے ایک ٹول ہے، لیکن رول بیک اسکرپٹس بھی خود ڈویلپر کے ذریعہ لکھے جاتے ہیں، اور انہیں اسی امکان کے ساتھ مسائل ہو سکتے ہیں جو کہ مین چینج سیٹ کے اسکرپٹس میں ہوتے ہیں۔ اس کا مطلب ہے کہ اسے کسی بھی صورت میں بیک اپ کے ساتھ محفوظ طریقے سے چلانا مفید ہے۔
5. اگر ممکن ہو تو ثابت شدہ ڈیٹا بیس بیک اپ کو ترقی میں استعمال کریں۔
اگر یہ معاہدوں اور رازداری سے متصادم نہیں ہے، تو ڈیٹا بیس میں کوئی ذاتی ڈیٹا نہیں ہے، اور اس کا وزن دو سورجوں جتنا نہیں ہے - لائیو مائیگریشن سرورز پر اسے استعمال کرنے سے پہلے، آپ چیک کر سکتے ہیں کہ یہ ڈویلپر کی مشین پر کیسے کام کرے گا اور حساب لگا سکتا ہے۔ ہجرت کے دوران تقریباً 100% ممکنہ مسائل۔
6. ٹیم کے دیگر ڈویلپرز کے ساتھ بات چیت کریں۔
ایک اچھی طرح سے منظم ترقیاتی عمل میں، ٹیم میں شامل ہر شخص جانتا ہے کہ کون کیا کر رہا ہے۔ حقیقت میں، ایسا اکثر نہیں ہوتا ہے، اس لیے، اگر آپ اپنے کام کے حصے کے طور پر ڈیٹا بیس کے ڈھانچے میں تبدیلیوں کی تیاری کر رہے ہیں، تو اس کے بارے میں پوری ٹیم کو اضافی طور پر مطلع کرنے کا مشورہ دیا جاتا ہے۔ اگر کوئی متوازی تبدیلیاں کر رہا ہے، تو آپ کو احتیاط سے ترتیب دینا چاہیے۔ یہ کام ختم کرنے کے بعد ساتھیوں کے ساتھ بات چیت کرنے کے قابل ہے، نہ صرف شروع میں۔ تبدیلیوں کے ساتھ بہت سے ممکنہ مسائل کوڈ کے جائزے کے مرحلے پر حل کیے جا سکتے ہیں۔
7. سوچیں کہ آپ کیا کر رہے ہیں!
یہ خود واضح مشورے کی طرح لگتا ہے جو کسی بھی صورتحال پر لاگو ہوتا ہے۔ تاہم، بہت سے مسائل سے بچا جا سکتا تھا اگر ڈویلپر ایک بار پھر تجزیہ کرتا کہ وہ کیا کر رہا ہے اور اس سے کیا اثر پڑ سکتا ہے۔ نقل مکانی کے ساتھ کام کرنے کے لیے ہمیشہ اضافی توجہ اور درستگی کی ضرورت ہوتی ہے۔
نیٹ ورک
آئیے اب ان عام جال کو دیکھتے ہیں جن میں آپ پھنس سکتے ہیں اگر آپ اوپر دیے گئے مشورے پر عمل نہیں کرتے ہیں، اور آپ کو بالکل کیا کرنا چاہیے؟
صورتحال 1: دو ڈویلپر ایک ہی وقت میں نئی تبدیلیاں شامل کرنے کی کوشش کر رہے ہیں۔
واسیا اور پیٹیا ایک دوسرے کے بارے میں جانے بغیر ایک چینج سیٹ ورژن 4 بنانا چاہتے ہیں۔ انہوں نے ڈیٹا بیس کے ڈھانچے میں تبدیلیاں کیں اور مختلف چینج سیٹ فائلوں کے ساتھ پل کی درخواست جاری کی۔ عمل کا مندرجہ ذیل طریقہ کار تجویز کیا گیا ہے:
فیصلہ کرنے کا طریقہ
- کسی نہ کسی طرح، ساتھیوں کو اس ترتیب پر متفق ہونا چاہیے جس میں ان کی تبدیلیوں کو جانا چاہیے، مثال کے طور پر، پیٹن کو پہلے لاگو کیا جانا چاہیے۔
- کسی کو خود میں دوسرا شامل کرنا چاہیے اور واسیا کے چینج سیٹ کو ورژن 5 کے ساتھ نشان زد کرنا چاہیے۔ یہ چیری پک یا صاف انضمام کے ذریعے کیا جا سکتا ہے۔
- تبدیلیوں کے بعد، آپ کو یقینی طور پر کیے گئے اقدامات کی درستگی کی جانچ کرنی چاہیے۔
درحقیقت، Liquibase میکانزم آپ کو ریپوزٹری میں دو ورژن 4 چینج سیٹس رکھنے کی اجازت دے گا، تاکہ آپ ہر چیز کو ویسا ہی چھوڑ سکیں۔ یعنی، آپ کے پاس مختلف ناموں کے ساتھ ورژن 4 میں صرف دو تبدیلیاں ہوں گی۔ اس نقطہ نظر کے ساتھ، بعد میں ڈیٹا بیس کے ورژن کو نیویگیٹ کرنا بہت مشکل ہو جاتا ہے۔
اس کے علاوہ، Liquibase، hobbits کے گھر کی طرح، بہت سے راز رکھتا ہے. ان میں سے ایک validCheckSum کلید ہے، جو ورژن 1.7 میں نمودار ہوئی ہے اور آپ کو ایک مخصوص تبدیلی سیٹ کے لیے ایک درست ہیش ویلیو بتانے کی اجازت دیتی ہے، قطع نظر اس کے کہ ڈیٹا بیس میں کیا ذخیرہ ہے۔ دستاویزی مندرجہ ذیل کہتے ہیں:
ایک چیکسم شامل کریں جو اس changeSet کے لیے درست سمجھا جاتا ہے، قطع نظر اس کے کہ ڈیٹا بیس میں کیا ذخیرہ ہے۔ بنیادی طور پر استعمال کیا جاتا ہے جب آپ کو تبدیلی سیٹ کو تبدیل کرنے کی ضرورت ہوتی ہے اور آپ نہیں چاہتے کہ ڈیٹا بیس پر غلطیاں پھینکی جائیں جن پر یہ پہلے سے چل چکا ہے (کوئی تجویز کردہ طریقہ کار نہیں)
ہاں، ہاں، اس طریقہ کار کی سفارش نہیں کی جاتی ہے۔ لیکن بعض اوقات ایک مضبوط روشنی کا جادوگر بھی تاریک تکنیکوں میں مہارت حاصل کرتا ہے۔
صورتحال 2: نقل مکانی جو ڈیٹا پر منحصر ہے۔
آئیے فرض کریں کہ آپ کے پاس لائیو سرورز سے ڈیٹا بیس بیک اپ استعمال کرنے کی اہلیت نہیں ہے۔ پیٹیا نے ایک چینج سیٹ بنایا، اس کا مقامی طور پر تجربہ کیا اور پورے اعتماد کے ساتھ کہ وہ صحیح تھا، ڈویلپر سے پل کی درخواست کی۔ صرف اس صورت میں، پروجیکٹ لیڈ نے واضح کیا کہ آیا پیٹیا نے اسے چیک کیا تھا، اور پھر اسے شامل کیا تھا۔ لیکن ڈیولپمنٹ سرور پر تعیناتی گر گئی۔
درحقیقت، یہ ممکن ہے، اور کوئی بھی اس سے محفوظ نہیں ہے۔ ایسا ہوتا ہے اگر ٹیبل کے ڈھانچے میں ترمیم کسی طرح ڈیٹا بیس کے مخصوص ڈیٹا سے منسلک ہو۔ ظاہر ہے، اگر پیٹیا کا ڈیٹا بیس صرف ٹیسٹ کے اعداد و شمار سے بھرا ہوا ہے، تو ہو سکتا ہے کہ یہ تمام مسائل کا احاطہ نہ کرے۔ مثال کے طور پر، جب کسی ٹیبل کو حذف کرتے ہیں، تو پتہ چلتا ہے کہ فارن کی کے ذریعے دیگر ٹیبلز میں ایسے ریکارڈ موجود ہیں جو حذف کیے جانے والے ریکارڈ سے متعلق ہیں۔ یا کالم کی قسم کو تبدیل کرتے وقت، پتہ چلتا ہے کہ 100% ڈیٹا کو نئی قسم میں تبدیل نہیں کیا جا سکتا۔
فیصلہ کرنے کا طریقہ
- خصوصی اسکرپٹ لکھیں جو ایک بار منتقلی کے ساتھ استعمال ہوں گی اور ڈیٹا کو مناسب شکل میں لائیں۔ ہجرت کو لاگو کرنے کے بعد ڈیٹا کو نئے ڈھانچے میں منتقل کرنے کے مسئلے کو حل کرنے کا یہ ایک عمومی طریقہ ہے، لیکن خاص معاملات میں اس سے پہلے بھی کچھ ایسا ہی لاگو کیا جا سکتا ہے۔ یہ راستہ، یقیناً، ہمیشہ دستیاب نہیں ہوتا، کیونکہ لائیو سرورز پر ڈیٹا میں ترمیم کرنا خطرناک اور تباہ کن بھی ہو سکتا ہے۔
- ایک اور مشکل طریقہ موجودہ تبدیلی سیٹ میں ترمیم کرنا ہے۔ مشکل یہ ہے کہ وہ تمام ڈیٹا بیس جہاں پہلے ہی اس کی موجودہ شکل میں لاگو ہو چکے ہیں کو بحال کرنا پڑے گا۔ یہ بہت ممکن ہے کہ پوری بیک اینڈ ٹیم کو مقامی طور پر شروع سے ڈیٹا بیس کو رول آؤٹ کرنے پر مجبور کیا جائے۔
- اور سب سے عالمگیر طریقہ یہ ہے کہ ڈیٹا کے ساتھ مسئلہ کو ڈویلپر کے ماحول میں منتقل کیا جائے، اسی صورت حال کو دوبارہ بنایا جائے اور ٹوٹے ہوئے میں ایک نیا چینج سیٹ شامل کیا جائے، جو مسئلہ کو دور کر دے گا۔
عام طور پر، جتنا زیادہ ڈیٹا بیس پروڈکشن سرور ڈیٹا بیس کی ساخت میں ملتا جلتا ہے، اتنا ہی کم امکان ہوگا کہ ہجرت کے ساتھ مسائل دور ہوجائیں گے۔ اور یقیناً، اس سے پہلے کہ آپ ریپوزٹری میں تبدیلی بھیجیں، آپ کو کئی بار سوچنا چاہیے کہ آیا اس سے کچھ ٹوٹ جائے گا۔
صورت حال 3. لیکوبیس پیداوار میں جانے کے بعد استعمال ہونا شروع ہو جاتی ہے۔
فرض کریں کہ ٹیم لیڈ نے Petya سے Liquibase کو پروجیکٹ میں شامل کرنے کے لیے کہا، لیکن پروجیکٹ پہلے ہی پروڈکشن میں ہے اور ڈیٹا بیس کا ڈھانچہ موجود ہے۔
اس کے مطابق، مسئلہ یہ ہے کہ کسی بھی نئے سرور یا ڈویلپر مشینوں پر، ان میزوں کو شروع سے دوبارہ بنایا جانا چاہیے، اور موجودہ ماحول کو ایک مستقل حالت میں رہنا چاہیے، نئی تبدیلیوں کو قبول کرنے کے لیے تیار رہنا چاہیے۔
فیصلہ کرنے کا طریقہ
اس کے بھی کئی طریقے ہیں:
- پہلا اور سب سے واضح یہ ہے کہ ایک علیحدہ اسکرپٹ ہو جسے نئے ماحول کی شروعات کرتے وقت دستی طور پر لاگو کیا جانا چاہیے۔
- دوسرا کم واضح ہے، ایک Liquibase منتقلی ہے جو دوسرے Liquibase سیاق و سباق میں ہے، اور اسے لاگو کریں۔ آپ یہاں Liquibase سیاق و سباق کے بارے میں مزید پڑھ سکتے ہیں: . عام طور پر، یہ ایک دلچسپ طریقہ کار ہے جسے کامیابی سے استعمال کیا جا سکتا ہے، مثال کے طور پر، جانچ کے لیے۔
- تیسرا راستہ کئی مراحل پر مشتمل ہے۔ سب سے پہلے، موجودہ ٹیبلز کے لیے ایک ہجرت بنانا ضروری ہے۔ پھر اسے کسی نہ کسی ماحول پر لاگو کرنا ہوگا اور اس طرح اس کی ہیش سم حاصل ہوگی۔ اگلا مرحلہ ہمارے غیر خالی سرور پر خالی Liquibase ٹیبلز کو شروع کرنا ہے، اور تبدیلیوں کے استعمال کی تاریخ کے ساتھ جدول میں، آپ ڈیٹا بیس میں پہلے سے موجود تبدیلیوں کے ساتھ "گویا لاگو" تبدیلی سیٹ کے بارے میں دستی طور پر ریکارڈ رکھ سکتے ہیں۔ . اس طرح، موجودہ سرور پر، تاریخ کا الٹی گنتی ورژن 2 سے شروع ہو جائے گی، اور تمام نئے ماحول ایک جیسا برتاؤ کریں گے۔
صورتحال 4. نقل مکانی بہت زیادہ ہو جاتی ہے اور ان کے پاس مکمل ہونے کا وقت نہیں ہوتا ہے۔
سروس ڈیولپمنٹ کے آغاز میں، ایک قاعدہ کے طور پر، Liquibase کو بیرونی انحصار کے طور پر استعمال کیا جاتا ہے، اور ایپلیکیشن شروع ہونے پر تمام منتقلی پر کارروائی کی جاتی ہے۔ تاہم، وقت گزرنے کے ساتھ، آپ کو درج ذیل معاملات میں ٹھوکر لگ سکتی ہے:
- نقل مکانی بہت زیادہ ہو جاتی ہے اور اسے مکمل ہونے میں کافی وقت لگتا ہے۔
- تقسیم شدہ ماحول میں منتقلی کی ضرورت ہے، مثال کے طور پر، بیک وقت کئی ڈیٹا بیس سرور مثالوں پر۔
اس صورت میں، بہت لمبے عرصے تک منتقلی کا اطلاق کرنے کے نتیجے میں درخواست شروع ہونے پر وقت ختم ہو جائے گا۔ مزید برآں، ہر ایپلیکیشن مثال کے لیے الگ الگ منتقلی کا اطلاق کرنے سے مختلف سرورز کی مطابقت پذیری ختم ہو سکتی ہے۔
فیصلہ کرنے کا طریقہ
ایسے معاملات میں، آپ کا پروجیکٹ پہلے سے ہی بڑا ہے، شاید ایک بالغ بھی، اور Liquibase ایک علیحدہ بیرونی ٹول کے طور پر کام کرنا شروع کر دیتا ہے۔ حقیقت یہ ہے کہ Liquibase بطور لائبریری ایک جار فائل میں مرتب کی گئی ہے، اور کسی پروجیکٹ کے اندر یا آزادانہ طور پر انحصار کے طور پر کام کر سکتی ہے۔
اسٹینڈ اسٹون موڈ میں، آپ اپنے CI/CD ماحول یا اپنے سسٹم ایڈمنسٹریٹرز اور تعیناتی ماہرین کے مضبوط کندھوں پر منتقلی کے نفاذ کو چھوڑ سکتے ہیں۔ ایسا کرنے کے لیے آپ کو Liquibase کمانڈ لائن کی ضرورت ہوگی۔ . اس موڈ میں، تمام ضروری منتقلی کے بعد ایپلیکیشن لانچ کرنا ممکن ہو جاتا ہے۔
آؤٹ پٹ
درحقیقت، ڈیٹا بیس کی منتقلی کے ساتھ کام کرتے وقت اور بھی بہت سے نقصانات ہوسکتے ہیں، اور ان میں سے بہت سے تخلیقی نقطہ نظر کی ضرورت ہوتی ہے۔ یہ سمجھنا ضروری ہے کہ اگر آپ ٹول کو صحیح طریقے سے استعمال کرتے ہیں، تو ان میں سے زیادہ تر نقصانات سے بچا جا سکتا ہے۔ خاص طور پر، مجھے مختلف شکلوں میں درج تمام مسائل سے نمٹنا پڑا، اور ان میں سے کچھ میری غلطیوں کا نتیجہ تھے۔ زیادہ تر ایسا ہوتا ہے، یقیناً عدم توجہی کی وجہ سے، لیکن بعض اوقات اس ٹول کو استعمال کرنے میں مجرمانہ نااہلی کی وجہ سے ہوتا ہے۔
ماخذ: www.habr.com