핏펫몰 개발 스쿼드의 git 전략 연대기

암흑의 시대

체계 없이 개발하던 시절

계몽의 시대

체계를 만들어가다. 다니엘 호도비에츠키 1791년 작
Author: Rowan Haddad, Original blog post
  1. 우리가 테스트에 사용하는 알파/스테이징 서버 테스트 방법과 맞지 않음
  2. main에 테스트가 완료되지 않은 feature 브랜치가 머지될 수 있음
Author: Vincent Driessen, Original blog post
  1. develop, release 브랜치를 알파/스테이징 테스트용으로 사용할 수 있어 우리의 테스트 방법을 도입할 수 있음
  2. 브랜치가 많이 나뉘기 때문에 테스트가 완료된 브랜치만 머지할 수 있음
  • prod: 상용 서버 배포 브랜치
  • main: 기본 브랜치
  • staging: 스테이징 서버 배포 브랜치 (QA 테스트용)
  • release: Release Candidate 브랜치
  • alpha: 알파 서버 배포 브랜치 (개발자 내부 테스트용)
  • develop: 개발 브랜치
  • developalpha
  • releasestaging
  • mainprod
  1. develop에서 feature 브랜치 생성
  2. featuredevelop에 병합
  3. developalpha에 병합 → 알파 서버 배포됨 → 개발자 내부 테스트 진행
  4. developrelease에 병합
  5. releasestaging에 병합 → 스테이징 서버 배포됨 → QA 테스트 진행
  6. releasemain에 병합
  7. mainprod에 병합 → 상용 서버 배포됨
feature2는 브랜치 생성시부터 feature1 변경내역을 가지고 있다
  1. feature 브랜치가 develop에서 따이고, 개발 직후 develop에 병합되기 때문에 발생하는 문제
  • develop에서 feature1 브랜치 생성 → 개발 완료 직후 develop에 머지 → develop에서 feature2 브랜치 생성을 하게 되면 feature2feature1의 개발 내역을 전부 갖게 됨
  • feature1이 버그나 일정으로 지연될 경우 feature2는 손으로 feature1 내역을 제거하거나 (이 경우 나중에 feature1 머지 충돌 발생), feature1이 배포 될 때 까지 지연됨
feature1의 QA 실패가 feature2의 배포까지 막는다
  • 여러 개발 내역들이 병합되어 올라오기 때문에, feature 브랜치 중 하나라도 QA를 통과하지 못하면 배포가 통째로 지연되게 됨
이제 feature2는 feature1 변경내역을 가지지 않는다
  1. develop에서 feature 브랜치 생성 → main에서 feature 브랜치 생성
  1. develop 브랜치 제거
  2. main에서 feature 브랜치 생성
  3. featurealpha에 PR 및 병합 → 알파 서버 배포됨 → 개발자 내부 테스트 진행
  4. featurereleases/<배포날짜>에 병합
  5. releases/<배포날짜>staging에 PR 및 병합 → 스테이징 서버 배포됨 → QA 테스트 진행
  6. releases/<배포날짜>main에 병합
  7. mainprod에 PR 및 병합 → 상용 서버 배포됨
일주일간 쌓인 변경 내역을 배포하는 담당자

현재

카스파 다비드 프리드리히, 1817년 작
가자! 수시 배포!
브랜치가 크게 간략화 되었다
  • prod: 상용 서버 배포 브랜치
  • main: 기본 브랜치. 언제든 배포가 가능하도록 유지한다. Release Candidate역할을 한다.
  • staging: 스테이징 서버 배포 브랜치 (QA 테스트용)
  • alpha: 알파 서버 배포 브랜치 (개발자 내부 테스트용)
이제 feature 별로 개별 테스트 및 배포가 가능하다
  1. main에서 feature 브랜치 생성
  2. featurealpha에 PR 및 병합 → 알파 서버 배포됨 → 개발자 내부 테스트 진행
  3. featurestaging에 PR 및 병합 → 스테이징 서버 배포됨 → QA 테스트 진행
  4. featuremain에 PR 및 병합
  5. mainprod에 PR 및 병합 → 상용 서버 배포됨
하루 종일 배포 및 검토만 한 담당자
일 2회 배포를 진행하는 담당자
  • 각 단계별 PR이 명확함
  • 배포 주기를 짧게 가져갈 수 있어 배포가 길게 지연되지 않음
  • 한번 배포할 때 들어가는 기능 단위가 작아 관리자 검토가 용이
  • feature당 PR을 3개씩 만들어야 함 (alpha, staging, main)
  • feature 브랜치는 항상 alpha에 먼저 병합되므로 브랜치 목록에서 보면 항상 merged 상태가 된다. 따라서 PR 목록을 보지 않고서는 어느 단계까지 배포되었는지 알 수 없습니다.
우린 답을 찾을 것이다. 늘 그랬듯이

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store