[아티클 프로젝트 005] 하루에 1000번 배포하는 조직되기

하루에 1000번 배포하는 조직되기

 

잦은 배포는 많은 비즈니스 충족을 뜻하고 사용자에게 더 많은 가치를 빠르게 전달할 수 있다는 것을 의미하며 
빠른 성장과 높은 가치를 인정받게될 수 있다.
실제로 유명한 스타트업, 테크 기업들은 하루 1000번 이상의 크고 작은 배포가 이루어지고 있다고한다.

 

gitflow

하나의 repository에서 메인테이너들이 동시에 작업할 경우 큰 장점이 있는 모델
총 5가지의 브랜치로 이루어져있다.
- master, release, develop, hotfixes, feature

 

흐름

- develop에서 feature 브랜치를 생성, feature에서 개발 -> develop에 병합
- develop에서 release 브랜치 생성, release에서 배포에 핃요한 문서 작업 혹은 버그 수정 등을 진행
- release 준비가 완료되면 release 브랜치를 master와 develop에 병합

 

잦은 배포에서 더이상 git-flow를 따를 필요가 없다.
브랜치를 생성하고 병합하고의 절차가 너무 많았기 떄문에 복잡한 프로세스를 줄일 필요가 있다고 생각했으며
여러명이 동시 작업 후 배포를 진행했을 경우 특정 기능에 장애가 나면 tag기반으로 롤백할 때 전체를 할 수 밖에 없는 상황이 있었기에 배포 정책을 수정할 필요를 느꼈다고한다.
따라서 최소한의 브랜치를 생성하여 작업을 하게되었다고하는데,
master만이 존재하며 작업 시 master에서 브랜치를 생성 (브랜치 네이밍은 명확히) 후 작업하고 master에 병합
(안전하지 않아보인다면 원본 글을 읽고오세요, 병합 전 절차들이 있습니다.)

 

- 병합할때는 squash and merge 방식을 사용한다고한다.

- 브랜치의 모든 커밋을 squash하여 하나의 커밋으로 만들고 이 브랜치를 병합한다.
- 병합을 요청하는 단위는 배포가능한 단위여야하고 작을 수록 좋다.

- git flow와 가장 큰 차이는 master에 병합될때마다 커밋들을 배포하지 않고 여러 커밋을 모아서 배포
  ㄴ 사이드이펙트나 커뮤니케이션의 비용문제로 빠르게 배포하는 것을 권장
  ㄴ 여러 기차가 정차해 있다가 출발하는 모양과 비슷하다고 해서 commit-Train based deployment라고 한다.

 

그 아래 배포 툴에관한 내용 잘 몰라서 읽고 넘어가자

 

결론은 ... 
하루에 1000번의 배포를 할 수 있는가?
모니터링 툴과 장애 대응 프로세스, 조직의 비즈니스 역량이 있어야 가능하며 판단할 수 있는 지표가 될 수 있다.

 

---

 

원본 글

https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/