git-flow 별 배포 전략

by

git-flow

git-flow

Development

  1. dev 브랜치에서 feature 브랜치 생성: feature/DV-0000
  2. 개발자 Local에서 구현
  3. 작업 완료 후 푸시: push feature/DV-0000
  4. merge to dev from feature/DV-0000
    1. 취합 전에 PR로 코드 리뷰 가능
  5. Dev 환경 배포(자동, 수동) dev
  6. delete branch feature/DV-0000

git-flow

QA

  1. 코드 프리징된 dev 브랜치에서 release 브랜치 생성: release/7.1.0
  2. QA 환경 배포(자동, 수동) on release/7.1.0
  3. 버그 수정을 위한 feature 브랜치 생성: feature/QA-0000 from release/7.1.0
  4. 버그 수정: merge to release/7.1.0 from feature/QA-0000
    1. 취합 전에 PR로 코드 리뷰 가능
  5. QA 환경 배포(자동, 수동) on release/7.1.0
  6. QA Sign-off

Release

  1. release/7.1.0 merge to main
  2. 7.1.0 Tagging = Versioning
  3. Staging 배포
  4. Staging QA
  5. Production 배포
  6. release/7.1.0 merge to dev
  7. delete branch release/7.1.0

Staging 배포 전략

main <- release/7.1.0

Production 환경에 나가기 전에 가장 완벽한 방법으로 테스트 가능
Staging 환경 QA 중 버그가 발견되면 버저닝을 다시 해야함.
충돌 가능성 존재

release/7.1.0 <- main

Staging 환경 QA 중 버그가 발견되어도 브랜칭 피로감이 없음
추후 release/7.1.0 -merge-> main 시 충돌 없음.

git-flow

Hotfix

  1. main 브랜치에서 hotifx 브랜치 생성: hotfix/7.1.1
    1. QA 환경 배포 후 검증
  2. merge to main from hotfix/7.1.1
  3. Production 환경 배포(자동, 수동)
  4. 7.1.1 Tagging = Versioning
  5. merge to dev from hotfix/7.1.1
  6. delete branch hotfix/7.1.1

git-flow on Sourcetree

Keymap: CMD + OPT + F

github-flow


출처: https://www.youtube.com/watch?v=cP0I9w2coGU

main: 기본 브랜치이면서 Production 배포 브랜치

  1. feature 브랜치 생성 후 개발자가 구현: feature/DV-0000
  2. PR 생성 및 변경: Lint, Test, 정적 분석 등
  3. 코드 리뷰
    1. 리뷰 후 수정사항이 있으면 추가 수정사항 커밋 후 푸시
  4. PR 승인
  5. main 브랜치로 취합: Production 배포
    1. feature 브랜치 삭제

github-flow

  • 일반적으로 버저닝 없음.
  • CI/CD Pipeline 가 필수로 요구됨.
    • 상시 배포 체계
  • Dev, QA 환경에 대한 고민: Tagging?
  • 빠르게 배포하는 Start-up 애플리케이션에서 유리
  • main 브랜치에 Protection Rule 적용 필수!

gitlab-flow


출처: https://blog.programster.org/git-workflows

gitlab-flow hotfix


출처: https://www.linkedin.com/pulse/gitlab-flow-jadson-santos

  • 개인적으로 이해가 잘 안되는 부분은 pre-production에서 검증이 없음.

Trunk-Based Development


출처: https://launchdarkly.com/blog/git-branching-strategies-vs-trunk-based-development/

github-flow 전략에서 더 간략히 해서 단 하나의 main (or trunk)브랜치로만 개발

  • 아예 Branching를 하지 않음. feature (or topic)브랜치 조차 만들지도 않음.
  • 로컬에서 main 브랜치에서 바로 개발하고 바로 푸시!
  • Release 시에는 태깅과 동시에 CI/CD Pipelline가 작동됨.
  • 일반적으로 TDD, 카나리 배포, Blue/Green 배포, Feature Flag 기능이 요구됨.
  • 성숙한 엔지니어링 실력과 문화!

Trunk-Based Development 장/단점

장 점단 점
상시 배포 가능(하루에도 N번)큰 기능 배포가 어려움(통합 테스트…)
작은 단위 배포(분할정복!. 오류 확률 낮아짐)대기시간이 긴 경우.(다른 기능에 의존해서 대기)
초 빠른 배포 가능버그가 배포될 확률이 높아짐(QA 없음)
TDD(or Test) 필수코드 리뷰는 어떻게?
QA 전략에 대한 고민(카나리로 커버하나?)

배포 크기가 작으니 문제도 작다! 빨리 배포해서 나가자!

그 외 전략들

  • Multi production brach
    • 패키지 쪽에서 많이 사용함.

forking 전략 vs branching 전략

  • forking 전략
    • 프로젝트 멤버가 아니여도 참여(기여) 가능
    • 오픈소스
    • 브랜치 관리를 위한 피로도가 있음.
  • branching 전략
    • 조직(ex: 회사) 내에서 구성원들끼리 협업하는 경우
    • 권한이 없는 사람은 멀 할 수가 없음.
    • 브랜치 관리가 상대적으로 쉬움

Jordan의 경험

  • 0: 무전략
  • 1: git-flow
  • 2: git-flow(branching 전략) + PR + CI/CD Pipeline

지금 다니는 회사는?

git-flow + “PR, Github Actions” + forking 전략 조합 형태

  • 많은 회사들이 이 조합으로 운영되고 있음.
  • dev -> qa -> staging -> production(<- hotfix) 만족할려면 git-flow가 잘 맞아 보임

지금 다니는 회사에서 생각할 점

  • dev -> qa -> staging -> production(<- hotfix)
  • dev2, qa2 환경 별로 브랜치가 존재
  • release 브랜치를 적절하게 이용하지 못하고 있음.
    • QA 버그 픽스 시 dev가 아닌 release에 작업하는 것을 좋을 것 같음.
    • Staging 배포 시 고민(release vs main)
  • forking 전략 이제 그만 branching 전략으로 가는 것이 낫다.
    • 회사에서 프로젝트 하는데 굳이 forking로 할 시 장점이 없음.

정답은 없다.

문화, 상황, 코드, 구성원들 조합에 따라서 달라짐

잘 Research 해서 사용하자~

Refs.

Leave a Comment