Bazel과 Gradle의 차이점은 무엇입니까?

Google은 방금 빌드 도구 Bazel을 오픈 소스로 제공 했습니다 . 이 도구와 Gradle 의 차이점은 무엇입니까 ? Gradle이 할 수없는 것은 무엇이며, 더 잘하는 것은 무엇이며, Gradle은 더 잘하는 것은 무엇입니까?

면책 조항 : Bazel에서 일하고 Gradle에 익숙하지 않습니다. 그러나 내 동료 중 한 명이이 두 시스템의 비교를 작성했습니다.

Bazel과 Gradle은 빌드 경험의 다양한 측면을 강조합니다. 유연성과 비 차폐성에 대한 Gradle의 요구는 빌드 구조에 대한 제한을 제한하는 반면 Bazel의 안정성과 성능에 대한 요구는 협상 할 수없는 제한을 강제합니다.

Gradle은 Bazel과 동일한 원칙, 즉 Gradle 팀이 성능 (증분 빌드, 병렬 구성 및 실행, Gradle 데몬), 정확성 (콘텐츠 기반 "최신"검사) 및 재현성에 큰 관심을 기울입니다. (선언적 구문, 종속성 버전 관리, 명시 적으로 선언 된 종속성에 대한 풍부한 지원). Bazel은 유연한 프로젝트 레이아웃의 필요성을 존중합니다.

미묘한 차이는 Gradle이 모범 사례를 장려하고 Bazel이 요구하고 싶어한다는 것입니다. Gradle은 Ant 경험 (일관되지 않은 결과로 자신 만의 프로젝트 구조를 정의 할 수있는 자유)과 Maven 경험 (다양한 프로젝트 요구에 대한 여지없이 강제 모범 사례) 사이의 중간 지점을 목표로합니다. Bazel은 강력한 워크 플로우를 가능하게하는 강력한 보장을 희생하지 않고도 유연한 프로젝트 지원이 가능하다고 생각합니다.

어느 철학도 더“올바른”것은 아닙니다. 프로젝트에 가장 적합한 도구는 특정 프로젝트의 가치에 달려 있습니다.

그레들 개요

Gradle은 사용자가 프로젝트를 구성하는 방법에 대한 제약을 최소화하면서 완전하고 안정적인 빌드 흐름을 쉽게 구성 할 수있는 매우 유연한 시스템입니다. 이는 강력한 빌딩 블록 (예 : 자동 종속성 추적 및 검색, 긴밀하게 통합 된 플러그인 지원)을 제공하지만 사용자가 원하는대로 이러한 블록을 결합 할 수있는 일반 Turing-complete 스크립팅 인터페이스를 제공합니다.

Gradle은 다음 기능을 강조합니다.

• 다른 시스템에서 쉽게 마이그레이션 Gradle은 모든 프로젝트 구성을 쉽게 수용하여 임의의 워크 플로우 구조를 쉽게 구현합니다. 기본적으로 Ant 태스크를 이해하고 기본적으로 Maven 및 Ivy 저장소와 통합됩니다.
• 확장 성이 뛰어난 스크립팅 모델. 사용자는 Groovy 스크립트를 작성하여 모든 빌드 로직을 구현합니다. "빌드"는 단순히 일반 작업의 종속성 순서대로 실행되는 것으로, 기본적으로 개방형이며 재정의 가능하며 확장 가능한 메소드 정의입니다.
• 풍부한 의존성 관리. 외부 코드 저장소, 로컬 파일 시스템 및 기타 Gradle 프로젝트에서 버전 별 종속성을 선언하고 자동으로 스테이징 할 수 있습니다. 마찬가지로 빌드 출력은 리포지토리 및 다른 위치에 자동 게시 될 수 있습니다.
• 긴밀하게 통합 된 플러그인 시스템. 플러그인은 원하는 워크 플로우를 용이하게하기 위해 조직 된 작업 묶음입니다. Gradle의 "핵심"기능 중 다수는 실제로 플러그인 (예 : Java, Android)을 통해 구현됩니다. 플러그인은 빌드 스크립트 로직과 긴밀하게 상호 작용합니다. 플러그인은 Gradle의 핵심 데이터 구조에 깊이 액세스 할 수 있습니다.

바젤 개요

Bazel은 내부 Google 프로젝트를 안정적이고 효율적으로 구축해야 할 필요성에서 진화했습니다. Google의 개발 환경은 비정상적으로 규모가 크고 복잡하기 때문에 Bazel은 빌드의 무결성과이를 달성하는 데있어 성능 오버 헤드가 매우 낮다는 점을 강력하게 보장합니다.

