Git Branch Model/Strategy

Release Train

IT회사에서 일상적으로 사용하는 RT는 "Release Train"의 약자입니다. 소프트웨어 개발과정에서 사용 되는 용어로, 주로 Agile 또는 린소프트웨어 개발 방법론에서 활용됩니다. Release Train은 여러 팀이 협력하여 일정 주기마다 새로운 소프트웨어 버전을 배포하는 프로세스를 나타냅니다. 이 프로세스는 큰 프로젝트 또는 제품을 관리하고 지속적으로 배포하기 위해 사용됩니다.

Release Train 접근 방식은 다음과 같이 동작합니다:

1. 일정 주기: 일정한 주기(보통은 2주, 4주 등)로 소프트웨어 버전을 배포하는 시간 단위를 결정합니다.
2. 팀 협력: 여러 개발 팀이 하나의 Release Train에 참여합니다. 이 팀들은 동시에 개발을 진행하며, 주기마다 생성된 기능이나 개선사항을 공유하고 통합합니다.
3. 기능 묶음: 각 주기마다 새로운 기능, 버그 수정 등을 묶어서 배포할 준비를 합니다. 이 기능 묶음들이 전체적인 소프트웨어 배포의 핵심이 됩니다.
4. 통합 및 테스트: 주기가 끝날 때, 다양한 팀에서 개발한 기능들을 통합하고 테스트합니다. 이 단계에서 각 팀이 개발한 코드들이 충돌하지 않도록 조치하고, 품질을 검증합니다.
5. 릴리즈: 주기가 끝나면 통합 및 테스트를 마친 기능들을 하나의 큰 배포로써 출시합니다. 이것이 바로 Release Train이며, 사용자들에게 새로운 기능과 개선사항을 제공합니다.

VS. Git Branch Strategy

Git Flow , Github Flow

• Git Flow는 흐름이 복잡하지만 branch를 체계적으로 관리할 수 있다. 따라서 긴 호흡으로 개발을 진행하며, 주기적으로 배포하고 QA, 배포 할 필요성이 있을 때 Git Flow를 추천한다.
• 반대로 Github Flow는 작업 과정이 매우 단순하다는 장점이 있다. 따라서 Git을 처음 접하는 인원이 많거나 지속적으로 테스트하고 빠르게 배포되어야하는 서비스라면 Github Flow가 적합하다

Github Flow , Gitlab Flow

• 둘 다 master branch에서 시작하여 개발 중인 코드를 관리하고 기능 개발을 위해 새로운 branch를 생성하며 완료된 기능을 master branch로 병합하는 과정이 동일합니다. 또한 테스트와 리뷰를 거친 후 안정화된 코드를 production 환경에 배포하는 것 역시 동일.
• Gitlab flow가 Git flow와 Github flow의 특징을 결합한 방법론이라는 것입니다.
• Gitlab flow는 개발과 배포를 위한 유연성과 간단한 프로세스를 조합하여 팀이 더욱 효과적으로 협업하고 production 환경에 안정적인 코드를 배포할 수 있도록 지원합니다.

---

Github Flow

 

특징

• Git Flow에 비해 굉장히 간단함, 처음 git을 접하는 사람에게 가장 간단하고 적응하기 쉬운 전략.
• master branch와 pull request 방식을 활용하여 굉장히 단순한 형태의 전략
• hotfix와 가장 작은 기능(feature), 배포(release)을 구분하지 않는다. 단지 우선순위가 어디가 높은가 라는 단계적 처리가 필요 하다.
• 수시로 배포가 일어나고, CI/CD 파이프라인이 구성되어 있는 프로젝트에 유용
  • CI가 거의 필수적이며, 배포는 자동으로 진행할 수 있다.
  • GitHub의 서비스 특성상 릴리즈 라는 개념이 없는 서비스를 진행하고 있어서 그런 것으로 보임
• release branch가 명확하지 않은 시스템에서 사용 하기 맞게 되어있다. 

