ROI(Return On Investment)
- 투자 이익률을 이야기 한다.
- IT업계보다는 투자 관련해서 많이 쓰는 용어
- 투자한 것에 비해 얼마나 이익이 올랐는지를 나타내는 지표
- FE Unit Test는 투자 대비 경제성이 안 좋을 가능성이 클 것 같다는 고민 중에 다른 분에게 들은 용어
git flow가 안 좋다는 글을 읽고 생각 정리
- git flow에 대해서 부정적인 입장의 포스트를 보면서 ROI에 대한 이야기까지 나오게 되었다.
- 커리어리에서 어떤 개발자 분의 글을 보다가 고민에 빠졌다.
- git flow를 활용해서 develop 브랜치를 두는 것이 효율적이지 않다는 내용이었다.
- 현재 서비스를 개발하는 회사들이 애자일을 중시하며 빠른 간격의 출시를 하는 경우가 많고
따라서 develop 브랜치에 통합하고 다시 배포해야 하는 과정이 쓸데 없이 번거롭다는 것이었다.
- 이 의견에 동의가 되지 않아 다른 프론트엔드 개발자분과 이야기를 나눴는데, 글 쓰신 분이 아마 백엔드 개발자가 아닐까 한다는 이야기를 들었다.
- 백엔드 개발에서는 Unit Test를 거의 완벽하게 할 수 있기 때문에 배포 후 버그가 생길 가능성이 프론트엔드 개발보다는 줄어든다.
- 프론트엔드 개발에서 모든 부분에 대해서 Unit Test를 수행하는 것은 사실상 어렵다.
- 왜냐하면 페이지마다 모양이 다르고, 버튼을 눌렀을 때 나오는 결과도 매번 다르기 때문에 한 컴포넌트에 대한 Unit Test를 만들었다고 해도 다른 컴포넌트에서 동일하게 사용하기는 쉽지 않기 때문이다. (이 부분에 대해서는 긴 포스트가 따로 필요할 것 같다.)
- 따라서 백엔드 개발을 하는 입장에서는 develop 브랜치가 쓸데 없이 작업을 두 번하게 만든다고 느낄 수 있다.
- 하지만 프론트엔드 개발에서는 아무리 조심한다고 해도, 배포 버전에서 예상치 못한 오류가 발생할 가능성이 크다.
- 좋은 케이스는 아니지만 많은 회사에서 프론트엔드 개발에 Unit Test를 포기하고 있다고 한다.
- 그 이유가 ROI가 낮기 때문이다. (회사는 돈이 가장 중요하기 때문에…)
- 따라서 develop 브랜치를 두고 해당 브랜치로 배포하는 develop 서버가 있는 것이 좋다고 생각한다.
- 번거롭기는 하지만 정식 배포 전 develop 서버나 stage 서버를 하나 더 만들어서 QA를 진행하고 올리는 것이 안정적이라고 생각하고,
- git flow는 그런 관점에서 효율적인 브랜치 관리 방법이라고 생각한다.