Google właśnie udostępnił swoje narzędzie do budowania Bazel . Jakie są różnice między tym narzędziem a Gradle ? Co może zrobić, czego Gradle nie może, co robi lepiej, a co Gradle robi lepiej?
Google właśnie udostępnił swoje narzędzie do budowania Bazel . Jakie są różnice między tym narzędziem a Gradle ? Co może zrobić, czego Gradle nie może, co robi lepiej, a co Gradle robi lepiej?
Odpowiedzi:
Zastrzeżenie: pracuję na Bazel i nie jestem dobrze zaznajomiony z Gradle. Jednak jeden z moich współpracowników sporządził porównanie obu systemów, które sparafrazuję tutaj:
Bazel i Gradle podkreślają różne aspekty budowania. Do pewnego stopnia ich priorytety są niekompatybilne - dążenie Gradle do elastyczności i nienachalności ogranicza ograniczenia, jakie może nałożyć na konstrukcję konstrukcyjną, podczas gdy dążenie firmy Bazel do niezawodności i wydajności siłą rzeczy wymusza niezbywalne ograniczenia.
Gradle ceni te same zasady, co Bazel, tj. Zespół Gradle przywiązuje dużą wagę do wydajności (kompilacje przyrostowe, równoległa konfiguracja i wykonanie, demon Gradle), poprawność (sprawdzanie aktualności na podstawie zawartości) i odtwarzalność (bogate wsparcie dla deklaratywnej składni, wersjonowania zależności, jawnie zadeklarowanych zależności). Bazel szanuje potrzebę elastycznych układów projektów.
Niuans polega na tym, że Gradle chce promować dobre praktyki, podczas gdy Bazel chce tego wymagać. Gradle dąży do znalezienia środka pomiędzy doświadczeniem Ant (swoboda definiowania własnej struktury projektu z niespójnymi wynikami) a doświadczeniem Maven (narzucone najlepsze praktyki bez miejsca na różne potrzeby projektowe). Bazel uważa, że elastyczne wsparcie projektu jest możliwe bez poświęcania silnych gwarancji, które umożliwiają jego potężne przepływy pracy.
Żadna filozofia nie jest bardziej „poprawna” - to, które narzędzie najlepiej pasuje do projektu, zależy od wartości tego projektu.
Gradle to bardzo elastyczny system, który ułatwia użytkownikom tworzenie kompletnych, niezawodnych przepływów kompilacji przy minimalnych ograniczeniach dotyczących sposobu organizacji projektów. Czyni to poprzez dostarczanie potężnych bloków konstrukcyjnych (np. Automatyczne śledzenie i pobieranie zależności, ściśle zintegrowana obsługa wtyczek) z ogólnym, kompletnym interfejsem skryptowym Turinga, który może łączyć te bloki w dowolny sposób.
Gradle podkreśla następujące cechy:
Bazel wyewoluował z potrzeby niezawodnego i wydajnego budowania wewnętrznych projektów Google. Ponieważ środowisko programistyczne Google jest niezwykle duże i złożone, Bazel oferuje niezwykle silne gwarancje dotyczące integralności swoich kompilacji i niezwykle niskiego narzutu wydajności w ich osiągnięciu.
Stanowi to podstawę dla potężnych przepływów pracy programistycznych zbudowanych wokół odtwarzalnych kompilacji, w których „kompilacja” staje się abstrakcyjną jednostką, do której można się odwoływać, powtarzać, przekazywać do różnych maszyn i przekazywać do dowolnych programów i usług, tak że każda instancja jest znana jako dokładnie to samo.
Bazel podkreśla następujące cechy:
Ponieważ linki do artykułów zwykle umierają, oto podsumowanie poglądów zespołu Gradle na temat firmy Bazel (większość pochodzi bezpośrednio z artykułu opublikowanego w marcu 2015 r.):
Został zaprojektowany, aby rozwiązać problem występujący wyłącznie w Google; ogromna monolityczna baza kodów (setki milionów LOC).
Przewaga zrównoleglania, którą obecnie zapewnia Bazel, zostanie dopasowana przez „naszą nadchodzącą nową konfigurację i model komponentów” (pamiętaj o dacie artykułu tutaj).
Bazel nie ma deklaratywnego języka budowania wysokiego poziomu, który sprawia, że kompilacja jest łatwa w użyciu dla programistów. W Google można to zrekompensować wyspecjalizowanym zespołem serwisowym, który jest właścicielem narzędzia do kompilacji.
Bazel nie jest zbudowany z myślą o rozszerzalności (chociaż zespół programistów Bazel od tego czasu przeciwdziałał temu, zapewniając, że pracują nad rozszerzalnością).
Szybkość jest zoptymalizowana wokół idei, że wszystkie zależności przechodnie są przechowywane w jednym dużym repozytorium; wszystkie biblioteki i narzędzia są wpisywane do tego centralnego repozytorium. Większość przedsiębiorstw ma bardziej rozproszone wymagania dotyczące zarządzania zależnościami.
Bazel to tylko * nix, nie działa w systemie Windows. Eliminuje to dużą liczbę potencjalnych przedsiębiorstw.
Brak ekosystemu wtyczek.
Gradle jest najczęściej używany w ekosystemie JVM (Java, Ggroovy, Scala, Kotlin ...). Jeśli twój projekt jest w tym obszarze i musisz zadać pytanie, Gradle lub Maven byłby lepszym wyborem. Aby rozwiązać problem z kompilacją Gradle, będziesz walczyć tylko z ekosystemem Java i JVM.
Bazel w sercu ma możliwość wykrywania przyrostowych zmian (a także rozproszonej pamięci podręcznej kompilacji) i pozwala na reagowanie, stosowanie wtyczek / reguł w celu uzyskania przyrostowych kompilacji. Konfiguracja i utrzymanie tego wymagała trochę wiedzy w zakresie CPP, Java i Python (Skylark), a także wiedzy administratora systemu. Ponownie, jeśli musisz zadać pytanie, myślę, że Gradle lub Maven byłyby tańszą inwestycją. Dzięki Bazel możesz zbudować dowolne języki, w dowolny sposób, który zdefiniujesz, więcej mocy, ale za cenę.