بنیادی ڈھانچہ بطور کوڈ: XP کا استعمال کرتے ہوئے مسائل پر کیسے قابو پایا جائے۔

ہیلو، حبر! پہلے، میں نے بنیادی ڈھانچے میں زندگی کے بارے میں کوڈ پیراڈیم کے طور پر شکایت کی تھی اور موجودہ صورتحال کو حل کرنے کے لیے کچھ بھی پیش نہیں کیا تھا۔ آج میں آپ کو یہ بتانے کے لیے واپس آیا ہوں کہ کون سے طریقے اور طرز عمل آپ کو مایوسی کے اتھاہ گہرائیوں سے نکلنے اور حالات کو درست سمت میں لے جانے میں مدد فراہم کریں گے۔

پچھلے مضمون میں "بطور بنیادی ڈھانچہ: پہلا تعارف" میں نے اس علاقے کے بارے میں اپنے تاثرات شیئر کیے، اس علاقے کی موجودہ صورت حال پر غور کرنے کی کوشش کی، اور یہاں تک کہ تجویز کیا کہ تمام ڈویلپرز کو معلوم معیاری طریقوں سے مدد مل سکتی ہے۔ ایسا لگتا ہے کہ زندگی کے بارے میں بہت سی شکایات تھیں، لیکن موجودہ حالات سے نکلنے کے لیے کوئی تجویز نہیں تھی۔

ہم کون ہیں، کہاں ہیں اور ہمیں کیا مسائل درپیش ہیں۔

ہم فی الحال Sre آن بورڈنگ ٹیم میں ہیں، جو چھ پروگرامرز اور تین انفراسٹرکچر انجینئرز پر مشتمل ہے۔ ہم سب انفراسٹرکچر کو بطور کوڈ (IaC) لکھنے کی کوشش کر رہے ہیں۔ ہم ایسا کرتے ہیں کیونکہ ہم بنیادی طور پر کوڈ لکھنا جانتے ہیں اور "اوسط سے اوپر" ڈویلپر ہونے کی تاریخ رکھتے ہیں۔

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

ٹیکنالوجی اسٹیک جو ہم اپنے IaC میں استعمال کرتے ہیں۔

• وسائل پیدا کرنے کے لیے ٹیرافارم۔
• تصاویر کو جمع کرنے کے لیے پیکر۔ یہ ونڈوز، سینٹوس 7 امیجز ہیں۔
• Jsonnet drone.io میں ایک طاقتور تعمیر کرنے کے ساتھ ساتھ پیکر json اور ہمارے ٹیرافارم ماڈیولز بنانے کے لیے۔
• Azure
• امیجز تیار کرتے وقت جوابدہ۔
• معاون خدمات اور پروویژننگ اسکرپٹس کے لیے ازگر۔
• اور یہ سب VSCode میں پلگ ان کے ساتھ جو ٹیم کے اراکین کے درمیان اشتراک کیا گیا ہے۔

میری طرف سے نتیجہ آخری مضمون اس طرح تھا: میں نے (سب سے پہلے اپنے اندر) رجائیت پیدا کرنے کی کوشش کی، میں یہ کہنا چاہتا تھا کہ اس علاقے میں موجود مشکلات اور پیچیدگیوں سے نمٹنے کے لیے ہم ان طریقوں اور طریقوں کو آزمائیں گے جو ہمیں معلوم ہیں۔

ہم فی الحال درج ذیل IaC مسائل کے ساتھ جدوجہد کر رہے ہیں:

• کوڈ کی نشوونما کے لیے ٹولز اور ذرائع کی خرابی۔
• سست تعیناتی۔ بنیادی ڈھانچہ حقیقی دنیا کا حصہ ہے، اور یہ سست ہو سکتا ہے۔
• طریقوں اور طریقوں کا فقدان۔
• ہم نئے ہیں اور زیادہ نہیں جانتے۔

ریسکیو کے لیے ایکسٹریم پروگرامنگ (XP)

تمام ڈویلپرز ایکسٹریم پروگرامنگ (XP) اور اس کے پیچھے کھڑے طریقوں سے واقف ہیں۔ ہم میں سے بہت سے لوگوں نے اس نقطہ نظر کے ساتھ کام کیا ہے، اور یہ کامیاب رہا ہے۔ تو کیوں نہ بنیادی ڈھانچے کے چیلنجوں پر قابو پانے کے لیے وہاں وضع کردہ اصولوں اور طریقوں کو استعمال کیا جائے؟ ہم نے یہ طریقہ اختیار کرنے کا فیصلہ کیا اور دیکھیں کہ کیا ہوتا ہے۔

آپ کی صنعت کے لیے XP اپروچ کی لاگو ہونے کی جانچ کرنایہاں اس ماحول کی تفصیل ہے جس کے لیے XP مناسب ہے، اور یہ ہم سے کیسے متعلق ہے:

1. متحرک طور پر سافٹ ویئر کی ضروریات کو تبدیل کرنا۔ یہ ہم پر واضح تھا کہ آخر مقصد کیا ہے۔ لیکن تفصیلات مختلف ہو سکتی ہیں۔ ہم خود فیصلہ کرتے ہیں کہ ہمیں کہاں ٹیکسی کی ضرورت ہے، اس لیے تقاضے وقتاً فوقتاً تبدیل ہوتے رہتے ہیں (بنیادی طور پر خود سے)۔ اگر ہم ایس آر ای ٹیم کو لیں، جو خود آٹومیشن کرتی ہے، اور خود کام کی ضروریات اور دائرہ کار کو محدود کرتی ہے، تو یہ نکتہ بالکل فٹ بیٹھتا ہے۔

2. نئی ٹیکنالوجی کا استعمال کرتے ہوئے مقررہ وقت کے منصوبوں سے پیدا ہونے والے خطرات۔ کچھ ایسی چیزیں استعمال کرتے وقت ہمیں خطرات کا سامنا کرنا پڑ سکتا ہے جو ہمارے لیے نامعلوم ہیں۔ اور یہ 100% ہمارا معاملہ ہے۔ ہمارا پورا پروجیکٹ ان ٹیکنالوجیز کا استعمال تھا جس سے ہم پوری طرح واقف نہیں تھے۔ عام طور پر، یہ ایک مستقل مسئلہ ہے، کیونکہ... بنیادی ڈھانچے کے شعبے میں ہر وقت بہت سی نئی ٹیکنالوجیز ابھرتی رہتی ہیں۔

3,4 چھوٹی، شریک واقع توسیعی ترقیاتی ٹیم۔ آپ جو خودکار ٹیکنالوجی استعمال کر رہے ہیں وہ یونٹ اور فنکشنل ٹیسٹ کی اجازت دیتی ہے۔ یہ دونوں نکات ہم پر بالکل سوٹ نہیں کرتے۔ اول، ہم ایک مربوط ٹیم نہیں ہیں، اور دوم، ہم میں سے نو ہیں، جنہیں ایک بڑی ٹیم سمجھا جا سکتا ہے۔ اگرچہ، "بڑی" ٹیم کی کچھ تعریفوں کے مطابق، بہت زیادہ 14+ افراد ہیں۔

آئیے XP کے کچھ طریقوں کو دیکھتے ہیں اور وہ تاثرات کی رفتار اور معیار کو کیسے متاثر کرتے ہیں۔

ایکس پی فیڈ بیک لوپ کا اصول

میری سمجھ میں، فیڈ بیک سوال کا جواب ہے، کیا میں صحیح کام کر رہا ہوں، کیا ہم وہاں جا رہے ہیں؟ ایکس پی کے پاس اس کے لیے ایک الہی اسکیم ہے: ایک ٹائم فیڈ بیک لوپ۔ دلچسپ بات یہ ہے کہ ہم جتنے کم ہوں گے، اتنی ہی تیزی سے ہم ضروری سوالات کے جوابات دینے کے لیے OS حاصل کرنے میں کامیاب ہوں گے۔

یہ بحث کے لیے ایک دلچسپ موضوع ہے، کہ ہماری IT انڈسٹری میں جلدی سے OS حاصل کرنا ممکن ہے۔ اندازہ لگائیں کہ چھ ماہ تک کسی پروجیکٹ کو کرنا کتنا تکلیف دہ ہوتا ہے اور تب ہی پتہ چلتا ہے کہ شروع میں ہی غلطی تھی۔ یہ ڈیزائن اور پیچیدہ نظاموں کی کسی بھی تعمیر میں ہوتا ہے۔

ہمارے IaC کے معاملے میں، تاثرات ہماری مدد کرتا ہے۔ میں فوری طور پر اوپر دیے گئے خاکے میں ایک چھوٹی سی ایڈجسٹمنٹ کروں گا: ریلیز پلان میں ماہانہ سائیکل نہیں ہوتا ہے، لیکن یہ دن میں کئی بار ہوتا ہے۔ اس OS سائیکل سے جڑے ہوئے کچھ طرز عمل ہیں جن کو ہم مزید تفصیل سے دیکھیں گے۔

اہم: فیڈ بیک اوپر بیان کردہ تمام مسائل کا حل ہو سکتا ہے۔ XP کے طریقوں کے ساتھ مل کر، یہ آپ کو مایوسی کی کھائی سے نکال سکتا ہے۔

اپنے آپ کو مایوسی کی کھائی سے کیسے نکالیں: تین طریقے

ٹیسٹ

XP فیڈ بیک لوپ میں ٹیسٹ کا ذکر دو بار کیا گیا ہے۔ یہ صرف ایسا نہیں ہے۔ وہ پوری ایکسٹریم پروگرامنگ تکنیک کے لیے انتہائی اہم ہیں۔

