۲۹ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

چگونه چنگال گیت مایکروسافت برای مونورپوهای عظیم مقیاس می‌شود

مایکروسافت سیستم فایل مجازی Git و بهینه‌سازی‌های Scalar خود را در قالبی از Git قرار داده است که برای پشتیبانی از مخازن عظیم و تیم‌های توزیع‌شده بزرگ طراحی شده است.

مایکروسافت سیستم فایل مجازی Git و بهینه‌سازی‌های Scalar خود را در قالبی از Git قرار داده است که برای پشتیبانی از مخازن عظیم و تیم‌های توزیع‌شده بزرگ طراحی شده است.

ساخت برنامه‌های کاربردی در مقیاس در مقایسه با ساختن یک سیستم عامل مانند Windows چیزی نیست، به خصوص وقتی صحبت از کنترل کد منبع می‌شود. چگونه مخزن (یا مخازن) چنین غول نرم‌افزاری را با هزاران توسعه‌دهنده و آزمایش‌کننده و با یک خط لوله ساخت پیچیده که به طور مداوم کدهای تازه را ارائه می‌کند، مدیریت می‌کنید؟

تاریخچه مایکروسافت با سیستم‌های کنترل منبع داخلی پیچیده است. ممکن است فکر کنید که از Visual SourceSafe که اکنون متوقف شده است استفاده می‌کند، اما برای سیستم‌های فایل محلی و پروژه‌های کوچک‌تر مناسب‌تر است. در عوض، مایکروسافت در طول سال‌ها از ابزارهای مختلف زیادی استفاده کرد، در ابتدا یک فورک داخلی از سیستم کنترل بازبینی یونیکس آشنا، قبل از استانداردسازی در انبار منبع پرفورس.

Git در ردموند به دیوار برخورد می کند

در همین حال، برخی از بخش‌های کسب‌وکار از سرور بنیاد تیم ویژوال استودیو استفاده می‌کردند، قبل از اینکه به استفاده از Git به‌عنوان پایه یک پلتفرم مهندسی مشترک برای کل شرکت تغییر کنند. سرور بنیاد تیم از Git پشتیبانی می‌کند و ترکیبی از یک ابزار بصری و خط فرمان از موارد استفاده مختلف در سراسر مایکروسافت پشتیبانی می‌کند.

این تغییر بسیار منطقی بود، زیرا Git برای مقابله با پیچیدگی‌های مدیریت یک پایگاه کد عظیم با تعداد زیادی از توسعه‌دهندگان توزیع‌شده در سطح جهانی طراحی شده بود. تعجب آور نیست که شباهت های زیادی بین نحوه ساخت ویندوز و لینوکس وجود دارد و Git دارای ویژگی هایی است که برای هر دو به خوبی کار می کند.

با این حال، یک مشکل بزرگ برای یک مخزن عظیم مانند ویندوز وجود دارد. با وجود پیچیدگی و قطعات متحرک بسیار، ابزارهایی مانند ویندوز و آفیس در مخازن تکی توسعه یافته اند، مونورپوهای عظیمی که حجم زیادی از فضای ذخیره سازی را اشغال می کنند—حدود ۳۰۰ گیگابایت و ۳.۵ میلیون فایل فقط برای ویندوز. مشکل از نحوه برخورد Git با مخازن ناشی می‌شود: تکرار آن‌ها و هر تغییری در هر کپی. برای Windows، اندازه مخزن به سرعت رایانه‌های شخصی توسعه‌دهنده را تحت تأثیر قرار می‌دهد و به سرعت شبکه توسعه‌دهنده را مسدود می‌کند.

GVFS – سیستم فایل مجازی Git را وارد کنید

اگر همه توسعه دهندگان شما روی یک شبکه ارتباطی فوق سریع و شبکه ذخیره سازی پرسرعت کار کنند، ممکن است یک مخزن انبوه قابل اجرا باشد، اما مطمئناً زمانی که شما یک تیم توزیع شده در سطح جهانی هستید که ادارات و کارمندان خانگی را با هم ترکیب می کنید، چنین نیست. مایکروسافت نیاز داشت راهی برای استفاده از مخزن Git به عنوان یک سیستم فایل مجازی ایجاد کند، به جای کپی کردن کل مخزن از طریق یک شبکه ناشناخته، فایل‌های محلی را فقط در صورت نیاز ایجاد کند.

نحوه انتقال کد ASP.NET Core 5 به ASP.NET Core 6

ابزار حاصل قابلیت‌های Git را با نیازهای توسعه مایکروسافت متعادل می‌کند. این به هیچ وجه Git را تغییر نمی دهد، اگرچه قابلیت های آفلاین Git را قربانی می کند. این تصمیم خوبی بود، زمانی که اکثریت قریب به اتفاق توسعه دهندگان مایکروسافت در ردموند کار می کردند.

