GitLab 이슈를 활용한 Git Branch Strategy

개요

아키텍트는 대규모 프로젝트에서 원하는 목표를 달성하기 위해 다양한 영역의 아키텍처를 설계하는 것은 물론 개발 생산성 향상을 위해 개발절차를 확정하고 개발에 필요한 환경과 가이드를 제공하는 등 담당해야 할 과제들이 존재한다. 이때 개발절차를 확정하기 위해 선행되어야하는 것이 있는데 바로 SCM 정책수립이다.

SCM(Source Code Management)은 소스코드 저장소에 대한 수정 사항을 추적하고 여러 개발자의 소스코드 병합과정에서 발생가능한 Conflict를 해결하는데 도움을 주는 도구이다. 특히 대규모 프로젝트일수록 필수적으로 고려되어야 한다.

최근 클라우드 환경 특히 마이크로서비스 아키텍처 환경으로 접어들어가며, 배포독립성, 민첩성이 강조되는 환경에서 Git이 떠올랐으며, 신규로 시작되는 프로젝트들은 Git 기반으로 개발하는 경우가 많아지고 있는 추세이다. 필자 역시 신규 프로젝트를 리딩하는 경우 Git을 권고하고 있다.

이번 포스팅에서는 Git 브랜치 전략에 따른 조직 구성원 별 역할을 정의하고, 이를 DevOps 체계에 어떻게 적용하는 것이 좋은지 알아보자.

---

포스팅 순서

• 프로젝트 팀 구성
• GitLab 프로젝트 준비
  • Group 등록
  • Member 등록
  • Project 등록
  • Mileston 등록
  • Label 등록
  • Issue 등록
• Git 브랜치 전략 수립
  • Git Flow
  • GitHub Flow
  • GitLab Flow
• GitLab 개발 프로세스

---

프로젝트 팀 구성

먼저 프로젝트를 수행할 팀을 구성해 보자. 여기서 프로젝트 팀이란 마이크로서비스 아키텍처 환경에서 서비스 단위로 팀을 구성하는 것을 가정한다.

팀 구성은 피자 2판을 나눠먹을 수 있는 단위라고 하지만, 대체로 비슷한 비즈니스 유형을 처리하는 조직으로 구성하는 것이 바람직하다. 하나의 팀에는 Developer와 Operator가 공존해야 하며, 8:2 또는 7:3 비율로 팀을 구성한다.

Developer와 Operator 조직은 소수로 이루어지겠지만, 팀 내에서 역할 분리는 굉장히 중요하다. 소수의 프로젝트에서 역할이 명확히 구분되지 않을 경우 일에 대한 진척 지연은 물론 책임소지에 대한 문제가 발생할 가능성이 높다. 다음은 DevOps 조직이 10명으로 이루어져 있을 경우를 가정하고, 팀을 구성하는 예시이다.

비율은 팀마다 요구되는 기술셋에 따라 다르게 구성될 수 있겠지만, 적정한 비율은 MSA리더 (1) : 개발리더 (1) : 개발자 (5) : QA (1) : 운영리더 (1) : 운영자 (1) 또는 개발자 (4) : 운영자 (2) 정도로 구분해 볼 수 있을 것이다. (참고해야 할 사항으로 최근 DevSecOps라고 하여 Security를 조직에 포함하는 형태로 발전되어 가고 있다. 다만, Security 담당자는 하나의 마이크로서비스 단위에 소속하기 어려운 상황(인력확보 측면, 범위 측면 등)이므로 본 포스팅에서는 Security는 제외하고 설명하고자 한다.)

프로젝트 팀이 구성이 되면, 역할을 부여해야 한다. 역할 역시 범위를 조정해 볼 수 있지만, 일반적으로 아래와 같은 역할을 부여할 수 있다.