یہ فرض کیا جاتا ہے کہ آپ کے پاس یونٹ اور قبولیت کے ٹیسٹ ہیں۔ کچھ آپ کو چند منٹوں میں رائے دیتے ہیں، کچھ کچھ دنوں میں، اس لیے انہیں لکھنے میں زیادہ وقت لگتا ہے اور ان کا اکثر جائزہ لیا جاتا ہے۔

ایک کلاسک ٹیسٹنگ پرامڈ ہے، جس سے پتہ چلتا ہے کہ مزید ٹیسٹ ہونے چاہئیں۔

IaC پروجیکٹ میں یہ فریم ورک ہم پر کیسے لاگو ہوتا ہے؟ دراصل... بالکل نہیں۔

• یونٹ ٹیسٹ، اس حقیقت کے باوجود کہ ان میں سے بہت زیادہ ہونا چاہیے، بہت زیادہ نہیں ہو سکتے۔ یا وہ بہت بالواسطہ طور پر کسی چیز کی جانچ کر رہے ہیں۔ درحقیقت، ہم کہہ سکتے ہیں کہ ہم انہیں بالکل نہیں لکھتے۔ لیکن یہاں اس طرح کے ٹیسٹ کے لیے چند ایپلی کیشنز ہیں جو ہم کرنے کے قابل تھے:
  1. jsonnet کوڈ کی جانچ کرنا۔ یہ، مثال کے طور پر، ہماری ڈرون اسمبلی پائپ لائن ہے، جو کافی پیچیدہ ہے۔ jsonnet کوڈ ٹیسٹوں میں اچھی طرح سے احاطہ کرتا ہے۔
     ہم اسے استعمال کرتے ہیں۔ Jsonnet کے لیے یونٹ ٹیسٹنگ فریم ورک.
  2. اسکرپٹ کے ٹیسٹ جو وسائل کے شروع ہونے پر عمل میں آتے ہیں۔ اسکرپٹ ازگر میں لکھے جاتے ہیں، اور اس لیے ان پر ٹیسٹ لکھے جا سکتے ہیں۔
• ٹیسٹوں میں کنفیگریشن کو چیک کرنا ممکنہ طور پر ممکن ہے، لیکن ہم ایسا نہیں کرتے۔ کے ذریعے وسائل کی ترتیب کے قواعد کی جانچ پڑتال کو ترتیب دینا بھی ممکن ہے۔ tflint. تاہم، وہاں کے چیک ٹیرافارم کے لیے بہت بنیادی ہیں، لیکن بہت سے ٹیسٹ اسکرپٹ AWS کے لیے لکھے گئے ہیں۔ اور ہم Azure پر ہیں، لہذا یہ دوبارہ لاگو نہیں ہوتا ہے۔
• اجزاء کے انضمام کے ٹیسٹ: یہ اس بات پر منحصر ہے کہ آپ ان کی درجہ بندی کیسے کرتے ہیں اور آپ انہیں کہاں رکھتے ہیں۔ لیکن وہ بنیادی طور پر کام کرتے ہیں۔

  انضمام کے ٹیسٹ اس طرح نظر آتے ہیں۔

  
  
  ڈرون سی آئی میں تصاویر بناتے وقت یہ ایک مثال ہے۔ ان تک پہنچنے کے لیے، آپ کو پیکر کی تصویر بننے کے لیے 30 منٹ انتظار کرنا ہوگا، پھر ان کے گزرنے کے لیے مزید 15 منٹ انتظار کرنا ہوگا۔ لیکن وہ موجود ہیں!

  تصویری تصدیق کا الگورتھم

  1. پیکر کو پہلے تصویر کو مکمل طور پر تیار کرنا چاہیے۔
  2. ٹیسٹ کے آگے ایک مقامی ریاست کے ساتھ ایک ٹیرافارم ہے، جسے ہم اس تصویر کو تعینات کرنے کے لیے استعمال کرتے ہیں۔
  3. کھولتے وقت، تصویر کے ساتھ کام کرنا آسان بنانے کے لیے قریب میں پڑا ایک چھوٹا ماڈیول استعمال کیا جاتا ہے۔
  4. تصویر سے VM کے تعینات ہونے کے بعد، جانچ شروع ہو سکتی ہے۔ بنیادی طور پر، چیک گاڑی کے ذریعے کئے جاتے ہیں. یہ چیک کرتا ہے کہ اسکرپٹس نے اسٹارٹ اپ پر کیسے کام کیا اور ڈیمن کیسے کام کرتے ہیں۔ ایسا کرنے کے لیے، ssh یا winrm کے ذریعے ہم نئی اٹھائی گئی مشین میں لاگ ان ہوتے ہیں اور کنفیگریشن اسٹیٹس کو چیک کرتے ہیں یا سروسز ختم ہو چکی ہیں۔