Git Virtual File System، GVFS، که به عنوان یک درایور سیستم فایل ویندوز ارائه می شود، برای نظارت بر دایرکتوری کاری و پوشه .git شما طراحی شده است، و فقط آنچه را که برای کاری که انجام می دهید به پایین می کشد. انجام و بررسی فقط فایل های مورد نیاز شما. همچنان می‌توانید محتویات مخزن را ببینید، گویی که یک پسوند سیستم فایل رایانه شخصی شما است، دقیقاً مانند روشی که فایل‌های OneDrive فقط زمانی که به صراحت آنها را انتخاب می‌کنید دانلود می‌شوند.

هنگامی که مایکروسافت شروع به استفاده از GVFS کرد، متوجه موارد لبه‌های مختلفی شد که نشان می‌داد Git کارهای غیرضروری روی فایل‌ها انجام می‌دهد، بنابراین مهندسان آن به ارائه راه‌حل‌هایی برای این مشکلات در پروژه Git پرداختند. این اصلاحات برای بهبود عملکرد Git برای مخازن بزرگ طراحی شده‌اند و به مایکروسافت اجازه می‌دهند تا به یک monorepo داخلی عظیم برای کنترل منبع تغییر مکان دهد.

مقیاس‌سازی Git با Scalar

موضوع به همین جا ختم نشد. اکنون ما در حال سومین نسخه عمومی از کار مایکروسافت در مقیاس سازی Git هستیم، این بار به عنوان بخشی از فورک Git خود شرکت—یک توزیع Git با هدف خاص که برای پشتیبانی از monorepos طراحی شده است.

نسخه کنونی بر اساس کاری است که در سال ۲۰۲۰ با نام Scalar منتشر شد. Scalar برنامه‌ای است که هر مخزن Git را بدون توجه به جایی که میزبانی می‌کند سرعت می‌بخشد. این نیاز به پیاده‌سازی Git سفارشی مایکروسافت دارد، اگرچه هدف درازمدت داشتن بخش زیادی از کدهای لازم در سمت سرور در نسخه رسمی Git است. Scalar ابزاری است که دارای نظر است ، با تمرکز بر بهبود عملکرد Git.

Scalar یک برنامه خط فرمان دات نت است که در پس زمینه اجرا می شود و مخازن ثبت شده را مدیریت می کند. می‌توانید از آن در کنار GVFS یا به‌عنوان یک شتاب‌دهنده مستقل، استفاده از ویژگی های اخیر Git. مایکروسافت از Scalar با GVFS به صورت داخلی استفاده می کند و سرورهای کش را بین مخازن خود و رایانه های شخصی توسعه دهنده قرار می دهد. GVFS برای Scalar ضروری نیست، اما مطمئنا کمک می کند.

کد منبع جاوا می تواند به رمزگذاری UTF-8 تغییر کند

پس از نصب و اجرا، Scalar می توان در کنار یک کلاینت سنتی Git استفاده کرد، مخازن را با استفاده از یک کش محلی یا یک سرور کش راه دور شبیه سازی کرد و مخزن محلی خود را مدیریت کرد. همانطور که مایکروسافت آن را در وبلاگ اعلامیه قرار داده است، پیش‌فرض انجام یک تسویه‌حساب پراکنده است که به Scalar اجازه می‌دهد تا این کار را انجام دهد. post، “روی فایل هایی که مهم هستند تمرکز کنید.”

Scalar کلون های محلی را تنظیم می کند، سپس توسعه دهندگان می توانند از Git به طور معمول استفاده کنند. این کار با ارائه یک رویکرد لایه‌بندی به مدیریت فایل انجام می‌شود: یک فهرست سطح بالا از تمام فایل‌های موجود در یک مخزن (که می‌تواند میلیون‌ها باشد)، یک فهرست کاری پراکنده از فایل‌هایی که ممکن است برای کاری که روی آن کار می‌کنید نیاز داشته باشید، و در نهایت مجموعه ای از فایل هایی که تغییر داده اید.

مدیریت Git در پس‌زمینه

بسیاری از کارهای Scalar در پس‌زمینه اتفاق می‌افتد، به طوری که ویژگی‌هایی مانند جمع‌آوری زباله Git، هنگام بازنویسی و به‌روزرسانی فایل‌ها، تعهدات را مسدود نمی‌کند. Scalar این کار را با تنظیم تنظیمات کلیدی Git برای جلوگیری از عملیات پیش زمینه انجام می دهد. شما همچنان از Git همانطور که معمولا استفاده می کنید استفاده می کنید، اما عملیات تعمیر و نگهداری مخزن به پردازشگر فشرده و شبکه فشرده به فرآیند Scalar پس زمینه واگذار می شود، جایی که آنها می توانند با اولویت پایین تری بدون تأثیر بر کاری که انجام می دهید، کار کنند.