담당	역할
MSA리더	- MSA리더는 담당 프로젝트 내 수행해야 하는 모든 의사결정 조율 - 프로젝트 진척을 관리하는 주체
개발리더	- Developer 조직에서 수행되는 의사 결정 및 코드리뷰를 담당 - 각 개발자의 진척을 관리하는 주체
개발자	- 마이크로서비스 개발 및 유지보수 - 단위테스트 주체
QA	- CI/CD 구축 및 관리 - E2E 테스트, Contract 테스트 등 다중 서비스 간의 테스트 담당 주체
운영리더	- Operator 조직에서 수행되는 의사 결정을 담당하고 조율 - 개발자 지원을 위한 의사소통 창구 역할
운영자	- 마이크로서비스 장애 대응 - 주요 클라우드 관련 솔루션 구축 운영 (PaaS, API Gateway, Service Mesh, Telemetry, Backing 등)

위와 같은 조직 구성으로 보면, 소규모 SI 프로젝트가 수행되는 형태로도 볼 수 있다. 다만, SI는 시스템을 통합한 이후 프로젝트에서 철수하지만, 마이크로서비스의 DevOps 조직은 지속적으로 개발하고 운영해 나간다는 측면에서 차이가 있다.

---

GitLab 프로젝트 준비

지금부터는 Git 프로젝트 내에서 Git Branch 전략을 수립함에 있어 위 수행 담당자 별 역할을 정리해 보도록 하자. 다음은 GitLab 내에서 수행 가능한 범위로 한정하며, 외부 3rd Party 솔루션 적용은 고려하지 않았을 경우이다.

1) Group 등록

그룹은 마이크로서비스 단위 또는 프로젝트 팀 단위로 구성할 수 있으며, 대체로 프로젝트 팀 단위로 구성하는 것이 좋다. 하나의 프로젝트 팀 내에서 담당하는 마이크로서비스가 때로는 하나 이상이 될 수 있고, 각 역할을 담당하는 구성원이 다를 수 있지만, 이는 Issue를 활용하여 구분해 나가는 것이 좋다. 

그룹을 등록하는 방법은 다음과 같다.

(Admin Area > Overview > Groups > New Group)

위와 같이 마케팅서비스팀이라는 그룹을 생성하였다.

2) Member 등록

생성한 그룹에 멤버를 등록한다. 등록한 멤버에게는 프로젝트에서 담당하게 될 역할에 따른 접근권한을 부여한다.

(Admin Area > Overview > Groups > 그룹선택)

접근권한은 크게 5가지로 구분된다.

접근권한	담당	역할
Owner	MSA PL	- 그룹 / 프로젝트 생성자 - 그룹 / 프로젝트 내 수행되는 모든 권한 포함 - 멤버 권한부여, 프로젝트 / 마일스톤 / 이슈 관리 등 전체 GitLab 프로젝트 수행에 필요한 권한을 부여
Maintainer	개발리더	- 그룹 / 프로젝트 내 수정/삭제 권한 제외 Owner와 동일한 권한 - Issue 및 브랜치를 생성하여 개발자에게 업무를 부여하고, 개발된 소스코드에 대한 소스리뷰 및 Merge Request를 승인하는 역할 - Master Branch에 Push하거나, Release하는 역할
Developer	개발자	- 신규 개발 또는 유지보수 담당 - 새로운 브랜치 생성 및 Push가 가능하지만, Maintainer에 의해 할당된 이슈와 브랜치에서 개발 수행 - Protected 브랜치를 제외한 모든 브랜치에 push 가능. Develop 브랜치에 Push 권한을 제거하기 위해 main 브랜치 이외에 develop 브랜치를 protected 브랜치로 구성 # Protected 브랜치 구성 방법 : Project - 3) 프로젝트 등록 과정이 완료된 이후 설정 가능 > Settings > Repository > Protected Branches > Allowed to merge/Allowed to push 설정 - 개발 후 코드리뷰 및 Develop 브랜치에 머지 요청
Reporter	QA	- 이슈 관리 가능 - Merge 또는 Push 권한이 없음 - Merge Request 생성 가능
Guest	운영리더/운영자	- 프로젝트를 직접적으로 수행하지는 않지만, 프로젝트에 커멘트를 남기거나 그룹 / 프로젝트 조회가 가능한 권한

