Part IV 도구

CHAPTER 16 버전 관리와 브랜치 관리

버전 관리 시스템은 가장 널리 쓰이는 소프트웨어 엔지니어링 도구

트렁크 기반 개발(Trunk-Based Development)이 확장성이 뛰어나기에 그 이유와 함깨 몇가지 제안

VCS(Version Control System)은 파일의 시간에 따른 변경 기록을 추적하는 시스템
합의된 단일 진실 공급원(Single Source of Truth)을 제공

버전관리는 디지털 협업이라는 새로운 업무방싱을 발전시키는 과정에서 함께 진화했다

소프트웨어 엔지니어링은 프로그래밍에 시간의 흐름을 통합한 개념이다
소스 코드 생성과 제품을 장기간 지속 관리하는것은 다르게 보고 있다

버전을 관리하려면 비용이 든다 하지만 이 비용은 아주 저렴하다

중앙집중형 VCS
- 단 하나의 중앙 리포지터리를 이용하는 모델
- CVS, Subversion
분산형 VCS
- 각 개발자가 자신의 로컬 리포지터리를 가지고 중앙 리포지터리와 동기화하는 모델
- Git, Mercurial
진실 공급원
- 중앙집중형 VCS는 진싱 공급원이라는 개념을 사용한다
- 분산형 VCS는 진실 공급원이라는 개념을 사용하지 않는다
  버전 관리 VS 의존성 관리
  차이점
VCS는 주로 코드를 어떻게 관리할지를 다루고 대체로 훨씬 세세하게 관리
의존성 관리는 훨씬 어렵다 다른 조직에서 통제하는 프로젝트들을 관리해야 하기 때문

상이한 버전들을 관리하는 방식을 통틀어 관리 방식을 통틀어 브랜치 관리가고 한다

진행 중인 작업은 브랜치와 비슷하다
개발 브랜치
- 구현은 다했지만 커멋하지 않았어요 와 이제부터 이코드 기준으로 개발하세요의 중간단계
- 개발 브랜치에 의존하는 방식은 확장하는 한계가 있다
릴리즈 브랜치
- 하루에도 몇번씩 릴리스할 수 있는 지속적 배포가 잘 자리 잡은 조직에서는 대체로 릴리스 브랜치를 건너 뛴다

구글의 소스 코드 대부분은 하나의 리포지터리 즉 모노리포에서 관리 됨

원 버전
- 모든 의존성의 우리 리포지터리에 담겨 있고 각 의존성은 단하나의 안정된 버전만 존재해야 됨
시나리오 여러 버전을 허용한다면
- 여러 버전에 의존하더라고 실행 파일이 올바르게 작동되도록 해주는 트릭이 사용된다(쉐이딩)
원버전 규칙
- 개발자가 이 구성요소는 어떤 버전을 사용해야 하죠?라고 묻는 상황을 만들지 않아야 된다
장수 브랜치는 웬만하면 금지
- 빌드 호라이즌 정책
- 프로덕션 환경에서 구동 중인 모든 제품은 최대 6개월 안에 다시 빌드해야 재배포 해야 됨
릴리즈 브런치는?
- 많은 팀이 릴리즈 브랜치를 이용하고 최소한의 수정만 반영한다

모노리포의 장점