رفتن به محتوا

اجرای موازی عامل‌ها

این راهنما نشان می‌دهد چگونه چند عامل را هم‌زمان اجرا کنید بدون آنکه نوشته‌هایشان یکدیگر را بازنویسی کند.

واحد ایزوله‌سازی فضا است، نه عامل

بخش با عنوان “واحد ایزوله‌سازی فضا است، نه عامل”

وقتی کار در یک فضا شروع می‌شود، Control Center برای هر مخزن ثبت‌شده زیر ریشهٔ خودِ آن فضا یک checkout کپی‌هنگام‌نوشتن تأمین می‌کند، روی شاخه‌ای برگرفته از قالب شاخهٔ فضای کاری. سپس هر عامل در آن فضا دایرکتوری کاری overlay خودش را می‌گیرد — اما overlayها پوشهٔ repos/ آن فضا را به اشتراک می‌گذارند.

پس:

  • دو عامل در فضاهای متفاوت در checkoutهای متفاوت و روی شاخه‌های متفاوت کار می‌کنند. این ایزوله‌سازی واقعی است.
  • دو عامل در فضای یکسان در همان checkout و روی همان شاخه کار می‌کنند. مسیرهای overlayشان متفاوت است، پس قفل مسیر اعزام (که اجراها را تنها وقتی پشت‌سرهم می‌کند که دایرکتوری کاری یکسانی درخواست کنند) آن‌ها را هم پشت‌سرهم نمی‌کند. می‌توانند هم‌زمان همان فایل‌ها را بنویسند.

قاعده‌ای که از این نتیجه می‌آید: برای هر کار موازی، یک فضا.

اجرای موازی کارها — فضاهای جداگانه

بخش با عنوان “اجرای موازی کارها — فضاهای جداگانه”
  1. یک فضا با عامل A باز کنید و کاری به آن بفرستید.
  2. فضای دومی با عامل B باز کنید و کار دیگری به آن بفرستید.
  3. هر دو بی‌درنگ اعزام می‌شوند، هرکدام در checkout فضای خودش و روی شاخهٔ خودش.

هر وقت قرار باشد عامل‌ها فایل‌ها را ویرایش کنند، دستور کار همین است.

در یک فضای واحد، بیش از یک عامل را @-منشن کنید:

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

هر دو عامل موازی اعزام می‌شوند و با برچسب فرستنده در همان فضا جریان می‌یابند. چون checkout فضا را مشترک دارند، این را برای همکاری به کار ببرید — یکی می‌نویسد، یکی می‌خواند، یا دو عامل روی همان درخت استدلال می‌کنند — نه برای دو ویرایش مستقل.

قالب داخلی pr_review نمونهٔ همراه یک گسترش است: چند گره بازبین هم‌زمان از یک تریگر بیرون می‌آیند و یک گره Consolidate (join) یافته‌هایشان را در یک گزارش جمع می‌کند. آن را از صفحهٔ پایپ‌لاین‌ها اجرا کنید تا هر بازبین موازی اعزام شود.

ویرایشگر پایپ‌لاین نگهبان پایانی را پنهان می‌کند و وقتی گامی را اضافه یا متصل می‌کنید، آن را طوری دوباره سیم‌کشی می‌کند که منتظر هر مقصد زنده بماند؛ پس شاخه‌هایی که خودتان می‌کشید واقعاً اجرا می‌شوند.

مشاهده‌پذیری → زنده (پانویس نوار کنار → مشاهده‌پذیری، سپس زبانهٔ زنده) فهرست عامل‌های این فضای کاری را نشان می‌دهد و هر ثانیه به‌روز می‌شود: وضعیت (در حال اجرا / بیکار / پارک‌شده / سقط‌شده)، اینکه هرکدام چه می‌کند، توکن‌ها و هزینهٔ آخرین اجرایش و یک کنترل کشتن برای فرایند در حال اجرا. با انتخاب یک سطر، کشوی رونوشت زنده باز می‌شود.

تنظیمات → فضای کاری → عامل‌ها همان فهرست را با واژگانی متفاوت و توجه‌محور نشان می‌دهد که از تاریخچهٔ اجرای هر عامل مشتق شده است — در حال اجرا، مسدود، ناموفق، بیکار، هرگز اجرا نشده — و طوری مرتب شده که هر چیزی که به توجه نیاز دارد به بالا بیاید. زبانهٔ گزارش‌ها در هر عامل تاریخچهٔ اجرای خودش را نگه می‌دارد.

هر دو سطح به فضای کاری فعال محدودند.

در میان فضاها، هر فضا روی شاخهٔ خودش است، پس برخورد هنگام ادغام pull request دوم به‌شکل یک تعارض ادغام معمولی Git خودش را نشان می‌دهد. آن را همان‌طور حل کنید که هر تعارض ادغام دیگری را حل می‌کنید.

درون یک فضا نه مرز شاخه‌ای هست و نه قفلی: عامل‌ها همان فایل‌ها را زنده می‌نویسند و آن‌که عقب می‌ماند به‌سادگی بازنویسی می‌شود. اگر دیدید می‌خواهید دو عامل در یک فضا ویرایش کنند، کار را به‌جای آن به دو فضا تقسیم کنید.

برای کاهش برخوردها در هر دو حالت:

  • به هر عامل حوزهٔ متمایزی بدهید — فایل‌های متفاوت، ماژول‌های متفاوت.
  • پیش از اعزام، با گراف کد بررسی کنید که یک تغییر چه چیزهایی را دست می‌زند. جستجوی کد با گراف کد را ببینید.
  • pull request هر عامل را بی‌درنگ بازبینی و ادغام کنید.

هر عامل در حال اجرا این هزینه‌ها را دارد:

  • یک checkout فضا — تا وقتی کپی‌هنگام‌نوشتن در دسترس است روی دیسک ناچیز؛ روی Windows یک git worktree. فایل‌سیستمی که نتواند reflink کند، به‌جای کپی‌کردن، تأمین را شکست می‌دهد.
  • یک فرایند روی میزبان سرور
  • توکن‌های مدل، که به‌ازای هر عامل انباشته می‌شوند

هزینه‌ها در مشاهده‌پذیری → بینش‌ها می‌نشینند. توجه کنید که یک نوبت تعاملی معمولی سقف هزینه ندارد؛ برای آن دو فرمانی که سقف دارند مدیریت هزینه‌ها را ببینید.