• ٹیرافارم کے ماڈیولز میں انضمام کے ٹیسٹ کے ساتھ بھی صورتحال ایسی ہی ہے۔ یہاں ایک مختصر جدول ہے جو اس طرح کے ٹیسٹ کی خصوصیات کی وضاحت کرتا ہے۔

  
  
  پائپ لائن پر فیڈ بیک تقریباً 40 منٹ کا ہے۔ سب کچھ بہت طویل عرصے تک ہوتا ہے۔ اسے رجعت کے لیے استعمال کیا جا سکتا ہے، لیکن نئی ترقی کے لیے یہ عام طور پر غیر حقیقی ہے۔ اگر آپ اس کے لیے بہت تیار ہیں، چلتے ہوئے اسکرپٹ تیار کریں، تو آپ اسے 10 منٹ تک کم کر سکتے ہیں۔ لیکن یہ اب بھی یونٹ ٹیسٹ نہیں ہیں، جو 5 سیکنڈ میں 100 ٹکڑے کرتے ہیں۔

امیجز یا ٹیرافارم ماڈیولز کو جمع کرتے وقت یونٹ ٹیسٹ کی عدم موجودگی کام کو علیحدہ خدمات میں منتقل کرنے کی حوصلہ افزائی کرتی ہے جو کہ صرف REST کے ذریعے چلائی جا سکتی ہیں، یا Python اسکرپٹس میں۔

مثال کے طور پر، ہمیں اس بات کو یقینی بنانے کی ضرورت تھی کہ جب ورچوئل مشین شروع ہوتی ہے، تو یہ خود کو سروس میں رجسٹر کرتی ہے۔ اسکیل ایف ٹی، اور جب ورچوئل مشین تباہ ہوگئی تو اس نے خود کو حذف کردیا۔

چونکہ ہمارے پاس اسکیل ایف ٹی ایک سروس کے طور پر ہے، ہم اس کے ساتھ API کے ذریعے کام کرنے پر مجبور ہیں۔ وہاں ایک ریپر لکھا ہوا تھا جسے آپ کھینچ سکتے ہیں اور کہہ سکتے ہیں: "اندر جاؤ اور اسے حذف کرو۔" یہ تمام ضروری ترتیبات اور رسائی کو محفوظ کرتا ہے۔

ہم اس کے لیے پہلے ہی عام ٹیسٹ لکھ سکتے ہیں، کیونکہ یہ عام سافٹ ویئر سے مختلف نہیں ہے: کسی قسم کی اپیہا کا مذاق اڑایا جاتا ہے، آپ اسے کھینچیں، اور دیکھیں کہ کیا ہوتا ہے۔

ٹیسٹ کے نتائج: یونٹ ٹیسٹنگ، جو OS کو ایک منٹ میں دینا چاہیے، وہ نہیں دیتی۔ اور اہرام میں اعلیٰ قسم کی جانچیں مؤثر ہیں، لیکن مسائل کے صرف ایک حصے کا احاطہ کرتی ہیں۔

جوڑا پروگرامنگ۔

ٹیسٹ یقیناً اچھے ہیں۔ آپ ان میں سے بہت کچھ لکھ سکتے ہیں، وہ مختلف قسم کے ہو سکتے ہیں۔ وہ اپنی سطح پر کام کریں گے اور ہمیں رائے دیں گے۔ لیکن خراب یونٹ ٹیسٹوں کا مسئلہ، جو تیز ترین OS دیتے ہیں، باقی ہے۔ ایک ہی وقت میں، میں اب بھی ایک تیز OS چاہتا ہوں جس کے ساتھ کام کرنا آسان اور خوشگوار ہو۔ نتیجے میں حل کے معیار کا ذکر نہ کرنا۔ خوش قسمتی سے، ایسی تکنیکیں موجود ہیں جو یونٹ ٹیسٹوں کے مقابلے میں بھی تیز فیڈ بیک فراہم کر سکتی ہیں۔ یہ جوڑی پروگرامنگ ہے۔

کوڈ لکھتے وقت، آپ جلد از جلد اس کے معیار پر رائے حاصل کرنا چاہتے ہیں۔ جی ہاں، آپ فیچر برانچ میں سب کچھ لکھ سکتے ہیں (تاکہ کسی کے لیے کچھ نہ ٹوٹے)، گیتھب میں پل کی درخواست کر سکتے ہیں، اسے کسی ایسے شخص کو تفویض کر سکتے ہیں جس کی رائے میں وزن ہو، اور جواب کا انتظار کریں۔

لیکن آپ طویل انتظار کر سکتے ہیں۔ لوگ سب مصروف ہیں، اور جواب، یہاں تک کہ اگر ایک بھی ہے، اعلی ترین معیار کا نہیں ہوسکتا ہے۔ فرض کریں کہ جواب فوراً آ گیا، جائزہ لینے والے کو فوراً سارا خیال سمجھ آ گیا، لیکن جواب پھر بھی دیر سے آتا ہے، حقیقت کے بعد۔ کاش یہ پہلے ہوتا۔ یہ وہی ہے جو جوڑی پروگرامنگ کا مقصد ہے - لکھنے کے وقت۔

