میری مشین پر کام کرتا ہے: یہ کیا ہے، کیوں ہوتا ہے اور کیسے روکیں

«میری مشین پر کام کرتا ہے» کا کیا مطلب ہے

«میری مشین پر کام کرتا ہے» — وہ جملہ جو ڈیولپر اس وقت کہتا ہے جب کوئی ساتھی یا ٹیسٹر بگ کی رپورٹ کرتا ہے، لیکن بگ ڈیولپر کی مشین پر دوبارہ پیدا نہیں ہوتا۔ ظاہری طور پر یہ مسئلے کا انکار لگتا ہے، لیکن تکنیکی طور پر صورت حال حقیقی ہے: کوڈ ایک ماحول میں کام کر سکتا ہے اور دوسرے میں ناکام ہو سکتا ہے۔ ترتیب کا ایک بٹ بھی بدل جائے تو ایپلیکیشن کا رویہ مکمل طور پر بدل جاتا ہے۔

یہ جملہ IT کمیونیٹی میں ایک میم بن گیا ہے کیونکہ یہ بک بار سچا اور بے کار ہے۔ ڈیولپر کے نقطہ نظر سے — کوڈ واقعی میں اس کی مشین پر کام کرتا ہے۔ ٹیم کے نقطہ نظر سے — مسئلہ موجود ہے اور اسے حل کرنے کی ضرورت ہے، جواز نہیں۔ صورت حال کا مزاق یہ ہے کہ ڈیولپر سچ کہتا ہے، لیکن یہ سچ بگ کو ٹھیک کرنے میں مدد نہیں کرتا۔ یہ میم اتنا مقبول ہے کہ Reddit، XKCD اور DevOps کانفرنسز پر ہزاروں پوسٹ اس کے لیے مخصوص ہیں۔

عملی نقطہ نظر سے، «میری مشین پر کام کرتا ہے» کا جملہ ماحول کی تولید کی مسائل کا اشارہ کرنے والا ایک اشارہ ہے۔ اگر دو ڈیولپر ایک ہی کوڈ پر ایک ہی نتیجہ حاصل نہیں کر سکتے — تو ماحول کے قیام کا عمل معیاری نہیں ہے۔ DevOps کا عمل کہتا ہے: ماحول مانوی عمل کے بغیر ریپوزیٹری سے ایک کمانڈ سے دوبارہ پیدا کیا جا سکنا چاہیے۔

مقامی ماحول پروڈکشن سے کیوں مختلف ہے

ڈیولپر کا مقامی ماحول تقریبنا ہمیشہ پروڈکشن سے مختلف ہوتا ہے۔ ڈیولپر macOS یا Windows استعمال کرتا ہے، جبکہ سرور Linux پر چلتا ہے۔ مختلف آپریٹنگ سسٹم میں مختلف فائل سسٹم، انکوڈنگ، ثریڈ ٹائمنگ اور سسٹم کالز ہوتے ہیں۔ اگر دونوں ماحول Linux بھی ہوں — کرنل، glibc، OpenSSL کے ورشن مختلف ہو سکتے ہیں۔

دوسری وجہ — نصب شدہ سافٹ ویئر کا سیٹ۔ ڈیولپر کی مشین پر Node.js 20 کا عالمی ورشن نصب ہو سکتا ہے، جبکہ CI/CD ترتیب میں ورشن 18 متعین ہو سکتا ہے۔ یا ڈیولپر مقامی طور پر PostgreSQL 16 استعمال کرتا ہے، اور پروڈکشن پر — PostgreSQL 14۔ مائنر ورشن میں فرق عام طور پر قابل توجہ نہیں ہوتے، لیکن بڑے اپڈیٹ SQL کیریوں کے رویہ کو بدل سکتے ہیں۔ npm Inc. کے مطابق، انحصارات سے متعلق 67% بگ پیچ ورشن میں فرق کے نتیجے میں ہوتے ہیں۔

تیسری وجہ — نیٹ ورک کے حالات۔ مقامی مشین پر کوئی تاخیر، بینڈوڈھ کی حدود یا DNS کے مسائل نہیں ہوتے۔ پروڈکشن پر، کسی بیرونی API کی کوئی درخواست 5 ms کے بجائے 500 ms لے سکتی ہے۔ ٹائم آؤٹ، دوبارہ کوشش کی لاگیک، ریس کنڈیشن — یہ سارے مسائل صرف حقیقی بوجہ اور حقیقی نیٹ ورک کے حالات میں ظاہر ہوتے ہیں۔ Toxiproxy جیسے اوزاروں کے ذریعے نیٹ ورک ایمیولیشن دیپلئے سے پہلے ایسے مسائل کی شناخت میں مدد کرتا ہے۔

مقامی طور پر بگ کی غیر تولید کی عام وجوہات