각각의 역할에 맞게 접근권한을 부여하되, 위와 같이 반드시 구성할 필요는 없으며, 프로젝트 특성에 맞게 부여하는 것이 중요하다. 특히 개발리더와 개발자간 역할부여에 많은 부분 고려되어야 하며, 개발자에게 부여할 권한의 범위에 따라 개발리더의 역할이 한정될 수 있다.

위는 그룹에 포함되는 멤버에게 권한을 부여한 예시이다.

3) Project 등록

프로젝트는 마이크로서비스 단위로 생성한다. 이는 클라우드 상에서 서비스로 매핑된다. 즉, 개발자가 개발하고, QA가 배포하기 위한 모든 서비스가 존재해야 하며, 독립적으로 빌드/배포가 가능해야 한다.

(Admin Area > Overviwe > Projects > New Project > Create new project) 

위는 마케팅서비스(marketing-service) 프로젝트를 생성하는 과정이다.

4) Mileston 등록

마일스톤은 큰 틀의 유지보수 단계를 정의할 수도 있지만, 단위 기능 개발에 필요한 단계를 정의할 수도 있다. 즉, 명확히 추구하는 목표를 정의하고, Due Date를 기준으로 업무를 세분화하여 관리될 수 있도록 일정을 정의한다. 프로젝트 내에 여러 마일스톤이 관리될 수 있다.

(Project > Issues > Milestones > New mileston)

주요 업무 / 업무 순서 정의 / Start Date / Due Date를 정의하여 이후 프로젝트의 이슈를 정의하고, 진척을 관리하는 지표로 삼을수 있다. 마일스톤의 계획을 세우는 일은 프로젝트 리더의 주요 업무라 할 수 있다.

위는 마일스톤 생성화면이다. 마일스톤에 연계된 이슈/머지요청/라벨/멤버 정보를 확인할 수 있다. Issue/Merge Request/Participants/Labels 등이 연동되었을 경우 아래와 같이 연계정보를 마일스톤에서 확인할 수 있다.

5) Label 등록

Label은 해쉬태그와 같이 Issue와 Merge Request의 유형을 한눈에 알아보기 위한 방식이다.

(Project > Project Information > Labels > New Label)

위와 같이 액션아이템, 리스크, 버그, 신규기능, 커스터마이징, 이슈 등으로 구분하여 태그를 생성하고, Issue 및 Merge Request에 활용한다.

6) Issue 등록

이슈는 개선사항이나, 신규 추가되어야 할 부분들에 대해 프로젝트 별로 등록하여 관리하는 Documentation의 일종이다. 앞서 생성한 마일스톤과 라벨을 등록하고 이슈를 관리할 Assigner를 등록한다.

(Project > Issues > List > New issue)

위와 같이 이슈 생성이 완료되면, 오른쪽 상단의 Assignee Edit 버튼을 통해 해당 이슈를 할당 할 수 있다. 이슈를 할당할 경우 자동으로 이슈가 생성된 프로젝트에 접근권한이 부여되며, 할당한 역할에 따라 프로젝트에서 업무 수행이 가능하다.

이때 할당된 사용자는 To-Do 리스트를 받게 되며, 아래와 같이 상단에 To-Do 리스트가 표기되고 이동 시 이슈 정보를 확인할 수 있다.

이슈는 프로젝트와 매핑되며, 프로젝트에 할당되어 있는 인원은 이슈에 동일한 권한으로 자동 할당된다. 그룹의 경우 마이크로서비스팀 단위로 생성했다면, 이슈의 경우 팀 내에서도 여러 마이크로서비스를 개발할 경우 또는 여러 기능이 한번에 개발될 경우 각 할당 업무별로 구분하여 생성하는 것이 좋다.

---

Git 브랜치 전략 수립

