이전 페이지를 살펴보면 한 가지 주제가 반복됩니다. 자체 코드를 관리하는 것은 비교적 간단하지만 종속 항목을 관리하는 것은 훨씬 더 어렵습니다. 다양한 종속 항목이 있습니다. 때로는 작업에 종속 항목이 있고(예: '출시를 완료로 표시하기 전에 문서를 푸시해야 함') 때로는 아티팩트에 종속 항목이 있습니다(예: '코드를 빌드하려면 최신 버전의 컴퓨터 비전 라이브러리가 필요함'). 때로는 코드베이스의 다른 부분에 내부 종속 항목이 있고 때로는 조직이나 서드 파티의 다른 팀이 소유한 코드나 데이터에 외부 종속 항목이 있습니다. 하지만 어떤 경우든 '이것을 사용하려면 저것이 필요합니다'라는 아이디어는 빌드 시스템 설계에서 반복적으로 나타나며, 종속 항목 관리는 빌드 시스템의 가장 기본적인 작업일 것입니다.
모듈 및 종속 항목 처리
Bazel과 같은 아티팩트 기반 빌드 시스템을 사용하는 프로젝트는 모듈 집합으로 나뉘며, 모듈은 BUILD 파일을 통해 서로 간의 종속 항목을 표현합니다. 이러한 모듈과 종속 항목을 적절하게 구성하면 빌드 시스템의 성능과 유지관리하는 데 필요한 작업량에 큰 영향을 미칠 수 있습니다.
세밀한 모듈 및 1:1:1 규칙 사용
아티팩트 기반 빌드를 구조화할 때 가장 먼저 떠오르는 질문은 개별 모듈이 얼마나 많은 기능을 포함해야 하는지 결정하는 것입니다. Bazel에서 모듈은 java_library 또는 go_binary과 같은 빌드 가능한 단위를 지정하는 타겟으로 표현됩니다. 한쪽 끝에서는 루트에 하나의 BUILD 파일을 배치하고 해당 프로젝트의 모든 소스 파일을 재귀적으로 globbing하여 전체 프로젝트를 단일 모듈에 포함할 수 있습니다. 다른 극단적인 경우 거의 모든 소스 파일을 자체 모듈로 만들 수 있으므로 각 파일이 종속된 다른 모든 파일을 BUILD 파일에 나열해야 합니다.
대부분의 프로젝트는 이러한 극단적인 경우 사이에 있으며, 선택에는 성능과 유지관리성 간의 절충이 필요합니다. 전체 프로젝트에 단일 모듈을 사용하면 외부 종속 항목을 추가할 때를 제외하고 BUILD 파일을 터치할 필요가 없지만 빌드 시스템이 항상 전체 프로젝트를 한 번에 빌드해야 합니다. 즉, 빌드의 일부를 병렬화하거나 분산할 수 없으며 이미 빌드한 부분을 캐시할 수도 없습니다. 파일당 하나의 모듈은 그 반대입니다. 빌드 시스템은 빌드의 단계를 캐싱하고 예약하는 데 최대한의 유연성을 갖지만, 엔지니어는 어떤 파일이 어떤 파일을 참조하는지 변경할 때마다 종속 항목 목록을 유지하는 데 더 많은 노력을 기울여야 합니다.
정확한 세부사항은 언어에 따라 (그리고 언어 내에서도) 다르지만 Google은 일반적으로 작업 기반 빌드 시스템에서 작성할 수 있는 것보다 훨씬 작은 모듈을 선호합니다. Google의 일반적인 프로덕션 바이너리는 수만 개의 타겟에 종속되는 경우가 많으며, 중간 규모의 팀조차 코드베이스 내에서 수백 개의 타겟을 소유할 수 있습니다. 패키징에 관한 강력한 기본 개념이 있는 Java와 같은 언어의 경우 각 디렉터리에는 일반적으로 단일 패키지, 타겟, BUILD 파일이 포함됩니다 (Bazel을 기반으로 하는 또 다른 빌드 시스템인 Pants에서는 이를 1:1:1 규칙이라고 함). 패키징 규칙이 약한 언어는 BUILD 파일당 여러 타겟을 정의하는 경우가 많습니다.
작은 빌드 타겟의 이점은 대규모로 확장할 때 실제로 나타나기 시작합니다. 작은 빌드 타겟은 더 빠른 분산 빌드와 타겟 재빌드 필요성 감소로 이어지기 때문입니다.
테스트가 도입되면 장점이 더욱 분명해집니다. 세부적인 타겟은 빌드 시스템이 특정 변경사항의 영향을 받을 수 있는 제한된 테스트 하위 집합만 실행하는 데 훨씬 더 스마트해질 수 있음을 의미하기 때문입니다. Google은 더 작은 타겟을 사용하는 것이 시스템에 이점이 있다고 생각하므로 개발자에게 부담을 주지 않도록 BUILD 파일을 자동으로 관리하는 도구에 투자하여 단점을 완화하기 위해 노력했습니다.
buildifier, buildozer과 같은 이러한 도구 중 일부는 buildtools 디렉터리에서 Bazel과 함께 사용할 수 있습니다.
모듈 표시 최소화
Bazel 및 기타 빌드 시스템을 사용하면 각 타겟이 공개 상태를 지정할 수 있습니다. 공개 상태는 다른 타겟이 종속될 수 있는 타겟을 결정하는 속성입니다. 비공개 타겟은 자체 BUILD 파일 내에서만 참조할 수 있습니다. 타겟은 명시적으로 정의된 BUILD 파일 목록의 타겟에 더 광범위한 공개 상태를 부여하거나 공개 상태의 경우 작업공간의 모든 타겟에 공개 상태를 부여할 수 있습니다.
대부분의 프로그래밍 언어와 마찬가지로 가시성을 최대한 최소화하는 것이 좋습니다. 일반적으로 Google의 팀은 해당 타겟이 Google의 모든 팀에서 사용할 수 있는 널리 사용되는 라이브러리를 나타내는 경우에만 타겟을 공개합니다.
코드를 사용하기 전에 다른 사용자와 협력해야 하는 팀은 고객 타겟 허용 목록을 타겟의 공개 상태로 유지합니다. 각 팀의 내부 구현 타겟은 팀이 소유한 디렉터리로만 제한되며 대부분의 BUILD 파일에는 비공개가 아닌 타겟이 하나만 있습니다.
종속 항목 관리
모듈은 서로를 참조할 수 있어야 합니다. 코드베이스를 세부적인 모듈로 나누는 것의 단점은 이러한 모듈 간의 종속 항목을 관리해야 한다는 것입니다 (도구를 사용하면 이를 자동화할 수 있음). 이러한 종속성을 표현하는 것이 일반적으로 BUILD 파일의 콘텐츠 대부분을 차지합니다.
내부 종속 항목
세부적인 모듈로 나뉘어진 대규모 프로젝트에서는 대부분의 종속 항목이 내부일 가능성이 높습니다. 즉, 동일한 소스 저장소에 정의되고 빌드된 다른 타겟에 있습니다. 내부 종속 항목은 빌드를 실행하는 동안 미리 빌드된 아티팩트로 다운로드되는 대신 소스에서 빌드된다는 점에서 외부 종속 항목과 다릅니다. 또한 내부 종속 항목에는 '버전' 개념이 없습니다. 타겟과 모든 내부 종속 항목은 항상 저장소의 동일한 커밋/버전에서 빌드됩니다. 내부 종속 항목과 관련하여 신중하게 처리해야 하는 문제 중 하나는 전이 종속 항목을 처리하는 방법입니다 (그림 1). 타겟 A가 타겟 B에 종속되고 타겟 B가 공통 라이브러리 타겟 C에 종속된다고 가정해 보겠습니다. 타겟 A가 타겟 C에 정의된 클래스를 사용할 수 있어야 하나요?
그림 1. 전이 종속 항목
기본 도구에 관한 한 문제가 없습니다. B와 C는 모두 빌드 시 타겟 A에 연결되므로 C에 정의된 모든 심볼은 A에 알려져 있습니다. Bazel은 수년 동안 이를 허용했지만 Google이 성장하면서 문제가 발생하기 시작했습니다. B가 더 이상 C에 의존하지 않도록 리팩터링되었다고 가정해 보겠습니다. 그런 다음 C에 대한 B의 종속 항목이 삭제되면 B에 대한 종속 항목을 통해 C를 사용한 A 및 기타 타겟이 중단됩니다. 사실상 타겟의 종속 항목이 공개 계약의 일부가 되어 안전하게 변경할 수 없었습니다. 이로 인해 시간이 지남에 따라 종속 항목이 누적되었고 Google의 빌드 속도가 느려지기 시작했습니다.
Google은 결국 Bazel에 '엄격한 전이 종속성 모드'를 도입하여 이 문제를 해결했습니다. 이 모드에서 Bazel은 타겟이 직접 종속되지 않은 심볼을 참조하려고 하는지 감지하고, 그런 경우 오류와 종속 항목을 자동으로 삽입하는 데 사용할 수 있는 셸 명령어로 실패합니다. Google의 전체 코드베이스에 이 변경사항을 적용하고 수백만 개의 빌드 타겟을 리팩터링하여 종속 항목을 명시적으로 나열하는 데는 수년이 걸렸지만 그만한 가치가 있었습니다. 타겟에 불필요한 종속 항목이 적고 엔지니어가 종속 항목에 의존하는 타겟이 손상될까 걱정하지 않고 필요하지 않은 종속 항목을 삭제할 수 있으므로 빌드가 훨씬 빨라졌습니다.
일반적으로 엄격한 전이 종속 항목을 적용하는 데는 절충이 필요했습니다. 자주 사용되는 라이브러리를 우연히 가져오는 대신 여러 곳에 명시적으로 나열해야 하므로 빌드 파일이 더 장황해졌고 엔지니어는 BUILD 파일에 종속 항목을 추가하는 데 더 많은 노력을 기울여야 했습니다. 그 후 Google에서는 누락된 종속 항목을 자동으로 감지하고 개발자 개입 없이 BUILD 파일에 추가하여 이러한 반복 작업을 줄이는 도구를 개발했습니다. 이러한 도구가 없더라도 코드베이스가 확장됨에 따라 절충안이 충분히 가치가 있는 것으로 확인되었습니다. BUILD 파일에 종속 항목을 명시적으로 추가하는 것은 일회성 비용이지만 암시적 전이 종속 항목을 처리하면 빌드 타겟이 있는 한 지속적인 문제가 발생할 수 있습니다. Bazel은 기본적으로 Java 코드에 엄격한 임시 종속 항목을 적용합니다.
외부 종속 항목
종속 항목이 내부가 아닌 경우 외부여야 합니다. 외부 종속 항목은 빌드 시스템 외부에서 빌드되고 저장된 아티팩트의 종속 항목입니다. 종속 항목은 아티팩트 저장소 (일반적으로 인터넷을 통해 액세스)에서 직접 가져오며 소스에서 빌드하는 대신 그대로 사용됩니다. 외부 종속 항목과 내부 종속 항목의 가장 큰 차이점 중 하나는 외부 종속 항목에는 버전이 있으며 이러한 버전은 프로젝트의 소스 코드와 독립적으로 존재한다는 것입니다.
자동 종속 항목 관리와 수동 종속 항목 관리 비교
빌드 시스템에서는 외부 종속 항목의 버전을 수동 또는 자동으로 관리할 수 있습니다. 수동으로 관리하는 경우 빌드 파일은 아티팩트 저장소에서 다운로드할 버전을 명시적으로 나열하며, 1.1.4와 같은 시맨틱 버전 문자열을 사용하는 경우가 많습니다. 자동으로 관리되는 경우 소스 파일은 허용되는 버전의 범위를 지정하고 빌드 시스템은 항상 최신 버전을 다운로드합니다. 예를 들어 Gradle에서는 종속 항목의 주 버전이 1인 경우 종속 항목의 부 버전이나 패치 버전이 허용되도록 종속 항목 버전을 '1.+'로 선언할 수 있습니다.
자동으로 관리되는 종속 항목은 소규모 프로젝트에 편리할 수 있지만, 일반적으로 상당한 규모의 프로젝트나 두 명 이상의 엔지니어가 작업하는 프로젝트에서는 문제가 발생할 수 있습니다. 자동으로 관리되는 종속 항목의 문제는 버전이 업데이트되는 시점을 제어할 수 없다는 것입니다. 외부 당사자가 호환성이 깨지는 업데이트를 하지 않는다고 주장하더라도 (의미론적 버전 관리를 사용한다고 주장하는 경우에도) 이를 보장할 방법이 없으므로, 하루는 작동하던 빌드가 다음 날에는 작동하지 않을 수 있으며 변경사항을 감지하거나 작동하는 상태로 롤백하는 쉬운 방법이 없습니다. 빌드가 중단되지 않더라도 추적할 수 없는 미묘한 동작이나 성능 변화가 있을 수 있습니다.
반면 수동으로 관리되는 종속 항목은 소스 제어의 변경이 필요하므로 쉽게 검색하고 롤백할 수 있으며 저장소의 이전 버전을 체크아웃하여 이전 종속 항목으로 빌드할 수 있습니다. Bazel에서는 모든 종속 항목의 버전을 수동으로 지정해야 합니다. 적당한 규모에서도 수동 버전 관리의 오버헤드는 제공되는 안정성에 비해 충분히 가치가 있습니다.
단일 버전 규칙
라이브러리의 서로 다른 버전은 일반적으로 서로 다른 아티팩트로 표현되므로 이론적으로는 동일한 외부 종속 항목의 서로 다른 버전이 빌드 시스템에서 서로 다른 이름으로 선언되지 않을 이유가 없습니다. 이렇게 하면 각 타겟이 사용할 종속 항목 버전을 선택할 수 있습니다. 실제로 이로 인해 많은 문제가 발생하므로 Google은 코드베이스의 모든 서드 파티 종속 항목에 대해 엄격한 단일 버전 규칙을 적용합니다.
여러 버전을 허용할 때 가장 큰 문제는 다이아몬드 종속성 문제입니다. 타겟 A가 타겟 B와 외부 라이브러리의 v1에 종속된다고 가정해 보겠습니다. 나중에 타겟 B가 동일한 외부 라이브러리의 v2에 종속되도록 리팩터링되면 타겟 A는 이제 동일한 라이브러리의 두 가지 다른 버전에 암시적으로 종속되므로 중단됩니다. 효과적으로 타겟에서 여러 버전이 있는 서드 파티 라이브러리로 새 종속 항목을 추가하는 것은 안전하지 않습니다. 타겟의 사용자가 이미 다른 버전에 종속되어 있을 수 있기 때문입니다. 단일 버전 규칙을 따르면 이 충돌이 불가능합니다. 타겟이 서드 파티 라이브러리에 대한 종속 항목을 추가하는 경우 기존 종속 항목은 이미 동일한 버전에 있으므로 함께 사용할 수 있습니다.
전이 외부 종속 항목
외부 종속 항목의 트랜지티브 종속 항목을 처리하는 것은 특히 어려울 수 있습니다. Maven Central과 같은 많은 아티팩트 저장소에서는 아티팩트가 저장소에 있는 다른 아티팩트의 특정 버전에 대한 종속 항목을 지정할 수 있습니다. Maven이나 Gradle과 같은 빌드 도구는 기본적으로 각 전이 종속 항목을 재귀적으로 다운로드하는 경우가 많습니다. 즉, 프로젝트에 단일 종속 항목을 추가하면 총 수십 개의 아티팩트가 다운로드될 수 있습니다.
이는 매우 편리합니다. 새 라이브러리의 종속 항목을 추가할 때 해당 라이브러리의 전이 종속 항목을 각각 추적하고 모두 수동으로 추가해야 하는 것은 매우 고통스러운 일입니다. 하지만 큰 단점도 있습니다. 서로 다른 라이브러리가 동일한 서드 파티 라이브러리의 서로 다른 버전에 종속될 수 있으므로 이 전략은 필연적으로 단일 버전 규칙을 위반하고 다이아몬드 종속성 문제를 야기합니다. 타겟이 동일한 종속성의 다른 버전을 사용하는 두 개의 외부 라이브러리에 종속된 경우 어떤 버전을 가져올지 알 수 없습니다. 또한 새 버전이 일부 종속 항목의 충돌하는 버전을 가져오기 시작하면 외부 종속 항목을 업데이트할 때 코드베이스 전체에서 관련이 없는 것처럼 보이는 오류가 발생할 수 있습니다.
이러한 이유로 Bazel은 전이 종속 항목을 자동으로 다운로드하지 않습니다.
안타깝게도 만능 해결책은 없습니다. Bazel의 대안은 저장소의 모든 외부 종속 항목과 저장소 전체에서 해당 종속 항목에 사용되는 명시적 버전을 나열하는 전역 파일을 요구하는 것입니다. 다행히 Bazel은 Maven 아티팩트 집합의 트랜시티브 종속 항목을 포함하는 파일을 자동으로 생성할 수 있는 도구를 제공합니다. 이 도구를 한 번 실행하여 프로젝트의 초기 WORKSPACE 파일을 생성할 수 있으며, 이 파일을 수동으로 업데이트하여 각 종속 항목의 버전을 조정할 수 있습니다.
여기에서도 편의성과 확장성 중에서 선택해야 합니다. 소규모 프로젝트에서는 전환 종속 항목 관리에 신경 쓰지 않아도 되는 것을 선호할 수 있으며 자동 전환 종속 항목을 사용해도 괜찮을 수 있습니다. 이 전략은 조직과 코드베이스가 커질수록 매력이 떨어지고 충돌과 예상치 못한 결과가 점점 더 자주 발생합니다. 규모가 커지면 종속 항목을 수동으로 관리하는 비용이 자동 종속 항목 관리로 인해 발생하는 문제를 처리하는 비용보다 훨씬 적습니다.
외부 종속 항목을 사용하여 빌드 결과 캐싱
외부 종속 항목은 라이브러리의 안정적인 버전을 출시하는 서드 파티에서 제공하는 경우가 가장 많으며, 소스 코드를 제공하지 않을 수도 있습니다. 일부 조직에서는 자체 코드를 아티팩트로 제공하여 다른 코드에서 내부 종속 항목이 아닌 서드 파티 종속 항목으로 사용할 수 있도록 할 수도 있습니다. 아티팩트 빌드가 느리지만 다운로드가 빠른 경우 이론적으로 빌드 속도를 높일 수 있습니다.
하지만 이로 인해 많은 오버헤드와 복잡성이 발생합니다. 누군가 이러한 각 아티팩트를 빌드하고 아티팩트 저장소에 업로드해야 하며 클라이언트는 최신 버전을 유지해야 합니다. 또한 시스템의 여러 부분이 저장소의 서로 다른 지점에서 빌드되고 소스 트리의 일관된 뷰가 더 이상 없기 때문에 디버깅이 훨씬 더 어려워집니다.
아티팩트 빌드에 시간이 오래 걸리는 문제를 해결하는 더 나은 방법은 앞에서 설명한 대로 원격 캐싱을 지원하는 빌드 시스템을 사용하는 것입니다. 이러한 빌드 시스템은 모든 빌드에서 생성된 아티팩트를 엔지니어 간에 공유되는 위치에 저장하므로 개발자가 다른 사용자가 최근에 빌드한 아티팩트를 사용하는 경우 빌드 시스템은 아티팩트를 빌드하는 대신 자동으로 다운로드합니다. 이렇게 하면 아티팩트에 직접 종속되는 모든 성능 이점을 제공하면서도 항상 동일한 소스에서 빌드되는 것처럼 빌드가 일관되게 유지됩니다. 이는 Google에서 내부적으로 사용하는 전략이며 Bazel은 원격 캐시를 사용하도록 구성할 수 있습니다.
외부 종속 항목의 보안 및 안정성
서드 파티 소스의 아티팩트에 의존하는 것은 본질적으로 위험합니다. 서드 파티 소스 (예: 아티팩트 저장소)가 다운되면 외부 종속 항목을 다운로드할 수 없는 경우 전체 빌드가 중단될 수 있으므로 가용성 위험이 있습니다. 보안 위험도 있습니다. 서드 파티 시스템이 공격자에게 침해되면 공격자가 참조된 아티팩트를 자체 설계로 대체하여 빌드에 임의의 코드를 삽입할 수 있습니다. 두 문제 모두 의존하는 아티팩트를 제어하는 서버에 미러링하고 빌드 시스템이 Maven Central과 같은 서드 파티 아티팩트 저장소에 액세스하지 못하도록 차단하여 완화할 수 있습니다. 이러한 미러는 유지하는 데 노력과 리소스가 필요하므로 미러 사용 여부는 프로젝트 규모에 따라 달라집니다. 각 서드 파티 아티팩트의 해시를 소스 저장소에 지정하도록 요구하여 보안 문제를 완전히 방지할 수도 있습니다. 이렇게 하면 아티팩트가 조작된 경우 빌드가 실패합니다. 문제를 완전히 피하는 또 다른 대안은 프로젝트의 종속 항목을 벤더링하는 것입니다. 프로젝트가 종속 항목을 벤더링하면 소스 또는 바이너리로 프로젝트의 소스 코드와 함께 소스 제어에 체크인합니다. 이는 프로젝트의 모든 외부 종속 항목이 내부 종속 항목으로 변환된다는 의미입니다. Google은 이 접근 방식을 내부적으로 사용하여 Google 소스 트리의 루트에 있는 third_party 디렉터리에 Google 전반에서 참조되는 모든 서드 파티 라이브러리를 확인합니다. 하지만 이는 Google의 소스 관리 시스템이 매우 큰 모노레포를 처리하도록 맞춤 빌드되었기 때문에 Google에서만 작동하며, 모든 조직에서 벤더링이 옵션이 아닐 수 있습니다.