سوالات متداول

اگر سؤالی دارید یا نیاز به پشتیبانی دارید، به دریافت راهنمایی مراجعه کنید.

بازل چیست؟

Bazel ابزاری است که ساخت و تست نرم افزار را خودکار می کند. وظایف ساخت پشتیبانی شده شامل اجرای کامپایلرها و لینک‌کننده‌ها برای تولید برنامه‌ها و کتابخانه‌های اجرایی و مونتاژ بسته‌های قابل استقرار برای Android، iOS و سایر محیط‌های هدف است. Bazel شبیه به ابزارهای دیگر مانند Make، Ant، ​​Gradle، Buck، Pants و Maven است.

بازل چه ویژگی خاصی دارد؟

Bazel به گونه ای طراحی شده است که با روش توسعه نرم افزار در گوگل سازگار باشد. دارای ویژگی های زیر است:

• پشتیبانی از چند زبان: Bazel از بسیاری از زبان ها پشتیبانی می کند و می تواند برای پشتیبانی از زبان های برنامه نویسی دلخواه گسترش یابد.
• زبان ساخت سطح بالا: پروژه ها به زبان BUILD توصیف می شوند، یک قالب متن مختصر که پروژه را به عنوان مجموعه ای از کتابخانه های کوچک به هم پیوسته، باینری ها و تست ها توصیف می کند. در مقابل، با ابزارهایی مانند Make، باید فایل‌ها و فراخوان‌های کامپایلر را توصیف کنید.
• پشتیبانی از چند پلتفرم: از ابزار مشابه و فایل های BUILD یکسان می توان برای ساخت نرم افزار برای معماری های مختلف و حتی پلتفرم های مختلف استفاده کرد. در Google، ما از Bazel برای ساختن همه چیز استفاده می‌کنیم، از برنامه‌های کاربردی سرور که در سیستم‌های مراکز داده ما اجرا می‌شوند تا برنامه‌های مشتری که روی تلفن‌های همراه اجرا می‌شوند.
• تکرارپذیری: در فایل های BUILD ، هر کتابخانه، تست و باینری باید وابستگی های مستقیم خود را به طور کامل مشخص کند. Bazel از این اطلاعات وابستگی استفاده می کند تا بداند هنگام ایجاد تغییرات در فایل منبع، چه چیزی باید بازسازی شود و کدام وظایف می توانند به صورت موازی اجرا شوند. این بدان معنی است که همه ساخت ها افزایشی هستند و همیشه نتیجه یکسانی را ایجاد می کنند.
• مقیاس پذیر: Bazel می تواند ساخت های بزرگ را مدیریت کند. در گوگل، معمولاً یک سرور باینری دارای 100 هزار فایل منبع است و ساخت‌هایی که هیچ فایلی در آنها تغییر نمی‌کند حدود 200 میلی‌ثانیه طول می‌کشد.

چرا گوگل از ... استفاده نمی کند؟

• Make, Ninja: این ابزارها کنترل بسیار دقیقی بر دستوراتی که برای ساخت فایل ها فراخوانی می شوند را می دهند، اما نوشتن قوانین صحیح به عهده کاربر است.
  • کاربران در سطح بالاتری با Bazel تعامل دارند. به عنوان مثال، Bazel دارای قوانین داخلی برای "تست جاوا"، "C++ باینری" و مفاهیمی مانند "پلتفرم هدف" و "پلتفرم میزبان" است. این قوانین برای بی‌خطا بودن آزمایش شده‌اند.
• Ant and Maven: Ant و Maven در درجه اول به سمت جاوا طراحی شده اند، در حالی که Bazel چندین زبان را مدیریت می کند. Bazel تقسیم‌پایه‌های کد را در واحدهای کوچک‌تر قابل استفاده مجدد تشویق می‌کند و می‌تواند تنها واحدهایی را که نیاز به بازسازی دارند بازسازی کند. این سرعت توسعه را هنگام کار با پایگاه های کد بزرگتر افزایش می دهد.
• Gradle: فایل‌های پیکربندی Bazel بسیار ساختارمندتر از Gradle هستند و به Bazel اجازه می‌دهند تا دقیقاً بفهمد هر عمل چه می‌کند. این امکان موازی سازی بیشتر و تکرارپذیری بهتر را فراهم می کند.
• Pants, Buck: هر دو ابزار توسط Googler های سابق در Twitter و Foursquare و Facebook ایجاد و توسعه داده شدند. آنها از Bazel الگوبرداری شده اند، اما مجموعه ویژگی های آنها متفاوت است، بنابراین آنها جایگزین مناسبی برای ما نیستند.

بازل از کجا آمد؟

Bazel مزه ابزاری است که گوگل از آن برای ساختن نرم افزار سرور خود به صورت داخلی استفاده می کند. برای ساختن نرم افزارهای دیگر نیز گسترش یافته است، مانند برنامه های تلفن همراه (iOS، Android) که به سرورهای ما متصل می شوند.

آیا ابزار داخلی خود را به عنوان منبع باز بازنویسی کردید؟ آیا این یک چنگال است؟

Bazel بیشتر کدهای خود را با ابزار داخلی به اشتراک می گذارد و قوانین آن روزانه برای میلیون ها بیلد استفاده می شود.

چرا گوگل بازی Bazel را ساخت؟

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

آیا بازل به خوشه ساخت نیاز دارد؟

Bazel به صورت پیش فرض عملیات ساخت را به صورت محلی اجرا می کند. با این حال، Bazel همچنین می‌تواند برای ساخت‌ها و آزمایش‌های سریع‌تر به یک Build Cluster متصل شود. برای جزئیات بیشتر به مستندات ما در مورد اجرای از راه دور و حافظه پنهان و کش از راه دور مراجعه کنید.

فرآیند توسعه گوگل چگونه کار می کند؟

برای پایگاه کد سرور خود، از گردش کار توسعه زیر استفاده می کنیم:

• تمام کد سرور ما در یک سیستم کنترل نسخه غول پیکر است.
• همه نرم افزار خود را با Bazel می سازند.
• تیم های مختلف دارای قسمت های مختلف درخت منبع هستند و اجزای خود را به عنوان اهداف BUILD در دسترس قرار می دهند.
• شاخه‌بندی عمدتاً برای مدیریت نسخه‌ها استفاده می‌شود، بنابراین همه نرم‌افزار خود را در نسخه اصلی توسعه می‌دهند.

Bazel سنگ بنای این فلسفه است: از آنجایی که Bazel نیاز دارد که همه وابستگی ها به طور کامل مشخص شوند، می توانیم پیش بینی کنیم که کدام برنامه ها و تست ها تحت تأثیر تغییر قرار می گیرند و آنها را قبل از ارسال بررسی کنیم.

پیشینه بیشتر در مورد فرآیند توسعه در Google را می توانید در وبلاگ ابزارهای eng پیدا کنید.

چرا بازل را باز کردی؟

ساختن نرم افزار باید سرگرم کننده و آسان باشد. ساخت های آهسته و غیرقابل پیش بینی لذت برنامه نویسی را از بین می برد.

چرا می خواهم از Bazel استفاده کنم؟

• Bazel ممکن است زمان ساخت سریع‌تری را به شما بدهد زیرا فقط می‌تواند فایل‌هایی را که نیاز به کامپایل مجدد دارند را کامپایل کند. به طور مشابه، می‌تواند از اجرای مجدد تست‌هایی که می‌داند تغییر نکرده‌اند صرفنظر کند.
• بازل نتایج قطعی تولید می کند. این باعث از بین رفتن انحراف بین ساخت های افزایشی و تمیز، لپ تاپ و سیستم CI و غیره می شود.
• Bazel می‌تواند اپلیکیشن‌های کلاینت و سرور مختلف را با یک ابزار از یک فضای کاری مشابه بسازد. برای مثال، می‌توانید یک پروتکل کلاینت/سرور را در یک commit تغییر دهید و آزمایش کنید که اپلیکیشن موبایل به‌روزرسانی شده با سرور به‌روز شده کار می‌کند، و هر دو را با یک ابزار ایجاد می‌کند و از تمام مزایای ذکر شده Bazel بهره می‌برد.

آیا می توانم نمونه هایی را ببینم؟

آره؛ یک مثال ساده را ببینید یا کد منبع Bazel را برای مثال پیچیده تر بخوانید.

بازل در چه چیزی بهترین است؟

بازل در پروژه های ساختمانی و آزمایشی با ویژگی های زیر می درخشد:

• پروژه هایی با پایگاه کد بزرگ
• پروژه هایی که به زبان های کامپایل شده (چندین) نوشته شده اند
• پروژه هایی که در چندین پلتفرم مستقر می شوند
• پروژه هایی که تست های گسترده ای دارند

کجا می توانم بازیل را اجرا کنم؟

Bazel روی Linux، macOS (OS X) و Windows اجرا می شود.

تا زمانی که یک JDK برای پلتفرم موجود باشد، انتقال به دیگر پلتفرم‌های یونیکس باید نسبتاً آسان باشد.

برای چه کاری از بازل استفاده نکنم؟

• بازل سعی می کند در مورد ذخیره سازی هوشمندانه عمل کند. این به این معنی است که برای اجرای عملیات ساخت که خروجی‌های آن‌ها نباید حافظه پنهان شوند، خوب نیست. به عنوان مثال، مراحل زیر نباید از Bazel اجرا شوند:
  • مرحله تلفیقی که داده ها را از اینترنت واکشی می کند.
  • مرحله آزمایشی که به نمونه QA سایت شما متصل می شود.
  • یک مرحله استقرار که پیکربندی ابری سایت شما را تغییر می دهد.
• اگر ساخت شما شامل چند مرحله طولانی و متوالی است، Bazel ممکن است نتواند کمک زیادی به شما کند. با شکستن گام های بلند به اهداف کوچکتر و مجزا که Bazel می تواند به صورت موازی اجرا کند، سرعت بیشتری کسب خواهید کرد.

مجموعه ویژگی های Bazel چقدر پایدار است؟

ویژگی‌های اصلی (C++، جاوا و قوانین پوسته) در داخل گوگل کاربرد گسترده‌ای دارند، بنابراین به‌طور کامل آزمایش شده‌اند و بسیار کم هستند. به همین ترتیب، ما هر روز نسخه‌های جدید Bazel را در صدها هزار هدف آزمایش می‌کنیم تا رگرسیون‌ها را پیدا کنیم، و هر ماه چندین بار نسخه‌های جدید را منتشر می‌کنیم.

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

Bazel به عنوان یک باینری چقدر پایدار است؟

در داخل گوگل، ما مطمئن می شویم که خرابی های Bazel بسیار نادر است. این همچنین باید برای پایگاه کد منبع باز ما نیز صادق باشد.

چگونه می توانم استفاده از Bazel را شروع کنم؟

به شروع مراجعه کنید.

آیا داکر مشکلات تکرارپذیری را حل نمی کند؟

با Docker می‌توانید به راحتی جعبه‌های sandbox با نسخه‌های سیستم‌عامل ثابت ایجاد کنید، به‌عنوان مثال، اوبونتو 12.04، فدورا 21. این مشکل تکرارپذیری برای محیط سیستم را حل می‌کند – یعنی «به کدام نسخه از /usr/bin/c++ نیاز دارم؟»

Docker با توجه به تغییرات در کد منبع به تکرارپذیری نمی‌پردازد. اجرای Make با یک Makefile ناقص در داخل ظرف داکر همچنان می تواند نتایج غیر قابل پیش بینی داشته باشد.

در داخل گوگل، ابزارها را برای تکرارپذیری در کنترل منبع بررسی می کنیم. به این ترتیب، می‌توانیم تغییرات ابزارها ("ارتقا GCC به 4.6.1") را با همان مکانیزم تغییرات در کتابخانه‌های پایه بررسی کنیم ("تعیین محدودیت‌ها در OpenSSL").

آیا می توانم باینری برای استقرار در Docker بسازم؟

با Bazel، می‌توانید باینری‌های مستقل و با پیوند استاتیک در C/C++ و فایل‌های jar خود را برای جاوا بسازید. این‌ها با وابستگی‌های کمی به سیستم‌های یونیکس معمولی اجرا می‌شوند و به همین دلیل باید در داخل یک ظرف Docker نصب شوند.

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

آیا می توانم تصاویر Docker را با Bazel بسازم؟

بله، شما می توانید از قوانین داکر ما برای ساخت تصاویر داکر قابل تکرار استفاده کنید.

آیا Bazel بیلدهای من را به طور خودکار قابل تکرار می کند؟

برای باینری های جاوا و سی پلاس پلاس، بله، با فرض اینکه زنجیره ابزار را تغییر ندهید. اگر مراحل ساختی دارید که شامل دستور العمل های سفارشی می شود (به عنوان مثال، اجرای باینری ها از طریق یک اسکریپت پوسته در داخل یک قانون)، باید کمی دقت بیشتری به خرج دهید:

• از وابستگی هایی که اعلام نشده اند استفاده نکنید. اجرای Sandboxed (–spawn_strategy=sandboxed، فقط در لینوکس) می تواند به یافتن وابستگی های اعلام نشده کمک کند.
• از ذخیره مهرهای زمانی و شناسه های کاربری در فایل های تولید شده خودداری کنید. فایل های ZIP و سایر آرشیوها به ویژه مستعد این هستند.
• از اتصال به شبکه خودداری کنید. اجرای سندباکس در اینجا نیز می تواند کمک کند.
• از فرآیندهایی که از اعداد تصادفی استفاده می کنند اجتناب کنید، به ویژه، پیمایش فرهنگ لغت در بسیاری از زبان های برنامه نویسی تصادفی است.

آیا نسخه های باینری دارید؟

بله، می‌توانید آخرین نسخه‌های باینری را بیابید و خط‌مشی انتشار ما را مرور کنید

من از Eclipse/IntelliJ/XCode استفاده می کنم. بازل چگونه با IDE ها کار می کند؟

برای IntelliJ، افزونه IntelliJ with Bazel را بررسی کنید.

برای XCode، Tulsi را بررسی کنید.

برای Eclipse، افزونه E4B را بررسی کنید.

برای سایر IDE ها، پست وبلاگ در مورد نحوه کار این افزونه ها را بررسی کنید.

من از Jenkins/CircleCI/TravisCI استفاده می کنم. بازل چگونه با سیستم های CI تعامل می کند؟

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

جزئیات بیشتر در مورد کدهای خروج در دفترچه راهنمای کاربر موجود است.

چه ویژگی های آینده را می توانیم در Bazel انتظار داشته باشیم؟

نقشه راه ما را ببینید .

آیا می توانم از Bazel برای پروژه INSERT LANGUAGE HERE خود استفاده کنم؟

بازل قابل توسعه است. هر کسی می تواند پشتیبانی از زبان های جدید را اضافه کند. بسیاری از زبان‌ها پشتیبانی می‌شوند: برای فهرستی از توصیه‌ها به دایره‌المعارف ساخت و برای فهرست جامع‌تر به awesomebazel.com مراجعه کنید.

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

آیا می توانم به پایگاه کد بازل کمک کنم؟

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

چرا همه توسعه ها در فضای باز انجام نمی شود؟

ما هنوز باید رابط های بین کد عمومی در Bazel و برنامه های افزودنی داخلی خود را مرتباً بازسازی کنیم. این امر باعث می شود که توسعه زیاد در فضای باز دشوار باشد.

آیا منبع باز بازل را تمام کرده اید؟

منبع باز Bazel یک کار در حال پیشرفت است. به طور خاص، ما هنوز در حال کار بر روی منبع باز هستیم:

• بسیاری از تست‌های واحد و ادغام ما (که باید کمک‌کننده وصله‌ها را آسان‌تر کند).
• ادغام کامل IDE

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

آیا قسمت هایی از بازل وجود دارد که هرگز منبع باز نمی شود؟

بله، برخی از کدهای پایه یا با فناوری خاص گوگل ادغام می شوند یا ما به دنبال بهانه ای برای خلاص شدن از شر آن بوده ایم (یا ترکیبی از این دو است). این بخش‌های پایه کد در GitHub در دسترس نیستند و احتمالاً هرگز هم نخواهند بود.

چگونه با تیم تماس بگیرم؟

ما در [email protected] قابل دسترسی هستیم.

کجا اشکالات را گزارش کنم؟

یک مشکل را در GitHub باز کنید.

کلمه "Blaze" در پایگاه کد چه خبر است؟

این یک نام داخلی برای ابزار است. رجوع به بازل بازل شود.

چرا سایر پروژه های گوگل (اندروید، کروم) از ابزارهای ساخت دیگری استفاده می کنند؟

تا قبل از انتشار اول (آلفا)، Bazel به صورت خارجی در دسترس نبود، بنابراین پروژه های منبع باز مانند Chromium و Android نمی توانستند از آن استفاده کنند. علاوه بر این، عدم پشتیبانی اولیه از ویندوز مشکلی برای ساخت برنامه های ویندوز مانند کروم بود. از آنجایی که پروژه به بلوغ رسیده و پایدارتر شده است، پروژه متن باز اندروید در حال مهاجرت به Bazel است.

چگونه "بازل" را تلفظ می کنید؟

مانند "ریحان" (گیاه) در انگلیسی آمریکایی: "BAY-zel". با "فندق" هم قافیه است. IPA: /ˈbeɪzˌəl/