اوبر پلتفرم GitFarm را عرضه کرده؛ سرویسی متمرکز که اجرای دستورات Git را بر عهده می‌گیرد و مصرف منابع کلاینت‌ها در مونو‌ریپوهای بزرگ را تا بیش از 80% کاهش می‌دهد، ضمن اینکه زمان تحویل یک چک‌اوت آماده را به کمتر از 1 ثانیه رسانده است.

علت نیاز به GitFarm

سامانه‌های اتوماسیون اوبر روزانه میلیون‌ها فراخوان Git را روی مونو‌ریپوهایی که از Go، Java، Python، وب، Android و iOS پشتیبانی می‌کنند اجرا می‌کنند. پیش از GitFarm، هر سرویس برای خواندن فایل‌ها، اعتبارسنجی تغییرات یا محاسبه merge base مجبور به نگه‌داشتن یک چک‌اوت کامل محلی بود؛ عملیاتی که برای مونو‌ریپوی Go اوبر تقریباً 15 دقیقه طول می‌کشید و نیازمند حدود 6 هسته CPU، 32 گیگابایت حافظه و بیش از 40 گیگابایت دیسک بود.

معماری و نحوه عملکرد

GitFarm به‌عنوان یک «کلاینت متمرکز Git» عمل می‌کند؛ یعنی عملیات استاندارد Git را به نیابت از سرویس‌ها اجرا می‌کند و برای ارائه دستورات از API پرسرعت gRPC استفاده می‌کند. درخواست‌ها ابتدا از طریق یک Gateway احراز هویت و مجوزدهی شده و سپس به خوشه‌های بک‌اند هدایت می‌شوند. دستورات در سندباکس‌های ایزوله و کوتاه‌مدت اجرا می‌شوند تا امنیت و سازگاری حفظ شود.

بک‌اندها cloneهای bare مخازن را نگهداری و با به‌روزرسانی‌های مبتنی بر push و fetchهای دوره‌ای همگام می‌کنند. علاوه بر این، مجموعه‌هایی از چک‌اوت‌های از پیش‌گرم‌شده و کانتینرهای سندباکس مدیریت می‌شوند تا هنگام دریافت درخواست، به‌جای ساختن کلون و محیط اجرا از صفر، یک چک‌اوت آماده سوار شود. این مکانیزم «پولینگ» سربار آماده‌سازی را به زیر 1 ثانیه رسانده است.

نمودار معماری GitFarm اوبر با اجزایی مثل Gateway و بک‌اند

پشتیبانی از گردش‌کارهای پیچیده

GitFarm با استفاده از جلسات استریم دوطرفه gRPC از گردش‌کارهای چنددستوری پشتیبانی می‌کند. این امکان اجازه می‌دهد مجموعه‌ای از دستورات پشت‌سرهم روی همان چک‌اوت اجرا شوند — مثلاً گرفتن یک شاخه، محاسبه merge base و push یک مرجع مشتق‌شده — بدون نیاز به مقداردهی مجدد وضعیت مخزن. کلاینت‌ها در صورت ضرورت می‌توانند صریحاً git fetch اجرا کنند یا از وضعیت همگام‌شده بک‌اند بهره ببرند که برای بارهای کاری با تحمل کهنگی محدود مناسب است.

نتایج میدانی در اوبر

  • یک سرویس مالکیت کد پس از مهاجرت به GitFarm، چک‌اوت‌های محلی را روی 6 میزبان حذف کرد؛ مصرف CPU از بیش از 70 هسته به 16 هسته و حافظه از حدود 400 گیگابایت به 32 گیگابایت کاهش یافت. زمان راه‌اندازی از 15–20 دقیقه به کمتر از 1 دقیقه رسید.
  • یک سرویس ممیزی که 10,000 تا 20,000 رویداد در ساعت را روی حدود 9,000 مخزن پردازش می‌کرد، با حذف سربار زمان‌بندی و آماده‌سازی فضاهای کاری، میانگین تاخیر را از حدود 110–160 ثانیه (با Buildkite) به 20–30 ثانیه کاهش داد. مراجع مرتبط: Buildkite.

دستاوردهای فنی کلیدی

نکات فنی مؤثر در کارایی GitFarm شامل موارد زیر است:

  • اجرای دستورات Git داخل سندباکس‌های ایزوله و موقتی برای افزایش امنیت و سازگاری محیط اجرا.
  • نگهداری cloneهای bare و به‌روزرسانی آن‌ها از طریق push/fetch برای کاهش زمان همگام‌سازی بین کلاینت و مخزن مرکزی.
  • پولینگ چک‌اوت‌ها و کانتینرها برای تحویل سریع یک چک‌اوت آماده (<1 ثانیه).
  • پشتیبانی از جریان‌های چنددستوری با استریم gRPC برای جلوگیری از مقداردهی مجدد وضعیت مخزن بین دستورات.

پیامدها برای توسعه و عوامل برنامه‌نویسی

معماری GitFarm ظرفیت زیرساخت را برای بارهای کاری نوظهور افزایش می‌دهد؛ از جمله عوامل برنامه‌نویسی (coding agents) که مرتبا شاخه‌سازی، diff، آزمایش و اعتبارسنجی تغییرات را انجام می‌دهند و می‌توانند بار زیادی روی سرویس‌های Git ایجاد کنند. آشیش ورما در لینکداین به این پتانسیل اشاره کرده است.

نقشه راه و قابلیت‌های آتی

GitFarm از اوایل 2025 در تولید به‌کار گرفته شده است. برنامه‌های آتی شامل استریم خروجی Git، پشتیبانی رسمی از چک‌اوت‌های پراکنده (sparse checkouts)، ورک‌اسپیس‌های bare، نشست‌های طولانی‌تر، آینه‌سازی مخازن و یکپارچه‌سازی با SubmitQueue است.

مطالعه بیشتر

برای مرجع و مرور مبانی Git می‌توانید به صفحه Git در ویکی‌پدیا مراجعه کنید.

جمع‌بندی

GitFarm نمونه‌ای از بهینه‌سازی عملیاتی است که باعث کاهش محسوس هزینه‌های زیرساختی و افزایش پاسخگویی سیستم‌ها می‌شود؛ به‌خصوص در محیط‌های مونو‌ریپوی بزرگ و در مواجهه با بارهای کاری مدرن مانند CI/CD و عوامل هوشمند. چالش پیش رو، سازگار کردن این رویکرد با معماری‌ها و نیازهای دیگر شرکت‌ها است تا سرعت توسعه و بهره‌وری تیم‌ها افزایش یابد.