آئیے اس بات پر بحث کرتے ہیں کہ کیوں CI ٹولز اور CI بالکل مختلف چیزیں ہیں۔
CI کس درد کو حل کرنے کا ارادہ رکھتا ہے، خیال کہاں سے آیا، تازہ ترین تصدیقات کیا ہیں کہ یہ کام کرتا ہے، یہ کیسے سمجھیں کہ آپ کے پاس پریکٹس ہے اور صرف جینکنز انسٹال نہیں ہے۔
کنٹینیوئس انٹیگریشن کے بارے میں رپورٹ بنانے کا خیال ایک سال پہلے آیا، جب میں انٹرویو کے لیے جا رہا تھا اور نوکری کی تلاش میں تھا۔ میں نے 10-15 کمپنیوں سے بات کی، ان میں سے صرف ایک ہی واضح طور پر جواب دینے کے قابل تھی کہ CI کیا ہے اور یہ بتانے کے قابل تھا کہ انہیں کیسے معلوم ہوا کہ ان کے پاس یہ نہیں ہے۔ باقی جینکنز کے بارے میں ناقابل فہم بکواس کر رہے تھے :) ٹھیک ہے، ہمارے پاس جینکنز ہے، یہ بناتا ہے، سی آئی! رپورٹ کے دوران، میں یہ بتانے کی کوشش کروں گا کہ Continuous Integration اصل میں کیا ہے اور کیوں جینکنز اور اس جیسے ٹولز کا اس کے ساتھ بہت کمزور تعلق ہے۔
تو، جب آپ لفظ CI سنتے ہیں تو عام طور پر ذہن میں کیا آتا ہے؟ زیادہ تر لوگ جینکنز، گٹلاب سی آئی، ٹریوس وغیرہ کے بارے میں سوچیں گے۔
یہاں تک کہ اگر ہم اسے گوگل کرتے ہیں تو یہ ہمیں یہ ٹولز دے گا۔
اگر آپ پوچھنے سے واقف ہیں، تو ٹولز کی فہرست بنانے کے فوراً بعد، وہ آپ کو بتائیں گے کہ CI تب ہوتا ہے جب آپ پل ریکوئسٹ فار کمٹ میں ٹیسٹ بناتے اور چلاتے ہیں۔
مسلسل انضمام ٹولز کے بارے میں نہیں ہے، برانچ میں ٹیسٹ کے ساتھ اسمبلیوں کے بارے میں نہیں ہے! مسلسل انٹیگریشن نئے کوڈ کے بہت بار بار انضمام کی مشق ہے اور اسے استعمال کرنے کے لیے جینکنز، گٹ لیب وغیرہ پر باڑ لگانا بالکل بھی ضروری نہیں ہے۔
اس سے پہلے کہ ہم یہ معلوم کریں کہ ایک مکمل CI کیسا لگتا ہے، آئیے پہلے ان لوگوں کے سیاق و سباق میں غوطہ لگائیں جو اس کے ساتھ آئے ہیں اور اس تکلیف کو محسوس کریں جو وہ حل کرنے کی کوشش کر رہے تھے۔
اور انہوں نے ایک ٹیم کے طور پر مل کر کام کرنے کے درد کو حل کیا!
آئیے ٹیموں میں ترقی کرتے وقت ڈویلپرز کو درپیش مشکلات کی مثالیں دیکھیں۔ یہاں ہمارے پاس ایک پروجیکٹ ہے، گٹ میں ایک ماسٹر برانچ اور دو ڈویلپرز۔
اور وہ کام پر چلے گئے جیسا کہ ہر کوئی کافی عرصے سے عادی تھا۔ ہم نے چیزوں کی عظیم اسکیم میں ایک کام لیا، ایک فیچر برانچ بنائی، اور کوڈ لکھا۔
ایک نے خصوصیت کو تیزی سے ختم کیا اور اسے ماسٹر میں ضم کردیا۔
دوسرے کو مزید وقت درکار تھا، یہ بعد میں ضم ہو گیا اور تنازعہ پر ختم ہوا۔ اب، کاروبار کو درکار خصوصیات لکھنے کے بجائے، ڈویلپر اپنا وقت اور توانائی تنازعات کو حل کرنے میں صرف کرتا ہے۔
اپنی خصوصیت کو ایک عام ماسٹر کے ساتھ جوڑنا جتنا مشکل ہے، ہم اس پر اتنا ہی زیادہ وقت صرف کرتے ہیں۔ اور میں نے اسے ایک سادہ سی مثال کے ساتھ دکھایا۔ یہ ایک مثال ہے جہاں صرف 2 ڈویلپرز ہیں۔ تصور کریں کہ کیا ایک کمپنی میں 10 یا 15 یا 100 لوگ ایک ذخیرہ کو لکھتے ہیں۔ آپ ان تمام تنازعات کو حل کرنے کے لیے پاگل ہو جائیں گے۔
ایک قدرے مختلف معاملہ ہے۔ ہمارے پاس ایک ماسٹر ہے اور کچھ ڈویلپر کچھ کر رہے ہیں۔
انہوں نے ایک ٹہنی بنائی۔
ایک مر گیا، سب ٹھیک تھا، اس نے ٹاسک پاس کیا۔
اس دوران دوسرے ڈویلپر نے اپنا کام سونپ دیا۔ مان لیں کہ اس نے اسے جائزہ کے لیے بھیجا تھا۔ بہت سی کمپنیوں کی ایک پریکٹس ہے جسے ریویو کہتے ہیں۔ ایک طرف، یہ مشق اچھی اور مفید ہے، دوسری طرف، یہ ہمیں کئی طریقوں سے سست کر دیتی ہے۔ ہم اس میں نہیں جائیں گے، لیکن یہاں ایک عمدہ مثال ہے کہ جائزہ لینے کی ایک بری کہانی کیا لے سکتی ہے۔ آپ نے نظرثانی کے لیے پل کی درخواست جمع کرائی ہے۔ ڈویلپر کے لیے مزید کچھ نہیں ہے۔ وہ کیا کرنے لگتا ہے؟ وہ دوسرے کام کرنے لگتا ہے۔
اس وقت کے دوران، دوسرے ڈویلپر نے کچھ اور کیا.
پہلے نے تیسرا کام مکمل کیا۔
اور کچھ عرصے بعد، اس کا جائزہ لیا گیا، اور وہ شرائط پر آنے کی کوشش کر رہا ہے. تو کیا ہو رہا ہے؟ یہ تنازعات کی ایک بڑی تعداد کو پکڑتا ہے. کیوں؟ کیونکہ جب اس کی پل کی درخواست جائزے میں لٹک رہی تھی، کوڈ میں بہت سی چیزیں پہلے ہی بدل چکی تھیں۔
تنازعات کے ساتھ کہانی کے علاوہ، مواصلات کے ساتھ ایک کہانی ہے. جب آپ کا تھریڈ ریویو پر لٹک رہا ہوتا ہے، جب کہ یہ کسی چیز کا انتظار کر رہا ہوتا ہے، جب آپ کسی فیچر پر طویل عرصے سے کام کر رہے ہوتے ہیں، تو آپ اس بات کا پتہ لگانا بند کر دیتے ہیں کہ آپ کی سروس کے کوڈ بیس میں اور کیا کچھ تبدیل ہو رہا ہے۔ شاید آپ جو ابھی حل کرنے کی کوشش کر رہے ہیں وہ کل ہی حل ہو چکا تھا اور آپ کوئی طریقہ اختیار کر کے اسے دوبارہ استعمال کر سکتے ہیں۔ لیکن آپ کو یہ نظر نہیں آئے گا کیونکہ آپ ہمیشہ ایک پرانی شاخ کے ساتھ کام کر رہے ہیں۔ اور اس فرسودہ برانچ کے نتیجے میں ہمیشہ آپ کو انضمام کا تنازعہ حل کرنا پڑتا ہے۔
یہ پتہ چلتا ہے کہ اگر ہم ایک ٹیم کے طور پر کام کرتے ہیں، یعنی، ذخیرہ میں ایک شخص نہیں بلکہ 5-10 لوگ گھوم رہے ہیں، تو ہم جتنا زیادہ وقت تک اپنے کوڈ کو ماسٹر میں شامل نہیں کریں گے، ہمیں اتنا ہی زیادہ نقصان اٹھانا پڑے گا کیونکہ ہمیں آخر کار ضرورت ہے۔ کچھ پھر اسے ضم کریں۔ اور ہمارے پاس جتنے زیادہ تنازعات ہیں، اور ہم جتنے پرانے ورژن کے ساتھ کام کرتے ہیں، اتنے ہی زیادہ مسائل ہوتے ہیں۔
ایک ساتھ کچھ کرنا تکلیف دہ ہے! ہم ہمیشہ ایک دوسرے کے راستے میں آتے ہیں۔
یہ مسئلہ 20 سال سے زیادہ پہلے دیکھا گیا تھا۔ مجھے انتہائی پروگرامنگ میں مسلسل انضمام کی مشق کا پہلا ذکر ملا۔
ایکسٹریم پروگرامنگ پہلا فرتیلی فریم ورک ہے۔ یہ صفحہ 96 میں شائع ہوا۔ اور خیال یہ تھا کہ کچھ قسم کے پروگرامنگ کے طریقوں، منصوبہ بندی اور دیگر چیزوں کو استعمال کیا جائے، تاکہ ترقی ممکن حد تک لچکدار ہو، تاکہ ہم اپنے کلائنٹس کی طرف سے کسی بھی تبدیلی یا ضروریات کا فوری جواب دے سکیں۔ اور انہوں نے 24 سال پہلے اس بات کا سامنا کرنا شروع کر دیا تھا کہ اگر آپ کوئی کام بہت لمبے عرصے کے لیے کرتے ہیں، تو آپ اس پر زیادہ وقت صرف کرتے ہیں کیونکہ آپ کے درمیان تنازعات ہوتے ہیں۔
اب ہم انفرادی طور پر "مسلسل انضمام" کے جملے کا تجزیہ کریں گے۔ اگر ہم اس کا براہ راست ترجمہ کرتے ہیں تو ہمیں مسلسل انضمام ملتا ہے۔ لیکن یہ کتنا مسلسل ہے یہ بہت واضح نہیں ہے؛ یہ بہت منقطع ہے۔ لیکن اس میں کتنا انضمام ہے یہ بھی زیادہ واضح نہیں ہے۔
اور اسی لیے اب میں آپ کو Extreme Programming کے حوالے دے رہا ہوں۔ اور ہم دونوں الفاظ کا الگ الگ تجزیہ کریں گے۔
انضمام - جیسا کہ میں نے پہلے ہی کہا ہے، ہم اس بات کو یقینی بنانے کی کوشش کرتے ہیں کہ ہر انجینئر کوڈ کے جدید ترین ورژن کے ساتھ کام کرے، تاکہ وہ اپنے کوڈ کو زیادہ سے زیادہ ایک مشترکہ برانچ میں شامل کرنے کی کوشش کرے، تاکہ یہ چھوٹی شاخیں ہوں۔ کیونکہ اگر وہ بڑے ہیں، تو ہم آسانی سے ایک ہفتہ تک انضمام کے تنازعات میں پھنس سکتے ہیں۔ یہ خاص طور پر سچ ہے اگر ہمارے پاس ایک طویل ترقیاتی سائیکل ہے جیسے آبشار، جہاں ڈویلپر کچھ بڑی خصوصیت کو کاٹنے کے لیے ایک ماہ کے لیے چلا گیا۔ اور وہ بہت طویل عرصے تک انضمام کے مرحلے میں پھنس جائے گا۔
انضمام اس وقت ہوتا ہے جب ہم اپنی شاخ لیتے ہیں اور اسے ماسٹر کے ساتھ ضم کرتے ہیں، ہم اسے ضم کرتے ہیں۔ جب ہم ٹرانسبیس ڈویلپر ہوتے ہیں تو ایک حتمی آپشن ہوتا ہے، جہاں ہم اس بات کو یقینی بنانے کی کوشش کرتے ہیں کہ ہم فوری طور پر بغیر کسی اضافی شاخ کے ماسٹر کو لکھیں۔
عام طور پر، انضمام کا مطلب ہے آپ کا کوڈ لینا اور اسے ماسٹر میں گھسیٹنا۔
یہاں لفظ "مسلسل" سے کیا مراد ہے، تسلسل کسے کہتے ہیں؟ پریکٹس کا مطلب ہے کہ ڈویلپر اپنے کوڈ کو جلد از جلد ضم کرنے کی کوشش کرتا ہے۔ کسی بھی کام کو انجام دیتے وقت یہ اس کا مقصد ہوتا ہے - اپنے کوڈ کو جلد از جلد ماسٹر میں حاصل کرنا۔ ایک مثالی دنیا میں، ڈویلپرز ہر چند گھنٹوں میں ایسا کریں گے۔ یعنی آپ ایک چھوٹا سا مسئلہ لے کر اسے ماسٹر میں ضم کر دیں۔ سب کچھ بہت اچھا ہے. یہ وہی ہے جس کے لئے آپ کوشش کرتے ہیں۔ اور یہ کام مسلسل کرنا چاہیے۔ جیسے ہی آپ کچھ کرتے ہیں، آپ اسے فوری طور پر ماسٹر میں ڈال دیتے ہیں.
اور ڈویلپر جو کچھ بناتا ہے اس کا ذمہ دار ہے کہ اس نے اسے کام کرنے کے لئے کیا کیا اور کچھ بھی نہیں توڑا۔ یہ وہ جگہ ہے جہاں عام طور پر ٹیسٹ کی کہانی سامنے آتی ہے۔ ہم اپنے عزم پر، اپنے انضمام پر، اس بات کو یقینی بنانے کے لیے کچھ ٹیسٹ چلانا چاہتے ہیں کہ یہ کام کرتا ہے۔ اور یہ وہ جگہ ہے جہاں جینکنز آپ کی مدد کر سکتے ہیں۔
لیکن کہانیوں کے ساتھ: آئیے تبدیلیوں کو چھوٹا کریں، کاموں کو چھوٹا ہونے دیں، آئیے ایک مسئلہ بنائیں اور فوری طور پر کسی نہ کسی طرح اسے ماسٹر میں شامل کرنے کی کوشش کریں - یہاں کوئی جینکنز مدد نہیں کرے گا۔ کیونکہ جینکنز صرف ٹیسٹ چلانے میں آپ کی مدد کرے گی۔
آپ ان کے بغیر کر سکتے ہیں۔ اس سے آپ کو بالکل بھی تکلیف نہیں ہوگی۔ کیونکہ پریکٹس کا مقصد جتنی بار ممکن ہو پیمائش کرنا ہے، تاکہ مستقبل میں کسی بھی تنازعہ پر بہت زیادہ وقت ضائع نہ ہو۔
آئیے تصور کریں کہ کسی وجہ سے ہم 2020 میں انٹرنیٹ کے بغیر ہیں۔ اور ہم مقامی طور پر کام کرتے ہیں۔ ہمارے پاس جینکنز نہیں ہے۔ یہ ٹھیک ہے. آپ اب بھی آگے بڑھ سکتے ہیں اور مقامی برانچ بنا سکتے ہیں۔ آپ نے اس میں کچھ کوڈ لکھا۔ ہم نے 3-4 گھنٹے میں کام مکمل کیا۔ ہم نے ماسٹر پر سوئچ کیا، ایک گٹ پل کیا، اور اپنی شاخ کو وہاں ضم کر دیا۔ تیار. اگر آپ اکثر ایسا کرتے ہیں، مبارک ہو، آپ کے پاس مسلسل انضمام ہے!
جدید دنیا میں اس بات کا کیا ثبوت ہے کہ توانائی خرچ کرنے کے قابل ہے؟ کیونکہ عام طور پر یہ مشکل ہے۔ اگر آپ اس طرح کام کرنے کی کوشش کریں گے تو آپ سمجھیں گے کہ اب کچھ منصوبہ بندی متاثر ہوگی، آپ کو سڑنے والے کاموں میں مزید وقت دینا پڑے گا۔ کیونکہ اگر آپ انسان... کرتے ہیں، تو آپ جلدی سمجھ میں نہیں آسکیں گے اور، اس کے مطابق، مصیبت میں پڑ جائیں گے۔ آپ کو اب مشق نہیں ہوگی۔
اور یہ مہنگا ہوگا۔ مسلسل انضمام کا استعمال کرتے ہوئے کل سے فوری طور پر کام کرنا ممکن نہیں ہوگا۔ آپ کو اس کی عادت ڈالنے میں بہت زیادہ وقت لگے گا، آپ کو سڑنے والے کاموں کی عادت ڈالنے میں بہت وقت لگے گا، ریویو پریکٹس کو دوبارہ کرنے کی عادت ڈالنے میں بہت وقت لگے گا، اگر آپ کے پاس کوئی ہے . کیونکہ ہمارا مقصد آج اسے پگھلنا ہے۔ اور اگر آپ تین دن کے اندر جائزہ لیتے ہیں، تو آپ کو پریشانی ہوتی ہے اور کنٹینیوئس انٹیگریشن آپ کے لیے کام نہیں کر رہا ہے۔
لیکن کیا ہمارے پاس ابھی کوئی متعلقہ ثبوت موجود ہے جو ہمیں بتاتا ہے کہ اس پریکٹس میں سرمایہ کاری کرنا معنی خیز ہے؟
پہلی چیز جو میرے ذہن میں آئی وہ تھی DevOps کی ریاست۔ یہ ایک مطالعہ ہے جو لڑکے 7 سال سے کر رہے ہیں۔ اب وہ اسے ایک آزاد تنظیم کے طور پر کرتے ہیں، لیکن گوگل کے تحت۔
اور ان کے 2018 کے مطالعے نے ان کمپنیوں کے درمیان باہمی تعلق کو ظاہر کیا جو مختصر مدت کی شاخوں کو استعمال کرنے کی کوشش کرتی ہیں جو تیزی سے مربوط ہوتی ہیں، اکثر انضمام ہوتی ہیں، اور بہتر آئی ٹی کارکردگی کے اشارے رکھتی ہیں۔
یہ اشارے کیا ہیں؟ یہ 4 میٹرکس ہیں جو وہ اپنے سوالناموں میں تمام کمپنیوں سے لیتے ہیں: تعیناتی کی فریکوئنسی، تبدیلیوں کے لیے لیڈ ٹائم، سروس کو بحال کرنے کا وقت، ناکامی کی شرح میں تبدیلی۔
اور، سب سے پہلے، یہ باہمی تعلق ہے، ہم جانتے ہیں کہ وہ کمپنیاں جو کثرت سے پیمائش کرتی ہیں ان کے میٹرکس بہت بہتر ہوتے ہیں۔ اور ان کی کمپنیوں کو کئی زمروں میں تقسیم کیا گیا ہے: یہ سست کمپنیاں ہیں جو آہستہ آہستہ کچھ پیدا کرتی ہیں، درمیانے درجے کی کارکردگی کرنے والی، اعلی کارکردگی دکھانے والی اور اشرافیہ۔ اشرافیہ Netflix، Amazon ہیں، جو انتہائی تیز ہیں، ہر چیز کو جلدی، خوبصورتی اور مؤثر طریقے سے کرتے ہیں۔
دوسری کہانی جو ابھی ایک ماہ قبل ہوئی تھی۔ ٹیکنالوجی ریڈار میں گٹ فلو کے بارے میں بہت اچھا مضمون ہے۔ گٹ فلو دیگر تمام لوگوں سے مختلف ہے کیونکہ اس کی شاخیں لمبی رہتی ہیں۔ ریلیز کی شاخیں ہیں جو طویل عرصے تک زندہ رہتی ہیں، اور خصوصیت والی شاخیں جو طویل عرصے تک زندہ رہتی ہیں۔ ٹکنالوجی راڈار پر یہ مشق ہولڈ میں منتقل ہوگئی ہے۔ کیوں؟ کیونکہ لوگوں کو انضمام کے درد کا سامنا کرنا پڑتا ہے۔
اگر آپ کی شاخ بہت لمبے عرصے تک زندہ رہتی ہے، تو یہ پھنس جاتی ہے، بوسیدہ ہوجاتی ہے، اور ہم اس میں کسی قسم کی تبدیلی کرنے کی کوشش میں زیادہ وقت صرف کرنے لگتے ہیں۔
اور حال ہی میں گٹ فلو کے مصنف نے کہا کہ اگر آپ کا مقصد مسلسل انضمام ہے، اگر آپ کا مقصد یہ ہے کہ آپ جتنی بار ممکن ہو سکے رول کرنا چاہتے ہیں، تو گٹ فلو ایک برا خیال ہے۔ انہوں نے مضمون میں الگ سے مزید کہا کہ اگر آپ کے پاس کوئی بیک اینڈ ہے جہاں آپ اس کے لیے کوشش کر سکتے ہیں، تو گٹ فلو آپ کے لیے ضرورت سے زیادہ ہے، کیونکہ گٹ فلو آپ کو سست کر دے گا، گٹ فلو آپ کے لیے انضمام کے ساتھ مسائل پیدا کرے گا۔
اس کا مطلب یہ نہیں ہے کہ گٹ فلو خراب ہے اور اسے استعمال نہیں کیا جانا چاہئے۔ یہ دوسرے مواقع کے لیے ہے۔ مثال کے طور پر، جب آپ کو کسی سروس یا ایپلیکیشن کے متعدد ورژنز کو سپورٹ کرنے کی ضرورت ہوتی ہے، یعنی جہاں آپ کو طویل مدت کے لیے سپورٹ کی ضرورت ہوتی ہے۔
لیکن اگر آپ ان لوگوں سے بات کریں جو اس طرح کی خدمات کو سپورٹ کرتے ہیں تو آپ کو اس حقیقت کے بارے میں بہت تکلیف سننے کو ملے گی کہ یہ ورژن 3.2 تھا جو کہ 4 ماہ پہلے تھا، لیکن اس میں یہ درستگی شامل نہیں تھی اور اب اسے بنانے کے لیے، آپ کو تبدیلیوں کا ایک گروپ بنانے کی ضرورت ہے۔ اور اب وہ دوبارہ پھنس گئے ہیں، اور اب وہ ایک ہفتے سے کچھ نئی خصوصیت کو نافذ کرنے کی کوشش کر رہے ہیں۔
جیسا کہ الیگزینڈر کووالیف نے چیٹ میں صحیح طور پر نوٹ کیا ہے، ارتباط وابستگی جیسا نہیں ہے۔ یہ حقیقت ہے. یعنی اس کا کوئی سیدھا تعلق نہیں ہے کہ اگر آپ کے پاس کنٹینیوئس انٹیگریشن ہے تو تمام میٹرکس بہت اچھے ہوں گے۔ لیکن ایک مثبت تعلق ہے کہ اگر ایک ہے تو غالباً دوسرا بھی ہے۔ حقیقت نہیں، لیکن زیادہ امکان ہے۔ یہ صرف ایک تعلق ہے۔
ایسا لگتا ہے کہ ہم پہلے ہی کچھ کر رہے ہیں، ایسا لگتا ہے کہ ہم پہلے ہی ضم ہو رہے ہیں، لیکن ہم یہ کیسے سمجھ سکتے ہیں کہ ہمارے پاس اب بھی مسلسل انضمام ہے، کہ ہم اکثر ضم ہو رہے ہیں؟
Jez Humble ہینڈ بک، Accelerate، Continuous Delivery ویب سائٹ اور Continuous Delivery کتاب کے مصنف ہیں۔ وہ یہ ٹیسٹ پیش کرتا ہے:
- انجینئر کا کوڈ ہر روز ماسٹر کو ملتا ہے۔
- ہر کمٹ کے لیے آپ یونٹ ٹیسٹ چلاتے ہیں۔
- ماسٹر میں تعمیر گر گئی، یہ تقریبا 10 منٹ میں طے کی گئی تھی.
وہ اس طرح کا ٹیسٹ استعمال کرنے کا مشورہ دیتا ہے تاکہ یہ یقینی بنایا جا سکے کہ آپ کے پاس کافی مشق ہے۔
مجھے مؤخر الذکر تھوڑا متنازعہ لگتا ہے۔ یعنی، اگر آپ اسے 10 منٹ میں ٹھیک کر سکتے ہیں، تو آپ کے پاس Continuous Integration ہے، یہ میری رائے میں تھوڑا عجیب لگتا ہے، لیکن یہ سمجھ میں آتا ہے۔ کیوں؟ کیونکہ اگر آپ اکثر جم جاتے ہیں تو اس کا مطلب ہے کہ آپ کی تبدیلیاں چھوٹی ہیں۔ اگر ایک چھوٹی تبدیلی کا مطلب ہے کہ آپ کا ماسٹر بلڈ ٹوٹ گیا ہے، تو آپ کو فوری طور پر ایک مثال مل سکتی ہے کیونکہ تبدیلی چھوٹی ہے۔ یہاں آپ کا ایک چھوٹا سا انضمام تھا، اس میں 20-30 لائنیں بدل گئیں۔ اور، اس کے مطابق، آپ تیزی سے سمجھ سکتے ہیں کہ وجہ کیا تھی، کیونکہ تبدیلیاں بہت چھوٹی ہیں، آپ کے پاس مسئلہ تلاش کرنے کے لیے بہت چھوٹا علاقہ ہے۔
اور یہاں تک کہ اگر ہمارا پروڈ ریلیز ہونے کے بعد الگ ہوجاتا ہے، تب بھی اگر ہمارے پاس مسلسل انضمام کی مشق ہے، تو ہمارے لیے عمل کرنا بہت آسان ہے، کیونکہ تبدیلیاں بہت چھوٹی ہیں۔ ہاں، اس سے منصوبہ بندی متاثر ہوگی۔ اس سے تکلیف ہوگی۔ اور، شاید، اس پریکٹس میں سب سے مشکل چیز کاموں کو توڑنے کی عادت ڈالنا ہے، یعنی اسے کیسے کریں تاکہ آپ کچھ لے سکیں اور اسے چند گھنٹوں میں کر سکیں اور ساتھ ہی ایک جائزہ پاس کریں، اگر آپ کے پاس ایک ہے. جائزہ ایک الگ درد ہے۔
یونٹ ٹیسٹ صرف ایک اسسٹنٹ ہیں جو آپ کو یہ سمجھنے میں مدد کرتا ہے کہ آیا آپ کا انضمام کامیاب رہا اور کیا کچھ نہیں ٹوٹا۔ میری رائے میں، یہ بھی مکمل طور پر لازمی نہیں ہے، کیونکہ یہ مشق کا نقطہ نہیں ہے.
یہ Continuous Integration کا مختصر تعارف ہے۔ اس مشق میں بس اتنا ہی ہے۔ میں سوالات کے لیے تیار ہوں۔
میں صرف ایک بار پھر مختصراً بیان کروں گا:
- مسلسل انضمام جینکنز نہیں ہے، یہ Gitlab نہیں ہے.
- یہ کوئی ٹول نہیں ہے، یہ ایک پریکٹس ہے کہ ہم اپنے کوڈ کو جتنی بار ممکن ہو ماسٹر میں ضم کرتے ہیں۔
- ہم ایسا اس لیے کرتے ہیں تاکہ مستقبل میں انضمام کے ساتھ پیدا ہونے والے بہت زیادہ درد سے بچا جا سکے، یعنی ہمیں ابھی تھوڑا سا درد محسوس ہوتا ہے تاکہ مستقبل میں مزید تجربہ نہ ہو۔ یہ پوری بات ہے۔
- اس طرف کوڈ کے ذریعے بات چیت ہوتی ہے، لیکن میں اسے بہت کم دیکھتا ہوں، لیکن یہ بھی وہی ہے جس کے لیے اسے ڈیزائن کیا گیا تھا۔
آپ کے سوالات
غیر گلنے والے کاموں کا کیا کریں؟
گلنا۔ مسئلہ کیا ہے؟ کیا آپ کوئی مثال دے سکتے ہیں کہ کوئی کام ہو اور وہ گل نہ ہو؟
ایسے کام ہیں جو لفظ "مکمل طور پر" سے گلے نہیں جا سکتے، مثال کے طور پر، وہ کام جن کے لیے بہت گہری مہارت کی ضرورت ہوتی ہے اور جنہیں حقیقت میں ایک ماہ کے دوران حل کیا جا سکتا ہے تاکہ کچھ قابل ہضم نتیجہ حاصل کیا جا سکے۔
اگر میں آپ کو صحیح طریقے سے سمجھتا ہوں تو کوئی بڑا اور پیچیدہ کام ہے جس کا نتیجہ صرف ایک ماہ میں نظر آئے گا؟
ہاں یہ صحیح ہے. جی ہاں، نتیجہ کا اندازہ لگانا ایک ماہ سے پہلے ممکن نہیں ہوگا۔
ٹھیک. عام طور پر یہ کوئی مسئلہ نہیں ہے۔ کیوں؟ کیونکہ اس معاملے میں، جب ہم ٹہنی کے بارے میں بات کرتے ہیں، تو ہم ایک خصوصیت والی ٹہنی کے بارے میں بات نہیں کر رہے ہیں۔ خصوصیات بڑی اور پیچیدہ ہو سکتی ہیں۔ وہ اجزاء کی ایک بڑی تعداد کو متاثر کر سکتے ہیں۔ اور شاید ہم انہیں مکمل طور پر ایک شاخ میں نہیں کر سکتے۔ یہ ٹھیک ہے. ہمیں صرف اس کہانی کو توڑنے کی ضرورت ہے۔ اگر کوئی خصوصیت مکمل طور پر تیار نہیں ہے، تو اس کا مطلب یہ نہیں ہے کہ اس کے کوڈ کے کچھ ٹکڑوں کو ضم نہیں کیا جا سکتا۔ آپ نے شامل کیا، کہیں، منتقلی اور فیچر کے اندر کچھ مراحل ہیں۔ آئیے کہتے ہیں کہ آپ کے پاس ایک مرحلہ ہے - ہجرت کریں، ایک نیا طریقہ شامل کریں۔ اور آپ ان چیزوں کو پہلے ہی ہر روز پیمائش کر سکتے ہیں۔
ٹھیک. پھر کیا بات ہے؟
روز چھوٹی چھوٹی چیزوں کو مارنے کا کیا فائدہ؟
جی ہاں.
اگر وہ کچھ توڑتے ہیں، تو آپ اسے فوراً دیکھتے ہیں۔ آپ کے پاس ایک چھوٹا سا ٹکڑا ہے جس میں کچھ ٹوٹ گیا ہے، اسے ٹھیک کرنا آپ کے لیے آسان ہے۔ بات یہ ہے کہ اب ایک چھوٹے ٹکڑے کو ضم کرنا چند ہفتوں میں کسی بڑی چیز کو ضم کرنے سے کہیں زیادہ آسان ہے۔ اور تیسرا نکتہ یہ ہے کہ دوسرے انجینئرز کوڈ کے موجودہ ورژن کے ساتھ کام کریں گے۔ وہ دیکھیں گے کہ یہاں کچھ ہجرتیں شامل کی گئی ہیں، اور پھر کوئی طریقہ ظاہر ہوا ہے جسے وہ استعمال کرنا بھی چاہتے ہیں۔ ہر کوئی دیکھے گا کہ آپ کے کوڈ میں کیا ہو رہا ہے۔ ان تین چیزوں کے لیے ہی مشق کی جاتی ہے۔
آپ کا شکریہ، مسئلہ بند ہے!
(اولیگ سوروکا) کیا میں شامل کر سکتا ہوں؟ آپ نے سب کچھ ٹھیک کہا، میں صرف ایک جملہ شامل کرنا چاہتا ہوں۔
تو
کنٹینیوئس انٹیگریشن کے ساتھ، کوڈ کو ایک مشترکہ برانچ میں ضم کیا جاتا ہے جب فیچر مکمل طور پر تیار نہ ہو، بلکہ جب تعمیر ٹوٹنا بند ہو جائے۔ اور آپ دن میں جتنی بار چاہیں مہارت حاصل کرنے کے لیے محفوظ طریقے سے عہد کر سکتے ہیں۔ دوسرا پہلو یہ ہے کہ اگر کسی وجہ سے آپ ماہانہ کام کو کم از کم تین دن تک کاموں میں نہیں توڑ سکتے، میں تقریباً تین گھنٹے خاموش رہتا ہوں، تو آپ کو بہت بڑا مسئلہ ہے۔ اور حقیقت یہ ہے کہ آپ کے پاس مسلسل انضمام نہیں ہے ان مسائل میں سب سے کم ہے۔ اس کا مطلب ہے کہ آپ کو فن تعمیر اور زیرو انجینئرنگ کے طریقوں کے ساتھ مسائل ہیں۔ کیونکہ اگر یہ تحقیق بھی ہے تو بہرحال اسے مفروضوں یا چکر کی صورت میں مرتب کرنا چاہیے۔
ہم نے 4 میٹرکس کے بارے میں بات کی جو کامیاب کمپنیوں کو پیچھے رہنے والی کمپنیوں سے ممتاز کرتی ہیں۔ ہمیں ابھی بھی ان 4 میٹرکس کو دیکھنے کے لیے جینا ہے۔ اگر آپ کے اوسط کام کو مکمل ہونے میں ایک مہینہ لگتا ہے، تو میں پہلے اس میٹرک پر توجہ دوں گا۔ میں اسے پہلے 3 دن تک کم کروں گا۔ اور اس کے بعد میں Continuous کے بارے میں سوچنے لگا۔
کیا میں نے آپ کو صحیح طور پر سمجھا کہ آپ سمجھتے ہیں کہ عام طور پر انجینئرنگ کے طریقوں میں سرمایہ کاری کا کوئی فائدہ نہیں ہے اگر کسی کام کو مکمل ہونے میں ایک مہینہ لگتا ہے؟
آپ کے پاس مسلسل انضمام ہے۔ اور ایک ایسا موضوع ہے کہ 10 منٹ میں آپ یا تو ٹھیک کر سکتے ہیں یا پھر اسے رول بیک کر سکتے ہیں۔ تصور کریں کہ آپ نے اسے رول آؤٹ کیا۔ مزید یہ کہ، آپ کے پاس مسلسل تعیناتی بھی ہے، آپ نے اسے پروڈ میں رول آؤٹ کیا اور تب ہی محسوس ہوا کہ کچھ غلط ہو گیا ہے۔ اور آپ کو اسے واپس کرنے کی ضرورت ہے، لیکن آپ نے پہلے ہی اپنا ڈیٹا بیس منتقل کر دیا ہے۔ آپ کے پاس اگلے ورژن کا ڈیٹا بیس سکیما پہلے سے موجود ہے، مزید یہ کہ آپ کے پاس کسی قسم کا بیک اپ بھی تھا، اور ڈیٹا بھی وہیں لکھا ہوا تھا۔
اور آپ کے پاس کیا متبادل ہے؟ اگر آپ کوڈ کو رول بیک کرتے ہیں، تو یہ اس اپ ڈیٹ شدہ ڈیٹا بیس کے ساتھ مزید کام نہیں کر سکتا۔
بنیاد صرف آگے بڑھتی ہے، ہاں۔
جن لوگوں کے انجینئرنگ کے ناقص طریق کار ہیں انہوں نے غالباً اس کے بارے میں بھی موٹی کتاب نہیں پڑھی ہے۔ بیک اپ کے ساتھ کیا کرنا ہے؟ اگر آپ بیک اپ سے بحال کرتے ہیں، تو اس کا مطلب ہے کہ آپ اس وقت کے دوران جمع کردہ ڈیٹا کو کھو دیتے ہیں۔ مثال کے طور پر، ہم نے ڈیٹا بیس کے نئے ورژن کے ساتھ تین گھنٹے تک کام کیا، صارفین وہاں رجسٹرڈ ہیں۔ آپ پرانے بیک اپ سے انکار کرتے ہیں کیونکہ اسکیم نئے ورژن کے ساتھ کام نہیں کرتی، اس لیے آپ نے ان صارفین کو کھو دیا ہے۔ اور وہ غیر مطمئن ہیں، وہ قسم کھاتے ہیں۔
مسلسل انضمام اور مسلسل ترسیل کی حمایت کرنے والے طریقوں کی مکمل رینج میں مہارت حاصل کرنے کے لیے، صرف لکھنا سیکھنا کافی نہیں ہے.... سب سے پہلے، ان میں سے بہت کچھ ہو سکتا ہے، یہ ناقابل عمل ہو جائے گا. اس کے علاوہ سائنسی جیسے دیگر طریقوں کا ایک گروپ ہے۔ اس طرح کی ایک مشق ہے، GitHub نے اسے ایک وقت میں مقبول کیا. یہ تب ہوتا ہے جب آپ کے پاس پرانا کوڈ اور نیا کوڈ ایک ہی وقت میں چل رہا ہوتا ہے۔ یہ تب ہوتا ہے جب آپ ایک نامکمل خصوصیت بناتے ہیں، لیکن یہ کچھ قدر واپس کر سکتا ہے: یا تو بطور فنکشن یا ریسٹ API۔ آپ نئے کوڈ اور پرانے کوڈ دونوں پر عمل کرتے ہیں، اور ان کے درمیان فرق کا موازنہ کرتے ہیں۔ اور اگر کوئی فرق ہے تو آپ اس ایونٹ کو لاگ ان کریں۔ اس طرح آپ کو معلوم ہوگا کہ آپ کے پاس ایک نئی خصوصیت ہے جو پرانی کے اوپر رول آؤٹ کرنے کے لیے تیار ہے اگر آپ نے ایک خاص وقت کے لیے دونوں کے درمیان کوئی تضاد نہیں رکھا ہے۔
اس طرح کے سینکڑوں رواج ہیں۔ میں ٹرانس بیس ڈویلپمنٹ کے ساتھ شروع کرنے کا مشورہ دوں گا۔ وہ مسلسل انضمام پر 100٪ نہیں ہے، لیکن طرز عمل ایک جیسے ہیں، ایک دوسرے کے بغیر اچھی طرح نہیں رہ سکتا۔
کیا آپ نے مثال کے طور پر ٹرانس بیس ڈویلپمنٹ دی ہے جہاں آپ پریکٹس دیکھ سکتے ہیں یا آپ لوگوں کو ٹرانسبیس ڈیبلپمنٹ کا استعمال شروع کرنے کا مشورہ دیتے ہیں؟
ایک نظر ڈالیں، کیونکہ وہ اسے استعمال نہیں کر سکیں گے۔ ان کو استعمال کرنے کے لیے آپ کو بہت کچھ پڑھنا ہوگا۔ اور جب کوئی شخص پوچھتا ہے: "ایک مہینہ لگنے والی خصوصیت کا کیا کرنا ہے، تو اس کا مطلب ہے کہ اس نے ٹرانس بیس ڈویلپمنٹ کے بارے میں نہیں پڑھا ہے۔" میں ابھی تک اس کی سفارش نہیں کروں گا۔ میں صرف اس موضوع پر توجہ مرکوز کرنے کا مشورہ دوں گا کہ بڑے کاموں کو چھوٹے کاموں میں صحیح طریقے سے کیسے توڑا جائے۔ یہ گلنے کا جوہر ہے۔
سڑنا معمار کے اوزاروں میں سے ایک ہے۔ ہم پہلے تجزیہ کرتے ہیں، پھر سڑنا، پھر ترکیب، پھر انضمام۔ اور اس طرح ہمارے لئے سب کچھ کام کرتا ہے۔ اور ہمیں اب بھی سڑنے کے ذریعے مسلسل انضمام کی طرف بڑھنے کی ضرورت ہے۔ پہلے مرحلے پر سوالات پیدا ہوتے ہیں، اور ہم پہلے ہی چوتھے مرحلے کے بارے میں بات کر رہے ہیں، یعنی ہم جتنی بار انضمام کریں گے، اتنا ہی بہتر ہے۔ ایسا کرنے میں ابھی بہت جلدی ہے؛ یہ اچھا ہو گا کہ پہلے اپنی یک سنگی کو کاٹ دیں۔
آپ کو کچھ آریھ پر کئی تیر اور چوکور کھینچنے کی ضرورت ہے۔ آپ یہ نہیں کہہ سکتے کہ اب میں ایک نئی ایپلی کیشن کا آرکیٹیکچرل ڈایاگرام دکھاؤں گا اور ایک مربع دکھاؤں گا، جس کے اندر ایپلیکیشن کے لیے سبز بٹن ہے۔ کسی بھی صورت میں، زیادہ مربع اور تیر ہوں گے. میں نے جو بھی خاکہ دیکھا اس میں ایک سے زیادہ تھے۔ اور سڑن، یہاں تک کہ تصویری نمائندگی کی سطح پر بھی، پہلے سے ہی ہو رہی ہے۔ لہذا، چوکوں کو آزاد بنایا جا سکتا ہے. اگر نہیں، تو میرے پاس معمار کے لیے بڑے سوالات ہیں۔
چیٹ سے ایک سوال ہے: "اگر جائزہ لازمی ہے اور اس میں کافی وقت لگتا ہے، شاید ایک دن یا زیادہ؟"
آپ کو مشق کے ساتھ مسائل ہیں. جائزہ ایک دن یا اس سے زیادہ نہیں چلنا چاہیے۔ یہ پچھلے سوال کی وہی کہانی ہے، صرف تھوڑا سا نرم۔ اگر ایک جائزہ ایک دن کے لیے چلتا ہے، تو غالب امکان ہے کہ یہ جائزہ کچھ بہت بڑی تبدیلی پر جا رہا ہے۔ اس کا مطلب یہ ہے کہ اسے چھوٹا کرنے کی ضرورت ہے۔ ٹرانسبیس ڈویلپمنٹ میں، جس کی اولیگ نے سفارش کی، ایک کہانی ہے جسے مسلسل جائزہ کہتے ہیں۔ اس کا خیال یہ ہے کہ ہم جان بوجھ کر اتنی چھوٹی پل کی درخواست کرتے ہیں، کیونکہ ہم ایک وقت میں مسلسل اور تھوڑا تھوڑا ضم ہونے کی کوشش کرتے ہیں۔ اور اس طرح پل کی درخواست ایک تجرید یا 10 لائنوں کو تبدیل کرتی ہے۔ اس جائزے کا شکریہ، اس میں ہمیں چند منٹ لگتے ہیں۔
اگر جائزہ میں ایک دن یا اس سے زیادہ وقت لگتا ہے، تو کچھ غلط ہے۔ سب سے پہلے، آپ کو فن تعمیر کے ساتھ کچھ مسائل ہوسکتے ہیں. یا یہ کوڈ کا ایک بڑا ٹکڑا ہے، 1 لائنیں، مثال کے طور پر۔ یا آپ کا فن تعمیر اتنا پیچیدہ ہے کہ انسان اسے سمجھ نہیں سکتا۔ یہ قدرے ضمنی مسئلہ ہے، لیکن اسے بھی حل کرنا پڑے گا۔ شاید جائزہ لینے کی ضرورت ہی نہیں ہے۔ ہمیں اس بارے میں بھی سوچنے کی ضرورت ہے۔ جائزہ وہ چیز ہے جو آپ کو سست کرتی ہے۔ عام طور پر اس کے فوائد ہیں، لیکن آپ کو یہ سمجھنے کی ضرورت ہے کہ آپ ایسا کیوں کر رہے ہیں۔ کیا یہ آپ کے لیے معلومات کو فوری طور پر پہنچانے کا ایک طریقہ ہے، کیا یہ آپ کے لیے اندرونی طور پر کچھ معیارات قائم کرنے کا طریقہ ہے یا کیا؟ آپ کو اس کی ضرورت کیوں ہے؟ کیونکہ جائزہ کو یا تو بہت جلد یا مکمل طور پر منسوخ کرنے کی ضرورت ہے۔ یہ ٹرانسبیس ڈیولپمنٹ کی طرح ہے - کہانی بہت خوبصورت ہے، لیکن صرف بالغ لڑکوں کے لیے۔
4 میٹرکس کے بارے میں، میں اب بھی ان کو ہٹانے کی تجویز کروں گا تاکہ یہ سمجھ سکیں کہ اس سے کیا ہوتا ہے۔ نمبر دیکھو، تصویر دیکھو، سب کچھ کتنا خراب ہے۔
(دمتری) میں آپ کے ساتھ اس بارے میں بحث کرنے کے لیے تیار ہوں۔ نمبرز اور میٹرکس سب زبردست ہیں، پریکٹسز بہت اچھے ہیں۔ لیکن آپ کو یہ سمجھنے کی ضرورت ہے کہ آیا کاروبار کو اس کی ضرورت ہے۔ ایسے کاروبار ہیں جن کو اس قسم کی تبدیلی کی ضرورت نہیں ہے۔ میں ایسی کمپنیوں کو جانتا ہوں جہاں ہر 15 منٹ میں تبدیلیاں نہیں کی جا سکتیں۔ اور اس لیے نہیں کہ وہ بہت برے ہیں۔ یہ ایک ایسا لائف سائیکل ہے۔ اور شاخوں کی خصوصیت، ٹوگل فیچر بنانے کے لیے، آپ کو گہرے علم کی ضرورت ہے۔
یہ مشکل ہے. اگر آپ ٹوگل فیچر کے بارے میں مزید تفصیل سے کہانی پڑھنا چاہتے ہیں، تو میں اس کی انتہائی سفارش کرتا ہوں۔ . اور ٹوگل فیچرز کے بارے میں مارٹن فاؤلر کا ایک شاندار مضمون ہے: کون سی قسمیں ہیں، لائف سائیکل وغیرہ۔ ٹوگل فیچر پیچیدہ ہے۔
اور آپ نے ابھی تک اس سوال کا جواب نہیں دیا ہے: "کیا جینکنز کی ضرورت ہے یا نہیں؟"
جینکنز کی واقعی کسی بھی صورت میں ضرورت نہیں ہے۔ اگرچہ سنجیدگی سے، ٹولز: جینکنز، گٹلاب آپ کو سہولت فراہم کریں گے۔ آپ دیکھیں گے کہ اسمبلی جمع ہے یا جمع نہیں ہے۔ وہ آپ کی مدد کر سکتے ہیں، لیکن وہ آپ کو مشق نہیں کریں گے۔ وہ آپ کو صرف ایک دائرہ دے سکتے ہیں - ٹھیک ہے، ٹھیک نہیں۔ اور پھر، اگر آپ ٹیسٹ بھی لکھتے ہیں، کیونکہ اگر کوئی ٹیسٹ نہیں ہے، تو یہ تقریباً بے معنی ہے۔ لہذا، اس کی ضرورت ہے کیونکہ یہ زیادہ آسان ہے، لیکن عام طور پر آپ اس کے بغیر رہ سکتے ہیں، آپ کو زیادہ نقصان نہیں ہوگا۔
یعنی، اگر آپ کے پاس مشقیں ہیں، تو کیا اس کا مطلب ہے کہ آپ کو اس کی ضرورت نہیں ہے؟
یہ ٹھیک ہے. میں Jez Humble ٹیسٹ کی سفارش کرتا ہوں۔ وہاں میرا آخری نکتہ کے بارے میں دو ٹوک رویہ ہے۔ لیکن عام طور پر، اگر آپ کے پاس تین چیزیں ہیں، تو آپ مسلسل ضم ہوتے ہیں، آپ ماسٹر میں کمٹ پر ٹیسٹ چلاتے ہیں، آپ ماسٹر میں بلڈ کو تیزی سے ٹھیک کر لیتے ہیں، پھر شاید آپ کو کسی اور چیز کی ضرورت نہ ہو۔
جب کہ ہم شرکاء کے سوالات کا انتظار کر رہے ہیں، میرا ایک سوال ہے۔ ہم صرف پروڈکٹ کوڈ کے بارے میں بات کر رہے تھے۔ کیا آپ نے اسے انفراسٹرکچر کوڈ کے لیے استعمال کیا ہے؟ کیا یہ ایک ہی ضابطہ ہے، کیا اس کے اصول اور ایک ہی زندگی کا چکر ہے، یا زندگی کے مختلف چکر اور اصول ہیں؟ عام طور پر، جب ہر کوئی مسلسل انضمام اور ترقی کے بارے میں بات کرتا ہے، تو ہر کوئی بھول جاتا ہے کہ انفراسٹرکچر کوڈ بھی ہے۔ اور حال ہی میں اس میں زیادہ سے زیادہ اضافہ ہوا ہے۔ اور کیا ان تمام قوانین کو وہاں لایا جائے؟
ایسا بھی نہیں کہ ایسا ہونا چاہیے، یہ بہت اچھا ہوگا کیونکہ یہ اسی طرح زندگی کو آسان بنا دے گا۔ جیسے ہی ہم کوڈ کے ساتھ کام کرتے ہیں، bash اسکرپٹ کے ساتھ نہیں، لیکن ہمارے پاس نارمل کوڈ ہوتا ہے۔
اسٹاپ، اسٹاپ، ایک باش اسکرپٹ بھی کوڈ ہے۔ میری پرانی محبت کو مت چھونا۔
ٹھیک ہے، میں تمہاری یادوں کو نہیں روندوں گا۔ مجھے باش سے ذاتی ناپسند ہے۔ یہ ہر وقت بدصورت اور خوفناک ٹوٹ جاتا ہے۔ اور یہ اکثر غیر متوقع طور پر ٹوٹ جاتا ہے، یہی وجہ ہے کہ مجھے یہ پسند نہیں ہے۔ لیکن ٹھیک ہے، ہم کہتے ہیں کہ آپ کے پاس بیش کوڈ ہے۔ ہوسکتا ہے کہ میں واقعی میں نہیں سمجھتا ہوں اور وہاں عام جانچ کے فریم ورک موجود ہیں۔ میں صرف علم میں نہیں ہوں۔ اور ہمیں وہی فائدہ ملتا ہے۔
جیسے ہی ہم بنیادی ڈھانچے کے ساتھ کوڈ کے طور پر کام کرتے ہیں، ہمیں ڈیولپرز کی طرح تمام مسائل کا سامنا کرنا پڑتا ہے۔ کچھ مہینے پہلے، مجھے ایک ایسی صورتحال کا سامنا کرنا پڑا جہاں ایک ساتھی نے مجھے 1 لائنوں کے لیے پل کی درخواست بھیجی۔ اور آپ 000 گھنٹے تک ریویو پر ہینگ آؤٹ کرتے ہیں۔ وہی مسائل پیدا ہوتے ہیں۔ یہ اب بھی کوڈ ہے۔ اور یہ اب بھی ایک تعاون ہے۔ ہم پل کی درخواست کے ساتھ پھنس جاتے ہیں اور ہم اس حقیقت کے ساتھ پھنس جاتے ہیں کہ ہم ایک ہی باش میں ایک ہی انضمام کے تنازعات کو حل کر رہے ہیں، مثال کے طور پر۔
میں اب اس ساری چیز کو انتہائی خوبصورت انفرا پروگرامنگ پر بہت سرگرمی سے دیکھ رہا ہوں۔ میں اب پلومی کو انفراسٹرکچر میں لے آیا ہوں۔ یہ اپنی خالص ترین شکل میں پروگرامنگ ہے۔ وہاں یہ اور بھی اچھا ہے، کیونکہ میرے پاس پروگرامنگ لینگویج کی تمام صلاحیتیں ہیں، یعنی میں نے اسی ifs کے ساتھ نیلے رنگ سے خوبصورت ٹوگل بنایا ہے اور سب کچھ ٹھیک ہے۔ یعنی میری تبدیلی آقا میں پہلے سے ہے۔ ہر کوئی اسے پہلے ہی دیکھ سکتا ہے۔ دوسرے انجینئر اس کے بارے میں جانتے ہیں۔ اس نے پہلے ہی وہاں کچھ متاثر کیا ہے۔ تاہم، یہ تمام انفراسٹرکچر کے لیے فعال نہیں تھا۔ مثال کے طور پر یہ میرے ٹیسٹ بینچوں کے لیے آن ہو گیا۔ اس لیے آپ کے سوال کا دوبارہ جواب دینا ضروری ہے۔ یہ ہمارے لیے زندگی کو آسان بناتا ہے، جیسا کہ کوڈ کے ساتھ کام کرنے والے انجینئرز، اسی طرح سے۔
اگر کسی اور کے سوالات ہیں؟
میرا ایک سوال ہے. میں اولیگ کے ساتھ بات چیت جاری رکھنا چاہتا ہوں۔ عام طور پر، میں سمجھتا ہوں کہ آپ ٹھیک کہتے ہیں، کہ اگر کسی کام کو مکمل ہونے میں ایک مہینہ لگتا ہے، تو آپ کو فن تعمیر کا مسئلہ ہے، آپ کو تجزیہ، سڑنے، منصوبہ بندی وغیرہ میں مسئلہ ہے، لیکن مجھے یہ احساس ہے کہ اگر آپ شروع کرتے ہیں۔ Continuous Integration کے مطابق زندگی گزارنے کی کوشش کریں، پھر آپ منصوبہ بندی کے ساتھ درد کو درست کرنا شروع کر دیں گے، کیونکہ آپ اس سے کہیں دور نہیں ہوں گے۔
(اولیگ) جی ہاں، یہ صحیح ہے. یہ مشق ثقافت کو بدلنے والے کسی بھی دوسرے سنجیدہ عمل سے موازنہ ہے۔ عادات پر قابو پانا سب سے مشکل چیز ہے، خاص کر بری عادات۔ اور اگر اس پریکٹس کو لاگو کرنے کے لیے، آپ کے آس پاس کے لوگوں کی عادات میں ایک سنجیدہ تبدیلی کی ضرورت ہے: ڈویلپرز، مینجمنٹ، پروڈکشن مینیجر، تو حیرت آپ کے منتظر ہے۔
کیا حیرت ہو سکتی ہے؟ ہم کہتے ہیں کہ آپ فیصلہ کرتے ہیں کہ آپ زیادہ کثرت سے انضمام کریں گے۔ اور آپ کے پاس انضمام سے منسلک کچھ دوسری چیزیں ہیں، مثال کے طور پر، نمونے اور آپ کی کمپنی میں، مثال کے طور پر، ایک پالیسی ہے کہ ہر آرٹفیکٹ کا کسی نہ کسی طرح سے کسی نہ کسی قسم کے آرٹفیکٹ اسٹوریج سسٹم میں حساب ہونا چاہیے۔ اور اس میں کچھ وقت لگتا ہے۔ ایک شخص کو اس باکس کو چیک کرنے کی ضرورت ہے کہ اس نے بطور ریلیز مینیجر، اس نمونے کا تجربہ کیا ہے تاکہ یہ یقینی بنایا جا سکے کہ یہ پروڈکشن میں ریلیز کے لیے تیار ہے۔ اگر اس میں 5-10-15 منٹ لگتے ہیں، لیکن آپ ہفتے میں ایک بار لے آؤٹ کرتے ہیں، تو ہفتے میں ایک بار آدھا گھنٹہ گزارنا ایک چھوٹا ٹیکس ہے۔
اگر آپ دن میں 10 بار مسلسل انضمام کرتے ہیں، تو 10 بار کو 30 منٹ سے ضرب کرنے کی ضرورت ہے۔ اور یہ اس ریلیز مینیجر کے کام کرنے کے وقت سے زیادہ ہے۔ وہ بس یہ کرتے کرتے تھک جاتا ہے۔ کچھ مشقوں کے لیے مقررہ اخراجات ہیں۔ بس۔
اور آپ کو یا تو اس قاعدے کو منسوخ کرنے کی ضرورت ہے تاکہ آپ اس طرح کا کوڑا کرکٹ مزید نہ کریں، یعنی آپ کسی چیز سے مطابقت رکھنے کے لیے دستی طور پر کوئی ڈگری تفویض نہ کریں۔ آپ مکمل طور پر تیاری کے ٹیسٹ کے کچھ خودکار سیٹ پر انحصار کر رہے ہیں۔
اور اگر آپ کو کسی سے ثبوت کی ضرورت ہے، تاکہ باس اس پر دستخط کرے، اور آپ واسیہ کے یہ کہے بغیر کہ وہ اس کی اجازت دیتا ہے، پروڈکشن میں نہیں آتے، وغیرہ۔ - یہ سب بکواس پریکٹیشنر کے راستے میں آ جاتا ہے۔ کیونکہ اگر ٹیکس سے وابستہ کچھ سرگرمیاں ہوں تو ہر چیز 100 گنا بڑھ جاتی ہے۔ لہذا، شفٹ اکثر سب کی طرف سے خوشی کے ساتھ استقبال نہیں کیا جائے گا. کیونکہ لوگوں کی عادتیں بدلنا مشکل ہے۔
جب کوئی شخص اپنا معمول کا کام کرتا ہے تو وہ بغیر سوچے سمجھے کرتا ہے۔ اس کا علمی بوجھ صفر ہے۔ وہ صرف اس کے ساتھ کھیلتا ہے، اس کے سر میں پہلے سے ہی ایک چیک لسٹ ہے، اس نے یہ ایک ہزار بار کیا ہے۔ اور جیسے ہی آپ آتے ہیں اور اس سے کہتے ہیں: "آئیے اس پریکٹس کو منسوخ کریں اور پیر سے ایک نیا متعارف کرائیں،" اس کے لیے یہ ایک طاقتور علمی بوجھ بن جاتا ہے۔ اور یہ ایک ہی وقت میں سب کے سامنے آتا ہے۔
لہذا، سب سے آسان بات، اگرچہ ہر کوئی اس عیش و آرام کا متحمل نہیں ہوسکتا ہے، لیکن یہ وہی ہے جو میں ہمیشہ کرتا ہوں، یہ مندرجہ ذیل ہے. اگر کوئی نیا پراجیکٹ شروع ہوتا ہے، تو عام طور پر تمام غیر تجربہ شدہ طریقوں کو فوری طور پر اس پروجیکٹ میں شامل کر دیا جاتا ہے۔ جب کہ پروجیکٹ جوان ہے، ہم واقعی کسی بھی چیز کا خطرہ نہیں رکھتے۔ ابھی تک کوئی پیداوار نہیں ہے، تباہ کرنے کے لیے کچھ بھی نہیں ہے۔ لہذا، یہ تربیت کے طور پر استعمال کیا جا سکتا ہے. یہ نقطہ نظر کام کرتا ہے۔ لیکن تمام کمپنیوں کو اکثر ایسے منصوبے شروع کرنے کا موقع نہیں ملتا۔ اگرچہ یہ بھی تھوڑا عجیب ہے، کیونکہ اب ایک مکمل ڈیجیٹل تبدیلی آچکی ہے، ہر ایک کو حریفوں کے ساتھ رہنے کے لیے تجربات شروع کرنا ہوں گے۔
یہاں آپ اس نتیجے پر پہنچتے ہیں کہ آپ کو پہلے یہ سمجھنا چاہیے کہ آپ کو کیا کرنا ہے۔ دنیا مثالی نہیں ہے، اور پیداوار بھی مثالی نہیں ہے۔
ہاں یہ چیزیں ایک دوسرے سے جڑی ہوئی ہیں۔
کاروبار بھی ہمیشہ یہ نہیں سمجھتے کہ انہیں اس راستے پر جانے کی ضرورت ہے۔
ایک ایسی صورتحال ہے جس میں کوئی تبدیلی ممکن نہیں۔ یہ ایسی صورتحال ہے جہاں ٹیم پر زیادہ دباؤ ہے۔ ٹیم پہلے ہی کافی جل چکی ہے۔ اس کے پاس کسی بھی تجربات کے لیے فالتو وقت نہیں ہے۔ وہ صبح سے شام تک خصوصیات پر کام کرتے ہیں۔ اور نظم و نسق میں کم اور کم خصوصیات ہیں۔ زیادہ سے زیادہ کی ضرورت ہے۔ ایسی صورت حال میں کوئی تبدیلی ممکن نہیں۔ ٹیم کو صرف یہ کہا جا سکتا ہے کہ کل ہم بھی کل کی طرح کریں گے، ہمیں بس کچھ اور خصوصیات بنانے کی ضرورت ہے۔ اس لحاظ سے، کسی بھی طرز عمل میں کوئی تبدیلی ممکن نہیں ہے۔ یہ ایک کلاسک صورت حال ہے جب کلہاڑی کو تیز کرنے کا وقت نہیں ہے، درختوں کو کاٹنے کی ضرورت ہے، لہذا وہ اسے ایک سست کلہاڑی سے کاٹتے ہیں. یہاں کوئی آسان تجاویز نہیں ہیں۔
(دمتری) میں چیٹ سے ایک وضاحت پڑھوں گا: "لیکن ہمیں مختلف سطحوں پر بہت زیادہ ٹیسٹ کوریج کی ضرورت ہے۔ ٹیسٹ کے لیے کتنا وقت مختص ہے؟ یہ تھوڑا مہنگا ہے اور بہت زیادہ وقت لگتا ہے۔"
(Oleg) یہ ایک کلاسک غلط فہمی ہے۔ آپ کے پر اعتماد ہونے کے لیے کافی ٹیسٹ ہونے چاہئیں۔ مسلسل انضمام کوئی چیز نہیں ہے جہاں 100% ٹیسٹ پہلے کیے جاتے ہیں اور اس کے بعد ہی آپ اس مشق کو لاگو کرنا شروع کرتے ہیں۔ مسلسل انضمام اس حقیقت کی وجہ سے آپ کے علمی بوجھ کو کم کرتا ہے کہ ہر ایک تبدیلی جو آپ اپنی آنکھوں سے دیکھتے ہیں اتنی واضح ہے کہ آپ سمجھ سکتے ہیں کہ آیا اس سے کچھ ٹوٹ جائے گا یا نہیں، چاہے بغیر ٹیسٹ کے۔ آپ اسے اپنے سر میں جلدی سے جانچ سکتے ہیں کیونکہ تبدیلیاں چھوٹی ہیں۔ یہاں تک کہ اگر آپ کے پاس صرف دستی ٹیسٹرز ہیں، تو یہ ان کے لیے بھی آسان ہے۔ آپ نے باہر نکل کر کہا: "دیکھو، کیا کچھ ٹوٹ گیا ہے؟" انہوں نے چیک کیا اور کہا، "نہیں، کچھ نہیں ٹوٹا ہے۔" کیونکہ ٹیسٹر جانتا ہے کہ کہاں دیکھنا ہے۔ آپ کے پاس کوڈ کے ایک ٹکڑے سے وابستہ ایک کمٹ ہے۔ اور اس کا استحصال مخصوص رویے سے ہوتا ہے۔
یہاں آپ کو، کورس کے، زیور.
(دمتری) میں یہاں متفق نہیں ہوں۔ ایک مشق ہے - ٹیسٹ پر مبنی ترقی، جو آپ کو اس سے بچائے گی۔
(اولیگ) ٹھیک ہے، میں ابھی تک اس مقام تک نہیں پہنچا ہوں۔ پہلا وہم یہ ہے کہ آپ کو 100% ٹیسٹ لکھنے کی ضرورت ہے یا آپ کو کنٹینیوئس انٹیگریشن کرنے کی بالکل بھی ضرورت نہیں ہے۔ یہ سچ نہیں ہے. یہ دو متوازی مشقیں ہیں۔ اور وہ براہ راست انحصار نہیں کرتے ہیں۔ آپ کے ٹیسٹ کی کوریج بہترین ہونی چاہیے۔ بہترین - اس کا مطلب یہ ہے کہ آپ کو خود یقین ہے کہ آپ کا ماسٹر جس معیار میں آپ کا ماسٹر کمٹمنٹ کے بعد باقی رہا ہے وہ آپ کو جمعہ کی شام شرابی میں "تعینات" بٹن کو اعتماد کے ساتھ دبانے کی اجازت دیتا ہے۔ آپ یہ کیسے حاصل کرتے ہیں؟ جائزے کے ذریعے، کوریج کے ذریعے، اچھی نگرانی کے ذریعے۔
اچھی نگرانی ٹیسٹوں سے الگ نہیں ہے۔ اگر آپ پری پروڈکشن پر ایک بار ٹیسٹ چلاتے ہیں، تو وہ آپ کے تمام صارف اسکرپٹ کو ایک بار چیک کرتے ہیں اور بس۔ اور اگر آپ انہیں ایک لامتناہی لوپ میں چلاتے ہیں، تو یہ آپ کا تعینات کردہ نگرانی کا نظام ہے، جو ہر چیز کی لامتناہی جانچ کرتا ہے - چاہے وہ کریش ہوا یا نہیں۔ اس صورت میں، فرق صرف یہ ہے کہ یہ ایک بار یا دو بار کیا جاتا ہے. ٹیسٹوں کا ایک بہت اچھا سیٹ... لامتناہی چل رہا ہے، یہ نگرانی ہے۔ اور مناسب نگرانی اس طرح ہونی چاہیے۔
اور اس لیے، جب آپ جمعہ کی شام تیار ہو جائیں گے اور گھر جائیں گے تو آپ اس حالت کو کیسے حاصل کریں گے، یہ ایک اور سوال ہے۔ ہوسکتا ہے کہ آپ صرف ایک جرات مندانہ بدمعاش ہو۔
آئیے مسلسل انٹیگریشن کی طرف تھوڑا پیچھے چلتے ہیں۔ ہم ایک قدرے مختلف پیچیدہ مشق میں بھاگ گئے۔
اور دوسرا وہم یہ ہے کہ MVP، وہ کہتے ہیں، جلدی کرنے کی ضرورت ہے، اس لیے وہاں ٹیسٹ کی بالکل ضرورت نہیں ہے۔ یقینی طور پر اس طرح سے نہیں۔ حقیقت یہ ہے کہ جب آپ ایم وی پی میں صارف کی کہانی لکھتے ہیں، تو آپ اسے گیند پر تیار کر سکتے ہیں، یعنی آپ نے سنا ہے کہ صارف کی کسی قسم کی کہانی تھی اور فوراً اسے کوڈ کرنے کے لیے بھاگے، یا آپ TDD کا استعمال کر کے کام کر سکتے ہیں۔ اور TDD کے مطابق، جیسا کہ پریکٹس سے پتہ چلتا ہے، اس میں زیادہ وقت نہیں لگتا، یعنی ٹیسٹ ایک ضمنی اثر ہیں۔ TDD کی مشق جانچ کے بارے میں نہیں ہے۔ ٹیسٹ پر مبنی ترقی کہلانے کے باوجود، یہ ٹیسٹوں کے بارے میں بالکل بھی نہیں ہے۔ یہ بھی ایک آرکیٹیکچرل نقطہ نظر ہے. یہ بالکل وہی لکھنے کا طریقہ ہے جس کی ضرورت ہے اور نہ لکھنے کی جو ضرورت نہیں ہے۔ یہ ایپلی کیشن آرکیٹیکچر بنانے کے معاملے میں آپ کی سوچ کی اگلی تکرار پر توجہ مرکوز کرنے کا عمل ہے۔
اس لیے ان وہموں سے چھٹکارا پانا اتنا آسان نہیں ہے۔ MVP اور ٹیسٹ ایک دوسرے سے متصادم نہیں ہیں۔ یہاں تک کہ، بلکہ، اس کے برعکس، اگر آپ TDD پریکٹس کا استعمال کرتے ہوئے MVP کرتے ہیں، تو آپ اسے اس سے بہتر اور تیز تر کریں گے اگر آپ بغیر پریکٹس کے کرتے ہیں، لیکن گیند پر۔
یہ ایک بہت ہی غیر واضح اور پیچیدہ خیال ہے۔ جب آپ یہ سنتے ہیں کہ اب میں مزید ٹیسٹ لکھوں گا اور اس کے ساتھ ساتھ میں تیزی سے کچھ کروں گا تو یہ بالکل ناکافی لگتا ہے۔
(دمتری) یہاں بہت سے لوگ، جب وہ MVP کہتے ہیں، لوگ کچھ عام لکھنے میں بہت سست ہوتے ہیں۔ اور یہ اب بھی مختلف چیزیں ہیں۔ MVP کو کسی بری چیز میں تبدیل کرنے کی ضرورت نہیں ہے جو کام نہیں کرتی ہے۔
ہاں، ہاں، تم ٹھیک کہتے ہو۔
اور پھر اچانک MVP پیداوار میں۔
ہمیشہ کے لئے۔
اور TDD بہت غیر معمولی لگتا ہے جب آپ سنتے ہیں کہ آپ ٹیسٹ لکھتے ہیں اور لگتا ہے کہ آپ زیادہ کام کرتے ہیں۔ یہ بہت عجیب لگتا ہے، لیکن حقیقت میں یہ اس طرح تیز اور خوبصورت نکلتا ہے۔ جب آپ ٹیسٹ لکھتے ہیں، تو آپ پہلے سے ہی اپنے ذہن میں بہت کچھ سوچتے ہیں کہ کس کوڈ کو کہا جائے گا اور کیسے، نیز ہم اس سے کس طرز عمل کی توقع کرتے ہیں۔ آپ صرف یہ نہیں کہتے ہیں کہ میں نے کچھ فنکشن لکھا ہے اور یہ کچھ کرتا ہے۔ پہلے تو آپ نے سوچا کہ اس کے فلاں فلاں حالات ہیں، فلاں فلاں سے پکارا جائے گا۔ آپ اسے ٹیسٹ کے ساتھ کور کرتے ہیں اور اس سے آپ سمجھتے ہیں کہ آپ کے انٹرفیس آپ کے کوڈ کے اندر کیسے نظر آئیں گے۔ اس کا فن تعمیر پر بہت بڑا اثر پڑتا ہے۔ آپ کا کوڈ خود بخود زیادہ ماڈیولر بن جاتا ہے، کیونکہ آپ پہلے یہ سمجھنے کی کوشش کرتے ہیں کہ آپ اسے کیسے آزمائیں گے، اور تب ہی اسے لکھیں۔
TDD کے ساتھ میرے ساتھ جو ہوا وہ یہ تھا کہ کسی وقت میں نے ایک روبی سرپرست کی خدمات حاصل کیں جب میں ابھی روبی پروگرامر تھا۔ اور وہ کہتا ہے: "آئیے اسے TDD کے مطابق کریں۔" میں نے سوچا: "لعنت، اب مجھے کچھ اضافی لکھنا پڑے گا۔" اور ہم نے اتفاق کیا کہ دو ہفتوں کے اندر میں TDD کا استعمال کرتے ہوئے Python میں تمام ورکنگ کوڈ لکھوں گا۔ دو ہفتوں کے بعد، مجھے احساس ہوا کہ میں واپس نہیں جانا چاہتا۔ اسے ہر جگہ لاگو کرنے کی دو ہفتوں کی کوشش کے بعد، آپ کو احساس ہوگا کہ آپ کے لیے سوچنا بھی کتنا آسان ہو گیا ہے۔ لیکن یہ واضح نہیں ہے، اس لیے میں ہر ایک کو مشورہ دیتا ہوں کہ اگر آپ کو لگتا ہے کہ TDD مشکل، وقت طلب اور غیر ضروری ہے، تو صرف دو ہفتوں تک اس پر قائم رہنے کی کوشش کریں۔ میرے لیے دو ہی کافی تھے۔
(دمتری) ہم اس خیال کو انفراسٹرکچر آپریشن کے نقطہ نظر سے بڑھا سکتے ہیں۔ کچھ بھی نیا شروع کرنے سے پہلے، ہم نگرانی کرتے ہیں اور پھر لانچ کرتے ہیں۔ اس صورت میں، نگرانی ہمارے لیے معمول کی آزمائش بن جاتی ہے۔ اور نگرانی کے ذریعے ترقی ہوتی ہے۔ لیکن تقریباً سبھی کہتے ہیں کہ یہ لمبا ہے، میں سست ہوں، میں نے ایک عارضی مسودہ بنایا ہے۔ اگر ہم نے عام نگرانی کی ہے، تو ہم CI نظام کی حالت کو سمجھتے ہیں۔ اور سی آئی سسٹم میں بہت زیادہ نگرانی ہے۔ ہم نظام کی حالت کو سمجھتے ہیں، ہم سمجھتے ہیں کہ اس کے اندر کیا ہے۔ اور ترقی کے دوران، ہم صرف اس نظام کو بنا رہے ہیں تاکہ یہ مطلوبہ حالت تک پہنچ جائے.
یہ مشقیں ایک طویل عرصے سے مشہور ہیں۔ ہم نے تقریباً 4 سال پہلے اس پر بات کی تھی۔ لیکن 4 سالوں میں عملی طور پر کچھ نہیں بدلا۔
لیکن اس نوٹ پر، میں سرکاری بحث کو ختم کرنے کی تجویز پیش کرتا ہوں۔
ویڈیو (میڈیا عنصر کے طور پر داخل کیا گیا، لیکن کسی وجہ سے کام نہیں کرتا):
ماخذ: www.habr.com