이는 재현 가능한 빌드를 기반으로 구축 된 강력한 개발 워크 플로우의 토대를 제공합니다. 여기서 "빌드"는 참조, 반복, 다른 머신으로 전달 및 임의의 프로그램 및 서비스로 전달되어 모든 인스턴스가 알려진 것으로 알려진 추상 엔티티가됩니다. 정확히 동일합니다.

Bazel은 다음 기능을 강조합니다.

• 단정. Bazel 빌드는 항상 정확한 출력, 기간을 생성하도록 설계되었습니다. 두 명의 사용자가 다른 머신에서 동일한 Bazel 플래그를 사용하여 동일한 커밋에서 동일한 빌드를 호출하면 동일한 결과가 표시됩니다. 증분 빌드는 클린 빌드만큼 안정적으로 정확하므로 후자는 본질적으로 불필요합니다.
• 공연. 빌드는 사용 가능한 리소스를 감안할 때 본질적으로 가능한 빨리 실행되도록 설계되었습니다. 작업은 종속성 체인이 허용하는 한 병렬화 할 수 있습니다. 불필요한 작업은 절대로 실행되지 않습니다 (예 : "최신"작업은 항상 건너 뜁니다). 로컬 기계 제한을 극복하기 위해 작업을 원격 실행 프로그램으로 자연스럽게 처리 할 수 ​​있습니다.
• 재현성. 어떤 환경에서도 빌드의 인스턴스를 충실하게 재현 할 수 있습니다. 예를 들어, 버그 보고서에 프로덕션 환경 Z에서 소프트웨어 Y의 버전 X가 실패한다고 표시되면 개발자는 동일한 것을 디버깅하고 있다는 확신을 가지고 자신의 컴퓨터에서 충실하게 다시 만들 수 있습니다.

기사 링크가 죽는 경향이 있으므로 Bazel 에 대한 Gradle Team의 의견을 요약하면 다음과 같습니다 (대부분 2015 년 3 월에 게시 된 기사에서 직접 해제).

Google 고유의 문제를 해결하도록 설계되었습니다. 거대한 모 놀리 식 코드베이스 (수백만 LOC).

Bazel이 현재 제공하는 병렬화 이점은 "다가오는 새로운 구성 및 구성 요소 모델"(기사 날짜를 염두에 두어야 함)과 일치합니다.

Bazel에는 개발자가 빌드를 쉽게 사용할 수 있도록하는 높은 수준의 선언적 빌드 언어가 없습니다. Google에서는 빌드 도구를 소유 한 전문 서비스 팀을 통해이를 보상 할 수 있습니다.

Bazel은 확장 성을 위해 구축되지 않았습니다 (Bazel 개발 팀은 확장 성을 위해 노력하고 있음을 보증하면서이를 반박했지만).

모든 전이 의존성이 하나의 큰 저장소에 저장된다는 아이디어를 중심으로 속도가 최적화됩니다. 모든 라이브러리 및 도구는이 중앙 저장소에 체크인됩니다. 대부분의 기업에는 더 많은 분산 종속성 관리 요구 사항이 있습니다.

Bazel은 * nix 전용이며 Windows에서는 실행되지 않습니다. 이것은 많은 잠재적 인 기업을 제거합니다.

플러그인 생태계가 없습니다.

Gradle은 주로 JVM 에코 시스템 (Java, Ggroovy, Scala, Kotlin ...)에서 사용됩니다. 프로젝트 가이 영역에 있고 질문을 해야하는 경우 Gradle 또는 Maven이 더 나은 선택입니다. Gradle 빌드 문제를 해결하려면 Java 및 JVM 에코 시스템 만 사용해야합니다.

Bazel의 핵심은 증분 변경 사항 (분산 빌드 캐시)을 감지하고 증분 빌드를 달성하기 위해 플러그인 / 규칙을 적용하고 반응 할 수 있도록하는 기능입니다. 이를 설정하고 유지하려면 CPP, Java 및 Python (Skylark) 및 System Admin의 지식에 대한 약간의 지식이 필요했습니다. 다시 질문을해야한다면 Gradle 또는 Maven이 더 저렴한 투자가 될 것이라고 생각합니다. Bazel을 사용하면 더 많은 언어를 정의 할 수 있고 비용은 많이 들지만 더 많은 언어를 만들 수 있습니다.