درباره‌ی مخزن کُد گوگل

مخزن کدهای داخلی گوگل، git نیست بلکه یک سیستمی داخلیه. این مقاله به معرفی اون پرداخته که به طور خلاصه: همه در یک مخزن (repo) هستند با ۲ میلیارد خط کد و روزانه ۴۵ هزار commit. در ورای آب و تاب ژورنالیستی مقاله، شاید مرور چند نکته‌ی کاربردی مفید باشه:

• اصلی‌ترین نکته: ما که برای سرورهای مختلف در نمایش تبلیغات به طور روزانه یا هفتگی binary جدید می‌سازیم و منتشر/release می‌کنیم، از مثلا تیم protocol buffer، یک package در نسخه‌ی فلان تحویل نمی‌گیریم، بلکه همون کُدی که به طور زنده در مخزن مشترک هست، به binaryمون link می‌شه. هر تکه کدی که به مخزن commit می‌شه، از همون لحظه به سرتاسر گوگل منتشر/release شده. این نکته‌ی مهمیه. سود و زیان‌های این مدل یکپارچه در مقایسه با مدلی که تیم‌ها به هم package تحویل می‌دن (و مدیریت سازگاری/compatibility و الخ) قابل برشمردنه ولی به طور خلاصه و به تجربه‌ی شخصی در کار با هر دو مدل، مدل یکپارچه مانند گوگل، با اختلاف مدل بهتریه. بجویید trunk based development.
• در این مخزن، هم کدهای ++C هست، هم python، هم js، هم همه چیز. هر binary، مثلا اونی که در سرور الف در سرویس search می‌نشینه، فقط بخشی رو استفاده می‌کنه. همچنان گراف وابستگی‌ها بزرگه و باید مثلا چند صدهزار فایل compile بشن، که توزیع‌شده انجام می‌شه - روی همون ماشین‌هایی که دارن سرویس maps و gmail رو ارائه می‌دن یعنی یک زیرساخت مشترک برای انواع کارها در اولویت‌های مختلف. توسط سیستمی به نام Borg مدیریت می‌شه که نسخه‌ی بیرونیش Kubernetes است. سرویس عریض و طویلی هم برای build توزیع‌شده داریم، که اون هم به عنوان یک سرویس ابری به بیرون عرضه شده.
• سیستم مدیریت مخزن (معادل git)، یک سرویس داخلیه به نام Piper که در مقاله هم اشاره شده و ساده‌تر از git است. git یه کم الکی پیچیده‌ست و بدتر از اون اینه که با یک سوتی می‌تونید به خودتون خیلی ضرر بزنید. با Piper خیلی کمتر. مثلا snapshotها برای همیشه ذخیره می‌شن. مخزنی با دومیلیارد خط کد رو نمی‌شه روی کامپیوترتون بیارید. قدیم‌ترها به Piper می‌گفتیم فلان زیرشاخه‌ها رو بیار و بقیه (برای وابستگی‌های build) از مخزن اصلی بیان. الان سال‌هاست که منسوخ شده و همه چیز از جمله همون کپیِ محلیِ فایلی که من ویرایش می‌کنم دیگه روی کامپیوتر من نیست.
• سیستم Piper خیلی تنگاتنگ به سیستم بازبینی کد (code review) ما که نسخه‌ی open sourceاش Gerrit است وصله. شما هیچ‌وقت نمی‌تونید یک تکه کد رو به مخزن commit کنید تا وقتی یک بازبین (reviewer) کد شما رو نخونده و تایید نکرده باشه. درباره‌ی چرخه‌ی توسعه می‌شه بعدا مفصل‌تر حرف زد.
• شاخه نداریم (به جز یک حالت خاص خودکار برای انتشار). می‌تونید شاخه‌های محلی برای خودتون بسازید، ولی در مخزن مشترک تنها یک شاخه داریم.
• همه‌ی این‌ها درباره‌ی مخزن مشترک بود به نام google3 که بیشتر سرویس‌های گوگل روی اون هستن. ولی برخی پروژه‌ها روی اون نیستن، مثل Chrome.

پرسش و پاسخ:

• در خصوص سلامت بودن دایرکتوری‌ها و تمیز نگه‌داشتنشون چه طور؟ مالکیت/ownership چطوری تقسیم می‌شه؟ خصوصا چیزایی که خارج از «‌سرویس‌های یک تیم» هست. مثلا کدهای مشترکی که برای کتابخانه rpc یا غیره زده شدن. یکی بره تغییرشون بده، changelist رو باید به کی بده؟ اگر در یک زیرشاخه، فایلی به نام OWNERS موجود باشه، هر changelistی که حاوی تغییری در اون زیرشاخه باشه باید به تایید یکی از کسانی که در اون فایل OWNERS (یا فایل OWNERS شاخه‌ی بالایی یا بالاتر) فهرست شدن برسه. این مکانیکشه. ولی برای تغییر کدهای دیگران یا کتابخانه‌های مشترک اگر تغییر کوچکه، صرفا changelist رو می‌نویسید و با یک توضیح مکفی می‌فرستید. ولی اگر تغییر کوچک نیست، معمولا باید از پیش با تیم صحبت کنید و ایده‌تون رو بگید و نظراتشون رو بشنوید و معمولا هم پس از رسیدن به توافق، یک PoC از اون تیم تعیین می‌شه که changelistها رو بهش بفرستید.
• دسترسی‌ها چطور اعمال میشه؟ وقتی سراسر کدهای شرکت در یک جا تجمیع شدن چه طور سطح دسترسی‌ها مشخص می‌شن؟ می‌شه زیرشاخه‌های خاصی رو «حفاظت‌شده» کرد و دسترسیش رو فقط به گروه خاصی داد، ولی این کار به ندرت و تنها برای زیرشاخه‌هایی که دارای اطلاعات سرّی هستن استفاده می‌شه. تقریبا همه‌ی کدهای همه‌ی سرویس‌های شرکت برای همه‌ی کارمندان در دسترسه. در مجموع جوّ اعتماده. ولی باز هم کُد در حد برنزه. داده‌ها و برخی مستندات در حد طلا و نقره هستن که بهتر محافظت می‌شن.