Branch 정의

• master
  • product 배포 branch
  • master branch는 어떤 때든 배포가 가능하다.
  • master branch는 항상 최신의 상태이며, stable 상태로 Product에 배포되는 branch이다.
• 새로운 feature branch
  • 새로운 feature를 시작하기 위해 만드는 branch
  • 항상 master branch에서 분기
  • Git Flow와는 다르게 feature, release, develop 등을 나누지 않음 → commit 메시지를 명확하게 작성해야 함
  • merge 준비가 완료되면 Pull Request를 통해 code review 단계를 진행
  • Pull Request에서 code review가 완료 → master branch로 반영

 

작업 과정 설명

1. master에서 새로운 branch 분기
2. 기능 개발 완료 시 master에 Pull Request 생성
3. Pull Request에서 code review
4. merge 시, product로 반영이 될 기능 이기에 이해관계가 연결된 사람들과 충분한 논의 이후 반영해야 한다 ← 배포 관련 부분이 확정 되야 5번 단계로 넘어 가야 한다.
5. review 및 test 완료 시 master branch로 merge
6. master branch에서 즉시 배포진행 ← 자동화 배포가 구성 되어 있어야 하지만, 수동으로 배포를 진행 해도 된다.

---

Git Flow

 

특징

1. 명확한 릴리즈 버전 관리를 위한 branch를 따로 관리하기 때문에 한 버전에 대한 유지보수가 용이함
   1. 운영 환경(master) 배포 branch와 개발 환경(develop) 배포 branch를 명시적으로 분리해서, 운영 환경에 어떤 코드 베이스가 배포 되어 있는지 한 눈에 확인할 수 있다는 점
   2. 운영 환경에 언제 배포해도 상관없는 stable branch(master)를 별도로 관리해서, 장애 혹은 버그 수정이 필요한 경우 master branch를 기준으로 빠르게 수정 → 아직 테스트가 완료되지 않은 feature branch가 운영 환경에 배포 되는걸 방지
2. 기능 개발 단위 사이사이의 conflict를 최소화 할 수 있음
3. 명확한 배포 기간과 주기적인 버전이 정해진 프로젝트에 적합
4. Git Flow 설계자 Vincent Driessen의 2020년 추가 의견

 

이 모델은 지금으로부터 10년 전인 2010년에 고안된 것으로, Git 자체가 등장한 지 얼마 되지 않은 시점입니다. 이 글에서 설명하는 브랜칭 모델인 깃플로는 10년 동안 많은 소프트웨어 팀에서 큰 인기를 끌면서 사람들이 일종의 표준처럼 취급하기 시작했지만, 안타깝게도 도그마나 만병통치약처럼 여겨지기도 합니다.

지난 10년 동안 Git 자체는 전 세계를 강타 했으며, 적어도 제 필터 버블?에서는 Git으로 개발되는 가장 인기 있는 소프트웨어 유형이 웹 앱으로 더 많이 이동하고 있습니다. 웹 앱은 일반적으로 롤백 되지 않고 지속적으로 제공 되며, 여러 버전의 소프트웨어가 동시에 실행되도록 지원할 필요가 없습니다.

10년 전 블로그 게시물을 작성할 때 염두에 두었던 소프트웨어의 종류가 아닙니다. 팀에서 소프트웨어의 지속적 배포를 수행하는 경우, 팀에 Git Flow를 무리하게 도입하는 대신 훨씬 더 간단한 워크 플로(예: GitHub 플로우)를 채택하는 것이 좋습니다.

하지만 명시적으로 버전이 지정된 소프트웨어를 빌드 하거나 여러 버전의 소프트웨어를 지원해야 하는 경우에는 지난 10년 동안 사람들에게 그랬던 것처럼 Git Flow가 여전히 팀에 적합할 수 있습니다. 그렇다면 계속 읽어보세요.

