Git 저장소 배포 이력을 태그 대신 커밋 체인으로 관리하자는 제안
- ZipRecruiter 모노레포에서 배포할 때마다 태그 객체가 하나씩 생겨 수천 개가 쌓였고, 그 결과 packed-refs 파일 검색이 느려짐
- 현재 방식으로 특정 앱의 최근 프로덕션 배포 시점을 알려면 전체 태그 목록을 받아 필터링하고 날짜순으로 정렬해야 함
- 제안은 (tier, app) 쌍마다 ref 하나만 두고, 릴리스 커밋을 두 번째 부모로 가지는 메타정보 커밋을 이전 메타정보 커밋과 연결하는 구조임
- 태그는 언제든 삭제하고 다시 만들 수 있어서 불변 기록으로 쓰기 어렵다는 점도 지적함
- 작성자는 이 방식이 채택되지 않았고 예상하지 못한 단점이 있을 수 있다고 밝힘
Hacker News opinions
환경 이름을 버전 태그에 넣는 건 별로 좋은 생각 아닌 듯. dev, stg, prod가 같은 커밋을 가리키길 바라는 수밖에 없음. 그냥 버전 번호 태그 하나 찍고, 환경별 리비전은 텍스트 파일로 따로 관리하는 게 낫더라.
ref를 trie에 저장하면 쉽게 해결될 것 같은데, 하위 호환이 골칫거리임. 아니면 ref 이름을 정렬해두는 방법도 있고.
릴리스랑 배포를 분리해야 함. 코드에 버전 라벨 하나 붙이고 아티팩트는 한 번만 만들고, 배포 때 어떤 버전 쓸지 정하면 됨. 환경 차이는 빌드 타임 말고 환경변수 같은 런타임에서 처리하는 게 예측하기 쉬움.
git tag는 실제 배포가 일어났다는 걸 말해주지 않음. 기껏해야 배포 시도 정도임. 실제 배포를 추적하고 누가 어디에 뭘 배포했는지 기록하는 CD 도구를 쓰면 안 되나?
저장소에 배포 이력을 넣는 건 안 맞다고 봄. 'a1b2c3d 커밋이 환경 X에 이 시각에 배포됨' 정보만 있으면 되고, 그건 배포 도구가 저장하면 됨. 커밋은 어디에 배포되든 그대로 존재함.
모노레포 얘기 나오면 이런 문제가 생겼다는 말이 너무 흔함. 푸는 문제보다 만드는 문제가 더 많은 것 같음.