위와 같이 GitLab 프로젝트 준비가 완료되면, 생성된 Issue에 팀원이 배정되고 권한이 부여된 상태가 될 것이다. 지금부터는 Git 브랜치 전략들에 대해 살펴보고, 마이크로서비스에 적용하기 용이한 Git 브랜치 전략은 어떤게 있는지 알아보도록 하자.

1) Git Flow

Git Flow 브랜치 전략의 기본 사상은 개발 대상의 특성에 따라 브랜치를 분리하는데 있다. Git Flow는 아래와 같은 5개의 브랜치로 구성된다.

• Master (main & protected)
• Develop
• Feature
• Release
• Hotfix

Master와 Develop 브랜치는 수명주기가 긴 또는 제거되지 않는 브랜치이다. Feature/Release/Hotfix 브랜치는 목적에 따라 생성되고 삭제되는 수명주기가 짧은 브랜치이다. PR에 따른 머지가 완료되면 Feature/Release/Hotfix 브랜치는 삭제된다. 특징은 복잡한 프로젝트 환경에서 배포가 적고 안정적인 배포를 진행해야 하는 경우 적합한 방식이다.

개발순서

• Clone
  • Master > Develop > Feature
  • Master > Hotfix > Develop
• Merge
  • Feature > Develop > Relase > Master
  • Develop > Hotfix > Master

장점

• Feature 브랜치는 sourcetree, gitkraken과 같은 개발자 로컬 repo에 저장관리하여 타 개발자의 영향 없이 순수 개발을 진행할 수 있다.
• 브랜치를 세분화하여 개발에 집중할 수 있도록 머지, 병합, 충돌에 대비할 수 있으며, 직관적인 구성이 가능하다.
• 체계적인 개발 프로세스를 통해 효율적인 테스트 환경을 구축할 수 있도록 지원한다.
• Release 브랜치를 적용하여 다중 버전의 배포가 가능하도록 구성할 수 있으며, 다양한 배포 전략을 적용할 수 있다.

단점

• 브랜치 전략의 복잡도에 따라 개발 프로세스 및 릴리즈 주기가 지나치게 복잡해지고 느려질 수 있다.
• Feature 브랜치 머지 및 코드 리뷰에 많은 시간이 소모된다.
• Git Flow 사상은 대체로 장기 프로젝트에 적합한 방식으로 민첩한 배포가 필요한 프로젝트에 적합하지 않다.

2) GitHub Flow

GitHub Flow 브랜치 전략은 소규모 팀에 적합한 Master / Feature 브랜치로만 이루어진 비교적 간단한 전략이다.

• Master
• Feature

여러 버전을 지원할 필요가 없는 웹 애플리케이션이나 민첩성이 중요한 배포 프로세스에 적용하기 적합한 전략이다.

개발순서

• Clone
  • Master > Feature
• Merge
  • Feature > Master

GitHub Flow는 Master 브랜치가 Release 브랜치 역할을 겸한다. Feature 브랜치는 신규 기능, 버그 픽스 등을 포함하며, 개발이 완료되면, Master 브랜치에 머지되어 배포한다.

GitHub Flow 전략을 성공적으로 수행하기 위해 아래 사항을 준수하는 것이 좋다.

• Master 브랜치의 모든 코드는 배포 가능해야 한다. 즉 빌드가 실패하거나, 배포 시 에러가 발생되지 않아야 하며, 이는 Master 브랜치로의 머지에 대한 엄격한 검증(코드리뷰, 테스트 등)이 있어야 함을 의미한다.
• PR(Pull Request)을 적극적으로 활용한다. 단순히 소스리뷰나 머지 요청을 위해 생성하기 보다는 DevOps 조직 전체적으로 의견을 주고 받을 수 있는 창구로 활용한다.
• Git Flow와 다르게 Feature 브랜치를 Remote에서 관리하는 것이 좋다. 엄격하게 Master 브랜치가 관리되어야 하므로 사전에 Feature 브랜치를 통해 동일 기능에 대한 검증을 선 진행하고 Master 브랜치의 병합이 진행되는 것이 효과적이다. 상단에서 살펴본 이슈를 활용하는 방법에 적합하다. 이슈를 통해 생성한 브랜치를 Feature 브랜치로 관리하고 브랜치에 Commit 권한을 모든 개발자에게 허용한다. 이후 Master 브랜치에 대한 MR이 완료되면 해당 브랜치는 삭제한다.
• Master 브랜치에 병합되면 Webhook을 통해 즉시 배포가 가능한 환경이 구성되어 있어야 한다. CI/CD 프로세스에 적용하여 Master 브랜치 머지는 배포라는 의미를 심어두는 것이 좋다.