결론적으로, 만병통치약은 존재하지 않는다는 사실을 항상 기억하세요. 자신의 상황을 고려하세요. 미워하지 마세요. 스스로 결정하세요.

Branch 정의

1. master branch: 안정화된 버전의 코드(버전태그 추가), 제품으로 출시 될 수 있는 branch, 사용자에게 배포 가능한 상태만을 관리
2. develop branch: 개발 중인 코드들의 base branch. 최신 개발 변경사항이 반영되어있는 branch(현재 개발중인 코드 반영)
3. feature branch: 각 기능마다 develop을 기준으로 feature를 생성해서 개발을 진행.
4. release branch: 이번 출시 버전을 준비하는 branch, QA 진행 및 배포 준비 역할, 해당 release가 종료 되면 삭제 가능
5. hotfix branch: 출시 버전에서 발생한 버그를 수정하는 branch. master Branch에서 버그 발생하면 바로 hotfix Branch를 분기해서 수정, 배포한 후 관리하는 branch

작업 과정 설명

• master에서 develop을 분기
• 개발자들은 develop branch에 자유롭게 커밋
• 기능 구현이 있는 경우 develop에서 feature-* branch를 분기
• 배포를 준비하기 위해 develop에서 release-* branch를 분기
• 테스트를 진행하면서 발생하는 버그 수정은 release-* branch에 직접 수정 및 반영
• 테스트 완료 및 배포 준비를 완료하면 release -> main으로 merge하고, release -> develop으로 develop에도 동일하게 반영한다.
• 배포 이후에 bug가 있을 경우 hotfix branch를 사용하여 해결한다. 그리고 hotfix -> master, hotfix -> develop으로 해당 commit을 반영한다.
• 배포를 버전별로 관리하기 위해 master에 tag를 붙인다.

---

Gitlab Flow

• 2023년 추가 된 concept: https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/

 

특징

• Git Flow ↔︎ Github Flow의 절충안
• Production branch가 존재(Git Flow의 master branch 역할과 같음)
• Gitlab Flow의 master branch는 production branch로 merge됨
• pre-production branch는 production branch로 넘어가기 전에 QA/Test를 진행하는 branch

 

Branch 정의

• master
• pre-prodution
  • production으로 넘어가기 전의 branch
  • QA/Test 등 배포 준비 작업을 담당
• production
  • 배포만을 담당
• 새로운 feature branch
  • github flow의 새로운 feature branch처럼 사용

 

과정 설명

1. master에서 새로운 branch 분기
2. 기능 개발 완료 시 master에 Pull Request 생성
3. Pull Request에서 code review
4. 다음 배포 버전의 Pre-production branch 생성 후, QA/Test 진행
5. Production branch 생성 및 배포
6. (Github Flow에서 배포만을 위해 추가된 Production branch와 테스트를 위한 Pre-production branch 빼고 동일합니다.)

---

Trunk-Based Development

https://paulhammant.com/2013/04/05/what-is-trunk-based-development/

특징

• 작은 규모의 프로젝트나 소규모 개발팀에서 주로 사용되며 릴리즈 주기가 짧은 프로젝트에 적합한 전략
• 단일 branch를 사용하여 개발을 진행하며 모든 개발자가 동일한 branch(trunk)에서 작업.
• 개발자는 자신이 작업한 변경사항을 주기적으로 commit하고 다른 개발자의 변경사항과 통합합니다. 이로써 지속적인 통합과 릴리즈를 강조하며 branch 관리에 따른 복잡성을 줄 이는 장점.
• 그러나 branch 충돌이 발생할 수 있고 변경 사항이 모든 개발자에게 바로 적용되기 때문에 신중하게 사용.

Branch 정의

• trunk(=master): 하나의 branch에서 모든 개발자가 작업을 합니다. 실제 개발과 배포를 위한 branch를 하나로 사용합니다.

 

참고(Updating,,)

• https://techblog.woowahan.com/2553/