CMS Team Git Branch - Part 1 전략 수립

sangin cha·2022년 9월 22일
0

수행중인 프로젝트 및 Tech Team 특성을 고려한 Git Branch 전략을 수립하자!

Why?

현황

  • master branch만 유지
  • 개발 / 운영을 모두 master branch 소스를 통해 서버에 배포
  • 완성 되지 않은 소스는 개인별 feature 브랜치 또는 Local Repository에서 commit만 하여 관리

문제점 및 필요성

  • 전체 소스가 QA 통과 전까지 운영 배포 불가
  • 장애 발생 시 이전 버전으로의 Rollback 불가
  • PC 오류 발생시 Local Repository 보관된 소스 사용 불가
  • 개발과 운영을 병행하며 기능별 배포 와 QA / 운영 버전 이원화 필요 증가

How?

Used Git-flow for Git Branch Strategy

Git branch 전략 유형

1. Git-flow

feature, develop, release, hotfix, master 총 5가지의 브랜치 유형을 갖는 형태

master와 develop 두개의 브랜치가 기준 역할을 수행하며, 개발과 운영의 유연성을 보장해 주는 유형

feature

  • 기능 구현시 추가되는 브랜치
  • feature/{기능명}의 형태로 브랜치 명 생성
  • feature 브랜치는 develop 브랜치에서 생성되며, develop 브랜치로 머지된다.
  • 머지 후 해당 브랜치 삭제 필수

develop

  • 개발 소스 코드의 중심적인 브랜치
  • 배포할 수준이 되면 release 브랜치에 머지

release

  • QA 배포용 브랜치
  • 브랜치명 release-1과 같은 형태로 릴리즈 버전 명기
  • QA 수행 후 master로 머지
  • 버그 패치 된 소스를 develop과 master 동시에 머지

hotfix

  • 운영에 배포된 소스 중 버그 발생 된 코드를 빠르게 패치하기 위한 브랜치
  • 브랜치명은 hotfix-1로 release 버전번호와 동일하게 버전을 명기
  • hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop, release, master 브랜치에 머지

master

  • 운영 배포용 브랜치
  • QA를 통과한 release 브랜치의 소스가 머지

support

  • 운영 지원 업무에 사용 되는 브랜치
  • 병렬 업무가 가능 하며, 필요에 따라 생성하고 완료시 삭제

장점

  • 기능이 고도화 되고, 업데이트가 주기적으로 이루어지는 조직에 유리
  • 프로젝트가 커질수록 코드에 용이

단점

  • 복잡함
  • 과연 그대로 사용하는 조직이 있을까?
  • 이렇게 복잡하게 관리되어도 완벽하게 흘러가지 않을 수 있다!

2. GitHub-flow

master

  • 기준 브랜치

topic

  • git-flow의 feature 처럼 기능별 생성하고, 완료되면 삭제되는 기능 단위의 브랜치
  • 기능 완료되면 바로 master 머지하는 것이 아니라, Pull Request를 요청하여 코드 리뷰를 진행
  • 코드 리뷰/테스트 완료 후 토픽 브랜치 그대로 운영에 배포
  • 이상이 없을 경우 master에 머지
  • 방식 : 일반적으로 기본(master) 브랜치와 개인별 생성하는 기능 단위의 토픽 브랜치로 관리하는 전략

장점

  • 개발자 습득 및 관리의 오버헤드가 적다.
  • 상시 배포 모델로 배포가 잦은 초기 프로젝트 진행 시 적합

단점

  • 너무 단순
  • stage, release, 이슈 통합에 대한 표준 프로세스가 없음
  • master 노드 하나만으로 충분할까?

3. GitLab-flow

Git-flow의 복잡성을 완화하고 효율성을 높인 전략
Github-flow의 단순 구조에 추가적인 가이드를 제공한 형태
master, feature, pre-production, production 브랜치 존재
비교적 적용이 쉬우면서도 원활한 운영이 가능

Production branch with GitLab flow

Environment branches with GitLab flow

Release branches with GitLab flow

Git flow, GitHub-flow, Gitlab-flow 비교

이러한 기본적인 3가지 전략 외에도 조직의 특성과 역량에 따라 기본전략을 변형하여 전략을 수립하는 경우도 있습니다.

NHN Cloud의 Git-flow 전략

