Git strategy

gistfile1.md

Git branch 전략과 개선

Git이라는 분산 버전관리 저장소를 잘 사용해보자.

Basis

분산 버전관리 시스템(git)

1. 내 드라이브에 저장된 branch를 origin으로 쉽게 변경 가능
2. Pull / Push로 상태를 쉽게 바꿀 수 있다. 대상을 내 것으로 갱신하려면 push, 내 것위에 남의 것으로 갱신하려면 pull
3. 따로 HA 구성하지 않아도 각자 보관중인 branch가 origin이기 때문에 바로 복구 가능, SPOF의 가능성이 적다.

이런 특성을 이용해서 중앙저장소와 협업을 쉽게해주는 도구를 서비스형태로 제공하는 것이

github/gitlab/bitbucket 등등

CI/CD

CI 목표: 핵심은 remote repo에 돌아가는 코드가 merge되어있어야 한다.

• 컴파일 -> 린터 -> 빌드 -> 테스트

CD 목표: 핵심은 하드웨어 서버의 상태와 무관하게 새로운 코드가 서버에 손쉽게 적용되어야한다.

브랜치 전략

Git flow 링크

1. 주 브랜치는 release, develop 브랜치
2. master는 버전 archive의 기능
3. 새로운 기능이 필요하면 feature/[기능이름]의 브랜치를 생성한다.
4. feature 브랜치의 기능 개발이 끝났다면 develop 브랜치로 PR (개발자 리뷰)
5. develop 브랜치로 리뷰를 통과한 소스코드가 병합되고, 개발서버로 배포된다.
6. 배포 후 팀원 리뷰, 비개발자 포함
7. 기능이 문제없이 작동하는 것을 확인 후 버전이 붙어 release 브랜치로 병합된다.
8. release 브랜치의 소스코드가 실제 운영서버로 배포된다.
9. 예외로 hotfix가 있는데, release에서 브랜치를 생성 후 작업하고 release로 바로 반영한다.

# 시나리오
### 노트북 삭제 기능을 개발한다.###
# 1. 해당 이슈를 Jira/ github/ gitlab에 등록
# ex) - 노트북 삭제 갱신 #2 (보통 #2같은 이슈번호는 자동으로 붙는다.)

# 2. repo 클론 혹은 pull
git clone [remote repo]
git checkout develop # 개발 브랜치로 먼저 와주어야 한다.
git checkout -b feature/delete-notebook # 브랜치를 생성하면서 checkout

# 3. 기능 개발이 완료되었다. commit
git commit
# 아래는 커밋 메시지 템플릿 - 1
feat: Add feature delete notebook(#2)

- 노트북 삭제 시 db 갱신
- 노트북 db에서 삭제 후 k8s pod 삭제 요청

# 커밋 메시지 템플릿 -2, 축약형
Add feature delete notebook - #2
# 축약형의 대한 내용은 해당 PR에서 자세하게 적는다.

# 4. 커밋 완료 후 원격 feature branch에 push한다
#    commit 메시지에 이슈번호를 남겼으므로 이슈와 자동 링크된다.
git push origin feature/delete-notebook
# 5. 푸시가 다 되었으면 해당 원격 repo에서 develop 브랜치로 PR 생성 후 코드리뷰 요청

###  develop -> release 병합 ###
# 해당 원격 repo에서 PR하거나, 관리자가 로컬에서 develop -> release로 merge 후 push
# 로컬 repo merge 작업 예시:
git checkout develop
git pull
# conflict 해결했다고 가정
git checkout release
git pull
git merge develop # merge후 pull이나 pull 후 merge 순서 상관없음.
git push origin release

### hotfixes ###
git checkout release
git pull
git checkout -b hotfix/fix-create-notebook-volume-name

# 수정이 완료되었다.
git commit -m "Fix create notebook volume name - #234"
git push origin hotfix/fix-create-notebook-volume-name
# release로 병합하는 PR 생성

Github flow 링크

1. 주 브랜치는 master
2. Gitflow에서 feature, hotfix, develop 브랜치는 결국 개발자의 작업이나 마찬가지라는 개념
3. 수정작업이 필요한 브랜치를 생성
4. 기능개발 혹은 버그 수정이 끝났다면 master 브랜치로 PR 생성
5. 리뷰 후 머지 master를 배포

# 커밋메시지, 시나리오는 위와 같지만 브랜치가 간소화

Gitlab flow 링크

1. 주 브랜치는 master
2. Gitflow에서 feature, hotfix, develop 브랜치는 결국 개발자의 작업이나 마찬가지라는 개념
3. 수정작업이 필요한 브랜치를 생성
4. 기능개발 혹은 버그 수정이 끝났다면 master 브랜치로 PR 생성
5. 리뷰 후 머지
6. release(production) 브랜치에서 배포 시점

유의사항

Branch 전략의 선택

1. 공통

   • PR 중단단계에서 CI가 구축되어있을 수록 사람이 하는일이 적어짐

   • 마찬가지로 release, develop merge단계에서 CD가 구축되어있을 수록 사람이 하는일이 적어짐

   • 테스트 주도 개발이 활성화 될 수 록 CI단계에서 에러검출 확률 증가

   • CI 단계에서 Sonarqube 같은 도구가 코드검증을 할 수록 시스템 안정성 증가

   • 코드 검증에서 시간을 쏟을 수록 초기 오픈은 늦어지지만 전체 생산성이 증가함.

2. Git flow는 서비스가 자주 유지보수되며 대규모 인원(10 ~ 300이상) 작업 시 유용.

   • 시스템이 운영, 개발, poc로 나눠져 있을 때 최적

   • 개발 -> 운영 적용 시 안정적이나 개발 속도가 더딤

3. Github flow(Gitlab flow)는 서비스가 자주 유지보수되며 소규모 적용 가능

   • 개발 속도가 빠르고 운영배포시점이 앞당겨진다.
   • CI툴과 개발자간의 PR리뷰 의존이 크다.

업무에 따른 버전관리 및 소스관리 선택

1. SI

   • 안정성보다 생산성이 우선인 문화, 다수 인원이 개발 후 소규모 인원이 운영
   • 대게 페이지, CRUD 작업
   • 테스트는 생산성 감소인 것처럼 보이므로 도입시 저항 큼, 경험적 개발 문화가 의외로 잘 정착(?)하여 실제 거의 필요없음
   • 최대한 Git flow를 택하면서 CI, 개발서버 단계에서 기능 위주의 검증이 이루어져야함(코드리뷰는 음...)

2. 서비스

   • 서비스의 개선이 자주, 빠르게 반영되어야함, 지속적 개발, 운영
   • 대게 특이한 기능이 비즈니스 모델에 연관되어있음
   • MVP에 대해 우선 테스트를 적용하고, 코드리뷰로 검증한다.
   • 작은 규모에선 Github flow + CI 툴 적용, 규모가 커지면(10명 이상으로 갈 수록) Git flow + CI-CD 연계적용

개선방향

1. 테스트코드와 CI 도입
2. 코드 품질에 대한 과정이 도입되면(CI, 코드리뷰) 단기적 코드 결과가 안 나올 수 있음을 조직 내에서 공감이 필요하다.
3. 테스트코드가 쌓이면서 기능의 최소요구사항이 높아짐으로써 품질이 올라감을 이해해야한다.
4. 강력한 PR리뷰는 코드품질 상승과 이어지므로 git 문화에 익숙한 Lead SW developer 필요.