상시배포에 git-flow는 적합하지 않다?

2014-01-02 15:58

수다양에 @자바지기 님이 흥미로운 글을 공유해 주셨습니다. http://scottchacon.com/2011/08/31/github-flow.html

git-flow는 너무 복잡하다(사실 git 그 자체가 이미 복잡하다). 상시배포를 하는 환경이라면 깃헙의 flow처럼 더 간단한 방식이 필요하다는 취지의 글인데요, 읽어보고 몇가지 느낀점을 적어봅니다.

먼저 글이 쓰여진 시기는 2011년으로 저자는 35명이서 깃헙을 개발해 나가던 시절의 이야기를 하고 있습니다. 상시배포를 하긴하지만 문제가 많이 발생할만한 규모는 아닌듯 합니다.

깃헙에서는 develop 브랜치를 두는 대신 pull-request라는 과정을 두어 리뷰를 거친 후 안전한 코드만 배포를 하게 합니다. 그를 위한 훌륭한 gui(깃헙 그자체)도 있구요. 이는 develop 브랜치를 별도로 두어 master 브랜치에는 배포 가능한 코드만 merge 되도록 관리한다는 git-flow의 컨셉과 크게 다르지 않습니다.

제가 실무에서 git-flow를 사용하지 않을때 느끼는 제일 큰 문제가 바로 이것입니다. 배포용 브랜치와 개별 피쳐가 merge 되어 개발단에서 통합으로 관리되는 브랜치가 분리되어 있지 않고 하나로 관리가 된다면 모르는새 안전하지 않은 코드가 배포되어 장애가 발생할 수 있습니다. git은 브랜칭이 자유롭기 때문에 svn보다 이 이슈가 더욱 큽니다.

또한 깃헙은 chat room/hubot을 통해 merge, pull request를 irc상에서 수행함으로써 구성원들이 실시간으로 과정을 지켜볼 수 있고 장애가 발생했을 때 빠른 대응이 가능하다고 알고 있습니다. 일반적인 조직에서는 이러한 공통의 소통창구가 없기 때문에 기민한 대응이 어렵습니다. 그래서 git-flow 같은 컨셉의 안전장치가 반드시 필요하다고 생각합니다.

뭔가 떠오르는데로 적느라 횡성수설 했는데 제가 하고싶은 말은 요겁니다.

자유로운 브랜칭과 상시배포에는 안전장치가 반드시 필요하다. 그리고 git-flow는 그를 위한 검증된 모델이다. 최소한 왜 git-flow가 어떻게 등장하게 되었고 어떤 이점이 있는지를 이해하자.

여러분의 생각은 어떠신가요?

BEST 의견 원본위치로↓
2014-01-03 14:55

깃의 브랜칭과 배포에 대한 전략은 회사의 상황에 따라 달라지는 것이 기본이라 생각합니다. 이 기본전략은 개발팀의 협의를 통해서 결정을 하고 운영되어야 합니다. 그렇겠죠?

위의 브랜치 전략은 git-flow를 약간 응용해서 제가 운영하고 있는 git 브랜칭 전략입니다. 실제 개발은 develop 브랜치에서 진행되고 있고, 아래와 같은 형태로 브랜치들을 처리하고 있습니다.

  • master : 솔루션의 큰 변경사항이 있을 경우에 대한 태깅용 브랜치
  • develop : 로컬 개발 및 테스트 브랜치
  • feature/기능 : 기능 개발할 때마다 생성
  • production/dev : 개발서버 배포 브랜치
  • production/a-company : A 고객사 배포 브랜치
  • production/b-company : B 고객사 배포 브랜치
  • production/{next}: 다음 고객사 배포 브랜치

위와 같은 브랜칭 전략을 구성하게 된 이유는, 저희 회사에서 제공하고 있는 솔루션의 변경이 생겼을 때를 고려해서 고객사별로 브랜치를 구성하고 변경사항을 관리하기 위해서 입니다. 고객사가 늘어나게 되면 헬이 되겠지만, 나름 문서화를 잘하고 명명규칙을 정하면 커버가능하겠다는 나름의 배짱 플레이가 있습니다. 깃의 '자유로운 브랜칭과 강력한 머징'은 이런 전략을 사용가능하도록 해줍니다. 지금은 수동으로 하고 있지만, 이를 자동화해줄 스크립트를 작성해서 간단하게 실행시킬 수도 있습니다(처음에 작성할 때는 번거롭겠지만).

소스코드의 버전관리(브랜칭) 정책과 배포에 대한 고려가 제일 우선이 되어야 여러가지 문제들의 실마리를 찾을 수 있을 겁니다.

예를 들어, 상시배포의 경우에는, 상시배포에 사용하는 브랜치(ex: freq-deploy)와 배포전략(개발서버에는 freq-deploy 브랜치를 통해 빌드배포를 진행한다, 이때 젠킨스에서는 SCM polling'소스코드의 변경이 있는지를 일정시간마다 확인해서 변경이 있을 때 빌드-배포 진행'을 걸어두거나 해당하는 작업에 대한 실행권한을 가진 계정으로 실행한다 등)의 전략을 수립하는 것이죠.