با مجموعه‌ای از نمایه‌ها که دایرکتوری کاری شما را مدیریت می‌کنند، Scalar از GVFS برای شبیه‌سازی مخازن تنها با استفاده از فایل‌های ریشه استفاده می‌کند و در صورت نیاز فایل‌های اضافی را دانلود می‌کند. فایل‌ها در یک فهرست اسکالر، با دایرکتوری کار در یک زیر شاخه src ذخیره می‌شوند. این ساختار فایل به شما امکان می‌دهد ساخت‌ها و شاخه‌ها را به صورت محلی مدیریت کنید.

کار مایکروسافت روی Scalar باعث شده است که توزیع Git خود را با Scalar CLI ارسال کند. می‌توانید نسخه‌های Git مایکروسافت را برای ویندوز، macOS و لینوکس (به‌عنوان یک بسته Debian، با سایر توزیع‌ها که نیاز به کامپایل از منبع دارند) پیدا کنید. یک نسخه ویندوز قابل حمل نیز وجود دارد. مایکروسافت اکنون ویژگی‌های خود را «ویژگی‌های پیشرفته Git» می‌نامد، رویکردی که عملکردی را که انجام می‌دهد برای اثبات اینکه چگونه Git می‌تواند در مقیاس عظیم کار کند، منطقی می‌سازد.

Angular 14 برای اضافه کردن فرم‌های واکنشی کاملاً تایپ‌شده

اگر می‌خواهید آن را امتحان کنید، ابتدا باید سرور Git خود را راه‌اندازی کنید که آماده میزبانی از مخازن خود باشد. می‌توانید از ابزارهای آشنای Git برای اجرا، ذخیره کد و مصنوعات، قبل از تغییر به Scalar و GVFS استفاده کنید. اگرچه Scalar با سایر پیاده‌سازی‌های Git کار می‌کند، اما باید به دنبال یکی از گزینه‌های شبیه‌سازی جزئی باشید که جایگزین رسمی GVFS است.

نسخه فعلی Microsoft Git شامل پیشرفت‌هایی در سمت سرور است تا اطمینان حاصل شود که monorepoهای عظیم مانند مخازن کوچک‌تر عمل می‌کنند، بدون نیاز به ابزار اضافی برای ساخت بیلدها از چندین منبع.

چرا اسکالر؟

می‌توانید Scalar را به‌عنوان زمینه‌ای برای اثبات مسیری که مایکروسافت می‌خواهد Git برود، در نظر بگیرید. Forking Git به شرکت اجازه می دهد تا این ویژگی ها را قبل از ارائه مجدد به جامعه گسترده تر Git امتحان کند. این یک رویکرد معقول است که کد را در دسترس جامعه قرار می‌دهد تا قبل از اینکه کسی درخواستی ارائه دهد، آن را ارزیابی کند.

با توجه به پروژه‌ها، انجمن‌ها و شرکت‌های زیادی که به Git متکی هستند، بسیار مهم است که تغییرات برای میلیون‌ها کاربر آن و میلیاردها خط کد میزبانی شده در مخازن در سرتاسر جهان، مشکلی ایجاد نکند. همه به ابزارهای Scalar و GVFS نیاز ندارند، اما مایکروسافت مطمئناً به این ابزار نیاز دارد و پروژه‌های دیگر ممکن است به ویژگی‌های مشابهی نیاز داشته باشند.

پروژه‌های بزرگ استانداردهای باز مانند جاوا اسکریپت و HTML با نشان دادن این نکته کار می‌کنند که پلتفرم‌های اصلی پایین‌دستی از ویژگی‌های جدید برنامه‌ریزی‌شده پروژه قبل از اینکه به مشخصات متعهد باشند، پشتیبانی می‌کنند و آنها را در پشت پرچم‌های ویژگی برای آزمایش پنهان می‌کنند. رویکرد مایکروسافت به Git مشابه است.

این به مایکروسافت این امکان را می‌دهد تا از مزایای این ویژگی‌های جدید در فورک خود بهره ببرند، در حالی که بقیه ما به استفاده از نصب‌های Git خود یا سرویس‌های Git مبتنی بر ابر، بدون نگرانی در مورد Scalar و نحوه عملکرد آن تا زمانی که بخشی از پلت فرم سپس انتقال به آسانی اجرای به‌روزرسانی روی سرور است.