장점

• 흐름이 간단하여 누구나 손쉽게 이해하고 접근할 수 있다. Git을 사용해 보지 않은 개발자도 쉽게 이해할 수 있다.
• GitHub에서 제공하는 이슈를 활용할 수 있다.
• 배포가 빈번한 MSA 환경 등 민첩한 CI/CD 배포 전략을 수립하기 용이하다.
• 소규모 팀과 웹 애플리케이션에 적합하다.
• 구글의 대부분의 프로젝트는 GitHub Flow를 사용한다.

단점

• 동시에 여러 버전의 소스를 지원하지 않는다.
• 코드리뷰는 물론 인프라 관점의 이해도가 높은 리더가 반드시 존재해야 한다.
• Develop 브랜치가 없어 운영 버그에 더 취약할 수 있다.

3) GitLab Flow

GitLab Flow 브랜치 전략은 GitHub Flow 브랜치 전략과 유사하지만 릴리스 버전에 따라 브랜치를 추가한다는 점이 다르다. GitLab Flow는 Master 브랜치가 있지만, 다른 브랜치 전략과 다르게 최종 릴리즈를 위한 소스를 관리하는 브랜치로 사용되지 않는다. GitLab Flow에서 Feature 브랜치에서 개발한 소스코드는 Master 브랜치를 타겟으로 PR, 코드리뷰 및 머지 승인과정이 진행된다.

• Master (main & protected)
• Feature
• production

GitLab Flow 브랜치 전략은 두 가지 유형의 릴리스 방법을 제시한다.

개발순서

• Clone
  • Master > Feature
• Merge
  • Feature > Master > Production

위와 같이 Master 브랜치가 배포 대상이 아닌 유일한 브랜치이다. 배포는 Production 브랜치에서 배포하며, Master 브랜치에 최종 머지되더라도 자동으로 CI/CD 파이프라인을 태우지 않는다.

장점

• Git Flow 브랜치 전략과 비교할 때 GitLab Flow은 더 간단하다.
• GitLab Flow은 GitHub Flow 브랜치 전략보다 더 체계적이고 구조화되어 있다.
• GitLab Flow은 CI/CD 및 다양한 버전의 릴리스를 배포할 수 있다.

단점

• GitLab Flow는 가장 단순하지도 않고, 복잡한 협업으로 프로젝트에서 가장 구조화되어 있지도 않은 Git 브랜치 전략이다.

# 선택

그래서 어떤걸 사용할꺼야? 라고 묻는다면, 역시나 프로젝트에 맞는 전략을 선택하라고 말하고 싶다. 다만, 기본적인 선택 기준은 다음과 같이 가져 갔으면 한다.

복잡도

• GitHub Flow < GitLab Flow < Git Flow

배포 민첩성 / 배포 빈도

• GitHub Flow > GitLab Flow > Git Flow

사실 위 두가지 조건을 가지고 선택한다면, 명확한 기준이 수립될 것이라고 본다. 예를 들어 MSA와 같은 빈번한 개발과 배포가 필요한 프로젝트에는 GitHub Flow 또는 GitLab Flow, SI 대형 프로젝트의 경우 Git Flow 또는 GitLab Flow를 검토해 보는 것이 좋을 듯 하다.

