궁금한 점이 있거나 지원이 필요한 경우 도움말 보기를 참고하세요.
Bazel이란 무엇인가요?
Bazel은 소프트웨어 빌드 및 테스트를 자동화하는 도구입니다. 지원되는 빌드 작업에는 실행 가능한 프로그램 및 라이브러리 생성을 위한 컴파일러 및 링커 실행, Android, iOS 및 기타 대상 환경을 위한 배포 가능한 패키지 조합 등이 포함됩니다. Bazel은 Make, Ant, Gradle, Buck, Pants, Maven과 같은 다른 도구와 유사합니다.
Bazel의 특별한 점은 무엇인가요?
Bazel은 Google에서 소프트웨어를 개발하는 방식에 맞게 설계되었습니다. 다음과 같은 기능이 있습니다.
- 다국어 지원: Bazel은 여러 언어를 지원하며 임의의 프로그래밍 언어를 지원하도록 확장될 수 있습니다.
- 상위 수준 빌드 언어: 프로젝트는
BUILD언어로 설명됩니다. 이 언어는 프로젝트를 상호 연결된 작은 라이브러리, 바이너리, 테스트 집합으로 설명하는 간결한 텍스트 형식입니다. 반면, Make와 같은 도구를 사용하면 개별 파일과 컴파일러 호출을 설명해야 합니다. - 멀티 플랫폼 지원: 동일한 도구와 동일한
BUILD파일을 사용하여 다양한 아키텍처와 플랫폼에 맞는 소프트웨어를 빌드할 수 있습니다. Google에서는 Bazel을 사용하여 데이터 센터의 시스템에서 실행되는 서버 애플리케이션에서 휴대전화에서 실행되는 클라이언트 앱에 이르기까지 모든 것을 구축합니다. - 재현성:
BUILD파일에서 각 라이브러리, 테스트 및 바이너리는 직접 종속 항목을 완전히 지정해야 합니다. Bazel은 이 종속 항목 정보를 사용하여 소스 파일을 변경할 때 다시 빌드해야 하는 항목과 병렬로 실행할 수 있는 작업을 파악합니다. 즉, 모든 빌드가 증분되며 항상 동일한 결과를 생성합니다. - 확장성: Bazel은 대규모 빌드를 처리할 수 있습니다. Google에서 서버 바이너리에 10만 개의 소스 파일이 있는 것이 일반적이며, 파일이 변경되지 않은 빌드에는 약 200ms 정도 걸립니다.
Google이 다음 기능을 사용하지 않는 이유는 무엇인가요?
- Make, 닌자: 이 도구는 파일을 빌드하기 위해 호출되는 명령을 매우 정확하게 제어할 수 있게 해주지만 올바른 규칙을 작성하는 것은 사용자의 몫입니다.
- 사용자는 더 높은 수준에서 Bazel과 상호작용합니다. 예를 들어 Bazel에는 '자바 테스트', 'C++ 바이너리'에 대한 기본 규칙, '타겟 플랫폼', '호스트 플랫폼'과 같은 개념이 있습니다. 이러한 규칙은 완벽한지 확인할 수 있도록 철저한 테스트를 거쳤습니다.
- Ant 및 Maven: Ant와 Maven은 주로 Java에 맞춰져 있는 반면, Bazel은 여러 언어를 처리합니다. Bazel은 코드베이스를 재사용 가능한 더 작은 단위로 세분화할 것을 권장하며 다시 빌드해야 하는 단위만 다시 빌드할 수 있습니다. 더 큰 코드베이스로 작업할 때 개발 속도가 빨라집니다.
- Gradle: Bazel 구성 파일은 Gradle의 구성 파일보다 훨씬 더 구조화되어 있어 Bazel이 각 작업의 역할을 정확히 이해할 수 있습니다. 이렇게 하면 동시 로드가 늘어나고 재현성이 향상됩니다.
- 바지, 벅: 두 도구 모두 트위터와 Foursquare, Facebook에서 각각 이전 Google 직원이 만들고 개발했습니다. Bazel을 모델링했지만 특성 세트가 다르기 때문에 현실적인 대안이 아닙니다.
Bazel은 어디에서 왔을까요?
Bazel은 Google이 서버 소프트웨어를 내부적으로 빌드하는 데 사용하는 도구의 버전입니다. Google 서버에 연결되는 모바일 앱 (iOS, Android) 등 다른 소프트웨어도 빌드하도록 확장되었습니다.
내부 도구를 오픈소스로 다시 작성했나요? 포크인가요?
Bazel은 대부분의 코드를 내부 도구와 공유하며 Bazel의 규칙은 매일 수백만 개의 빌드에 사용됩니다.
Google이 Bazel을 만든 이유는 무엇인가요?
오래 전 Google은 생성된 대용량 Makefile을 사용해 소프트웨어를 빌드했습니다. 이로 인해 빌드 속도가 느리고 불안정하여 개발자의 생산성과 회사의 민첩성이 저해되기 시작했습니다. Bazel은 이러한 문제를 해결하는 방법이었습니다.
Bazel에 빌드 클러스터가 필요한가요?
Bazel은 기본적으로 빌드 작업을 로컬에서 실행합니다. 하지만 Bazel은 빌드 및 테스트를 훨씬 더 빠르게 수행하기 위해 빌드 클러스터에 연결할 수도 있습니다. 자세한 내용은 원격 실행 및 캐싱과 원격 캐싱에 관한 문서를 참고하세요.
Google 개발 프로세스는 어떻게 진행되나요?
서버 코드베이스의 경우 다음과 같은 개발 워크플로를 사용합니다.
- 모든 서버 코드는 거대한 단일 버전 제어 시스템에 있습니다.
- 모두가 Bazel을 사용하여 소프트웨어를 빌드합니다.
- 각 팀이 소스 트리의 여러 부분을 소유하고 구성요소를
BUILD타겟으로 제공합니다. - 브랜치는 주로 출시 관리에 사용되므로 모든 사용자가 헤드 수정 단계에서 소프트웨어를 개발합니다.
Bazel은 이 철학의 초석입니다. Bazel은 모든 종속 항목을 완전히 명시해야 하기 때문에 어떤 프로그램과 테스트가 변경사항의 영향을 받는지 예측하고 제출하기 전에 심사할 수 있습니다.
Google의 개발 프로세스에 대한 자세한 배경 정보는 eng 도구 블로그에서 확인할 수 있습니다.
Bazel을 왜 열었나요?
소프트웨어 빌드는 재미있고 쉬워야 합니다. 느리고 예측할 수 없는 빌드는 프로그래밍의 재미를 떨어뜨립니다.
Bazel을 사용해야 하는 이유는 무엇인가요?
- Bazel을 사용하면 다시 컴파일해야 하는 파일만 다시 컴파일할 수 있으므로 빌드 시간이 더 빨라질 수 있습니다. 마찬가지로 변경되지 않은 것으로 알려진 테스트의 재실행도 건너뛸 수 있습니다.
- Bazel은 확정적 결과를 냅니다. 이렇게 하면 증분 빌드와 클린 빌드, 노트북, CI 시스템 간 편향이 사라집니다.
- Bazel은 동일한 작업공간에서 동일한 도구를 사용하여 서로 다른 클라이언트 앱과 서버 앱을 빌드할 수 있습니다. 예를 들어, 단일 커밋에서 클라이언트/서버 프로토콜을 변경하고 업데이트된 모바일 앱이 업데이트된 서버에서 작동하는지 테스트하여 두 가지 모두 동일한 도구로 빌드하여 앞서 언급한 Bazel의 이점을 모두 누릴 수 있습니다.
예시를 볼 수 있나요?
예. 간단한 예시를 참고하거나 더 복잡한 예시는 Bazel 소스 코드를 참고하세요.
Bazel이 가장 잘하는 것은 무엇입니까?
Bazel은 다음과 같은 속성을 사용하여 프로젝트를 빌드하고 테스트하는 데 주력하고 있습니다.
- 대규모 코드베이스가 있는 프로젝트
- (여러) 컴파일된 언어로 작성된 프로젝트
- 여러 플랫폼에 배포되는 프로젝트
- 광범위한 테스트가 포함된 프로젝트
Bazel을 실행할 수 있는 곳은 어디인가요?
Bazel은 Linux, macOS (OS X), Windows에서 실행됩니다.
다른 UNIX 플랫폼으로의 포팅은, 플랫폼에 JDK를 사용할 수 있는 한 비교적 쉽습니다.
Bazel을 사용하면 안 되는 것은 무엇인가요?
- Bazel은 캐싱을 현명하게 만들려고 합니다. 즉, 출력이 캐시되면 안 되는 빌드 작업을 실행하는 데는 적합하지 않습니다. 예를 들어 다음 단계는 Bazel에서 실행하면 안 됩니다.
- 인터넷에서 데이터를 가져오는 컴파일 단계
- 사이트의 품질보증 인스턴스에 연결하는 테스트 단계입니다.
- 사이트의 클라우드 구성을 변경하는 배포 단계
- 빌드가 몇 가지의 긴 순차적 단계로 구성된 경우 Bazel이 많은 도움이 되지 못할 수 있습니다. 긴 걸음 수를 Bazel이 동시에 실행할 수 있는 더 작은 별개의 대상으로 나누면 더 빠른 속도를 얻을 수 있습니다.
Bazel의 특성 세트는 얼마나 안정적인가요?
핵심 기능 (C++, Java, 셸 규칙)은 Google 내에서 광범위하게 사용되므로 철저한 테스트를 거쳤으며 이탈이 거의 발생하지 않습니다. 마찬가지로 매일 수십만 개의 타겟에서 새 버전의 Bazel을 테스트하여 회귀를 찾고 새 버전을 매월 여러 번 출시합니다.
간단히 말해, 실험용으로 표시된 기능을 제외하면 Bazel은 Just Work가 되어 줄 것입니다. 실험 대상이 아닌 규칙의 변경사항은 이전 버전과 호환됩니다. 기능 지원 상태의 자세한 목록은 지원 문서에서 확인할 수 있습니다.
Bazel이 바이너리로서 얼마나 안정적인가요?
Google 내에서 Bazel 비정상 종료가 매우 드물게 발생하는지 확인합니다. 이는 오픈소스 코드베이스에도 적용되어야 합니다.
Bazel 사용을 시작하려면 어떻게 해야 하나요?
시작하기를 참고하세요.
Docker는 재현성 문제를 해결하지 않나요?
Docker를 사용하면 Ubuntu 12.04, Fedora 21과 같은 고정 OS 릴리스로 샌드박스를 쉽게 만들 수 있습니다. 이 방법은 "어떤 버전의 /usr/bin/c++가 필요한가요?"와 같은 시스템 환경의 재현성 문제를 해결합니다.
Docker는 소스 코드 변경과 관련된 재현성을 해결하지 않습니다. Docker 컨테이너 내에서 불완전하게 작성된 Makefile로 Make를 실행하면 여전히 예기치 않은 결과가 발생할 수 있습니다.
Google 내부에서는 재현 가능성을 위해 도구를 소스 제어에 확인합니다. 이런 식으로 기본 라이브러리 변경사항('OpenSSL의 경계 검사 수정')과 동일한 메커니즘으로 도구 변경사항('GCC를 4.6.1로 업그레이드')을 검사할 수 있습니다.
Docker에 배포할 바이너리를 빌드할 수 있나요?
Bazel을 사용하면 정적으로 링크된 C/C++ 독립 실행형 바이너리와 Java용 자체 포함 jar 파일을 빌드할 수 있습니다. 이는 일반 UNIX 시스템에 대한 종속 항목이 거의 없이 실행되므로 Docker 컨테이너 내에 간단히 설치할 수 있어야 합니다.
Bazel에는 데이터 파일 세트를 사용하거나 다른 프로그램을 하위 프로세스로 실행하는 Java 프로그램과 같이 더 복잡한 프로그램을 구조화하기 위한 규칙이 있습니다. 이러한 환경을 독립형 보관 파일로 패키징하여 Docker 이미지를 비롯한 여러 시스템에 배포할 수 있습니다.
Bazel을 사용하여 Docker 이미지를 빌드할 수 있나요?
예. Docker 규칙을 사용하면 재현 가능한 Docker 이미지를 빌드할 수 있습니다.
Bazel이 내 빌드를 자동으로 재현 가능하게 하나요?
자바 및 C++ 바이너리는 가능합니다(도구 모음을 변경하지 않는다고 가정). 사용자 지정 레시피가 포함된 빌드 단계가 있는 경우 (예: 규칙 내에서 셸 스크립트를 통해 바이너리 실행) 다음과 같은 몇 가지 주의를 기울여야 합니다.
- 선언되지 않은 종속 항목은 사용하지 마세요. 샌드박스 실행 (–spawn_strategy=sandboxed, Linux에서만 해당)은 선언되지 않은 종속 항목을 찾는 데 도움이 될 수 있습니다.
- 생성된 파일에 타임스탬프와 user-ID를 저장하지 않습니다. ZIP 파일 및 기타 보관 파일에서 특히 이런 문제가 발생할 수 있습니다.
- 네트워크에 연결하지 마세요. 여기에도 샌드박스 실행이 도움이 될 수 있습니다.
- 랜덤 숫자를 사용하는 프로세스를 피하세요. 특히 사전 순회는 많은 프로그래밍 언어에서 무작위로 이루어집니다.
바이너리 출시 버전이 있나요?
예. 최신 출시 바이너리를 찾고 출시 정책을 검토하세요.
Eclipse/IntelliJ/XCode를 사용합니다. Bazel은 IDE와 어떻게 상호 운용되나요?
IntelliJ의 경우 Bazel 플러그인이 있는 IntelliJ를 확인하세요.
XCode에 관해서는 Tulsi를 확인하세요.
Eclipse의 경우 E4B 플러그인을 확인하세요.
다른 IDE는 이러한 플러그인의 작동 방식에 관한 블로그 게시물을 참고하세요.
Jenkins/CircleCI/TravisCI를 사용하고 있습니다. Bazel은 CI 시스템과 어떻게 상호 운용되나요?
빌드 또는 테스트 호출이 실패하면 Bazel이 0이 아닌 종료 코드를 반환하며 이는 기본 CI 통합에 충분합니다. Bazel은 정확성을 위해 클린 빌드가 필요하지 않으므로 빌드/테스트 실행을 시작하기 전에 CI 시스템을 정리하도록 구성해서는 안 됩니다.
종료 코드에 대한 자세한 내용은 사용자 설명서를 참조하세요.
Bazel에서 향후 어떤 기능을 기대할 수 있을까요?
로드맵을 참고하세요.
INSERT LANGUAGE HERE 프로젝트에 Bazel을 사용할 수 있나요?
Bazel은 확장 가능합니다. 누구나 새로운 언어에 대한 지원을 추가할 수 있습니다. 여러 언어가 지원됩니다. 빌드 백과사전에서 권장사항 목록을, awesomebazel.com에서 더 자세한 목록을 확인하세요.
확장 프로그램을 개발하거나 작동 방식을 알아보려면 Bazel 확장 문서를 참조하세요.
Bazel 코드베이스에 기여할 수 있나요?
참여 가이드라인을 참고하세요.
모든 개발이 개방형 환경에서 이루어지지 않는 이유는 무엇인가요?
여전히 Bazel의 공개 코드와 내부 확장 프로그램 간의 인터페이스를 자주 리팩터링해야 합니다. 이로 인해 공개 상태에서 많은 개발을 수행하기가 어렵습니다.
Bazel을 오픈소스로 제공했나요?
Bazel을 오픈소스로 제공하는 것은 진행 중인 작업입니다. 특히 Google은 계속해서 오픈소스를 제공하기 위해 노력하고 있습니다.
- 많은 단위 및 통합 테스트 (패치 기여를 더 쉽게 할 수 있음)
- 완전한 IDE 통합
코드 외에도 Bazel 커뮤니티와 함께 모든 코드 검토, 버그 추적, 설계 결정이 공개적으로 이루어지기를 바랍니다. 아직 거기에 있지 않으므로 일부 변경사항은 명확한 설명 없이 단순히 Bazel 저장소에 표시됩니다. 이러한 투명성 부족에도 불구하고 Google은 외부 개발자를 지원하고 협업하고자 합니다. 따라서 일부 개발이 아직 Google 내부에서 진행되고 있음에도 불구하고 코드를 공개하고 있습니다. 공개 모델로 전환하는 과정에서 명확하지 않거나 부당한 점이 있으면 알려주시기 바랍니다.
Bazel에는 결코 오픈소스로 제공되지 않는 부분이 있습니까?
예. 일부 코드베이스는 Google 고유의 기술과 통합되거나 이 둘을 조합할 수 있는 변명의 여지가 있습니다. 코드베이스의 이러한 부분은 GitHub에서 사용할 수 없으며 앞으로도 없을 것입니다.
지원팀에 연락하려면 어떻게 해야 하나요?
bazel-discuss@googlegroups.com으로 문의하시면 됩니다.
버그는 어디에 보고해야 하나요?
GitHub에서 문제를 엽니다.
코드베이스에 'Blaze'라는 단어는 무슨 문제가 있나요?
도구의 내부 이름입니다. Bazel을 Bazel로 언급하세요.
다른 Google 프로젝트 (Android, Chrome)에서 다른 빌드 도구를 사용하는 이유는 무엇인가요?
첫 번째 (알파) 릴리스까지는 Bazel을 외부에서 사용할 수 없었습니다. 따라서 Chromium 및 Android와 같은 오픈소스 프로젝트에서는 Bazel을 사용할 수 없었습니다. 또한 원래 Windows에 대한 지원이 부족했던 것도 Chrome과 같은 Windows 애플리케이션을 빌드하는 데 문제가 되었습니다. 프로젝트가 성숙하고 안정화되어 이제 Android 오픈소스 프로젝트를 Bazel로 이전하는 중입니다.
'Bazel'을 어떻게 발음해?
미국 영어의 'basil'(허브)과 같은 뜻으로, 'BAY-zel'은 'hazel'과 운율을 따릅니다. IPA: /;">bepez조정 모음/