رپورٹ کچھ DevOps طریقوں کے بارے میں بات کرے گی، لیکن ڈویلپر کے نقطہ نظر سے۔ عام طور پر، تمام انجینئر جو DevOps میں شامل ہوتے ہیں ان کے پاس پہلے سے ہی کئی سالوں کا انتظامی تجربہ ہوتا ہے۔ لیکن اس کا مطلب یہ نہیں ہے کہ یہاں ڈویلپر کے لیے کوئی جگہ نہیں ہے۔ اکثر نہیں، ڈویلپرز "دن کے اگلے فوری طور پر اہم بگ" کو ٹھیک کرنے میں مصروف رہتے ہیں، اور ان کے پاس DevOps فیلڈ پر ایک سرسری نظر ڈالنے کا وقت بھی نہیں ہوتا ہے۔ مصنف کی سمجھ میں، DevOps، سب سے پہلے، عام فہم ہے۔ دوم، یہ زیادہ موثر ہونے کا موقع ہے۔ اگر آپ ڈویلپر ہیں، عقل رکھتے ہیں اور ٹیم پلیئر کے طور پر زیادہ موثر بننا چاہتے ہیں تو یہ رپورٹ آپ کے لیے ہے۔
مجھے اپنا تعارف کرانے دو، میں پوری طرح تسلیم کرتا ہوں کہ کمرے میں ایسے لوگ موجود ہیں جو مجھے نہیں جانتے۔ میرا نام Anton Boyko ہے، میں Microsoft Azure MVP ہوں۔ MVP کیا ہے؟ یہ ماڈل ویو پیش کنندہ ہے۔ ماڈل ویو پیش کنندہ بالکل میں ہوں۔
اس کے علاوہ، میں فی الحال Ciklum میں حل آرکیٹیکٹ کے عہدے پر فائز ہوں۔ اور ابھی حال ہی میں میں نے اپنے آپ کو اتنا خوبصورت ڈومین خریدا ہے، اور میں نے اپنا ای میل اپ ڈیٹ کیا ہے، جسے میں عام طور پر پیشکشوں میں دکھاتا ہوں۔ آپ مجھے اس پر لکھ سکتے ہیں: me [dog] byokoant.pro۔ آپ مجھے سوالات کے ساتھ ای میل کر سکتے ہیں۔ میں عموماً ان کا جواب دیتا ہوں۔ بات صرف یہ ہے کہ میں ای میل کے ذریعے ایسے سوالات وصول نہیں کرنا چاہوں گا جو دو موضوعات سے متعلق ہوں: سیاست اور مذہب۔ آپ مجھے ہر چیز کے بارے میں بذریعہ ای میل لکھ سکتے ہیں۔ کچھ وقت گزر جائے گا، جواب دوں گا۔
اپنے بارے میں چند الفاظ:
- میں اس فیلڈ میں 10 سال سے ہوں۔
- میں نے مائیکرو سافٹ میں کام کیا۔
- میں یوکرینی Azure کمیونٹی کا بانی باپ ہوں، جس کی بنیاد ہم نے کہیں 2014 میں رکھی تھی۔ اور ہمارے پاس اب بھی ہے اور اسے ترقی دے رہے ہیں۔
- میں Azure کانفرنس کے بانی کا باپ بھی ہوں، جس کی ہم یوکرین میں میزبانی کر رہے ہیں۔
- میں Kyiv میں گلوبل Azure Bootcamp کو منظم کرنے میں بھی مدد کرتا ہوں۔
- جیسا کہ میں نے کہا، میں ایک Microsoft Azure MVP ہوں۔
- میں اکثر کانفرنسوں میں بولتا ہوں۔ مجھے واقعی کانفرنسوں میں بات کرنا پسند ہے۔ پچھلے ایک سال میں میں تقریباً 40 بار پرفارم کرنے میں کامیاب رہا۔ اگر آپ یوکرین، بیلاروس، پولینڈ، بلغاریہ، سویڈن، ڈنمارک، ہالینڈ، اسپین کے پاس سے گزرتے ہیں یا یورپ کے کسی دوسرے ملک کو دیتے ہیں یا لیتے ہیں، تو یہ بالکل ممکن ہے کہ جب آپ کسی ایسی کانفرنس میں جائیں جس کے دھارے میں کلاؤڈ تھیم ہو، آپ مجھے بولنے والوں کی فہرست میں دیکھ سکتے ہیں۔
- میں بھی سٹار ٹریک کا پرستار ہوں۔
آئیے ایجنڈے کے بارے میں تھوڑی بات کرتے ہیں۔ ہمارا ایجنڈا بہت آسان ہے:
- ہم اس بارے میں بات کریں گے کہ DevOps کیا ہے۔ آئیے بات کرتے ہیں کہ یہ کیوں ضروری ہے۔ پہلے، DevOps ایک کلیدی لفظ تھا جو آپ نے اپنے تجربے کی فہرست میں لکھا تھا اور فوری طور پر +$500 تنخواہ وصول کی تھی۔ اب آپ کو اپنی تنخواہ میں +500 ڈالر حاصل کرنے کے لیے، مثال کے طور پر، اپنے ریزیومے میں بلاکچین لکھنے کی ضرورت ہے۔
- اور پھر، جب ہم اس کے بارے میں تھوڑا سا سمجھیں گے کہ یہ کیا ہے، تو ہم اس بارے میں بات کریں گے کہ DevOps کے طریق کار کیا ہیں۔ لیکن عام طور پر DevOps کے تناظر میں اتنا زیادہ نہیں، لیکن ان DevOps طریقوں کے بارے میں جو ڈویلپرز کے لیے دلچسپی کا باعث ہو سکتے ہیں۔ میں آپ کو بتاؤں گا کہ وہ آپ کے لیے کیوں دلچسپی رکھتے ہیں۔ میں آپ کو بتاؤں گا کہ آپ کو ایسا کیوں کرنا چاہئے اور یہ آپ کو کم درد کا تجربہ کرنے میں کس طرح مدد کرسکتا ہے۔
ایک روایتی تصویر جسے بہت سے لوگ دکھاتے ہیں۔ بہت سے منصوبوں میں ایسا ہوتا ہے۔ یہ تب ہوتا ہے جب ہمارے پاس ترقیاتی اور آپریشن کے شعبے ہوتے ہیں جو ہمارے سافٹ ویئر کو سپورٹ کرتے ہیں۔ اور یہ محکمے ایک دوسرے سے رابطہ نہیں کرتے۔
شاید، اگر آپ DevOps اور آپریشنز کے محکموں میں اسے اتنی واضح طور پر محسوس کرنے کے قابل نہیں تھے، تو آپ Dev اور QA محکموں کے ساتھ مشابہت پیدا کر سکتے ہیں۔ ایسے لوگ ہیں جو سافٹ ویئر تیار کرتے ہیں اور QA لوگ ہیں جو ڈویلپرز کے نقطہ نظر سے خراب ہیں۔ مثال کے طور پر، میں اپنے شاندار کوڈ کو ذخیرے میں بھیج دیتا ہوں، اور وہاں کوئی بدمعاش بیٹھا ہے جو مجھے یہ کوڈ واپس کر دیتا ہے اور کہتا ہے کہ تمہارا کوڈ خراب ہے۔
یہ سب اس لیے ہوتا ہے کہ لوگ ایک دوسرے سے بات چیت نہیں کرتے۔ اور وہ غلط فہمی کی کسی دیوار سے کچھ پیکجز، کچھ ایپلیکیشن ایک دوسرے پر پھینک دیتے ہیں اور ان کے ساتھ کچھ کرنے کی کوشش کرتے ہیں۔
یہ بالکل وہی دیوار ہے جسے ڈی او اوپس کلچر کو تباہ کرنے کے لیے ڈیزائن کیا گیا ہے، یعنی لوگوں کو ایک دوسرے سے بات چیت کرنے پر مجبور کریں اور کم از کم یہ سمجھیں کہ پروجیکٹ میں مختلف لوگ کیا کرتے ہیں اور ان کا کام کیوں اہم ہے۔
اور جب ہم DevOps کے بارے میں بات کرتے ہیں، کوئی آپ کو بتائے گا کہ DevOps تب ہوتا ہے جب پروجیکٹ میں مسلسل انضمام ہوتا ہے۔ کوئی کہے گا کہ DevOps یہ ہے اگر پروجیکٹ "انفراسٹرکچر بطور کوڈ" پریکٹس کو نافذ کرتا ہے۔ کوئی کہے گا کہ DevOps کا پہلا قدم فیچر برانچنگ، فیچر فلیگز ہے۔
بنیادی طور پر، یہ سب اپنے طریقے سے سچ ہے۔ لیکن یہ ہمارے پاس صرف حتمی طرز عمل ہیں۔ ان طریقوں پر جانے سے پہلے، میں اس سلائیڈ کو دیکھنے کا مشورہ دیتا ہوں، جو آپ کے پروجیکٹ میں، آپ کی کمپنی میں Dev-Ops طریقہ کار کو لاگو کرنے کے 3 مراحل کو ظاہر کرتی ہے۔
اس سلائیڈ کا دوسرا غیر سرکاری نام بھی ہے۔ آپ یہ جاننے کے لیے آن لائن تلاش کر سکتے ہیں کہ DevOps کے 3 Musketeers کیا ہیں۔ یہ ممکن ہے کہ آپ کو یہ مضمون مل جائے۔ کیوں 3 Musketeers؟ اس کے نیچے لکھا ہے: لوگ، عمل اور مصنوعات، یعنی پی پی پی - پورتھوس، پورتھوس اور پورتھوس۔ یہ ہیں DevOps کے 3 مسکیٹیئرز۔ یہ مضمون مزید تفصیل سے بیان کرتا ہے کہ یہ کیوں ضروری ہے اور اس میں کیا شامل ہے۔
جب آپ DevOps کلچر کو لاگو کرنا شروع کرتے ہیں، تو یہ بہت ضروری ہے کہ اسے درج ذیل ترتیب میں لاگو کیا جائے۔
شروع میں آپ کو لوگوں سے بات کرنے کی ضرورت ہے۔ اور آپ کو لوگوں کو سمجھانے کی ضرورت ہے کہ یہ کیا ہے اور وہ اس سے کچھ فوائد کیسے حاصل کر سکتے ہیں۔
ہماری کانفرنس کا نام ڈاٹ نیٹ فیسٹ ہے۔ اور جیسا کہ منتظمین نے مجھے بتایا، ہم نے بنیادی طور پر یہاں ڈویلپرز کے سامعین کو مدعو کیا، اس لیے مجھے امید ہے کہ ہال میں موجود زیادہ تر لوگ ترقی میں شامل ہوں گے۔
ہم لوگوں کے بارے میں بات کریں گے، ہم اس بارے میں بات کریں گے کہ ڈیولپرز ہر روز کیا کرنا چاہتے ہیں۔ وہ سب سے زیادہ کیا چاہتے ہیں؟ وہ کچھ نیا کوڈ لکھنا چاہتے ہیں، نیا فریم ورک استعمال کرنا چاہتے ہیں، نئی خصوصیات بنانا چاہتے ہیں۔ ڈویلپرز کم سے کم کیا چاہتے ہیں؟ پرانے کیڑے ٹھیک کریں۔ مجھے امید ہے کہ آپ میری بات سے اتفاق کرتے ہیں۔ ڈویلپرز یہی چاہتے ہیں۔ وہ نئی خصوصیات لکھنا چاہتے ہیں، وہ کیڑے ٹھیک نہیں کرنا چاہتے۔
کیڑے کی تعداد جو ایک خاص ڈویلپر پیدا کرتا ہے اس پر منحصر ہے کہ اس کے بازو کتنے سیدھے ہیں اور وہ اس کے کندھوں سے کتنے بڑھتے ہیں، نہ کہ اس کی بٹ جیب سے۔ لیکن اس کے باوجود، جب ہمارے پاس کوئی بڑا پروجیکٹ ہوتا ہے، تو کبھی کبھی ایسا ہوتا ہے کہ ہر چیز پر نظر رکھنا ناممکن ہوتا ہے، اس لیے ہمارے لیے اچھا ہوگا کہ ہم کچھ ایسے طریقے استعمال کریں جو ہمیں زیادہ مستحکم اور اعلیٰ معیار کا کوڈ لکھنے میں مدد فراہم کریں۔
QAs سب سے زیادہ کیا چاہتے ہیں؟ مجھے نہیں معلوم کہ وہ ہال میں ہیں یا نہیں۔ میرے لیے یہ کہنا مشکل ہے کہ میں QA چاہتا ہوں، کیونکہ میں کبھی نہیں رہا۔ اور لڑکوں کو کوئی جرم نہیں، یہ کہا جائے گا کہ مجھے امید ہے کہ میں کبھی نہیں کروں گا۔ لیکن اس وجہ سے نہیں کہ میں ان کے کام کو بے معنی اور فضول سمجھتا ہوں، بلکہ اس لیے کہ میں اپنے آپ کو ایسا شخص نہیں سمجھتا جو اس کام کو احسن طریقے سے انجام دے سکے، اس لیے میں اس کو کرنے کی کوشش بھی نہیں کروں گا۔ لیکن جو کچھ میں سمجھتا ہوں اس سے، QA جو سب سے زیادہ پسند نہیں کرتا ہے وہ صبح کے وقت کام کرنا ہے، مسلسل کسی قسم کے ریگریشن ٹیسٹ چلانا، انہی کیڑوں پر قدم رکھنا جو انہوں نے 3 سپرنٹ پہلے ڈیولپرز کو بتائے تھے اور کہا: "آپ کب کریں گے؟ , Monsieur D 'Artagnan، اس مسئلے کو ٹھیک کریں۔' اور Monsieur D'Artagnan نے اسے جواب دیا: "ہاں، ہاں، ہاں، میں نے اسے پہلے ہی ٹھیک کر دیا ہے۔" اور یہ کیسے ہوتا ہے کہ میں نے ایک بگ کو ٹھیک کیا اور راستے میں 5 بنائے۔
جو لوگ پروڈکشن میں اس حل کی حمایت کرتے ہیں وہ چاہتے ہیں کہ یہ حل بغیر کسی بگ کے کام کرے، تاکہ انہیں ہر جمعہ کو سرور کو دوبارہ شروع کرنے کی ضرورت نہ پڑے، جب تمام عام لوگ بار میں جاتے ہیں۔ جمعے کو تعینات کیے گئے ڈویلپرز، ایڈمنز ہفتے تک بیٹھے ہیں، اس تعیناتی کو ٹھیک کرنے کی کوشش کر رہے ہیں۔
اور جب آپ لوگوں کو سمجھاتے ہیں کہ ان کا مقصد انہی مسائل کو حل کرنا ہے، تو آپ عمل کو باقاعدہ بنانے کی طرف بڑھ سکتے ہیں۔ یہ بہت اہم ہے. کیوں؟ کیونکہ جب ہم کہتے ہیں "رسمی کاری"، تو آپ کے لیے یہ بیان کرنا ضروری ہے کہ آپ کے عمل کم از کم ایک رومال پر کیسے ہوتے ہیں۔ آپ کو یہ سمجھنے کی ضرورت ہے کہ اگر آپ، مثال کے طور پر، QA ماحول یا پیداواری ماحول میں تعینات کرتے ہیں، تو یہ ہمیشہ اس ترتیب میں ہوتا ہے؛ ان مراحل پر ہم چلاتے ہیں، مثال کے طور پر، خودکار یونٹ ٹیسٹ اور UI ٹیسٹ۔ تعیناتی کے بعد، ہم چیک کرتے ہیں کہ آیا تعیناتی اچھی ہوئی یا خراب۔ لیکن آپ کے پاس پہلے سے ہی کارروائیوں کی ایک واضح فہرست موجود ہے جنہیں آپ پروڈکشن میں تعینات کرتے وقت بار بار دہرایا جانا چاہیے۔
اور صرف اس صورت میں جب آپ کے عمل کو باقاعدہ بنایا جاتا ہے، کیا آپ ایسے پروڈکٹس کو منتخب کرنا شروع کر دیتے ہیں جو ان عملوں کو خودکار بنانے میں آپ کی مدد کریں گی۔
بدقسمتی سے، میں اکثر ایسا ہوتا ہوا دیکھتا ہوں۔ جیسے ہی کوئی لفظ "DevOps" سنتا ہے، وہ فوری طور پر Jenkins کو انسٹال کرنے کا مشورہ دیتے ہیں، کیونکہ انہیں یقین ہے کہ جیسے ہی وہ Jenkins انسٹال کریں گے، ان کے پاس DevOps ہو جائیں گے۔ انہوں نے جینکنز کو انسٹال کیا، جینکنز کی ویب سائٹ پر "ہاؤ ٹو" آرٹیکلز کو پڑھا، ان ہاؤ ٹو آرٹیکلز میں پروسیس بھرنے کی کوشش کی، اور پھر لوگوں کے پاس آئے اور لوگوں کو جھکایا، اور کہا کہ کتاب کہتی ہے کہ آپ کو اس طرح کرنے کی ضرورت ہے، تو ہم اس طرح کرتے ہیں.
ایسا نہیں ہے کہ جینکنز ایک برا ٹول ہے۔ میرا یہ کہنا کسی بھی طرح سے نہیں ہے۔ لیکن یہ صرف مصنوعات میں سے ایک ہے۔ اور آپ جو پروڈکٹ استعمال کرتے ہیں وہ آپ کا آخری فیصلہ ہونا چاہیے، اور ہرگز آپ کا پہلا فیصلہ نہیں ہونا چاہیے۔ آپ کی مصنوعات کو ثقافت اور نقطہ نظر کے نفاذ کے ذریعہ کارفرما نہیں ہونا چاہئے۔ یہ سمجھنا بہت ضروری ہے، یہی وجہ ہے کہ میں اس سلائیڈ پر اتنا وقت صرف کرتا ہوں اور اتنی دیر تک یہ سب سمجھاتا ہوں۔
آئیے عام طور پر DevOps طریقوں کے بارے میں بات کرتے ہیں۔ وہ کیا ہیں؟ مختلف کیا ہے؟ انہیں کیسے آزمائیں؟ وہ کیوں اہم ہیں؟
پہلی پریکٹس جس کے بارے میں آپ نے سنا ہو گا اسے Continuous Integration کہتے ہیں۔ شاید اس پروجیکٹ میں کسی کے پاس کنٹینیوئس انٹیگریشن (CI) ہے۔
سب سے بڑا مسئلہ یہ ہے کہ اکثر جب میں کسی شخص سے پوچھتا ہوں: "کیا آپ کے پاس پروجیکٹ پر CI ہے؟" اور وہ کہتا ہے: "ہاں،" پھر جب میں پوچھتا ہوں کہ وہ کیا کرتا ہے، تو وہ مجھے آٹومیشن کا پورا عمل بتاتا ہے۔ یہ مکمل طور پر درست نہیں ہے۔
درحقیقت، CI کی مشق کا مقصد صرف اس کوڈ کو مربوط کرنا ہے جسے مختلف لوگ کسی نہ کسی قسم کے سنگل کوڈ بیس میں لکھتے ہیں۔ بس۔
CI کے ساتھ ساتھ، راستے میں عام طور پر دوسرے طریقے بھی ہوتے ہیں - جیسے مسلسل تعیناتی، ریلیز مینجمنٹ، لیکن ہم اس کے بارے میں بعد میں بات کریں گے۔
CI خود ہمیں بتاتا ہے کہ مختلف لوگ کوڈ لکھتے ہیں اور اس کوڈ کو ایک ہی کوڈ بیس میں مسلسل ضم کیا جانا چاہیے۔
یہ ہمیں کیا دیتا ہے اور یہ کیوں ضروری ہے؟ اگر ہمارے پاس ڈاٹ نیٹ ہے، تو یہ اچھی بات ہے، یہ ایک مرتب شدہ زبان ہے، ہم اپنی درخواست کو مرتب کر سکتے ہیں۔ اگر یہ مرتب کرتا ہے، تو یہ پہلے سے ہی ایک اچھی علامت ہے۔ اس کا مطلب ابھی تک کچھ نہیں ہے، لیکن یہ پہلی اچھی علامت ہے جسے ہم کم از کم مرتب کر سکتے ہیں۔
پھر ہم کچھ ٹیسٹ چلا سکتے ہیں، جو کہ ایک الگ مشق بھی ہے۔ تمام ٹیسٹ سبز ہیں – یہ دوسری اچھی علامت ہے۔ لیکن پھر، اس کا کوئی مطلب نہیں ہے۔
لیکن آپ ایسا کیوں کریں گے؟ آج میں جن تمام طریقوں کے بارے میں بات کروں گا وہ تقریباً ایک ہی قدر کے حامل ہیں، یعنی تقریباً ایک جیسے فوائد اور تقریباً اسی طریقے سے ماپا جاتا ہے۔
سب سے پہلے، یہ آپ کو ترسیل کو تیز کرنے کی اجازت دیتا ہے. یہ آپ کو ترسیل کو تیز کرنے کی اجازت کیسے دیتا ہے؟ جب ہم اپنے کوڈ بیس میں کچھ نئی تبدیلیاں کرتے ہیں، تو ہم فوری طور پر اس کوڈ کے ساتھ کچھ کرنے کی کوشش کر سکتے ہیں۔ ہم جمعرات کے آنے تک انتظار نہیں کرتے کیونکہ جمعرات کو ہم اسے QA ماحولیات میں جاری کرتے ہیں، ہم اسے یہیں اور یہیں کرتے ہیں۔
میں آپ کو اپنی زندگی کی ایک دکھ بھری کہانی سناؤں گا۔ یہ بہت پہلے کی بات ہے، جب میں ابھی جوان اور خوبصورت تھا۔ اب میں پہلے ہی جوان، خوبصورت اور ہوشیار اور معمولی ہوں۔ کچھ عرصہ پہلے میں ایک پروجیکٹ میں تھا۔ ہمارے پاس تقریباً 30 ڈویلپرز کی ایک بڑی ٹیم تھی۔ اور ہمارے پاس ایک بڑا، بڑا انٹرپرائز پروجیکٹ تھا جو تقریباً 10 سال تک تیار ہوا۔ اور ہماری مختلف شاخیں تھیں۔ ذخیرہ میں ہماری ایک شاخ تھی جس میں ڈویلپرز چلتے تھے۔ اور ایک برانچ تھی جس نے کوڈ کا ورژن دکھایا جو پروڈکشن میں ہے۔
پروڈکشن برانچ اس برانچ سے 3 ماہ پیچھے تھی جو ڈویلپرز کے لیے دستیاب تھی۔ اس کا کیا مطلب ہے؟ اس کا مطلب یہ ہے کہ جیسے ہی میرے پاس کہیں کوئی بگ ہے جو ڈویلپرز کی غلطی کی وجہ سے پروڈکشن میں جاتا ہے، کیونکہ انہوں نے اس کی اجازت دی، اور QA کی غلطی کی وجہ سے، کیونکہ انہوں نے اسے دیکھا، تو اس کا مطلب ہے کہ اگر مجھے ایک پروڈکشن کے لیے ہاٹ فکس کے لیے ٹاسک، پھر مجھے 3 ماہ قبل اپنے کوڈ کی تبدیلیوں کو واپس کرنا ہوگا۔ مجھے یاد رکھنا ہے کہ میرے پاس 3 مہینے پہلے کیا تھا اور اسے وہاں ٹھیک کرنے کی کوشش کرنا ہے۔
اگر آپ نے ابھی تک یہ تجربہ نہیں کیا ہے، تو آپ اسے اپنے ہوم پروجیکٹ پر آزما سکتے ہیں۔ اہم بات یہ ہے کہ اسے کسی تجارتی پر نہ آزمائیں۔ کوڈ کی کچھ سطریں لکھیں، چھ ماہ کے لیے ان کے بارے میں بھول جائیں، اور پھر واپس آئیں اور جلدی سے یہ بتانے کی کوشش کریں کہ کوڈ کی وہ لائنیں کس کے بارے میں ہیں اور آپ انہیں کیسے ٹھیک یا بہتر بنا سکتے ہیں۔ یہ ایک بہت ہی دلچسپ تجربہ ہے۔
اگر ہمارے پاس ایک مسلسل انضمام کی مشق ہے، تو یہ ہمیں اس وقت اور ابھی، جیسے ہی میں نے اپنا کوڈ لکھا ہے، اسے متعدد خودکار ٹولز سے چیک کرنے کی اجازت دیتا ہے۔ یہ مجھے پوری تصویر نہیں دے سکتا، لیکن اس کے باوجود، یہ کم از کم کچھ خطرات کو دور کر دے گا۔ اور اگر کوئی ممکنہ خرابی ہے، تو میں اس کے بارے میں ابھی جان لوں گا، یعنی لفظی طور پر چند منٹوں میں۔ مجھے 3 مہینے پیچھے ہٹنے کی ضرورت نہیں ہوگی۔ مجھے صرف 2 منٹ واپس جانے کی ضرورت ہوگی۔ ایک اچھی کافی مشین کے پاس 2 منٹ میں کافی بنانے کا وقت بھی نہیں ہوگا، لہذا یہ بہت اچھا ہے۔
اس کی قدر ہے کہ اسے ہر پروجیکٹ پر وقتاً فوقتاً دہرایا جا سکتا ہے، یعنی صرف وہی نہیں جس پر آپ نے اسے ترتیب دیا ہے۔ آپ خود دونوں پریکٹس کو دہرا سکتے ہیں اور پروجیکٹ میں آپ کی ہر نئی تبدیلی کے لیے خود CI کو دہرایا جائے گا۔ یہ آپ کو وسائل کو بہتر بنانے کی اجازت دیتا ہے کیونکہ آپ کی ٹیم زیادہ مؤثر طریقے سے کام کرتی ہے۔ اب آپ کی ایسی صورتحال نہیں رہے گی جہاں آپ کے پاس اس کوڈ سے کوئی بگ آجائے جس کے ساتھ آپ نے 3 مہینے پہلے کام کیا تھا۔ جب آپ بیٹھیں گے اور پہلے دو گھنٹے یہ سمجھنے کی کوشش میں گزاریں گے کہ پھر کیا ہوا ہے اور سیاق و سباق کے جوہر میں جانے سے پہلے آپ کسی چیز کو درست کرنا شروع کریں گے تو آپ کو سیاق و سباق کی تبدیلی نہیں ہوگی۔
ہم اس مشق کی کامیابی یا ناکامی کی پیمائش کیسے کر سکتے ہیں؟ اگر آپ بڑے باس کو رپورٹ کرتے ہیں کہ ہم نے CI پراجیکٹ پر کیا عمل درآمد کیا ہے، تو وہ بلہ بلہ سنتا ہے۔ ہم نے اسے نافذ کیا، ٹھیک ہے، لیکن کیوں، یہ ہمارے لیے کیا لے کر آیا، ہم اس کی پیمائش کیسے کریں، ہم اسے کس حد تک درست یا غلط طریقے سے نافذ کر رہے ہیں؟
پہلا یہ کہ، CI کی بدولت، ہم زیادہ سے زیادہ کثرت سے تعینات کر سکتے ہیں، اور زیادہ کثرت سے اس لیے کہ ہمارا کوڈ ممکنہ طور پر زیادہ مستحکم ہے۔ اسی طرح غلطی کو تلاش کرنے میں ہمارا وقت کم ہو جاتا ہے اور اس غلطی کو درست کرنے کا وقت بالکل اس وجہ سے کم ہو جاتا ہے کہ ہمیں سسٹم کی طرف سے یہیں اور ابھی جواب موصول ہوتا ہے کہ ہمارے کوڈ میں کیا خرابی ہے۔
ہمارے پاس ایک اور مشق آٹومیشن ٹیسٹنگ پریکٹس ہے، جو اکثر CI پریکٹس کے ساتھ آتی ہے۔ وہ ہاتھ جوڑ کر چلتے ہیں۔
یہاں کیا سمجھنا ضروری ہے؟ یہ سمجھنا ضروری ہے کہ ہمارے ٹیسٹ مختلف ہیں۔ اور ہر خودکار ٹیسٹ کا مقصد اپنے مسائل کو حل کرنا ہوتا ہے۔ ہمارے پاس، مثال کے طور پر، یونٹ ٹیسٹ ہیں جو ہمیں ایک ماڈیول کو الگ سے جانچنے کی اجازت دیتے ہیں، یعنی یہ خلا میں کیسے کام کرتا ہے؟ یہ اچھا ہے.
ہمارے پاس انضمام کے ٹیسٹ بھی ہیں جو ہمیں یہ سمجھنے کی اجازت دیتے ہیں کہ مختلف ماڈیول ایک دوسرے کے ساتھ کیسے ضم ہوتے ہیں۔ یہ بھی اچھا ہے۔
ہمارے پاس UI آٹومیشن ٹیسٹ ہو سکتے ہیں جو ہمیں یہ جانچنے کی اجازت دیتے ہیں کہ UI کے ساتھ کام کس حد تک گاہک کی طرف سے مقرر کردہ کچھ ضروریات کو پورا کرتا ہے وغیرہ۔
آپ جو مخصوص ٹیسٹ چلاتے ہیں اس پر اثر پڑ سکتا ہے کہ آپ انہیں کتنی بار چلاتے ہیں۔ یونٹ ٹیسٹ عام طور پر چھوٹے اور چھوٹے لکھے جاتے ہیں۔ اور انہیں باقاعدگی سے لانچ کیا جا سکتا ہے۔
اگر ہم UI آٹومیشن ٹیسٹ کے بارے میں بات کر رہے ہیں، تو یہ اچھا ہے اگر آپ کا پروجیکٹ چھوٹا ہے۔ آپ کے UI آٹومیشن ٹیسٹوں میں کچھ مناسب وقت لگ سکتا ہے۔ لیکن عام طور پر UI آٹومیشن ٹیسٹ ایسا ہوتا ہے جس میں ایک بڑے پروجیکٹ پر کئی گھنٹے لگتے ہیں۔ اور یہ اچھا ہے اگر یہ چند گھنٹے ہے۔ بات صرف یہ ہے کہ انہیں ہر تعمیر کے لیے چلانے کا کوئی فائدہ نہیں۔ رات کو ان کو چلانا سمجھ میں آتا ہے۔ اور جب ہر کوئی صبح کام پر آیا: ٹیسٹرز اور ڈویلپرز دونوں، انہیں کسی نہ کسی قسم کی رپورٹ موصول ہوئی کہ ہم نے رات کو UI آٹو ٹیسٹ چلایا اور یہ نتائج حاصل ہوئے۔ اور یہاں، ایک سرور کا ایک گھنٹہ کام جو یہ چیک کرے گا کہ آپ کی پروڈکٹ کچھ ضروریات کو پورا کرتی ہے، اسی QA انجینئر کے کام کے ایک گھنٹے سے کہیں زیادہ سستا ہوگا، چاہے وہ جونیئر QA انجینئر ہی کیوں نہ ہو جو کھانے اور شکریہ کے لیے کام کرتا ہے۔ اسی طرح، مشین کے آپریشن کا ایک گھنٹہ سستا ہو جائے گا. یہی وجہ ہے کہ اس میں سرمایہ کاری کرنا سمجھ میں آتا ہے۔
میرے پاس ایک اور پروجیکٹ ہے جس پر میں کام کر رہا ہوں۔ ہمارے پاس اس پروجیکٹ پر دو ہفتے کے اسپرنٹ تھے۔ یہ منصوبہ بڑا، مالیاتی شعبے کے لیے اہم تھا، اور غلطی نہیں کی جا سکتی تھی۔ اور دو ہفتے کے اسپرنٹ کے بعد، ترقی کے چکر کے بعد جانچ کا عمل شروع ہوا، جس میں مزید 4 ہفتے لگے۔ سانحہ کے پیمانے کا تصور کرنے کی کوشش کریں۔ ہم دو ہفتوں کے لیے کوڈ لکھتے ہیں، پھر ہم اسے ala CodeFreeze کرتے ہیں، اسے ایپلیکیشن کے نئے ورژن میں پیک کرتے ہیں، اور اسے ٹیسٹرز کے لیے رول آؤٹ کرتے ہیں۔ ٹیسٹرز اسے مزید 4 ہفتوں تک آزماتے ہیں، یعنی جب وہ اس کی جانچ کر رہے ہیں، ہمارے پاس ان کے لیے مزید دو ورژن تیار کرنے کا وقت ہے۔ یہ واقعی افسوسناک معاملہ ہے۔
اور ہم نے ان سے کہا کہ اگر آپ زیادہ نتیجہ خیز بننا چاہتے ہیں، تو آپ کے لیے خودکار جانچ کے طریقوں کو لاگو کرنا سمجھ میں آتا ہے، کیونکہ یہ وہی چیز ہے جو آپ کو یہاں، ابھی تک تکلیف پہنچاتی ہے۔
مسلسل تعیناتی کی مشق کریں۔ بہت اچھا، آپ نے تعمیر مکمل کر لیا ہے۔ یہ پہلے ہی اچھا ہے۔ آپ کا کوڈ مرتب ہو گیا ہے۔ اب یہ اچھا ہو گا کہ اس عمارت کو کسی ماحول پر تعینات کیا جائے۔ آئیے ڈویلپرز کے ماحول میں کہتے ہیں۔
یہ کیوں ضروری ہے؟ سب سے پہلے، آپ دیکھ سکتے ہیں کہ آپ تعیناتی کے عمل میں کتنے کامیاب ہیں۔ میں نے اس طرح کے پروجیکٹس سے ملاقات کی ہے، جب میں پوچھتا ہوں: "آپ ایپلیکیشن کا نیا ورژن کیسے لگاتے ہیں؟"، لوگ مجھے بتاتے ہیں: "ہم اسے جمع کرتے ہیں اور اسے زپ آرکائیو میں پیک کرتے ہیں۔ ہم اسے ایڈمن کو بذریعہ ڈاک بھیجتے ہیں۔ منتظم اس آرکائیو کو ڈاؤن لوڈ اور پھیلاتا ہے۔ اور پورا دفتر دعا کرنے لگتا ہے کہ سرور نیا ورژن اٹھا لے۔
آئیے کچھ آسان کے ساتھ شروع کریں۔ مثال کے طور پر، وہ آرکائیو میں سی ایس ایس ڈالنا بھول گئے یا جاوا اسکرپٹ فائل کے نام میں ہیش ٹیگ کو تبدیل کرنا بھول گئے۔ اور جب ہم سرور سے درخواست کرتے ہیں تو براؤزر سوچتا ہے کہ اس کے پاس یہ جاوا اسکرپٹ فائل پہلے سے موجود ہے اور اسے ڈاؤن لوڈ نہ کرنے کا فیصلہ کرتا ہے۔ اور ایک پرانا ورژن تھا، کچھ غائب تھا۔ عام طور پر، بہت سے مسائل ہوسکتے ہیں. لہذا، مسلسل تعیناتی کی مشق آپ کو کم از کم یہ جانچنے کی اجازت دیتی ہے کہ اگر آپ نے ایک صاف حوالہ تصویر لی اور اسے بالکل صاف ستھرا ماحول میں اپ لوڈ کیا تو کیا ہوگا۔ آپ دیکھ سکتے ہیں کہ یہ کہاں جاتا ہے۔
نیز، جب آپ کوڈ کو ایک دوسرے کے درمیان مربوط کرتے ہیں، یعنی کمانڈ کے درمیان، یہ آپ کو یہ بھی دیکھنے کی اجازت دیتا ہے کہ یہ UI پر کیسا لگتا ہے۔
ایک مسئلہ جو اس وقت پیش آتا ہے جہاں بہت زیادہ ونیلا جاوا اسکرپٹ استعمال ہوتا ہے وہ یہ ہے کہ دو ڈویلپرز نے جلدی سے ونڈو آبجیکٹ میں ایک ہی نام کے ساتھ متغیر کا اعلان کیا۔ اور پھر، آپ کی قسمت پر منحصر ہے. جس کی جاوا اسکرپٹ فائل کو دوسری جگہ نکالا جاتا ہے وہ دوسرے کی تبدیلیوں کو اوور رائٹ کردے گا۔ یہ بھی بہت پرجوش ہے۔ آپ اندر آتے ہیں: ایک چیز ایک شخص کے لیے کام کرتی ہے، دوسری چیز دوسرے کے لیے کام نہیں کرتی۔ اور یہ "حیرت انگیز" ہے جب یہ سب کچھ پیداوار میں آتا ہے۔
اگلی پریکٹس جو ہمارے پاس ہے وہ آٹومیٹک ریسٹور کی پریکٹس ہے، یعنی ایپلیکیشن کے پچھلے ورژن پر واپس جانا۔
ڈویلپرز کے لیے یہ کیوں اہم ہے؟ اب بھی وہ لوگ ہیں جو 90 کی دہائی کو یاد کرتے ہیں، جب کمپیوٹر بڑے اور پروگرام چھوٹے تھے۔ اور ویب ڈویلپمنٹ کا واحد طریقہ پی ایچ پی کے ذریعے تھا۔ ایسا نہیں ہے کہ پی ایچ پی ایک بری زبان ہے، حالانکہ یہ ہے۔
لیکن مسئلہ مختلف تھا۔ جب ہم نے اپنی پی ایچ پی سائٹ کا نیا ورژن تعینات کیا تو ہم نے اسے کیسے تعینات کیا؟ اکثر ہم نے فار مینیجر یا کچھ اور کھولا۔ اور ان فائلوں کو FTP پر اپ لوڈ کیا۔ اور ہمیں اچانک احساس ہوا کہ ہمارے پاس کچھ چھوٹا، چھوٹا بگ ہے، مثال کے طور پر، ہم سیمی کالون لگانا بھول گئے یا ڈیٹا بیس کے لیے پاس ورڈ تبدیل کرنا بھول گئے، اور ڈیٹا بیس کے لیے ایک پاس ورڈ موجود ہے، جو کہ لوکل ہوسٹ پر ہے۔ اور ہم فوری طور پر FTP سے جڑنے اور فائلوں میں ترمیم کرنے کا فیصلہ کرتے ہیں۔ یہ صرف آگ ہے! یہ وہی ہے جو 90 کی دہائی میں مشہور تھا۔
لیکن، اگر آپ نے کیلنڈر کو نہیں دیکھا، تو 90 کی دہائی تقریباً 30 سال پہلے کی تھی۔ اب سب کچھ تھوڑا مختلف ہو رہا ہے۔ اور اس سانحے کے پیمانے کا تصور کرنے کی کوشش کریں جب وہ آپ کو بتائیں: "ہم نے پروڈکشن میں تعینات کیا، لیکن وہاں کچھ غلط ہو گیا۔ یہ رہا آپ کا ایف ٹی پی لاگ ان اور پاس ورڈ، پروڈکشن سے جڑیں اور جلدی سے اسے ٹھیک کریں۔" اگر آپ چک نورس ہیں، تو یہ کام کرے گا۔ اگر نہیں، تو آپ کو خطرہ ہے کہ اگر آپ ایک بگ کو ٹھیک کرتے ہیں تو آپ مزید 10 کر دیں گے۔ یہی وجہ ہے کہ پچھلے ورژن پر واپس جانے کا یہ عمل آپ کو بہت کچھ حاصل کرنے کی اجازت دیتا ہے۔
یہاں تک کہ اگر کوئی خراب چیز کسی نہ کسی طرح کہیں پروڈکٹ میں آگئی، تو یہ برا ہے، لیکن مہلک نہیں۔ آپ اپنے پچھلے ورژن پر واپس جا سکتے ہیں۔ اگر اس اصطلاح میں اسے سمجھنا آسان ہو تو اسے بیک اپ کہیں۔ آپ اس پچھلے ورژن پر واپس جا سکتے ہیں، اور صارفین اب بھی آپ کے پروڈکٹ کے ساتھ کام کر سکیں گے، اور آپ کے پاس کافی بفر ٹائم ہوگا۔ آپ سکون سے، جلدی کے بغیر، یہ سب لے سکتے ہیں اور اسے مقامی طور پر جانچ سکتے ہیں، اسے ٹھیک کر سکتے ہیں، اور پھر نیا ورژن اپ لوڈ کر سکتے ہیں۔ ایسا کرنا واقعی سمجھ میں آتا ہے۔
اب آئیے کسی طرح دونوں سابقہ طریقوں کو ایک ساتھ جوڑنے کی کوشش کریں۔ ہمیں ایک تیسرا ملے گا جسے ریلیز مینجمنٹ کہا جاتا ہے۔
جب ہم اس کی کلاسیکی شکل میں مسلسل تعیناتی کے بارے میں بات کرتے ہیں، تو ہم کہتے ہیں کہ ہمیں ذخیرے سے کسی شاخ سے کوڈ نکالنا چاہیے، اسے مرتب کرنا چاہیے اور اسے تعینات کرنا چاہیے۔ اچھا ہے اگر ہمارا ماحول ایک جیسا ہو۔ اگر ہمارے پاس کئی ماحول ہیں، تو اس کا مطلب ہے کہ ہمیں ہر بار کوڈ کھینچنا ہوگا، یہاں تک کہ ایک ہی کمٹ سے۔ ہم اسے ہر بار باہر نکالیں گے، ہم اسے ہر بار بنائیں گے اور ہم اسے ایک نئے ماحول میں تعینات کریں گے۔ سب سے پہلے، یہ وقت ہے، کیونکہ ایک پروجیکٹ بنانے کے لئے، اگر آپ کے پاس ایک بڑا ہے اور 90 کی دہائی سے آیا ہے، تو اس میں کئی گھنٹے لگ سکتے ہیں۔
اس کے علاوہ ایک اور دکھ بھی ہے۔ جب آپ تعمیر کرتے ہیں، یہاں تک کہ ایک ہی مشین پر، آپ وہی ذرائع بنائیں گے، آپ کے پاس اب بھی اس بات کی کوئی گارنٹی نہیں ہے کہ یہ مشین اسی حالت میں ہے جیسا کہ یہ پچھلی تعمیر کے دوران تھی۔
فرض کریں کہ کوئی آیا اور آپ کے لیے DotNet کو اپ ڈیٹ کیا یا، اس کے برعکس، کسی نے کچھ حذف کرنے کا فیصلہ کیا۔ اور پھر آپ کو علمی اختلاف ہے کہ اس کمٹ سے دو ہفتے پہلے ہم ایک بلڈ بنا رہے تھے اور سب کچھ ٹھیک تھا، لیکن اب ایسا لگتا ہے کہ وہی مشین، وہی کمٹ، وہی کوڈ جسے ہم بنانے کی کوشش کر رہے ہیں، لیکن یہ کام نہیں کر رہا ہے۔ . آپ اس کے ساتھ طویل عرصے سے نمٹ رہے ہوں گے اور یہ حقیقت نہیں ہے کہ آپ اس کا پتہ لگائیں گے۔ کم از کم، آپ اپنے اعصاب کو بہت خراب کر لیں گے۔
لہذا، ریلیز مینجمنٹ پریکٹس ایک اضافی تجرید کو متعارف کرانے کا مشورہ دیتی ہے جسے آرٹفیکٹ ریپوزٹری یا گیلری یا لائبریری کہا جاتا ہے۔ آپ اسے جو چاہیں کہہ سکتے ہیں۔
بنیادی خیال یہ ہے کہ جیسے ہی ہمارے پاس وہاں کسی قسم کا عہد ہوتا ہے، کہتے ہیں، ایک برانچ میں جسے ہم اپنے مختلف ماحول میں تعینات کرنے کے لیے تیار ہیں، ہم اس کمٹ سے درخواستیں جمع کرتے ہیں اور اس ایپلی کیشن کے لیے ہمیں درکار ہر چیز، ہم اسے پیک کرتے ہیں۔ زپ آرکائیو میں رکھیں اور اسے کسی قابل اعتماد اسٹوریج میں محفوظ کریں۔ اور اس اسٹوریج سے ہم یہ زپ آرکائیو کسی بھی وقت حاصل کر سکتے ہیں۔
پھر ہم اسے لیتے ہیں اور خود بخود اسے دیو ماحول میں تعینات کر دیتے ہیں۔ ہم وہاں دوڑتے ہیں، اور اگر سب کچھ اچھا ہے، تو ہم اسٹیج پر تعینات ہوتے ہیں۔ اگر سب کچھ ٹھیک ہے، تو ہم ایک ہی آرکائیو کو پروڈکشن میں تعینات کرتے ہیں، وہی بائنریز، جو بالکل ایک بار مرتب کی گئی تھیں۔
اس کے علاوہ، جب ہمارے پاس اس طرح کی ایک گیلری ہوتی ہے، تو یہ ہمیں ان خطرات سے نمٹنے میں بھی مدد دیتی ہے جن پر ہم نے پچھلی سلائیڈ پر توجہ دی تھی جب ہم نے پچھلے ورژن میں رول بیک کے بارے میں بات کی تھی۔ اگر آپ نے غلطی سے کچھ غلط تعینات کیا ہے، تو آپ ہمیشہ اس گیلری سے کوئی دوسرا سابقہ ورژن لے سکتے ہیں اور اسے ان ماحول میں اسی طرح سے ہٹا سکتے ہیں۔ اگر کچھ غلط ہو جاتا ہے تو یہ آپ کو آسانی سے پچھلے ورژن پر واپس جانے کی اجازت دیتا ہے۔
ایک اور زبردست مشق ہے۔ آپ اور میں سب سمجھتے ہیں کہ جب ہم اپنی ایپلیکیشنز کو پچھلے ورژن میں واپس لاتے ہیں تو اس کا مطلب یہ ہو سکتا ہے کہ ہمیں پچھلے ورژن کے بنیادی ڈھانچے کی بھی ضرورت ہے۔
جب ہم ورچوئل انفراسٹرکچر کے بارے میں بات کرتے ہیں تو بہت سے لوگ سوچتے ہیں کہ یہ وہ چیز ہے جسے منتظمین ترتیب دیتے ہیں۔ اور اگر آپ کو ایک نیا سرور حاصل کرنے کی ضرورت ہے جس پر آپ اپنی درخواست کے نئے ورژن کی جانچ کرنا چاہتے ہیں، تو آپ کو منتظمین یا ڈیوپس کو ٹکٹ لکھنا ہوگا۔ ڈیوپس کو اس کے لیے 3 ہفتے لگیں گے۔ اور 3 ہفتوں کے بعد وہ آپ کو بتائیں گے کہ ہم نے آپ کے لیے ایک ورچوئل مشین انسٹال کی ہے جس میں ایک کور، دو گیگا بائٹس ریم اور ڈاٹ نیٹ کے بغیر ونڈوز سرور ہے۔ آپ کہتے ہیں: "لیکن میں ڈاٹ نیٹ چاہتا تھا۔" وہ: "ٹھیک ہے، 3 ہفتوں میں واپس آجاؤ۔"
خیال یہ ہے کہ انفراسٹرکچر کو کوڈ پریکٹس کے طور پر استعمال کرکے، آپ اپنے ورچوئل انفراسٹرکچر کو صرف ایک اور وسیلہ سمجھ سکتے ہیں۔
شاید، اگر آپ میں سے کوئی ڈاٹ نیٹ پر ایپلی کیشنز تیار کر رہا ہے، تو آپ نے ایک لائبریری کے بارے میں سنا ہوگا جسے Entity Framework کہتے ہیں۔ اور آپ نے یہ بھی سنا ہوگا کہ ہستی کا فریم ورک ان طریقوں میں سے ایک ہے جسے مائیکروسافٹ فعال طور پر آگے بڑھا رہا ہے۔ ڈیٹا بیس کے ساتھ کام کرنے کے لیے، یہ ایک نقطہ نظر ہے جسے کوڈ فرسٹ کہتے ہیں۔ یہ تب ہوتا ہے جب آپ کوڈ میں بیان کرتے ہیں کہ آپ اپنے ڈیٹا بیس کو کیسا دیکھنا چاہتے ہیں۔ اور پھر آپ درخواست کو تعینات کرتے ہیں۔ یہ ڈیٹابیس سے جڑتا ہے، یہ خود طے کرتا ہے کہ کون سی میزیں ہیں اور کون سی میزیں نہیں، اور ہر وہ چیز تخلیق کرتی ہے جس کی آپ کو ضرورت ہے۔
آپ اپنے انفراسٹرکچر کے ساتھ بھی ایسا ہی کر سکتے ہیں۔ اس میں کوئی فرق نہیں ہے کہ آیا آپ کو کسی پروجیکٹ کے لیے ڈیٹا بیس کی ضرورت ہے یا آپ کو کسی پروجیکٹ کے لیے ونڈوز سرور کی ضرورت ہے۔ یہ صرف ایک وسیلہ ہے۔ اور آپ اس وسیلے کی تخلیق کو خودکار کر سکتے ہیں، آپ اس وسیلے کی تشکیل کو خودکار کر سکتے ہیں۔ اس کے مطابق، جب بھی آپ کوئی نیا تصور، کوئی نیا طریقہ آزمانا چاہتے ہیں، آپ کو ڈیوپس کے لیے ٹکٹ لکھنے کی ضرورت نہیں پڑے گی، آپ آسانی سے اپنے لیے ایک الگ تھلگ ڈھانچہ تیار کر سکتے ہیں، ریڈی میڈ ٹیمپلیٹس سے، ریڈی میڈ اسکرپٹس سے اور اسے نافذ کر سکتے ہیں۔ وہاں آپ کے تمام تجربات ہیں۔ آپ اسے حذف کر سکتے ہیں، کچھ نتائج حاصل کر سکتے ہیں اور اس کے بارے میں مزید رپورٹ کر سکتے ہیں۔
اگلی مشق، جو موجود بھی ہے اور اہم بھی ہے، لیکن جسے بہت کم لوگ استعمال کرتے ہیں، وہ ہے ایپلی کیشن پرفارمنس مانیٹرنگ۔
میں ایپلی کیشن پرفارمنس مانیٹرنگ کے بارے میں صرف ایک بات کہنا چاہتا تھا۔ اس مشق کے بارے میں سب سے اہم کیا ہے؟ یہ وہی ہے جو ایپلیکیشن پرفارمنس مانیٹرنگ ایک اپارٹمنٹ کی مرمت کی طرح ہے۔ یہ کوئی حتمی حالت نہیں ہے، یہ ایک عمل ہے۔ آپ کو اسے باقاعدگی سے کرنے کی ضرورت ہے۔
اچھے طریقے سے، تقریباً ہر تعمیر پر ایپلیکیشن پرفارمنس مانیٹرنگ کرنا اچھا ہوگا، حالانکہ جیسا کہ آپ سمجھتے ہیں، یہ ہمیشہ ممکن نہیں ہوتا ہے۔ لیکن، کم از کم، ہر ریلیز کے لیے اسے انجام دینے کی ضرورت ہے۔
یہ کیوں ضروری ہے؟ کیونکہ اگر آپ کو اچانک کارکردگی میں کمی کا سامنا کرنا پڑتا ہے، تو آپ کو واضح طور پر سمجھنے کی ضرورت ہے کہ کیوں۔ اگر آپ کی ٹیم کے پاس دو ہفتے کے اسپرنٹ ہیں، تو کم از کم ہر دو ہفتوں میں ایک بار آپ کو اپنی ایپلیکیشن کو کسی الگ سرور پر تعینات کرنا چاہیے، جہاں آپ کے پاس واضح طور پر طے شدہ پروسیسر، RAM، ڈسکیں وغیرہ ہیں۔ اور وہی کارکردگی کے ٹیسٹ چلائیں۔ . آپ کو نتیجہ ملتا ہے۔ دیکھیں کہ یہ پچھلے سپرنٹ سے کیسے بدل گیا ہے۔
اور اگر آپ کو پتہ چلتا ہے کہ ڈرا ڈاؤن کہیں تیزی سے نیچے چلا گیا ہے، تو اس کا مطلب یہ ہوگا کہ یہ صرف پچھلے دو ہفتوں کے دوران ہونے والی تبدیلیوں کی وجہ سے تھا۔ یہ آپ کو بہت تیزی سے مسئلے کی شناخت اور حل کرنے کی اجازت دے گا۔ اور ایک بار پھر، یہ تقریباً وہی میٹرکس ہیں جن کے ذریعے آپ پیمائش کر سکتے ہیں کہ آپ نے اسے کتنی کامیابی سے انجام دیا۔
ہمارے پاس اگلی مشق ہے کنفیگریشن مینجمنٹ پریکٹس۔ اس بات کو سنجیدگی سے لینے والے بہت کم ہیں۔ لیکن میرا یقین کرو، یہ اصل میں ایک بہت سنگین چیز ہے.
حال ہی میں ایک مضحکہ خیز کہانی سامنے آئی۔ وہ لوگ میرے پاس آئے اور کہا: "ہماری درخواست کا سیکیورٹی آڈٹ کرنے میں ہماری مدد کریں۔" ہم نے کافی دیر تک ایک ساتھ کوڈ کو دیکھا، انہوں نے مجھے ایپلیکیشن کے بارے میں بتایا، خاکے بنائے۔ اور پلس یا مائنس سب کچھ منطقی، قابل فہم، محفوظ تھا، لیکن ایک BUT تھا! ان کے پاس اپنے سورس کنٹرول میں کنفیگریشن فائلیں تھیں، بشمول آئی پی ڈیٹا بیس کے ساتھ پروڈکشن کی فائلیں، ان ڈیٹا بیس سے منسلک ہونے کے لیے لاگ ان اور پاس ورڈز وغیرہ۔
اور میں کہتا ہوں: "دوستوں، ٹھیک ہے، آپ نے اپنے پروڈکشن ماحول کو فائر وال سے بند کر دیا ہے، لیکن حقیقت یہ ہے کہ آپ کے پاس پروڈکشن ڈیٹا بیس کے لیے لاگ ان اور پاس ورڈ بالکل سورس کنٹرول میں ہے اور کوئی بھی ڈویلپر اسے پڑھ سکتا ہے، پہلے سے ہی ایک بہت بڑا سیکیورٹی رسک ہے۔ . اور اس بات سے کوئی فرق نہیں پڑتا ہے کہ آپ کی درخواست کوڈ کے نقطہ نظر سے کتنی ہی محفوظ ہے، اگر آپ اسے سورس کنٹرول میں چھوڑ دیتے ہیں، تو آپ کبھی بھی کہیں بھی کوئی آڈٹ پاس نہیں کریں گے۔" میں اسی کے بارے میں بات کر رہا ہوں۔
کنفیگریشن مینجمنٹ۔ ہمارے پاس مختلف ماحول میں مختلف کنفیگریشن ہو سکتے ہیں۔ مثال کے طور پر، ہمارے پاس QA، ڈیمو، پروڈکشن ماحول وغیرہ کے لیے ڈیٹا بیس کے لیے مختلف لاگ ان اور پاس ورڈز ہو سکتے ہیں۔
یہ ترتیب خودکار بھی ہو سکتی ہے۔ اسے ہمیشہ درخواست سے الگ ہونا چاہیے۔ کیوں؟ چونکہ آپ نے ایک بار ایپلی کیشن بنائی ہے، اور پھر ایپلیکیشن کو اس بات کی کوئی پرواہ نہیں ہے کہ آیا آپ فلاں اور فلاں IP یا فلاں اور فلاں IP کے ذریعے SQL سرور سے جڑتے ہیں، اس لیے اسے وہی کام کرنا چاہیے۔ اس لیے، اگر اچانک آپ میں سے کوئی ابھی بھی کوڈ میں کنکشن سٹرنگ کو ہارڈ کوڈ کر رہا ہے، تو یاد رکھیں کہ اگر آپ خود کو میرے ساتھ اسی پروجیکٹ پر پاتے ہیں تو میں آپ کو تلاش کروں گا اور آپ کو سزا دوں گا۔ یہ ہمیشہ ایک علیحدہ کنفیگریشن میں رکھا جاتا ہے، مثال کے طور پر web.config میں۔
اور یہ کنفیگریشن پہلے ہی الگ سے منظم ہے، یعنی یہ بالکل وہی لمحہ ہے جب ایک ڈویلپر اور ایڈمنسٹریٹر ایک ہی کمرے میں آکر بیٹھ سکتے ہیں۔ اور ڈویلپر کہہ سکتا ہے: "دیکھو، میری درخواست کی بائنریز یہ ہیں۔ وہ کام کرتے ہیں. ایپلیکیشن کو کام کرنے کے لیے ڈیٹا بیس کی ضرورت ہے۔ یہاں بائنریز کے آگے ایک فائل ہے۔ اس فائل میں، یہ فیلڈ لاگ ان کے لیے ذمہ دار ہے، یہ پاس ورڈ کے لیے ہے، یہ آئی پی کے لیے ہے۔ اسے کہیں بھی تعینات کر دیں۔" اور یہ منتظم کے لیے آسان اور واضح ہے۔ وہ اس ترتیب کو منظم کر کے اسے واقعی کہیں بھی تعینات کر سکتا ہے۔
اور آخری مشق جس کے بارے میں میں بات کرنا چاہوں گا وہ ایک مشق ہے جو بادلوں سے بہت زیادہ تعلق رکھتی ہے۔ اور اگر آپ بادل میں کام کرتے ہیں تو یہ زیادہ سے زیادہ اثر لاتا ہے۔ یہ آپ کے ماحول کو خودکار طریقے سے ہٹانا ہے۔
میں جانتا ہوں کہ اس کانفرنس میں ان ٹیموں میں سے کئی لوگ ہیں جن کے ساتھ میں کام کرتا ہوں۔ اور ان تمام ٹیموں کے ساتھ جن کے ساتھ میں کام کرتا ہوں، ہم اس مشق کو استعمال کرتے ہیں۔
کیوں؟ یقینا، یہ بہت اچھا ہو گا اگر ہر ڈویلپر کے پاس ایک ورچوئل مشین ہو جو 24/7 کام کرے گی۔ لیکن شاید یہ آپ کے لیے خبر ہے، شاید آپ نے توجہ نہیں دی، لیکن ڈویلپر خود 24/7 کام نہیں کرتا۔ ایک ڈویلپر عام طور پر دن میں 8 گھنٹے کام کرتا ہے۔ یہاں تک کہ اگر وہ جلدی کام پر آجاتا ہے، تو اس کے پاس ایک بڑا لنچ ہوتا ہے جس کے دوران وہ جم جاتا ہے۔ اسے دن میں 12 گھنٹے ہونے دیں جب ڈویلپر دراصل ان وسائل کو استعمال کرتا ہے۔ ہماری قانون سازی کے مطابق، ہمارے پاس ہفتے میں 5 میں سے 7 دن ہوتے ہیں جنہیں کام کے دن سمجھا جاتا ہے۔
اس کے مطابق ہفتے کے دنوں میں یہ مشین 24 گھنٹے نہیں بلکہ صرف 12 گھنٹے کام کرے گی اور ویک اینڈ پر یہ مشین بالکل کام نہیں کرنی چاہیے۔ ایسا لگتا ہے کہ سب کچھ بہت آسان ہے، لیکن یہاں کیا کہنا ضروری ہے؟ اس بنیادی شیڈول پر اس سادہ پریکٹس کو نافذ کرنے سے، یہ آپ کو ان ماحولیات کو برقرار رکھنے کی لاگت کو 70% تک کم کرنے کی اجازت دیتا ہے، یعنی آپ نے اپنے dev، QA، ڈیمو، ماحول کی قیمت لی اور اسے 3 سے تقسیم کیا۔
سوال یہ ہے کہ باقی رقم کا کیا کیا جائے؟ مثال کے طور پر، ڈویلپرز کو ReSharper خریدنا چاہیے اگر ان کے پاس پہلے سے نہیں ہے۔ یا کاک ٹیل پارٹی کریں۔ اگر آپ کے پاس پہلے ایک ماحول تھا جس میں dev اور QA دونوں چرتے تھے، اور بس، اب آپ 3 مختلف بنا سکتے ہیں جو الگ تھلگ ہوں گے، اور لوگ ایک دوسرے کے ساتھ مداخلت نہیں کریں گے۔
مسلسل کارکردگی کی پیمائش کے ساتھ سلائیڈ کے بارے میں، ہم کارکردگی کا موازنہ کیسے کر سکتے ہیں اگر پروجیکٹ میں ڈیٹا بیس میں ہمارے پاس 1 ریکارڈ موجود ہیں، دو ماہ بعد ایک ملین ہیں؟ یہ کیسے سمجھیں کہ کارکردگی کو ماپنے کا مقصد کیوں اور کیا ہے؟
یہ ایک اچھا سوال ہے، کیونکہ آپ کو ہمیشہ ایک ہی وسائل پر کارکردگی کی پیمائش کرنی چاہیے۔ یعنی، آپ نیا کوڈ رول آؤٹ کرتے ہیں، آپ نئے کوڈ پر کارکردگی کی پیمائش کرتے ہیں۔ مثال کے طور پر، آپ کو کارکردگی کے مختلف منظرناموں کو جانچنے کی ضرورت ہے، فرض کریں کہ آپ یہ جانچنا چاہتے ہیں کہ ایپلی کیشن ہلکے بوجھ پر کیسے کام کرتی ہے، جہاں 1 صارفین ہیں اور ڈیٹا بیس کا سائز 000 گیگا بائٹس ہے۔ آپ نے اسے ناپا اور نمبر مل گئے۔ اگلا ہم ایک اور منظرنامہ لیتے ہیں۔ مثال کے طور پر، 5 صارفین، ڈیٹا بیس کا سائز 5 ٹیرا بائٹ۔ ہم نے نتائج حاصل کیے اور انہیں یاد کیا۔
یہاں کیا ضروری ہے؟ یہاں اہم بات یہ ہے کہ منظر نامے، ڈیٹا کے حجم، بیک وقت استعمال کرنے والوں کی تعداد وغیرہ پر منحصر ہے، آپ کچھ حدوں میں جا سکتے ہیں۔ مثال کے طور پر، نیٹ ورک کارڈ کی حد تک، یا ہارڈ ڈرائیو کی حد تک، یا پروسیسر کی صلاحیتوں کی حد تک۔ یہ آپ کے لیے سمجھنا ضروری ہے۔ مختلف منظرناموں میں آپ کچھ حدود میں چلے جاتے ہیں۔ اور جب آپ ان کو مارتے ہیں تو آپ کو نمبروں کو سمجھنے کی ضرورت ہے۔
کیا ہم ایک خاص ٹیسٹ ماحول میں کارکردگی کی پیمائش کے بارے میں بات کر رہے ہیں؟ یعنی کیا یہ پیداوار نہیں ہے؟
جی ہاں، یہ پیداوار نہیں ہے، یہ ایک آزمائشی ماحول ہے، جو ہمیشہ ایک جیسا ہوتا ہے تاکہ آپ اس کا موازنہ پچھلی پیمائشوں سے کر سکیں۔
سمجھ گیا شکریہ!
اگر کوئی سوال نہیں ہے تو، مجھے لگتا ہے کہ ہم ختم کر سکتے ہیں. شکریہ!
ماخذ: www.habr.com