ذیل میں جوڑے کے پروگرامنگ کے انداز اور IaC پر کام کرنے میں ان کے قابل اطلاق ہیں:

1. کلاسک، تجربہ کار + تجربہ کار، ٹائمر کے ذریعے شفٹ۔ دو کردار - ڈرائیور اور نیویگیٹر۔ دو لوگ. وہ ایک ہی کوڈ پر کام کرتے ہیں اور ایک مقررہ مدت کے بعد کرداروں کو تبدیل کرتے ہیں۔

آئیے اسلوب کے ساتھ اپنے مسائل کی مطابقت پر غور کریں:

• مسئلہ: کوڈ ڈیولپمنٹ کے لیے ٹولز اور ٹولز کی خرابی۔
  منفی اثر: ترقی میں زیادہ وقت لگتا ہے، ہم سست ہو جاتے ہیں، کام کی رفتار/تال ختم ہو جاتا ہے۔
  ہم کیسے لڑتے ہیں: ہم ایک مختلف ٹولنگ، ایک عام IDE استعمال کرتے ہیں اور شارٹ کٹ بھی سیکھتے ہیں۔
• مسئلہ: سست تعیناتی۔
  منفی اثر: کوڈ کے کام کرنے والے ٹکڑے کو بنانے میں لگنے والے وقت کو بڑھاتا ہے۔ انتظار کرتے کرتے ہم بور ہو جاتے ہیں، انتظار کرتے کرتے ہمارے ہاتھ کچھ اور کرنے کو پہنچ جاتے ہیں۔
  ہم کیسے لڑتے ہیں: ہم نے اس پر قابو نہیں پایا۔
• مسئلہ: طریقوں اور طریقوں کی کمی۔
  منفی اثر: اس کے بارے میں کوئی علم نہیں ہے کہ اسے اچھی طرح کیسے کرنا ہے اور اسے خراب طریقے سے کیسے کرنا ہے۔ تاثرات کی وصولی کو لمبا کرتا ہے۔
  ہم کیسے لڑتے ہیں: جوڑے کے کام میں رائے اور طرز عمل کے باہمی تبادلے سے مسئلہ تقریباً حل ہو جاتا ہے۔

IaC میں اس انداز کو استعمال کرنے کا سب سے بڑا مسئلہ کام کی ناہموار رفتار ہے۔ روایتی سافٹ ویئر ڈویلپمنٹ میں، آپ کی حرکت بہت یکساں ہے۔ آپ پانچ منٹ خرچ کر کے N لکھ سکتے ہیں۔ 10 منٹ خرچ کر کے 2N، 15 منٹ - 3N لکھ سکتے ہیں۔ یہاں آپ پانچ منٹ خرچ کر کے N لکھ سکتے ہیں، اور پھر مزید 30 منٹ گزار کر N کا دسواں حصہ لکھ سکتے ہیں۔ یہاں آپ کو کچھ معلوم نہیں، آپ پھنس گئے، احمق ہیں۔ تفتیش میں وقت لگتا ہے اور پروگرامنگ سے ہی توجہ ہٹ جاتی ہے۔

نتیجہ: اس کی خالص شکل میں یہ ہمارے لیے موزوں نہیں ہے۔

2. پنگ پونگ۔ اس نقطہ نظر میں ایک شخص ٹیسٹ لکھنا اور دوسرا اس پر عمل درآمد کرنا شامل ہے۔ اس حقیقت کو مدنظر رکھتے ہوئے کہ یونٹ ٹیسٹ کے ساتھ سب کچھ پیچیدہ ہے، اور آپ کو ایک انٹیگریشن ٹیسٹ لکھنا پڑتا ہے جس میں پروگرام کرنے میں کافی وقت لگتا ہے، پنگ پونگ کی تمام آسانی ختم ہوجاتی ہے۔

میں کہہ سکتا ہوں کہ ہم نے ٹیسٹ اسکرپٹ کو ڈیزائن کرنے اور اس کے لیے کوڈ کو لاگو کرنے کی ذمہ داریوں کو الگ کرنے کی کوشش کی۔ ایک شریک اسکرپٹ کے ساتھ آیا، کام کے اس حصے میں وہ ذمہ دار تھا، اس کے پاس آخری لفظ تھا۔ اور دوسرا عمل درآمد کا ذمہ دار تھا۔ یہ اچھی طرح سے کام کیا. اس اپروچ کے ساتھ اسکرپٹ کا معیار بڑھتا ہے۔

نتیجہ: افسوس، کام کی رفتار IaC میں پنگ پونگ کو جوڑی پروگرامنگ پریکٹس کے طور پر استعمال کرنے کی اجازت نہیں دیتی۔