위와 같은 브랜치 전략 이외에 다양하게 조합하여 자신만의 프로젝트 브랜치 전략을 생각해 볼 수 있다. 특히 CI/CD 파이프라인과의 조합을 통해 완성된 형태의 구성을 이뤄낼 수 있다. 다만, 주의해야 할 점은 위와 같이 화려한 브랜치 전략을 적용한다고 하여 프로젝트 관리가 더 잘되고 문제를 해소할 수 있는 것은 아니라는 것이다. 무엇보다 개발자의 브랜치 전략을 이해하고 있는지를 파악하고, 누구나 이해하기 쉬운 수준에서 브랜치를 관리해 나가는 것이 바람직하다.

---

GitLab 개발 프로세스

마지막으로 살펴볼 내용은 GitLab 환경에서 개발하는 절차에 대해 알아보자.

지금부터 살펴볼 내용은 GitHub Flow의 처리 흐름이다. 필자가 현재 진행 중인 마이크로서비스 환경에 적용하고자 고려 중에 있으며, 각 개발자들에게 제공할 개발 절차서에도 다음과 같은 내용이 담겨질 예정이다.

1) Feature 브랜치 생성

현재 환경은 Master 브랜치만 생성되어 있는 상태이며, "마케팅 로그인 기능 개발" 이라는 이슈를 생성한 상태이다. 이슈에는 jinfox와 narason이 초대되어 있고, jinfox는 Developer, narason은 Reporter 역할이 부여되어 있다.

먼저 이슈를 통해 Feature 브랜치를 생성해보자. 생성 권한은 Developer 이상에게 부여된다.

Create merge request and branch와 Create branch 중 Create branch를 선택하고 feature 브랜치 이름과 clone할 대상 브랜치인 master 브랜치를 입력한다.

위와 같이 feature-login 브랜치가 생성되었다. Feature 브랜치의 경우 remote에서 관리하는 경우와 local에서 관리하는 경우로 구분해 볼 수 있지만, 가이드에서는 remote에 관리하는 방법에 대해 알아본다.

2) Feature 브랜치 clone & push

a. git clone

[root@ip-192-168-93-115 feature]# git clone http://gitlaburl:gitlabport/root/marketing-service.git
Cloning into 'marketing-service'...
Username for 'http://localhost': jinfox
Password for 'http://jinfox@localhost': 
remote: Enumerating objects: 46, done.
remote: Total 46 (delta 0), reused 0 (delta 0), pack-reused 46
Receiving objects: 100% (46/46), 55.63 KiB | 27.81 MiB/s, done.
Resolving deltas: 100% (4/4), done.
[root@ip-192-168-93-115 feature]#

git clone의 경우 git pull과 비슷하지만, 초기 git init을 통해 .git 초기화 작업을 함께 수행해 준다. 쉽게 origin 생성을 자동으로 해준다는 의미이다.

b. branch 변경

[root@ip-192-168-93-115 feature]# cd marketing-service/
[root@ip-192-168-93-115 marketing-service]# git checkout -b  feature-login
Switched to a new branch 'feature-login'
[root@ip-192-168-93-115 marketing-service]# git branch -a
* feature-login
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature-login
  remotes/origin/master
[root@ip-192-168-93-115 marketing-service]#

소스코드 개발에 사용할 로컬 git 브랜치명을 결정한다. 일반적으로 remote와 동일한 브랜치명을 사용하거나, 뒤에 local을 붙여 사용한다.

또는 git checkout [source_branch] -b [target_branch] (ex - git checkout remotes/origin/feature-login -b feature-login-local)으로 생성할 경우 target 브랜치는 source 브랜치를 기준으로 생성된다.

c. commit & push

[root@ip-192-168-93-115 marketing-service]# git add .
[root@ip-192-168-93-115 marketing-service]# git commit -m "18080 port"
[feature-login 626c74c] 18080 port
 1 file changed, 2 insertions(+), 2 deletions(-)
