Чим відрізняються Базель від Градле?

Google просто відкрив свій інструмент для збирання Bazel . Які відмінності між цим інструментом та Gradle ? Що він може зробити, що Gradle не може, що робить краще, і що Gradle робить краще?

Відмова: Я працюю над Базелем, і я не дуже знайомий з Gradle. Однак один із моїх колег написав порівняння двох систем, які я перефразую тут:

Базель і Градле підкреслюють різні аспекти досвіду будівництва. До певної міри їхні пріоритети несумісні - прагнення Градле до гнучкості та ненав'язливості обмежує обмеження, які він може накласти на структуру побудови, тоді як бажання Базеля до надійності та продуктивності обов'язково застосовує обмеження, що не підлягають обговоренню.

Gradle дійсно цінує ті самі принципи, що і Bazel, тобто команда Gradle приділяє велику увагу продуктивності (покрокові побудови, паралелізована конфігурація та виконання, демон Gradle), правильність (перевірка на основі контенту "актуальної" перевірки) та відтворюваність (багата підтримка декларативного синтаксису, версія про залежність, явно оголошені залежності). І Базель поважає необхідність гнучких макетів проектів.

Нюанс полягає в тому, що Градле хоче просувати хорошу практику, тоді як Базель хоче цього вимагати. Градле прагне до середнього між досвідом Мураш (свобода визначати свою власну структуру проекту з неузгодженими результатами) та досвідом Мейвена (застосовувати кращі практики, не маючи місця для різних потреб проекту). Базель вважає, що гнучка підтримка проектів можлива без шкоди для надійних гарантій, що забезпечують його потужний робочий процес.

Жодна філософія не є більш «правильною» - той інструмент, який найкраще підходить для проекту, залежить від цінностей конкретного проекту.

Огляд Gradle

Gradle - це дуже гнучка система, яка дозволяє користувачам легко створювати повноцінні, надійні потоки збірки з мінімальними обмеженнями в організації організації своїх проектів. Це робиться завдяки постачанню потужних будівельних блоків (наприклад, автоматичного відстеження залежностей та пошуку, тісно інтегрована підтримка плагінів) із загальним інтерфейсом сценаріїв, повним Тьюрінгом, який може комбінувати ці блоки, як того бажають користувачі.

Градле підкреслює наступні особливості:

• Легка міграція з інших систем. Gradle легко розміщує будь-яку проектну організацію для легкого впровадження довільних структур робочого процесу. Він споконвічно розуміє завдання мурашок і вродже інтегрується з сховищами Maven та Ivy.
• Високо розширювана сценарна модель. Користувачі реалізують всю логіку побудови, написавши сценарії Groovy. "Побудова" - це просто виконання послідовно виконаних загальних завдань, які по суті є визначеннями відкритого, перезаписуваного, розширюваного методу.
• Багате управління залежністю. Універсальні залежності можуть бути оголошені та автоматично поетапно викладені із зовнішніх сховищ коду, локальних файлових систем та інших проектів Gradle. Виходи збірки можуть також автоматично публікуватися у сховищах та інших місцях.
• Щільно інтегрована система плагінів. Плагіни - це просто групи завдань, організованих для полегшення бажаного робочого процесу. Багато основних "функцій" Gradle реально реалізовані за допомогою плагінів (наприклад, Java, Android). Плагіни тісно взаємодіють (на власний розсуд) з побудовою логіки сценарію. Плагіни мають глибокий доступ до основних структур даних Gradle.

Огляд Базеля

Базель розвинулася з необхідності надійного та ефективного створення внутрішніх проектів Google. Оскільки середовище розробки Google незвичайно велике і складне, Bazel надає незвичайно міцні гарантії цілісності своїх конструкцій та незвично низьких витрат на їх виконання.

Це забезпечує основу для потужних робочих процесів розвитку, побудованих навколо відтворюваних збірок, де "збірка" стає абстрактною сутністю, яку можна посилати, повторювати, передавати на різні машини та передавати до довільних програм та служб таким, що, як відомо, кожен екземпляр точно так само.

Базель наголошує на наступних особливостях:

• Правильність. Склади Bazel розроблені таким чином, щоб завжди давати правильний вихід, період. Якщо два користувачі посилаються на одну і ту ж збірку одночасно з однаковими прапорами Bazel на різних машинах, вони побачать однакові результати. Поступові складання настільки ж надійно правильні, як і чисті складання, що робить останні фактично непотрібними.
• Продуктивність. Побудови призначені для виконання якомога швидше, враховуючи наявні в них ресурси. Завдання настільки ж паралельні, скільки дозволяють їх ланцюги залежностей. Зайва робота ніколи не виконується (тобто завжди актуальні завдання пропускаються). Робота, природно, може бути спрямована на віддалених виконавців для подолання місцевих лімітів машин.
• Відтворюваність. Будь-який примірник збірки може бути вірно відтворений у будь-якому середовищі. Наприклад, якщо у звіті про помилку йдеться, що версія X програмного забезпечення Y не працює у виробничому середовищі Z, розробник може вірно відтворити його на власній машині з упевненістю, що вони налагоджують те саме.

Оскільки посилання на статті мають тенденцію до вмирання, ось короткий виклад поглядів Команди Gradle на Базель (більшість з них безпосередньо виведені зі статті, опублікованої у березні 2015 року):

Він був розроблений для вирішення унікальної для Google проблеми; масивна монолітна кодова база (сотні мільйонів LOC).

Перевага паралелізації, яке Базель надає зараз, буде відповідати "нашій новій новій конфігурації та моделі компонентів" (майте на увазі дату статті тут).

Bazel не має декларативної мови складання, що робить цю збірку зручною для розробників. В Google це можна компенсувати спеціалізованою службою обслуговування, яка володіє інструментом збирання.

Bazel не побудований для розширення (хоча команда розробників Bazel з тих пір протидіяла цьому запевненням, що вони працюють над розширенням).

Швидкість оптимізована навколо ідеї, що всі перехідні залежності зберігаються в одному великому репо; всі бібліотеки та інструменти заносяться до цього центрального сховища. Більшість підприємств мають більш розповсюджені вимоги до управління залежностями.

Bazel - це * nix, він не працює в Windows. Це виключає велику кількість потенційних підприємств.

Відсутня екосистема плагінів.

Gradle здебільшого використовується в екосистемі JVM (Java, Ggroovy, Scala, Kotlin ...). Якщо ваш проект знаходиться в цій області, і вам доведеться задати питання, кращим вибором буде Gradle або Maven. Щоб усунути проблеми з побудовою Gradle, ви зможете працювати лише з Java та JVM-екосистемою.

Базель в основі має можливість виявляти поступові зміни (а також розподілений кеш збірки) і дозволяє реагувати, застосовувати плагіни / правила для досягнення нарощення нарощування. Для налаштування та підтримки цього знадобилося трохи знань про CPP, Java та Python (Skylark) та знання системного адміністратора. Знову, якщо вам доведеться задати питання, я думаю, що Gradle або Maven були б дешевшими інвестиціями. За допомогою Bazel ви можете створювати будь-які мови, залежно від того, яким чином ви визначите, більше енергії, але затрату.