3. مضبوط انداز. مشکل مشق. خیال یہ ہے کہ ایک شریک ہدایت کار بن جاتا ہے، اور دوسرا پھانسی کے ڈرائیور کا کردار ادا کرتا ہے۔ اس صورت میں، فیصلے کرنے کا حق صرف نیویگیٹر کے پاس ہے۔ ڈرائیور صرف پرنٹ کرتا ہے اور ایک لفظ کے ساتھ کیا ہو رہا ہے اس پر اثر انداز ہو سکتا ہے۔ کردار زیادہ دیر تک نہیں بدلتے۔

سیکھنے کے لیے اچھا ہے، لیکن مضبوط نرم مہارتوں کی ضرورت ہے۔ یہ وہ جگہ ہے جہاں ہم لڑکھڑا گئے۔ تکنیک مشکل تھی۔ اور یہ بنیادی ڈھانچے کے بارے میں بھی نہیں ہے۔

نتیجہ: یہ ممکنہ طور پر استعمال کیا جا سکتا ہے، ہم کوشش کرنا ترک نہیں کر رہے ہیں۔

4. ہجوم، ہجوم اور تمام معروف لیکن درج نہیں طرزیں۔ ہم اس پر غور نہیں کرتے، کیونکہ ہم نے اس کی کوشش نہیں کی ہے اور اپنے کام کے تناظر میں اس کے بارے میں بات کرنا ناممکن ہے۔

جوڑی پروگرامنگ کے استعمال کے عمومی نتائج:

• ہمارے پاس کام کی رفتار ناہموار ہے، جو مبہم ہے۔
• ہم ناکافی طور پر اچھی نرم مہارتوں میں بھاگ گئے۔ اور موضوع کا علاقہ ہماری ان خامیوں کو دور کرنے میں مدد نہیں کرتا۔
• لمبے ٹیسٹ اور ٹولز کے ساتھ مسائل جوڑے کی ترقی کو مشکل بنا دیتے ہیں۔

5. اس کے باوجود، کامیابیاں تھیں۔ ہم اپنا اپنا طریقہ "کنورجنس - ڈائیورجینس" لے کر آئے ہیں۔ میں مختصراً بیان کروں گا کہ یہ کیسے کام کرتا ہے۔

ہمارے پاس چند دنوں کے لیے مستقل شراکت دار ہیں (ایک ہفتے سے کم)۔ ہم مل کر ایک کام کرتے ہیں۔ ہم تھوڑی دیر کے لیے اکٹھے بیٹھتے ہیں: ایک لکھتا ہے، دوسرا بیٹھتا ہے اور سپورٹ ٹیم کو دیکھتا ہے۔ پھر ہم کچھ دیر کے لیے منتشر ہو جاتے ہیں، ہر ایک کچھ آزادانہ کام کرتا ہے، پھر ہم دوبارہ اکٹھے ہو جاتے ہیں، بہت تیزی سے ہم آہنگ ہو جاتے ہیں، کچھ مل کر کرتے ہیں اور دوبارہ منتشر ہو جاتے ہیں۔

منصوبہ بندی اور مواصلات

طریقوں کا آخری بلاک جس کے ذریعے OS کے مسائل حل کیے جاتے ہیں وہ کاموں کے ساتھ کام کی تنظیم ہے۔ اس میں تجربے کا تبادلہ بھی شامل ہے جو جوڑے کے کام سے باہر ہے۔ آئیے تین طریقوں کو دیکھیں:

1. گول درخت کے ذریعے مقاصد۔ ہم نے منصوبے کے مجموعی انتظام کو ایک درخت کے ذریعے منظم کیا جو مستقبل میں لامتناہی طور پر جاتا ہے۔ تکنیکی طور پر، ٹریکنگ میرو میں کی جاتی ہے۔ ایک کام ہے - یہ ایک درمیانی مقصد ہے۔ اس سے یا تو چھوٹے اہداف یا کاموں کے گروپ جاتے ہیں۔ کام خود ان سے آتے ہیں۔ تمام کام اس بورڈ پر بنائے جاتے ہیں اور دیکھ بھال کرتے ہیں۔

یہ اسکیم فیڈ بیک بھی فراہم کرتی ہے، جو دن میں ایک بار اس وقت ہوتی ہے جب ہم ریلیوں میں ہم آہنگی کرتے ہیں۔ سب کے سامنے ایک مشترکہ منصوبہ ہونا، لیکن منظم اور مکمل طور پر کھلا، ہر کسی کو یہ جاننے کی اجازت دیتا ہے کہ کیا ہو رہا ہے اور ہم نے کتنی ترقی کی ہے۔

کاموں کے بصری وژن کے فوائد:

• وجہ ہر کام کسی نہ کسی عالمی مقصد کی طرف جاتا ہے۔ کاموں کو چھوٹے اہداف میں گروپ کیا جاتا ہے۔ انفراسٹرکچر ڈومین خود کافی تکنیکی ہے۔ یہ ہمیشہ فوری طور پر واضح نہیں ہوتا ہے کہ کیا خاص اثر پڑتا ہے، مثال کے طور پر، کسی دوسرے nginx میں منتقل ہونے پر رن ​​بک لکھنے سے کاروبار پر کیا اثر پڑتا ہے۔ ٹارگٹ کارڈ کے قریب ہونے سے یہ واضح ہوجاتا ہے۔
  
  Causality مسائل کی ایک اہم خاصیت ہے۔ یہ براہ راست اس سوال کا جواب دیتا ہے: "کیا میں صحیح کام کر رہا ہوں؟"
• متوازی ہم میں سے نو ہیں، اور ہر ایک کو ایک کام پر ڈالنا جسمانی طور پر ناممکن ہے۔ ایک علاقے سے کام ہمیشہ کافی نہیں ہوسکتے ہیں۔ ہم چھوٹے ورکنگ گروپس کے درمیان کام کو متوازی کرنے پر مجبور ہیں۔ ایک ہی وقت میں، گروپ کچھ وقت کے لئے اپنے کام پر بیٹھتے ہیں، انہیں کسی اور کی طرف سے مضبوط کیا جا سکتا ہے. بعض اوقات لوگ اس ورکنگ گروپ سے دور ہو جاتے ہیں۔ کوئی چھٹی پر جاتا ہے، کوئی DevOps conf کے لیے رپورٹ بناتا ہے، کوئی Habr پر مضمون لکھتا ہے۔ یہ جاننا کہ کون سے اہداف اور کام متوازی طور پر کیے جا سکتے ہیں بہت اہم ہو جاتا ہے۔

2. صبح کی میٹنگوں کے متبادل پیش کنندگان۔ اسٹینڈ اپ پر ہمیں یہ مسئلہ درپیش ہے - لوگ متوازی طور پر بہت سے کام کرتے ہیں۔ بعض اوقات کام ڈھیلے طریقے سے جڑے ہوتے ہیں اور کوئی سمجھ نہیں آتا کہ کون کیا کر رہا ہے۔ اور ٹیم کے دوسرے ممبر کی رائے بہت اہم ہے۔ یہ اضافی معلومات ہے جو مسئلے کو حل کرنے کا راستہ بدل سکتی ہے۔ بلاشبہ، عام طور پر آپ کے ساتھ کوئی ہے، لیکن مشورہ اور تجاویز ہمیشہ مفید ہیں.

اس صورتحال کو بہتر بنانے کے لیے، ہم نے "Changing the Leading Stand-up" تکنیک کا استعمال کیا۔ اب انہیں ایک خاص فہرست کے مطابق گھمایا جاتا ہے، اور اس کا اثر ہوتا ہے۔ جب آپ کی باری ہوتی ہے، تو آپ کو ایک اچھی اسکرم میٹنگ چلانے کے لیے غوطہ لگانے اور یہ سمجھنے پر مجبور کیا جاتا ہے کہ کیا ہو رہا ہے۔

3. اندرونی ڈیمو۔ جوڑی پروگرامنگ سے کسی مسئلے کو حل کرنے میں مدد، مسئلے کے درخت پر تصور اور صبح کے وقت اسکرم میٹنگز میں مدد اچھے ہیں، لیکن مثالی نہیں۔ ایک جوڑے کے طور پر، آپ صرف اپنے علم سے محدود ہیں۔ ٹاسک ٹری عالمی سطح پر یہ سمجھنے میں مدد کرتا ہے کہ کون کیا کر رہا ہے۔ اور صبح کی میٹنگ میں پیش کنندہ اور ساتھی آپ کے مسائل کی گہرائی میں نہیں جائیں گے۔ وہ یقینی طور پر کچھ یاد کر سکتے ہیں.

اس کا حل ایک دوسرے سے کیے گئے کام کا مظاہرہ کرنے اور پھر اس پر بحث کرنے میں پایا گیا۔ ہم ہفتے میں ایک بار ایک گھنٹے کے لیے ملتے ہیں اور پچھلے ہفتے کے دوران کیے گئے کاموں کے حل کی تفصیلات دکھاتے ہیں۔

مظاہرے کے دوران، کام کی تفصیلات کو ظاہر کرنا اور اس کے آپریشن کا مظاہرہ کرنا یقینی بنانا ضروری ہے۔

رپورٹ چیک لسٹ کا استعمال کرتے ہوئے کی جا سکتی ہے۔1. سیاق و سباق میں داخل ہوں۔ یہ کام کہاں سے آیا، اس کی کیا ضرورت تھی؟

2. اس سے پہلے مسئلہ کیسے حل ہوا؟ مثال کے طور پر، بڑے پیمانے پر ماؤس کلک کرنے کی ضرورت تھی، یا کچھ بھی کرنا ناممکن تھا۔

3. ہم اسے کیسے بہتر بناتے ہیں۔ مثال کے طور پر: "دیکھو، اب اسکرپٹوسک ہے، یہاں ریڈمی ہے۔"

