مواد پر جائیں

ایجنٹس متوازی چلائیں

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

تنہائی کی اکائی ایجنٹ نہیں، اسپیس ہے

سیکشن کا عنوان “تنہائی کی اکائی ایجنٹ نہیں، اسپیس ہے”

جب کسی اسپیس میں کام شروع ہوتا ہے تو Control Center اُس اسپیس کے اپنے روٹ کے نیچے ہر رجسٹر شدہ ریپو کے لیے ایک copy-on-write چیک آؤٹ تیار کرتا ہے، ایسی برانچ پر جو ورک اسپیس کے برانچ ٹیمپلیٹ سے اخذ ہوتی ہے۔ پھر اسپیس کا ہر ایجنٹ اپنی الگ اوورلے ورکنگ ڈائریکٹری پاتا ہے — مگر اوورلے اُس اسپیس کی repos/ ڈائریکٹری شیئر کرتے ہیں۔

چنانچہ:

  • مختلف اسپیسز کے دو ایجنٹس مختلف چیک آؤٹس میں، مختلف برانچوں پر کام کرتے ہیں۔ یہ اصل تنہائی ہے۔
  • ایک ہی اسپیس کے دو ایجنٹس ایک ہی چیک آؤٹ میں، ایک ہی برانچ پر کام کرتے ہیں۔ اُن کے اوورلے پاتھ مختلف ہوتے ہیں، چنانچہ ڈسپیچ پاتھ لاک (جو رنز کو صرف اُس وقت سلسلے وار کرتا ہے جب وہ بالکل ایک ہی ورکنگ ڈائریکٹری طلب کریں) بھی اُنہیں سلسلے وار نہیں کرتا۔ وہ ایک ہی وقت میں ایک ہی فائلیں لکھ سکتے ہیں۔

اس سے یہ قاعدہ نکلتا ہے: ہر متوازی کام کے لیے ایک اسپیس۔

  1. ایجنٹ A کے ساتھ ایک اسپیس کھولیں اور اسے ایک کام بھیجیں۔
  2. ایجنٹ B کے ساتھ دوسری اسپیس کھولیں اور اسے کوئی مختلف کام بھیجیں۔
  3. دونوں فوراً ڈسپیچ ہو جاتے ہیں، ہر ایک اپنی اسپیس کے چیک آؤٹ میں، اپنی برانچ پر۔

جب بھی ایجنٹس فائلیں ترمیم کرنے والے ہوں، یہی ترکیب استعمال کریں۔

ایک ہی اسپیس میں مل کر کام کریں — کئی ذکر

سیکشن کا عنوان “ایک ہی اسپیس میں مل کر کام کریں — کئی ذکر”

ایک ہی اسپیس میں ایک سے زیادہ ایجنٹس کا @-ذکر کریں:

@alice refactor the auth module. @bob review what alice lands.

دونوں ایجنٹس متوازی ڈسپیچ ہوتے ہیں اور بھیجنے والے کے ٹیگ کے ساتھ اسی اسپیس میں اسٹریم کرتے ہیں۔ چونکہ وہ اسپیس کا چیک آؤٹ شیئر کرتے ہیں، اسے تعاون کے لیے استعمال کریں — ایک لکھے، دوسرا پڑھے، یا دو ایجنٹس ایک ہی درخت پر غور کریں — نہ کہ دو آزاد ترمیموں کے لیے۔

بلٹ اِن pr_review ٹیمپلیٹ فین آؤٹ کی بھیجی گئی مثال ہے: کئی ریویوور نوڈ ایک ہی ٹرگر سے بیک وقت چلتے ہیں اور ایک Consolidate (join) نوڈ اُن کے نتائج کو ایک رپورٹ میں سمیٹ دیتا ہے۔ اسے پائپ لائنز اسکرین سے چلائیں اور ہر ریویوور متوازی ڈسپیچ ہوتا ہے۔

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

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

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

دونوں سطحیں فعال ورک اسپیس تک محدود ہیں۔

الگ الگ اسپیسز میں ہر اسپیس اپنی برانچ پر ہوتی ہے، چنانچہ جب آپ دوسرا pull request مرج کرتے ہیں تو ٹکراؤ ایک عام Git merge conflict کی صورت میں سامنے آتا ہے۔ اسے اُسی طرح حل کریں جیسے آپ کوئی بھی merge conflict حل کرتے ہیں۔

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

کسی بھی صورت میں ٹکراؤ کم کرنے کے لیے:

  • ہر ایجنٹ کو ایک الگ دائرہ دیں — الگ فائلیں، الگ ماڈیول۔
  • ڈسپیچ کرنے سے پہلے کوڈ گراف سے دیکھیں کہ کوئی تبدیلی کس چیز کو چھوتی ہے۔ دیکھیں کوڈ گراف سے کوڈ تلاش کریں۔
  • ہر ایجنٹ کا pull request فوری طور پر ریویو اور مرج کریں۔

ہر چلتے ایجنٹ کی لاگت یہ ہے:

  • ایک اسپیس چیک آؤٹ — جب تک copy-on-write دستیاب ہو، ڈسک پر نہ ہونے کے برابر؛ Windows پر ایک git worktree۔ جو فائل سسٹم reflink نہ کر سکے وہ کاپی کرنے کے بجائے تیاری ناکام کر دیتا ہے۔
  • سرور ہوسٹ پر ایک پراسیس
  • ماڈل ٹوکن، جو فی ایجنٹ جمع ہوتے رہتے ہیں

لاگتیں آبزرویبلٹی → بصیرتیں میں نظر آتی ہیں۔ یاد رکھیں کہ ایک عام انٹرایکٹو ٹرن پر خرچ کی کوئی حد نہیں ہوتی؛ اُن دو کمانڈز کے لیے جو حد رکھتی ہیں، دیکھیں اخراجات منظم کریں۔