[root@ip-192-168-93-115 marketing-service]# git push -u origin feature-login
Username for 'http://localhost': jinfox
Password for 'http://jinfox@localhost': 
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 278 bytes | 278.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: 
remote: To create a merge request for feature-login, visit:
remote:   http://ec2-3-35-134-81.ap-northeast-2.compute.amazonaws.com/root/marketing-service/-/merge_requests/new?merge_request%5Bsource_branch%5D=feature-login
remote: 
To http://localhost/root/marketing-service.git
   55a8747..626c74c  feature-login -> feature-login
Branch 'feature-login' set up to track remote branch 'feature-login' from 'origin'.
[root@ip-192-168-93-115 marketing-service]#

소스코드 개발이 완료되어 remote에 반영하고자 할 경우 위와 같은 과정으로 반영한다. (add > commit > push)

3) MR(Merge Request) 요청

Feature 브랜치에 push된 소스코드를 Master Branch에 머지하기 위한 Merge Request를 작성한다. MR 역시 Developer 이상 역할을 요구한다.

(Project > Merge requests > New merge request > Create merge request)

Source Branch는 Feature 브랜치, Target Branch는 Master 브랜치를 구성하고, Compare branches and continue 버튼을 선택한다.

Merge Request를 작성하기 위해 Target 브랜치와의 변경된 상태를 확인한다.

> 주요 포인트로 아래 내용들에 대해 작성 한다.

• Assignee : 해당 Merge Request에 대한 담당자를 지정한다. MR을 승인하는 대상이다.
• Reviewer : 코드리뷰 도와줄 Member를 지정한다.
• Milestone : 요청한 MR과 관련된 마일스톤을 지정한다.
• Labels : 요청한 MR과 관련된 라벨을 지정한다.
• Merge Options
  • 요청한 머지가 승인될 경우 해당 브랜치를 제거할 것인지 여부
  • MR에 쌓여 있는 여러 커밋 요청들을 하나의 커밋으로 묶어서 머지할지 여부

Assignee는 머지 승인 권한이 있는 Maintainer, Reviewer는 추가로 코드 리뷰에 참여할 인원, Merge Options는 팀 내에서 결정하되, 첫번째 머지 승인 후 생성한 Feature Branch는 제거하는 옵션은 활성화하고 두번째 옵션은 정책에 따라 결정한다.

4) 리뷰 및 MR(Merge Request) 승인

Merge Request가 오픈되면 Assignee와 Reviewer에게 알림이 전송된다. 상단에 Assigned to you와 Review request for you에 각각 알림 메시지가 온것을 확인할 수 있다.

먼저 Reviewer가 해야할 역할을 알아보자.

리뷰어는 아래 Assignee와 다르게 승인이나, 머지 권한이 부여되지는 않는다.

(Merge Request > Changes > Line Comment > Comment 입력 > Start a review)

Reviewer와 Assignee의 코드리뷰에 따른 커멘트를 MR을 요청한 코드 수정자는 검토 후 반영 여부 등에 대해 커멘트 추가 및 소스코드 변경 작업을 진행한다.

다음으로 Overview 탭의 Approve를 선택한다. 코드 리뷰와 승인을 받는 과정을 통해 모든 마이크로서비스 개발자 간의 커뮤니케이션이 활성화 되고, 서로 더 좋은 아이디어를 공유할 수 있어 이는 매우 중요한 부분이자, 반드시 거쳐야 하는 과정이다.

위와 같이 Approve를 선택한 이후 화면이다. MR이 승인되었으니, 이제 Master 브랜치와 Merge만 진행되면 된다.

머지까지 완료된 화면이다. 머지 후 테스트 결과에 따라 Revert 또는 Cherry-pick을 실행할 수 있다. 마지막으로 브랜치가 삭제된것을 확인할 수 있다.

위와 같이 머지 승인 후 생성한 Feature 브랜치는 삭제된 것을 확인할 수 있다. 또한, Master 브랜치에 수정한 파일(Dockerfile)이 함께 반영된 것을 확인할 수 있다. 이때 Webhook을 걸어 CI/CD를 위한 파이프라인이 자동으로 동작하게 할 수 있다.

