GitFlow를 중지하고 정식 발매가 수월해지면

배경

서버 측에서 개발한 프로젝트에서 GitFlow(의) 운용을 진행했지만 정식으로 발표할 때 어려움을 겪었기 때문에git의 운용 절차를 바꾸어 없앴다.
먼저 문제의 내용부터 순서대로 쓰기 때문에 결론(새로운 운용 규칙)만 알고 싶은 사람여기
git 운용 절차에 대해 GitFlow, GitHub Flow, GitLab Flow 등이 유명하지만 둘 다 좀 다르다고 생각해서 정리했습니다.
<2018/06/10 추기>
나는 본래 새로운 절차에도 이름이 있기를 바랐지만, 같은 방법을'Git Feature Flow'라고 부르는 문장을 발견했다.개인적으로도 잘 어울릴 것 같아서 앞으로 이 호칭을 쓰고 싶어요.
cf. GitFlow를 사용하지 않습니다!간단한 "GitFeature Flow"
추가 기록 끝

배포 프로젝트 개요

나는 반드시 채택해야 할 운용 규칙도 프로젝트의 조건에 달려 있다고 생각하기 때문에 이 규칙을 도입한 프로젝트에 대해 조금 쓰자.

개발자(엔지니어) 10명 미만

비교적 소규모 팀이지만 1명보다 2명이 많다.

검증 서버는 항상 개발자 지점의 내용을 반영한다

개발자 브랜치가 업데이트되면 CI를 통해 자동으로 향상됩니다.

생산 환경에서 마스터 지점의 내용을 반영

master는 항상 발표할 수 있는 상태에 있어야 한다.

로컬 환경에서feature 지점 개발

많은 사람들이 가지고 있는 Mac으로 개발한다.

인증 서버 1개

도 각 지점에 따라 서버를 구축하는 것을 연구했지만 현황의 운용에서 1대가 좋다고 판단했다.

공식 발표 며칠 간격 ~ 2주 간격

보통 하루에 여러 번 공식 발표를 하는 느낌은 아니다.

방출 작업 자체가 업데이트 내용만 마스터에 들어가면 한 번의 명령으로 완성되기 때문에 작업 원가가 높지 않다.

원래 운영 프로세스

분기 모델

GitFlow라고 쓰면서 공식적인 절차가 아니라 GitFlow에서 릴리스 지점의 운용을 생략했다.

develop

내부 검증 지점

feature/xxx

로컬 기능 개발 지점

develop에서 파생

master

운영 운영을 위한 지점

상기 그림에서 두 개의 피처 지점을 만들어서 개발자에 통합할 때 검증용 서버에 반영합니다.
모든 동작 검증이 OK인 단계에서 개발자를 마스터에 통합하여 발표합니다.

다른 기능 검증이 없으면 발표할 수 없어서 곤란합니다.

상술한 절차 중 곤란한 모델.

이전과 같은 절차지만 피처/2를 먼저 검증하는 방법이 OK일 때 바로 발표되려면 곤란하다.
검증은 NG이기 때문에 수정이 필요한 피처/1의commit도 함께 발표됩니다.
당장 피처/1을 수정하고 검증하면 되지 않겠느냐고 생각할 수도 있지만, 프로젝트의 여러 가지 이유로 간단하게 완성할 수 없을 때가 있다.
(예를 들어 검증 후 규격을 변경해야 하거나 3일 후 담당자가 다음 작업을 할 수 있다. 수정이 빨리 끝나도 사내 검증 단계에서 최종 검사를 받아야 하는 위인은 잡히기 어렵다.)
feature/2는 이미 검증을 마쳤지만 평상시 절차에서 즉시 발표할 수 없습니다.피처/1의 수정과 검증이 끝날 때까지 기다리거나cherry-pick의 일부분만 제출하는 등 대응해야 합니다.
두 가지가 있다면 괜찮지만 개발자 수가 늘어나 각자 기능 개발을 하게 되면 발표 시기를 조정하는 것이 상당히 번거로워진다.
내부 검증용 서버가 한 대밖에 없기 때문에 동작 검증 후 정식 생산 절차에 따라 GitHub Flow와 GitLab flow도 같은 문제가 발생할 수 있다.

새 운영 프로세스

분기 모델

이 절차에 사용되는 지점도 세 가지가 있다.

develop

내부 검증을 위한 지점검증 서버에 반영됩니다.

직접commit/push가 아닙니다.

업데이트 시 피처 지점을 통합합니다.

master

생산 작업에 사용되는 지점.운영 서버에 반영됩니다.

직접commit/push가 아닙니다.

업데이트 시 피처 지점을 통합합니다.

feature/xxx

로컬 기능 개발에 사용되는 지점.

마스터에서 파생.

발표하고 싶은 모든 설치를 위한 제작.(여러 개의 피처 지점이 동시에 존재할 수 있습니다.)

GitFlow와 가장 큰 차이점은 항상 master 지점에서 feature 지점을 차단한다는 것이다.
GitFlow가 말하는 hotfix 브랜치 가까이.이렇게 되면 모든 기능이 발표될 수 있다.

이점

기능별 게시 가능

다른 사람이나 기능과 발표 시기를 조정할 필요가 없다.

핫픽스 지점 필요 없음

feature는 항상 마스터에서 파생되기 때문에 hotfix 지점도 평소의 feature 지점과 같다.

GitFlow의 경우 릴리즈된 수정은 비정규적인 분기 작업으로 이에 비해 간단합니다.

결점

모든 기능은 발표가 번거롭다.

develop에 통합되면 자동으로 반영되지 않기 때문에feature 지점의 존재를 잊어버리면 영원히 발표되지 않습니다.

의 말은 그렇지만 임무 관리 도구의 표와 피처링 지점을 대응하면 그리 번거롭지 않을 것이라고 생각합니다.

Tips로서 feature 지점에서 develop의 PullRequest로 보낼 때 마스터의 PullRequest까지 동시에 만드는 것은 잊기 어렵다.

feature 간의 충돌 가능성이 커진다.

마스터에 오랫동안 반영되지 않고 개발된 기능이 존재하면 다른 기능을 개발자에 통합할 때 충돌할 가능성이 커진다.

개발자가 합병할 때 충돌이 발생할 때 원인이 되는feature 지점과 조정해야 한다.

느끼다

자신이 참가한 프로젝트에서 각종 기능은 병행 제작되었다.다른 사람의 상황을 고려하지 않고 발표할 수 있기 때문에 운용이 상당히 수월해졌다.

그 결과 지금까지는 전체적인 조정이 번거로워 2주에 한 번씩 발표됐지만 소기능 추가·수정 발표는 이틀에 한 번씩 가능하다.

이용Gitgraph.js절차도 제작.처음 사용해 봤지만 사용하기 쉬워요!

저는 이 운용된 프로젝트와 회사가 다른 것이 있다고 생각했지만 간단하게 검색만 하면 찾을 수 없어서 정리했습니다.

참고 자료

Introducing GitFlow
https://datasift.github.io/gitflow/IntroducingGitFlow.html
GitHub Flow (Japanese translation)
https://gist.github.com/Gab-km/3705015
GitLab flow에서 학습한 워크플로우 실습
https://postd.cc/gitlab-flow/
Gitlab flow가 어플리케이션 개발에 적합하다고 생각합니다.
http://shoma2da.hatenablog.com/entry/2015/11/04/233534
Gitgraph.js
http://gitgraphjs.com
GitFlow를 사용하지 않습니다!간단한'Git Feature Flow'- Gulunabi를 더 좋게 만드는 엔지니어 블로그.
http://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama