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

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

بازل چیست؟

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

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

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

  • پشتیبانی از چند زبان: 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 همچنین می‌تواند برای ساخت‌ها و آزمایش‌های سریع‌تر به یک خوشه ساخت متصل شود. برای جزئیات بیشتر به مستندات ما در مورد اجرای از راه دور و حافظه پنهان و حافظه پنهان از راه دور مراجعه کنید.

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

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

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

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

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

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

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

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

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

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

آره؛ یک مثال ساده را ببینید یا کد منبع 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 ناقص در داخل ظرف Docker هنوز هم می تواند نتایج غیر قابل پیش بینی داشته باشد.

در داخل گوگل، ابزارها را برای تکرارپذیری در کنترل منبع بررسی می کنیم. به این ترتیب، می‌توانیم تغییرات ابزارها را بررسی کنیم ("ارتقا 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 در دسترس نیستند و احتمالاً هرگز در دسترس نخواهند بود.

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

ما در bazel-discuss@googlegroups.com قابل دسترسی هستیم.

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

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

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

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

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

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

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

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