# 참조 1

Maintainer의 머지 승인 시 Source와 Target 간 Conflict가 발생하는 경우가 종종 발생한다. 이 경우 Maintainer는 Conflict를 수정하기 위해 local repository 환경에서 Conflict를 수정하고 직접 반영해야 한다.

# 참조 2

Markdown 활용

GitLab Markdown을 활용하여 Document에 대한 가독성을 높일 수 있다. Markdown을 적용할 수 있는 부분 중 많이 활용되는 부분만 살펴보자면, Issue를 포함하여, Comment, MR 등에 활용된다.

[Sample gitlab markdown]

# 타이틀
타이틀은 30자 이내 간소하게

## 서브타이틀
서브타이틀은 50자 이내 간소하게

### 세부항목
세부항목은 최대한 자세하게

체크박스
- [ ] 본 이슈를 확인하셨습니까?

링크 거는 방법 [gitlab website](https://about.gitlab.com)

리스트
- item 1
- item 2
- item 3
- item 4

정렬
1. 대게
1. 가리비
1. 조개

위와 같이 작성하면, 

와 같이 Markdown 형태로 나타난다. 물론 이보다 워낙 많은 Markdown 문법이 있지만, 간단하게 살펴만 보고, 보다 자세한 부분을 확인하고 싶을 경우 아래 URL을 참고한다.

https://docs.gitlab.com/ee/user/markdown.html

GitLab Flavored Markdown | GitLab

또는 폐쇄망 설치 시 http://gitlab_ip:gitlab_port/help/user/markdown로 접근 가능하다.

---

결론

MSA 환경에서는 민첩한 배포와 빈번한 배포가 발생하기 때문에 가능하면 배포가 간단하고 CI/CD 자동화 구성이 가능한 전략을 선택하는 것이 좋다. 반대로 대형 SI나 모놀리식 아키텍처 방식으로 개발을 진행할 경우 복잡하지만, 체계적인 브랜치 전략을 가져가는 것이 좋다. 결론을 내리기 전에 마지막으로 브랜치 전략을 수립하는 것과 마찬가지로 반드시 지켜야 할 GitHub Flow 브랜치 규칙에 대해 알아보도록 하자.

• Master 브랜치는 직접 PUSH가 불가능하도록 protected 브랜치로 정의한다.
• Feature 브랜치는 Master 브랜치를 기준으로 Clone하여, 신규 브랜치를 생성한다.
• Developer는 Featrue 브랜치에 개발한 소스를 commit하고 push 한다.
• Master 브랜치에 반영하기 위해 Merge Request를 생성하여 코드리뷰 및 머지를 요청하며, Maintainer는 검토 후 머지승인을 진행한다.
• Master 브랜치에서 배포를 위해 이력 관리가 효율적으로 이뤄질 수 있도록 tag를 생성하여 관리하는 것이 좋다.

간편한 전략일수록 보다 꼼꼼하게 브랜치를 관리해야 하는데, 이때 TAG를 활용할 수 있다. GitHub Flow의 경우 별도의 Release 브랜치가 존재하지 않기 때문에, Master는 항상 배포되어야 하며, 복구할 수 있어야 한다. 이때, Master 브랜치의 Release 버전을 관리하기 위해 tag를 생성해 두는 것이 좋다.

혹시나 특정 버전으로 revert하여 수정이 필요할 경우 tag를 직접 수정할수는 없지만 local branch로 내려받아 수정 후 remote branch에 반영할 수는 있다.

tag 활용 방법에 대한 자세한 내용은 다음을 참고한다.

Git Branch & Tag를 활용한 프로젝트 배포 전략 마련하기

지금까지 GitLab 이슈를 활용한 브랜치 전략 및 개발 절차에 대해 알아보았다. 몇가지 브랜치 전략에 대해 알아보았지만, 어떠한 전략을 수립하는 것이 좋을지에 대해서는 여전히 프로젝트의 전략을 수립하는 아키텍처의 몫으로 남겨져 있다.