그리고 이런 전략은 팀원간에 공유되고 학습-체득화되어야 합니다. 누군가가 이 전략을 위반해서 자기 마음대로 처리를 하면 망가지겠죠. 혹은 github.com(https://github.com),,) bitbucket.org(https://bitbucket.org),,) yobi(http://yobi.io)와와) 같은 서비스 등을 통해서 배포에 사용되는 저장소와 개발자의 저장소를 분리하고 Pull Request하여 처리하는 전략을 짤 수도 있을 겁니다.

중요한건! 개발팀 내의 소스버전관리 및 빌드배포 전략을 확립하는 것입니다. ^^;

git-flow는 도구일 뿐, 중요한 건 그 도구를 어떻게 쓸 지를 결정하는 거죠. 이왕이면 그 도구의 목적에 대해서 제대로 알고 시작하는 것이 좋겠죠.

6개의 의견 from SLiPP

2014-01-02 16:56

git-flow 가 복잡하기 보다 버전관리에 대한 이슈와 요구사항이 복잡해진것 같습니다. git-flow 가 http://nvie.com/posts/a-successful-git-branching-model/ 에서 이야기하고 있는 경험적인 브랜치 전략이다 보니 사용함에 있어 여러 오해와 구멍이 있다고 생각합니다. 전 개인적으로 git-flow 의 브랜치 전략이 검증된 모델이라는 점에 극 공감을 하고 있습니다.

허나 사용하는 입장에서 git-flow 가 단순한 command 에 대한 alias 정도로만 인식 되어져 도구 뒤에 깔려있는 전략과 이유에 대해서는 배제되고 있다고 생각합니다.

git-flow 를 사용하기 위해서는 전제가 필요한데 이 전제를 무시 한 채 사용하기 때문에 복잡해지고 원래의 효과과를 보지 못하게 되는것 같네요.

2014-01-02 17:56

이 같은 도구나 무엇인가를 결정할 때 가장 중요한 점은 Context라고 생각한다. 현재 조직의 규모, 서비스의 상태, 프로젝트에 참여하고 있는 구성원의 지식 수준 등등 다양한 Context를 고려해 최선의 방법이라고 생각한다.

이런 관점에서 봤을 때 git-flow가 적합할 수도, 적합하지 않을 수도 있다고 본다. 이 글과 같이 안정장치에 대한 필요성이 낮은 환경에서는 github flow와 같이 단순한 전략을 취하는 것도 좋은 선택이라고 본다.

안정 장치를 어느 수준으로 볼 것이냐에 따른 것인데 github flow의 경우 배포하기 전에 리뷰라는 안정 장치를 두었다고 생각한다. 리뷰를 통해서도 충분히 안전하다고 판단했기 때문에 선택한 전략이라고 본다.

그렇다면 @진우, @하윤아빠 둘이 몸담고 있는 조직의 전략은 어떠해야 할까? 내가 결정할 수 있는 권한이 있는 것은 아니지만 내가 결정할 수 있다면 지금 단계에서는 git-flow와 같은 도구를 통해 안정 장치를 마련하는 것이 좋다는 생각이 든다. 가장 큰 이유는 아직까지 개발자들의 역량이나 workflow가 리뷰를 통해 안정 장치를 마련할 수 있는 수준은 아니라고 판단되기 때문이다. 따라서 시스템을 통해 명확하게 분리해야 한다고 생각한다. 또한 이미 100명이 넘는 개발자가 같은 소스 코드를 바라보고 있기 때문에 이 또한 시스템을 통한 분리가 필요하다고 본다. 모듈화가 잘 되어 있어 각 저장소를 바라보는 개발자가 10명 전후로 제한된다면 github flow도 괜찮은 전략이지만 현재는 모듈화도 부족한 상태이기 때문에 git-flow의 도입은 더 필요하지 않을까라고 생각한다.

난 제 3자의 입장이기 때문에 마음껏 씨부려봤다.

2014-01-03 14:55

깃의 브랜칭과 배포에 대한 전략은 회사의 상황에 따라 달라지는 것이 기본이라 생각합니다. 이 기본전략은 개발팀의 협의를 통해서 결정을 하고 운영되어야 합니다. 그렇겠죠?

위의 브랜치 전략은 git-flow를 약간 응용해서 제가 운영하고 있는 git 브랜칭 전략입니다. 실제 개발은 develop 브랜치에서 진행되고 있고, 아래와 같은 형태로 브랜치들을 처리하고 있습니다.

  • master : 솔루션의 큰 변경사항이 있을 경우에 대한 태깅용 브랜치
  • develop : 로컬 개발 및 테스트 브랜치
  • feature/기능 : 기능 개발할 때마다 생성
  • production/dev : 개발서버 배포 브랜치
  • production/a-company : A 고객사 배포 브랜치
  • production/b-company : B 고객사 배포 브랜치
  • production/{next}: 다음 고객사 배포 브랜치

위와 같은 브랜칭 전략을 구성하게 된 이유는, 저희 회사에서 제공하고 있는 솔루션의 변경이 생겼을 때를 고려해서 고객사별로 브랜치를 구성하고 변경사항을 관리하기 위해서 입니다. 고객사가 늘어나게 되면 헬이 되겠지만, 나름 문서화를 잘하고 명명규칙을 정하면 커버가능하겠다는 나름의 배짱 플레이가 있습니다. 깃의 '자유로운 브랜칭과 강력한 머징'은 이런 전략을 사용가능하도록 해줍니다. 지금은 수동으로 하고 있지만, 이를 자동화해줄 스크립트를 작성해서 간단하게 실행시킬 수도 있습니다(처음에 작성할 때는 번거롭겠지만).

소스코드의 버전관리(브랜칭) 정책과 배포에 대한 고려가 제일 우선이 되어야 여러가지 문제들의 실마리를 찾을 수 있을 겁니다.

예를 들어, 상시배포의 경우에는, 상시배포에 사용하는 브랜치(ex: freq-deploy)와 배포전략(개발서버에는 freq-deploy 브랜치를 통해 빌드배포를 진행한다, 이때 젠킨스에서는 SCM polling'소스코드의 변경이 있는지를 일정시간마다 확인해서 변경이 있을 때 빌드-배포 진행'을 걸어두거나 해당하는 작업에 대한 실행권한을 가진 계정으로 실행한다 등)의 전략을 수립하는 것이죠.

그리고 이런 전략은 팀원간에 공유되고 학습-체득화되어야 합니다. 누군가가 이 전략을 위반해서 자기 마음대로 처리를 하면 망가지겠죠. 혹은 github.com(https://github.com),,) bitbucket.org(https://bitbucket.org),,) yobi(http://yobi.io)와와) 같은 서비스 등을 통해서 배포에 사용되는 저장소와 개발자의 저장소를 분리하고 Pull Request하여 처리하는 전략을 짤 수도 있을 겁니다.

중요한건! 개발팀 내의 소스버전관리 및 빌드배포 전략을 확립하는 것입니다. ^^;

git-flow는 도구일 뿐, 중요한 건 그 도구를 어떻게 쓸 지를 결정하는 거죠. 이왕이면 그 도구의 목적에 대해서 제대로 알고 시작하는 것이 좋겠죠.

2014-01-05 13:25

@김지헌 좋은 말씀 고맙습니다.

공유해주신 브랜칭 전략에서 production이 고객사마다 분리되어있는데 production/dev와 feature와는 어떤식으로 싱크가 되는지 궁금하네요.

추가로,

그리고 이런 전략은 팀원간에 공유되고 학습-체득화되어야 합니다. 누군가가 이 전략을 위반해서 자기 마음대로 처리를 하면 망가지겠죠.

이 부분이 제일 우려되는 부분입니다. 전략에 대해 모두가 공감하고 같은 프로세스를 따르면 좋은데 각자 편한(익숙한) 방법으로 하려는 상황이 자주 발생하게 되는것 같습니다. 권한제어 등 시스템적인 부분으로 제어가 필요한 부분이겠지요.

2014-01-07 10:05

@진우

feature 는 git-flow의 feature 브랜치 전략입니다. 기능 개발을 할 때, develop 브랜치에서 브랜칭해서 기능개발을 완료하면 'git flow feature finish 기능-브랜치' 명령을 통해 사라지는 브랜치죠. ^^;

로컬에서 개발할 때는 develop에서 개발을 하고, 개발서버에 배포를 할 때는 develop에서 브랜칭된 production/dev 를 기준으로 배포하고 있습니다. 그래서 항상 deveop 브랜치에서 production/dev에 우선 머징하고 개발서버에 배포해서 확인한 후에, develop 에서 production/a-company, production/b-company 으로 머징하고 배포하는 작업을 하고 있습니다.

별다른 것은 없습니다. ^^;;

production/dev 같은 경우에는 고객사와 같은 서버환경을 가진 개발서버라서 여기서 정상동작 하면, 고객사들의 서버에서도 정상동작한다는 가정을 하고 진행되고 있습니다.

2014-01-24 02:54

git flow vs github flow 에 대해서 비슷한 고민을 하다보니 '프로젝트가 상시 배포가 가능한가.'라는 문제가 떠오릅니다. 별도의 안정화 과정이 개발 프로세스에 영향을 줄 만큼 유의미하게 길고 자동화가 안되어있다면 필연적으로 release-* 브랜치를 두고 master / develop을 분리하여 격리하는 것이 타당하다고 보이나, 반대로 충분히 짧은 시간 안에 지속적으로 안정화시킬 수 있다면 굳이 release-* / develop을 두어 분리하는 것이 무의미하다고 판단할 수 있겠죠.

즉 지속적인 상시 배포를 해야하는지, 또 실제로 안정적인 상시 배포가 가능한 상태인지가 두 브랜칭 전략을 결정하는 요인이 아닐까요?

의견 추가하기

연관태그

← 목록으로