2019-11-27

‘깃’깔나는 Git 워크플로 알아보기

(NHN edu 서버개발팀 신승엽)

git flow

master : 배포 브랜치. 버전을 태그로 관리
develop : 개발용 브랜치

서포팅 브랜치

• feature/.. : develop에서 딴다. 각 기능별로 merge하며 진행
• release/v1.1… : develop에서 생성. 배포 브랜치.
• hotfix/v1.0.1… : 배포버전의 문제를 고치는 목적. master에서 딴다

github flow

자신들의 개발 철학을 설명하며 github이 소개.

사람들이 헤메지 않게 해줌

• 강조점
  master는 언제 배포해도 문제가 없어야 한다

• 설명

  • 기능 개발 브랜치 = topic 브랜치 라고 부름. (즉 feature브랜치와 같음). 작업이 완료되지 않아도 항상 서버로 push한다 (조언을 받고싶을때, 제안하고싶을 때 등 다양항 경우에 PR을 생성해 서로 의견을 나눈다)
  • PR완료 및 merge 후 배포명령을 통해 배포 (topic브랜치를 바로 배포함)
  • CI 빌드 통과 필요 / 배포중 lock 가능 / master에 topic 브랜치의 내용이 존재하는지 체크 (master는 모든 배포사항을 포함해야 한다) → 배포 완료되면 lock을 해제한다
  • 배포를 허락하는 권한을 가진 gate keeper가 없다

gitlab flow

github flow는 너무 간단하다. (git flow는 너무 복잡)

자신들의 flow를 소개할 때, 모범사례들을 같이 소개했었다.

사례1) 지속적인 배포가 어려울 때

만약 배포가능 시간이 정해져있는 회사라면, github flow로는 작업하던 개발자가 merge조차 할 수 없게 된다.

=> production 브랜치를 만들어놓고, 배포 나갈걸 merge해주면 배포가 이루어진다.

사례2) 환경별 배포가 필요할 때

master → pre-production → production 순서로 단계를 밟는 merge만 가능. 따라서 배포도 마찬가지.

여기서 pre-production은 staging환경과 같은 말. staging에 merge가 되어야 하고, staging에서 다시 브랜치를 따서 production에 merge해야 한다.

배포 시각 기록을 하고싶다면 배포 스크립트에 tag를 생성하게 해주면 된다

NHN Edu 서버개발팀의 방식

단기간 일정 + 장기 일정

• 장기 일정은 코드네임 부여

rebase로 정돈된 히스토리 유지

따로 release브랜치 생성하지 않음. 개발일정 브랜치를 master에 머지해 배포함
배포하면

rebase로 기존 브랜치를 이동시키는데, 컨플릭이 심하면 새 브랜치를 만들고 cherrypick함

복잡하다는 단점이 있지만, 히스토리 정돈을 통해 디버깅이 용이해짐.

개발 플로우

정적 분석과 유닛 테스트가 인상적.

QA 기간도 개발 플로우의 일부.

github - branch protection 설정

• 유닛테스트 + SonarQube 정적분석 테스트 이용중

• 젠킨스 이용 - Github PR builder plugin

• SonarQube가 코드리뷰를 해준다. (IDE에서 해주는거랑 비슷한데 이건 PR올릴때의 테스트하니까 통과못하면 merge불가)

기계적인 테스트 , 코드리뷰는 자동으로 하고
사람은 좀더 비즈니스 로직에 집중해 리뷰한다.