[2019] '깃'깔나는 Git 워크플로 알아보기

  • Git-flow 기반으로 브랜치 종류를 유지(master, develop, feature, hotfix)
  • 배포 주기별로 develop 브랜치를 생성하는 것이 특징
  • develop 브랜치 하위에 세부 기능별로 Feature 브랜치를 생성하여 개발 진행
  • release 브랜치를 따로 두지 않고, develop 브랜치 그대로 QA에 배포
  • QA 테스트 완료 후 배포 주기 develop 브랜치를 master와 develop 브랜치에 Merge 후 운영 배포
  • QA 테스트 완료 후 스프린트 develop 브랜치를 master와 develop 브랜치에 Merge 후 운영 배포
  • 나머지 진행 중인 스프린트, 장기 기능 develop 브랜치들을 develop으로 rebase
  • 마찬가지로 feature 브랜치로 develop에 rebase 해줌
  • 운영 장애 발생시 master로 부터 hotfix 브랜치를 생성하여 처리하고 코드 리뷰 완료 후 develop과 master에 merge한다.

release 브랜치를 사용하지 않고, 배포주기별로 develop 브랜치를 관리한다는 면이 좋았습니다.

다만, rebase를 주기적으로 사용해야 하기 때문에 관리의 어려움과, 고객사별로 다양한 버전의 배포 버전을 갖고 있는 우리 입장에서는 QA 시점에 release 브랜치가 필요할 것으로 판단이 되어 우리와 맞지 않는다는 생각이 들었습니다.

Git 전문가가 사내에 있어서 Git을 지속적으로 모니터링하며, 개발자들을 통제할 수 있다면 적용이 수월할것 같은 전략이었습니다.

화해 개발팀 백엔드 플랫폼의 Git-flow 전략

브랜치 전략 수립을 위한 전문가의 조언들

  • Git-flow 전략에서 develop 브랜치를 사용하지 않고 release 브랜치만을 기준 브랜치로만 사용하는 전략

develop 브랜치를 사용하지 않는 사유를 써놓긴 하였지만, release branch들의 배포 관련한 소스 프리징 문제에 대응하기 위함인것 같은데... 솔직히... 직접 해보지 않아서 어떤 문제가 발생할지 감이 오진 않았습니다.

이 정도로 벤치마킹은 그만 하고......

그럼 우리는?

현황 파악 먼저!

  1. 현재 master 브랜치 버전의 소스가 경향/매경/서울신문에 운영되고 있어 배포 시 안전성 확보가 필요
  2. 단기간 개발하여 빠르게 배포해야 하는 기능 고도화 뿐만 아니라, 장기간 일정이 필요한 신규 기능에 대한 개발 Needs도 존재
  3. 애자일 프로세스의 Scrum 기법을 사용하면서 sprint 주기별로 개발 완료 된 결과물을 테스트하고 운영에 반영하고 있음
  4. 기술적으로는 아직 Git 브랜치에 대한 지식이 부족하고, 이렇게 깊게 브랜치 전략에 대해 고민해본 경험이 없음

한마디로, 운영중인 서비스에 정해진 주기마다 안정적으로 기능을 배포 할 수 있으면서도 Git에 대한 기능과 브랜치 경험을 쌓을 수 있는 형상관리와 배포 전략이 필요함!!

결국, 기본에 충실하자라는 전략을 세워보았습니다.

Git-flow 전략으로 결정!!

이게 좋을까 저게 좋을까 고민만 하다 허성세월 보내지말고, 기본부터 충실히 닦으면 어떨까 생각했습니다.
Git 브랜치에 대한 지식이 부족한 상태에서 효율적이고 안정적인 브랜치 전략을 수립하기 위해서는 가장 레퍼런스가 풍부한 Git-flow 전략이 우리에게 유용할 것이라 판단하였습니다.
경험이 축적되고 나면, 개선된 우리만의 Git-flow 전략을 가져갈 수 있지 않을까 생각합니다.

다음 장에서는 우리 팀이 개발 간 수행 해야할 Git 브랜치 방법과 Git 이용시 지켜야할 원칙에 대해 설명드리겠습니다.

참고 사이트

Git-flow의 흐름 설명이 잘 되어 있고, 진행 간 실행해야 하는 git 명령 코드도 잘 정리 되어 있음
https://nvie.com/posts/a-successful-git-branching-model/
각 브랜치 전략의 흐름의 그림으로 잘 표현함
https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5#Github-Flow_%ED%9D%90%EB%A6%84
화해 블로그로 자신들만의 브랜치 전략을 소개
http://blog.hwahae.co.kr/all/tech/tech-tech/9507/
각각의 브랜치 전략에 대한 장단점을 잘 작성되어 있음
https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/
우아한 형제들 기술 블로그 - 자신들의 flow 전략을 소개
https://techblog.woowahan.com/2553/
Gitlab CEO의 효율적 git 운영 규칙 11가지
https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/

profile
소프트웨어의 사용성과 사용자의 만족을 소프트웨어의 최우선 가치로 여기는 소프트웨어 엔지니어

0개의 댓글