معرفی
بازل (Bazel) ابزار ساخت، تست و اجرای خودکار نرم‌افزار برای پروژههای بزرگ، چندزبانه و دارای وابستگیهای فراوان است. تیم‌ها در فایلهای BUILD هدفهای ساخت را تعریف می‌کنند تا مشخص شود هر کتابخانه، برنامه، تست یا بسته با چه ورودی‌ها و وابستگی‌هایی ساخته میشود. راهنمای رسمی شروع کار با Bazel و فایلهای BUILD ساختار این مدل را توضیح می‌دهند.
گراف وابستگی و اجرای افزایشی
بازل ساخت را بر پایه گراف وابستگی اجرا میکند و در اجرای افزایشی، هدف‌هایی را دوباره می‌سازد که ورودی یا وابستگی‌شان تغییر کرده است. هدف این مدل، کنترل‌پذیرتر شدن ورودی‌های ساخت و کاهش وابستگیهای پنهان به محیط محلی است؛ جزئیات مدل وابستگی و اجرای ساخت در مستندات وابستگیها آمده است. ساخت موازی و کش محلی یا راه دور نیز میتواند در مخزن‌های بزرگ و اجرای تکراری ساخت و تست، زمان بازخورد را کاهش دهد، اما نتیجه به ساختار وابستگیها، کیفیت قواعد و زیرساخت کش تیم بستگی دارد.
پشتیبانی از زبان‌ها و قواعد ساخت (Starlark)
بازل برای زبان‌های گوناگون مانند Java، Kotlin، C++، Python و JavaScript استفاده میشود، اما سطح پشتیبانی همه زبان‌ها یکسان و لزوما داخلی نیست. بخشی از این پشتیبانی با ruleهای رسمی و بخشی با ruleها و افزونه‌های اکوسیستم فراهم میشود. برای نمونه، سازوکار توسعه قواعد و زبان Starlark در راهنمای قواعد Bazel و مستندات Starlark توضیح داده شده است.
برآورد یادگیری و هزینه نگهداری
یادگیری Bazel برای هر پروژه کوچک ضروری نیست. برآورد تحریریه این است که توسعه‌دهنده آشنا با ابزارهای ساخت، برای خواندن BUILDهای موجود و اجرای چند هدف ساده معمولا به ۸ تا ۱۶ ساعت تمرین نیاز دارد. راه‌اندازی آزمایشی روی یک ماژول، بسته به اندازه مخزن، تعداد زبان‌ها و تجربه تیم در CI/CD، اغلب ۲ تا ۶ هفته زمان می‌برد. نگهداری ruleها، مدیریت وابستگیهای خارجی و عیب‌یابی تفاوت محیط‌ها نیز بخشی از هزینه مداوم استفاده از آن است.
ارزیابی عملی پیش از مهاجرت
پیش از مهاجرت کل مخزن، یک ماژول دارای تست و وابستگیهای واقعی را انتخاب کنید. زمان ساخت سرد، زمان ساخت افزایشی پس از یک تغییر کوچک، مدت اجرای CI، نرخ استفاده از کش و زمان لازم برای نگهداری ruleها را قبل و بعد از آزمایش ثبت کنید. مستندات رسمی کش راه دور برای بررسی تنظیمات و محدودیت‌های کش کاربردی است.
جایگاه Bazel در بازار کار ایران
برای Bazel رویه استخدامی یا تقاضای محلی متمایز و مستندی در دست نیست. با این حال، هنگام بررسی آگهی‌های «DevOps Engineer»، «Software Engineer» یا موقعیت‌های تیم پلتفرم، به نشانه‌هایی مانند monorepo، CI/CD، build system، remote cache، ساخت چندزبانه و مدیریت وابستگیها توجه کنید. وجود این نشانه‌ها میتواند یادگیری Bazel را برای همان موقعیت مفیدتر کند، اما نام Bazel را نباید جایگزین مهارت‌های پایه توسعه، کنترل نسخه و تحویل مستمر دانست.
مقایسه با ابزارهای جایگزین
Gradle و Maven معمولا انتخاب‌های رایج‌تر برای پروژههای Java و Android هستند و اکوسیستم بالغی برای آن‌ها دارند. Apache Ant بیشتر در buildهای سنتی و اسکریپت‌محور دیده میشود و مدل وابستگی آن با Bazel تفاوت دارد. Nuke نیز عمدتا ابزار خودکارسازی build در اکوسیستم .NET است. بنابراین تنها برای تیم‌های .NET میتواند گزینه بررسی باشد، نه جایگزینی هم‌دامنه برای ساخت چندزبانه در مخزن‌های بزرگ.
این ابزار را با نام‌های دیگری نیز می‌شناسند:
- بیزل
ویژگی‌های کلیدی
در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.
-
ساخت افزایشی مبتنی بر گراف وابستگی
بازل وابستگی میان هدفهای ساخت را تحلیل میکند و پس از تغییر کد، فقط هدفهای متأثر را دوباره می‌سازد؛ نه کل پروژه را.
-
ساخت تکرارپذیر و ایزوله
قواعد ساخت می‌توانند ورودی‌ها و خروجیهای مجاز را مشخص کنند تا وابستگی پنهان به فایلهای محلی، متغیرهای محیطی یا وضعیت دستگاه کمتر شود.
-
اجرای موازی ساخت و تست
هدفهای مستقلی که به هم وابسته نیستند می‌توانند هم‌زمان ساخته یا تست شوند؛ قابلیتی مهم برای مخزن‌های بزرگ با تعداد زیاد تست.
-
کش محلی و راه دور
خروجیهای ساخت و نتایج تست قابل کش‌شدن هستند. تیم‌ها می‌توانند با کش راه دور، خروجی تولیدشده توسط یک توسعه‌دهنده یا CI را برای دیگران قابل استفاده کنند.
-
پشتیبانی از پروژههای چندزبانه
با قواعد و افزونه‌های مناسب، می‌توان ساخت و تست اجزای نوشته‌شده با چند زبان را در یک فرایند واحد مدیریت کرد.
-
قواعد ساخت قابل توسعه با Starlark
تنظیمات و قواعد بازل با زبان Starlark نوشته می‌شوند؛ زبانی شبیه Python که برای توصیف فرایند ساخت و ایجاد قواعد سفارشی به‌کار می‌رود.
-
ارزیابی عملی پیش از مهاجرت
یک ماژول آزمایشی را با Bazel بسازید و زمان ساخت سرد و افزایشی، نرخ استفاده از کش، مدت CI و زمان نگهداری ruleها را با وضعیت قبلی مقایسه کنید.
کاربردها
موارد زیر تصویری کلی از این بخش برای این ابزار ارائه می‌کنند.
-
مدیریت یک مخزن یکپارچه بزرگ
وقتی چند سرویس، کتابخانه مشترک، ابزار داخلی و تست در یک مخزن نگهداری می‌شوند، بازل میتواند وابستگیها و ساخت بخش‌های متأثر از هر تغییر را مدیریت کند.
-
ساخت و تست پروژه چندزبانه
برای محصولی که مثلاً بک‌اند Java، اجزای C++ و اسکریپت‌های Python دارد، بازل امکان تعریف یک جریان ساخت و تست هماهنگ را فراهم میکند.
-
کوتاه‌کردن زمان بازخورد CI
تیم‌هایی با تست‌های فراوان می‌توانند از اجرای موازی و کش راه دور استفاده کنند تا کارهای تکراری در هر اجرای خط CI دوباره انجام نشوند.
-
ساخت نرم‌افزار با خروجی قابل بازتولید
در پروژه‌هایی که یکسانبودن خروجی ساخت در لپ‌تاپ توسعه‌دهنده، سرور CI و محیط انتشار اهمیت دارد، قواعد صریح بازل به کنترل ورودی‌های ساخت کمک میکند.
-
توسعه کتابخانه‌ها و ابزارهای داخلی مشترک
وقتی چند تیم به کتابخانه‌های مشترک وابسته‌اند، تعریف هدفهای روشن و تست‌پذیر میتواند اثر تغییرات را پیش از ادغام کد آشکار کند.
ابزارهای جایگزین
اگر این ابزار پاسخگوی نیاز شما نبود، گزینه‌های زیر را بررسی کنید.
پرسش‌های رایج درباره بازل
اگر درباره این ابزار پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
بازل برای چه نوع پروژهای مناسب است؟
بازل معمولاً برای پروژههای بزرگ، چندماژوله یا چندزبانه مناسبتر است؛ بهویژه وقتی زمان ساخت و تست، وابستگیهای پیچیده یا یکسانبودن خروجی در محیطهای مختلف به مسئله تبدیل شده است.
آیا بازل جایگزین Gradle یا Maven است؟
در برخی پروژهها بله، اما انتخاب مستقیم نیست. Gradle و Maven در اکوسیستم Java و Android ابزارهای رایجتری هستند. بازل زمانی جذابتر میشود که ساخت چندزبانه، کش راه دور یا مقیاس مخزن اهمیت بیشتری داشته باشد.
فایل BUILD در بازل چیست؟
فایل BUILD هدفهای قابل ساخت، فایلهای ورودی، وابستگیها و قواعد ساخت را تعریف میکند. برای نمونه، یک هدف میتواند کتابخانه، برنامه اجرایی یا مجموعهای از تستها باشد.
آیا برای استفاده از بازل باید Starlark یاد بگیرم؟
برای شروع، خواندن و ویرایش قواعد آماده BUILD کافی است. اما برای تنظیمات پیچیده، ایجاد ماکرو یا نوشتن قواعد سفارشی، باید مفاهیم پایه Starlark را یاد بگیرید.
کش راه دور بازل چه فایدهای دارد؟
کش راه دور خروجیهای ساخت و نتایج قابل استفاده مجدد را میان توسعهدهندگان و سامانه CI به اشتراک میگذارد. در نتیجه، اگر خروجی معتبر قبلاً تولید شده باشد، نیاز به ساخت دوباره آن کمتر میشود.
چگونه قبل از مهاجرت، Bazel را ارزیابی کنم؟
یک ماژول واقعی را انتخاب کنید و زمان ساخت سرد و افزایشی، مدت اجرای CI، نرخ استفاده از کش و هزینه نگهداری ruleها را با ابزار فعلی مقایسه کنید. نتیجه این آزمایش برای تصمیم‌گیری از یک نمونه ساده معتبرتر است.