پہلی وجہ — ڈیٹا کی کمی۔ ڈیولپر ٹیسٹ فکسچرز کے ساتھ کام کرتا ہے، جبکہ پروڈکشن میں غیر متوقع قیمتوں کے ساتھ لاکھوں ریکارڈز ہوتے ہیں۔ NULL ایک فیلڈ میں جسے ڈیولپر لازمی سمجھتا تھا، نام میں Unicode کرکٹر، بہت لمبا سٹرنگ — یہ سب ایسے بگ پیدا کر سکتے ہیں جو مصنوعی ڈیٹا کے ساتھ مقامی DB پر دوبارہ پیدا نہیں کیے جا سکتے۔

دوسری وجہ — مختلف کامپائل اور بلڈ فلیگز۔ ریلیز بلڈ (Release/Distribution) ڈبگ بلڈ (Debug) سے مختلف ہو سکتا ہے۔ کامپائلر اپٹیمائیزیشن، ڈبگ لاگز کا خاتمہ، فنکشن ان لائن — یہ سب بگ چھپا سکتے ہیں یا اس کے برعکس ظاہر کر سکتے ہیں۔ عام مثال: ڈبگ بلڈ میں assert کام کرتا ہے جو ریلیز میں متغیرات کے ابتدائیے کردار کے مختلف ترتیب کے نتیجے میں ناکام ہوتا ہے۔

تیسری وجہ — مقامی کیش اور عارضی فائلیں۔ ڈیولپر بگ کو محسوس نہیں کر سکتا کیونکہ براؤزر میں پورانے اسکرپٹس کیش ہیں، Redis میں فرسودہ ڈیٹا محفوظ ہے، اور فائل سسٹم میں پځځلے رن کی عارضی فائلیں موجود ہیں۔ صاف رن (پرائیویٹ موڈ، کیش صاف کرنا، fresh install) اکسر اس بگ کو دوبارہ پیدا کرتا ہے جو “خود بھی” ظاہر نہیں ہوا تھا۔

چوتھی وجہ — عالمی اور مقامی انحصارات کا تصادم۔ Ruby gems، Python pip، Node.js npm جیسے اوزاروں میں عالمی طور پر نصب شدہ پیکیج ہو سکتے ہیں جو کوڈ کو مقامی طور پر کام کرنے میں “مدد” کرتے ہیں لیکن پروڈکشن میں غائب ہیں۔ ورڈشوئل ماحول (virtualenv، venv، nvm) کا استعمال پروجیکٹ کو عالمی تنصیبوں سے علیحدہ کرتا ہے اور ماحول کو دوبارہ پیدا کرنے کابل بناتا ہے۔

ٹیم ورک اور اعتماد پر اثر

«میری مشین پر کام کرتا ہے» کا جملہ ٹیم میں اعتماد ختم کر دیتا ہے۔ اگر ڈیولپر باقاعدہ بگ دوبارہ پیدا نہیں کر سکتا، تو ساتھی اس کی قابلیت یا ٹیسٹ کی گہرائی پر شک کرنے لگتے ہیں۔ وقت گزرنے کے ساتھ یہ مائیکرو مینجمنٹ کا سبب بنتا ہے: ہر تبدیلی کے لیے دوسرے ڈیولپر سے تصدیق درکار ہوتی ہے، جو ترقی کو سست کر دیتا ہے۔ Google Project Aristotle کے مطابق، ٹیم میں نفسیاتی حفاظت برا߁ راست پاداوری کو متاثر کرتی ہے، اور ماحول کے بارے میں مسلسل تنازع اس کو کم کرنے والے عوامل میں سے ایک ہے۔

دوسرا مسئلہ — code review کا سست ہونا۔ اگر ڈیولپر مقامی طور پر بگ کو دوبارہ پیدا نہیں کر سکتا، تو وہ ساتھی کے pull request کو “میرے پاس کام کرتا ہے — یعنی مسئلہ تمھارا ہے” کہکر مسترد کر سکتا ہے۔ یہ تنازعات کو ہوا دیتا ہے اور فیچر کی دلیوری میں تاخیر کرتا ہے۔ ماحول کی معیاری سازی اس تنازع کو ختم کرتی ہے: اگر دونوں ڈیولپر ایک ہی Docker کنٹینر میں کام کرتے ہیں، تو “کس کے پاس کام کرتا ہے” کا سوال بے معنی ہو جاتا ہے۔

تیسرا مسئلہ — ٹریکر میں بگ کا نقصان۔ بگ جو “ڈیولپر کے پاس دوبارہ پیدا نہیں ہوتے” اکسر “دوبارہ پیدا نہیں کیا جا سکتا” (Cannot Reproduce) کے نوٹ سے بند کر دیے جاتے ہیں۔ ایک مہینے بعد بگ پروڈکشن میں ظاہر ہوتا ہے، اور اسکا حل 10 گنا مہنگا پڑتا ہے۔ قاعدہ: اگر بگ کم از کم ایک شخص میں دوبارہ پیدا ہوتا ہے — وہ موجود ہے، اس بات سے آزاد کہ وہ ڈیولپر کے پاس کام کرتا ہے یا نہیں۔

ڈیولپر ماحول کو معیاری کیسے بنایں

