yuhodots / yuhodots.github.io

https://yuhodots.github.io
BSD Zero Clause License
5 stars 1 forks source link

Operations/24-05-27/ #24

Open utterances-bot opened 4 months ago

utterances-bot commented 4 months ago

CI/CD with GitHub Actions | Yuho Jeong

https://yuhodots.github.io/Operations/24-05-27/

jiun0 commented 4 months ago

사장님이 잘 읽히고 글이 친절해요

저도 gitflow 관련해서 계속 고민을 해왔는데, 회사를 다니는게 아니다 보니 잘 와닿진 않더라구요. 규모가 좀 있는 워터폴 방식에선 장점이 있겠으나 그렇지 않다면 좀 복잡하다는 생각이 들었어요. 저는 개인 프로젝트는 github flow 방식과 비슷하게 관리하고 있어요. 실무를 하고 계시는 입장에서는 git flow에 대해 어떤 생각을 가지고 계신지 어떤지 궁금하네요.

yuhodots commented 4 months ago

@jiun0 개인 단위로 가져가는 저장소는 gitflow 까지는 오버엔지니어링인데, 실제 서비스에 들어가는 저장소 정도 되어야 gitflow가 알맞은 선택같아요. 검증환경하고 운영환경이 명확하게 나뉘어서 안정적으로 코드를 테스트해볼 수 있다는 점이 마음 편한 것 같아요. 또다른 방법으로는 https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/ 트렁크기반 개발 이라는 것도 있는 것 같은데 저도 직접 써보진 않아서,, 써보고 알려주시죠 ㅎㅎ

jiun0 commented 4 months ago

그럼 git flow에서는 가장 자주 하게 되는 일은 develop에서 feature 브랜치를 파고 작업이 끝나면 다시 develop에 PR을 날리는 것이 될까요? 그리고 트렁크 기반 개발을 읽어 보았는데, 제가 말씀드렸던 github-flow와 유사한 거 같아요. 올려주신 포스팅에서는 단점들을 해결할 수 있는 방법들도 제시되어 있어 좋네요! 포스팅의 저자분도 말씀하셨듯 개발 기간을 길게 가져가거나 체계적인 릴리스를 구축하고 싶다면 git flow가, 빠른 피드백 반영과 개발을 기반으로 애자일한 방법을 채택하고 싶다면 트렁크 기반이 괜찮을 것 같다는 생각이 듭니다 ㅎㅎ