4. دکھائیں کہ یہ کیسے کام کرتا ہے۔ کچھ صارف کے منظر نامے کو براہ راست نافذ کرنے کا مشورہ دیا جاتا ہے۔ مجھے X چاہیے، میں Y کرتا ہوں، مجھے Y (یا Z) نظر آتا ہے۔ مثال کے طور پر، میں NGINX تعینات کرتا ہوں، url کو دھواں دیتا ہوں، اور 200 OK حاصل کرتا ہوں۔ اگر عمل طویل ہے تو اسے پہلے سے تیار کریں تاکہ آپ اسے بعد میں دکھا سکیں۔ یہ مشورہ دیا جاتا ہے کہ ڈیمو سے ایک گھنٹہ پہلے اسے بہت زیادہ نہ توڑیں، اگر یہ نازک ہے۔

5. وضاحت کریں کہ مسئلہ کتنی کامیابی سے حل ہوا، کون سی مشکلات باقی ہیں، کیا مکمل نہیں ہوئی، مستقبل میں کیا بہتری ممکن ہے۔ مثال کے طور پر، اب CLI، پھر CI میں مکمل آٹومیشن ہوگی۔

ہر اسپیکر کے لیے یہ مشورہ دیا جاتا ہے کہ وہ اسے 5-10 منٹ تک رکھیں۔ اگر آپ کی تقریر واضح طور پر اہم ہے اور اس میں زیادہ وقت لگے گا، تو اسے پہلے سے sre-takeover چینل میں مربوط کریں۔

آمنے سامنے والے حصے کے بعد دھاگے میں ہمیشہ بحث ہوتی ہے۔ یہ وہ جگہ ہے جہاں ہمیں اپنے کاموں پر فیڈ بیک کی ضرورت ہوتی ہے۔

نتیجے کے طور پر، جو کچھ ہو رہا ہے اس کی افادیت کا تعین کرنے کے لیے ایک سروے کیا جاتا ہے۔ یہ تقریر کے جوہر اور کام کی اہمیت پر رائے ہے۔

طویل نتائج اور آگے کیا ہے۔

ایسا لگتا ہے کہ مضمون کا لہجہ کچھ مایوس کن ہے۔ یہ غلط ہے. فیڈ بیک کی دو نچلی سطحیں، یعنی ٹیسٹ اور جوڑی پروگرامنگ، کام۔ روایتی ترقی کے طور پر کامل نہیں ہے، لیکن اس سے ایک مثبت اثر ہے.

ٹیسٹ، اپنی موجودہ شکل میں، صرف جزوی کوڈ کوریج فراہم کرتے ہیں۔ بہت سے کنفیگریشن فنکشنز بغیر جانچ کے ختم ہو جاتے ہیں۔ کوڈ لکھتے وقت اصل کام پر ان کا اثر کم ہوتا ہے۔ تاہم، انضمام کے ٹیسٹوں کا اثر ہے، اور وہ آپ کو بے خوفی سے ری فیکٹرنگ انجام دینے کی اجازت دیتے ہیں۔ یہ بہت بڑی کامیابی ہے۔ نیز، اعلیٰ سطحی زبانوں میں ترقی کی طرف توجہ مرکوز کرنے کے ساتھ (ہمارے پاس python، go ہے)، مسئلہ دور ہو جاتا ہے۔ اور آپ کو "گلو" کے لیے زیادہ چیک کی ضرورت نہیں ہے؛ ایک عام انضمام کی جانچ کافی ہے۔

جوڑوں میں کام کرنا مخصوص لوگوں پر زیادہ انحصار کرتا ہے۔ ٹاسک فیکٹر اور ہماری نرم مہارتیں ہیں۔ کچھ لوگوں کے ساتھ یہ بہت اچھا کام کرتا ہے، دوسروں کے ساتھ یہ بدتر کام کرتا ہے۔ اس سے یقیناً فائدے ہیں۔ یہ واضح ہے کہ یہاں تک کہ اگر جوڑے کے کام کے اصولوں کا کافی مشاہدہ نہیں کیا جاتا ہے، کاموں کو ایک ساتھ انجام دینے کی حقیقت کا نتیجہ کے معیار پر مثبت اثر پڑتا ہے۔ ذاتی طور پر، مجھے جوڑوں میں کام کرنا آسان اور زیادہ خوشگوار لگتا ہے۔

OS کو متاثر کرنے کے اعلیٰ درجے کے طریقے - کاموں کی منصوبہ بندی اور ان کے ساتھ کام کرنے سے قطعی طور پر اثرات مرتب ہوتے ہیں: اعلیٰ معیار کے علم کا تبادلہ اور بہتر ترقی کا معیار۔

ایک لائن میں مختصر نتیجہ

• HR پریکٹیشنرز IaC میں کام کرتے ہیں، لیکن کم کارکردگی کے ساتھ۔
• جو کام کرتا ہے اسے مضبوط کریں۔
• اپنے معاوضے کے طریقہ کار اور طریقوں کے ساتھ آئیں۔

ماخذ: www.habr.com