پہلا اور سب سے مؤثر طریقہ — Docker۔ پورا پروجیکٹ بغیر کسی اضافی عمل کے docker-compose up کے ذریعے چلنا چاہیے۔ ڈیٹابیس، کیش، پیغام کی قطار، ویب سرور — سب کنٹینروں میں چلتا ہے۔ ڈیولپر صرف Docker اور Git نصب کرتا ہے۔ باقی — کنٹینروں کے اندر۔ یہ اس بات کی ضمانت دیتا ہے کہ ٹیم کے تمام ارکان کا ماحول آپریٹنگ سسٹم سے آزاد ایک جیسا ہے۔

دوسرا طریقہ — ورشن مینجرز۔ اگر Docker ممکن نہیں (لائسنس کی پابندیاں، لگیسی انفراسٹرکچر)، تو nvm (Node.js)، rbenv (Ruby)، pyenv (Python)، sdkman (Java) استعمال کریں۔ ورشن مینجرز پروجیکٹ کے اندر زبانوں اور اوزاروں کے ورشن کو بدلنے کی اجازت دیتے ہیں۔ .nvmrc، .ruby-version، .python-version فائلیں ریپوزیٹری میں ہونی چاہیے اور CI/CD سے تصدیق کی جانی چاہیے۔

تیسرا طریقہ — ورڈشوئل مشینوں کے لیے Vagrant۔ Vagrant VirtualBox یا VMware پر متعین آپریٹنگ سسٹم اور ترتیب کے ساتھ ورڈشوئل مشین شروع کرتا ہے۔ VM کے اندر، تمام انحصارات provisioning اسکرپٹس (shell، Ansible، Puppet) کے ذریعے نصب کی جاتی ہیں۔ Vagrant Docker سے بھاری ہے لیکن آپریٹنگ سسٹم کی سطح پر مکمل علاحدگی فراہم کرتا ہے — ان پروجیکٹوں کے لیے مفید جو Linux کرنل کے مختص ورشن پر انحصر کرتے ہیں۔

چوتھا — makefile اور bootstrap اسکرپٹس۔ install، test، build، clean کے مقاصد کے ساتھ ایک سادہ Makefile بھی روٹین کاموں کو معیاری بنا سکتا ہے۔ make install کمانڈ کو تمام انحصارات نصب کرنے، DB ترتیب دینے اور ٹیسٹ ڈیٹا بنانے چاہیے۔ تمام ڈیولپرز کے لیے ایک واردے کا مقام ماحول کے قیام میں مانوی غلطیوں کو ختم کرتا ہے۔

ماحولی اختلاف کو روکنے کے اوزار

بنیادی اوزار — انحصارات کی lock فائلیں۔ package-lock.json (npm)، yarn.lock (Yarn)، Podfile.lock (CocoaPods)، pubspec.lock (Flutter) ہر پیکیج کے عین ورشن کو مقرر کرتی ہیں۔ lock فائل کے بغیر، مختلف اوقات پر انحصارات نصب کرنے والے دو ڈیولپر مختلف مائنر ورشن حاصل کر سکتے ہیں۔ Lock فائل ریپوزیٹری میں ہونی چاہیے اور مانوی طور پر ترمیم نہیں کی جانی چاہیے۔

دوسرا اوزار — ریپوزیٹری میں .env.example۔ تبصروں کے ساتھ ماحولی متغیرات کی سانچہ فائل۔ ڈیولپر اسے .env میں کاپی کرتا ہے اور اپنی قیمتیں بھرتا ہے۔ CI/CD پائپ لائن تصدیق کرتی ہے کہ تمام لازمی متغیرات مقرر کیے گئے ہیں۔ GitLab 2023 کے مطابق، .env.example استعمال کرنے والے ٹیم ماحولی متغیرات سے متعلق واقعات کی تعداد میں 40% تک کمی کرتے ہیں۔

تیسرا اوزار — pre-commit ہوکس۔ ہر کمیٹ سے پہلے چلنے والی خودکار تصدیق: لنٹر، فارمیٹر، قسموں کی تصدیق، ٹیسٹ۔ اگر ہوکس تمام ڈیولپرز میں ایک جیسے ترتیب دیئے گئے ہیں، تو فارمیٹنگ یا قسم کی غلطیاں جو “مقامی مشین پر ٹھیڡوارے” پروڈکشن تک نہیں پہنچیں۔ JavaScript کے لیے Husky اور Python کے لیے pre-commit مقبول حل ہیں۔

چوتھا — CI/CD پائپ لائن جو صاف ماحول میں ٹیسٹ چلاتی ہے۔ اگر ٹیسٹ CI میں پاس ہوتے ہیں لیکن مقامی طور پر نہیں — مسئلہ مقامی ماحول کی ترتیب میں ہے۔ اگر ٹیسٹ CI میں پاس نہیں ہوتے — pull request مرج نہیں ہوتا۔ یہ سخت قاعدہ “مقامی طور پر کام کرنے والے” بگ کو مین شاخ میں آنے سے روکتا ہے۔