놀토의 깃 브랜치 전략 설명해주세요
- 우선 놀토의 브랜치는 총 5가지가 있습니다
- main: 실 배포 브랜치
- release: 실제 배포 이전 QA를 진행하는 브랜치 + 태그를 달아 main에 병합
- develop: 다음 버전 출시를 위해 새로운 기능들을 모아두는 브랜치
- feature: 단일 기능을 개발하는 브랜치
- hotfix: release/main에서 예상못한 문제 상황이 생기면 수정 개발하는 브랜치
- feature -> develop 머지시 squash and merge
- 짜잘하게 기능을 어떤식으로 개발했는지까지 커밋 이력을 남길 필요가 없다 생각
- develop -> release -> master 머지시 rebase and merge
- 머지 과정에서 별도 커밋 생성 X
깃 플로우네요. 깃헙 플로우 왜 안썼어요?
- 깃헙플로우는 마스터는 항상 배포
- 여기에 병합은 엄격하게!
- 사실 처음 팀원들과 정할 때 레퍼런스로 봤던 자료가 깃 브랜치였음,,,
- 구구의 강의도 그랬고
- 엄격하게 각 브랜치의 역할을 정해서 함부로 main을 건드리지 않는 방식이 좋아보였음
아쉬웠던 부분이 있나요? 힘들었던 부분은?
- QA와 버그 픽스를 위해 release 브랜치를 만듦
- 실제로 QA 환경등을 구성해뒀음
- 하지만 develop 브랜치에 대해 바로바로 피드백을 받아볼 수 있도록 여기도 인프라를 구성해둠
- 새로운 기능들이 병합댔을때 문제가 없는지 바로바로 확인하기위함
- 그러다 보니 오히려 release가 했어야 할 역할이 상당 부분 develop에 넘어간 느낌
- hotfix도 develop에서 따게되는 상황 발생
- develop에서는 테스트만 돌릴껄 그랬나 싶기도함 혹은 release를 폐기하던가?
- release는 거의 tag만 붙여 main에 찔러넣는 브랜치로 변질됨
- main에서 무지성으로 commit을 해버렸었음
- 앞선 커밋을 참조하는 커밋을 새로 만들어버림
- 해당 커밋을 develop으로 병합을 안시켜줌
- 하나의 커밋을 빠뜨린 상태로 주구장창 기능 개발 착수
- release -> main 할라니까 진짜 충돌 빡세게 났음
- main 커밋을 하나 지워버리는 불상사 발생
CI는 뭐에요?
- 지속적 통합을 의미
- 분담하여 코드 작성 완료 시 바로 합쳐 오류에 대한 피드백 받기 쉬움
- 애자일하게 기능 개발하는 문화와 잘어울림
CD는 뭘까요?
- 지속적 배포
- 자동으로 배포되도록 작성
무슨 툴 쓰셨어요? 왜요?
- 팀원의 추천으로 젠킨스를 사용했음
- 처음 써보는지라 Freestyle 프로젝트를 사용
- develop 브랜치에 머지가 일어나면 웹훅을 사용해 젠킨스에서 빌드 및 테스트하도록 설정 (CI)
- dev 인프라 구성이 이뤄지고 난 후로는 publish over ssh를 통해 dev 서버에 배포하도록 설정
젠킨스 쓰면서 느낀 장점?
- 머지만해도 바로 CI를 통해 테스트 돌려보는게 좋았음
- 다 같이 합쳤을 때 이상이 있는지 없는지 판단하기 쉬움
- 인스턴스 들어가서 쉘스크립트 수동으로 안돌려도돼서 좋았음
젠킨스 쓰면서 느낀 단점?
- 여러개의 작업이 동시에 돌아가진 않는듯
- 병렬적 처리가 불가능했나?