라이브러리 버전관리, 더이상 buildSrc로 사용하지 마세요(feat. Catalog) | 헤이딜러 기술블로그
여러개의 앱과 서브모듈로 라이브러리를 관리하고 계신가요?
그렇다면 Gradle Catalog로 새로운 의존성 관리를 시작해 보세요.
안녕하세요.
헤이딜러 안드로이드팀의 윤영직입니다.
최근, 한 개 이상의 앱을 개발하고 유지보수 하는 팀이 늘어나고 있습니다.
그리고 개발자들은 항상 같은 고민을 합니다.
“코드를 여러 앱에서 재사용 할 수 없을까?”
헤이딜러에서도 마찬가지로 여러가지 앱을 동시에 개발하고 있습니다.
그렇기 때문에 각 앱과 공통으로 사용 가능한 모듈을 분리하여 관리하고 있습니다.
- 하나의 앱이 하나의 레포지터리를 가진다.
- 라이브러리 레포지터리는 공통 모듈을 가진다.
- 앱은 라이브러리 레포지터리를 서브 모듈로 가진다.
모듈을 분리하고 나면 개발자는 다음 고민에 빠집니다.
“버전과 의존성을 어떻게 관리할 수 있을까?”
저희도 역시 같은 고민을 가졌고,
build.gradle의 ext를 이용해서 이 문제를 해결하고 있었습니다.
그러던 중 점차 gradle kts + buildSrc를 이용한 의존성 관리가 유행하기 시작 했습니다.
하지만 저희는 이 방법을 바로 적용할 수 없었습니다.
gradle kts 마이그레이션 비용이 막대했고 공통으로 사용하기 위한 코드가 서브모듈에 위치해서 buildSrc를 공유할 수 없기 때문입니다.
어쩔 수 없이 기존 방법을 사용하면서 인터넷을 둘러보던 중…
Gradle의 Catalog라는 새로운 기능이 여러개의 프로젝트간에 버전을 공유하는 방법으로 소개되고 있었습니다.
궁금한건 못참는 저희 안드로이드 팀은 바로 테스트에 나섰고
결과적으로 기존 ext를 이용한 방법보다 의존성과 버전을 더욱 효율적으로 관리할 수 있었습니다.
어떤 이유로 Catalog로 넘어갔는지 말씀드리기 전에
어떤 차이가 있는지 한 번 살펴볼까요?
NOTE:
본 포스팅에서는 Catalog에 대한 자세한 설명은 다루지 않습니다.
자세한 설명과 사용 방법은 Gradle 문서에서 확인하실 수 있습니다.
TL;DR
샘플 코드와 gradle-kts는 다음 Github 프로젝트에서 먼저 확인 가능합니다.
STEP 1 | Library ext 를 toml로 옮기기
먼저ext.deps ext.versions 코드를 toml에 추가합니다.
공통으로 사용하기 위한 의존성을 정의합니다.
STEP 2 | App toml 재정의 하기 (Optional)
app에서 사용하고 있는 의존성 버전을 변경해야 할 때가 있습니다.
동일한 방식으로 app 모듈에서 재정의 하기 위한 toml 파일을 추가합니다.
STEP 3 | Catalog 적용하기
우선 settings.gradle에 Catalog 사용을 위한 설정을 추가합니다.
먼저 선언한 toml의 버전이 가장 높은 우선순위를 가집니다.
다음으로 build.gradle에 추가하고 싶은 의존성을 선언합니다.bundles는 gradle BOM 프로젝트와 유사한 방식으로 toml에 정의한 의존성을 일괄적으로 추가하면 끝입니다.
실제 의존성을 추가하는 build.gradle 코드는 이전 방식과 큰 차이가 없는 것을 볼 수 있습니다.
또한 buildSrc에서 Kotlin Object로 처리하던 방식보다 가독성 면에서 더욱 유리합니다.
Gradle Catalog로 넘어간 이유
- toml을 이용해 의존성 선언을 명시적으로 분리
- groovy나 kts보다 좋은 가독성
- 프로젝트가 분리되어 있어도 동일한 toml을 가져와서 바로 사용할 수 있음
- bundles와 같은 Catalog만의 매력적인 기능
- toml을 이용하면 마이그레이션이 상당히 쉬움
- …
Catalog는 앞서 설명한 장점 외에도 정말 많은 기능을 지원하고 있습니다.
저희와 비슷한 고민을 가지고 계신 분들이라면 지금이 바로
Catalog를 도입 해 볼 기회입니다.😊
언제나 그렇듯 작성한 코드가 완벽한 정답이라고 생각하지 않습니다.
이 주제와 관련되어 보다 좋은 구조나 의견이 있으시다면 댓글로 남겨주세요.
감사합니다.
