깃, 배포 담당자가 따로 있으신가요?

아쉽게도, 어떤 개발 프로세스에 대한 일반적 표준이라는 건 잘 없는 것 같습니다. 어디 교과서에 이렇게 이렇게 진행하면 좋다는 가이드가 있는 것도 아니고, 워낙 효과적인 프로세스가 시시때때로 변하는지라, 이렇다할 표준이 없다고 생각합니다. 만약, 어떤 문서화된 더 좋은 방법이 있다고 할 때, 님의 팀 환경에는 적절하지 않을 수도 있고, 그 반대일 수도 있죠. 만약, 어딘가에서 이러면 좋다라는 프로세스 가이드를 가져왔다고 칩시다. 님이 개발리더에게 "남들은 이렇게 한다더라. 우리도 이렇게 합시다"라는 식으로 얘기한다고 치면, 잘 들어주기야 하겠지만 본능 한편엔 이런 생각이 들 수도 있죠. "아니 남들 하는 거 다 따라하자는 거야?" 마치 남녀가 연애하는데, 내 친구의 남친은 이런이런 선물도 해주고 이벤트도 해준다더라... 이런 상황과 비슷하다고 봅니다. 그럼 일단 비교당하는 것도 기분나쁘고, 그럼 걔랑 사귀든지라는 생각까지도 들 수 있죠. 팀이 자리를 잡으면 회사의 문화 안에서, 팀내 문화와 구성원들간의 개성까지 버무려져서 이렇게 저렇게 어우러질 수 밖에 없습니다. 무언가 프로세스나 시스템의 문제가 있다고 여긴다면, 가장 바람직한 것은 개선책을 고민해서 겸손하게 제안해보거나, 개선책까지는 잘 모르겠다면, 불편한 점을 고민 털어놓는 시간에 덤덤히 털어놓는 겁니다. 회고 시간이라 거나, 워크샵 때 적절한 분위기가 무르익었거나, 아니면 평가 면담 등을 하는 시간, 아니면 리더와 티타임 시간이라든지요. 스트레스를 받는 부분이, 리더가 뭔가 정해놓고 잘 지원해주지를 않아서 업무상 불편이 있는 지점 같습니다. "그럴 바에는 룰을 바꾸시죠."라고 말하고 싶을 수 있지만, 결정권은 리더에게 있습니다. 내가 말할 수 있는 건 이래이래서 어려운 점이 있다고 고민을 털어놓는 거죠. 리더의 역할 중에 구성원의 고민을 들어주고 막힌 지점을 뚫어주는 것도 업무이니까, 리더가 해결점을 찾아주길 바래보면 좋겠습니다. 아니면, 고민을 털어놓았을 때, 리더가 님에게 물어볼 수 있죠. 님 생각에는 어떻게 하면 좋겠어? 리더 뿐 아니라 동료들 간에도 남의 기분을 상하게 하면서까지 업무를 잘해보아도, 얻는 것보다 장기적으로 잃는 것이 더 많을 수도 있겠습니다. 만약 리더에게 믿음이 가지 않는다면, 팀을 옮기시는 게 나을 수 있습니다. 상호신뢰가 없는 관계에서 팀이 잘 돌아가기도 어렵고, 나 개인적으로도 손해입니다. 잘 맞추기 어렵다면 잘 맞는 리더가 있는 조직으로 전배신청을 하는 것도 방법입니다. 한줄요약: 자칫 지금의 기분 상태에서 문제점을 지적하면 상대가 불쾌할 수도 있겠다. 톤앤매너 조심하자.

안녕하세요 :) 우선 제가 경험한 회사의 경우는 10명 이상 같은 저장소를 사용했었고, 하드웨어에 배포되는 제품이다 보니 안정성을 위해 배포/형상 관리 담당자가 있었습니다. 작성자분도 많은 동료들과 함께 같은 저장소를 사용해야 하고, 서비스가 많아 보이는데요. 지금과 같은 상황을 방지하고자 개발 리더가 룰을 정한 것 같습니다. 개발자들이 각자 개발한 기능을 빠르게 배포 못해서 답답할 수는 있지만 급하게 작업을 하다 보면 서비스의 안정성이 흔들릴 수밖에 없습니다. 이런 상황은 룰을 깨는 것보다 커뮤니케이션을 통해서 해결하는 게 좋습니다. 제 생각에는 개발 리더가 바쁘면 배포 역할을 다른 동료에게 위임해서 서비스의 안정성을 지키는 게 좋을 것 같습니다.

저희는 최소 1명이 리뷰를 했으면 아무나 머지할 수 있게 했습니다. 앱은 아무나 배포가능하게 workflow dispatch로 만들어놨고 백엔드는 개발은 각자 상용은 필요할때 리더에게 요청해서 배포

협업자가 적을수록 사실 배포 담당자는 득보단 실이 많죠. Git 관리 프로세스는 제가 다녔던 업체마다 다 달랐습니다. 큰 기업은 보통 dev / stage(혹은 release) / 운영 = 3개로 운영 작은 곳은 dev / 운영 = 2개로 운영 생각보다 2개로 운영하는 곳도 많습니다. 기본적으로 2개로 관리하든 3개로 관리하든, 혹은 4개(아직 경험한적은 X)든 dev와 별도의 test 브랜치를 두는데(글쓴이가 말하는 test 브랜치와 용도가 다를 수 있음) 모든 개발자들이 소스가 바로바로 반영될 수 있는 정말 테스트 용도의 브랜치가 있어야 효율적이었습니다. 이래야 Merge나 Rebase 단계에서 모든 개발자들의 부담이 사라져요. 그런데 배포 관리자의 입장에서는 저런 브랜치가 오히려 부담이죠. 글쓴이 분의 의도처럼 개발이 이루어지려면 배포 관리자가 따로 있어야 하나요?라는 질문에 저는 예라고 답하고 싶습니다. 스테이징 단계도 아니고 그 이전 단계부터 소스코드 관리가 필요하면 배포 관리자가 따로 있어야한다고 생각합니다. 예를 들어 백엔드 만지는 그룹에 개발자가 5~6명만 넘어도 글쓴이분 의도대로 관리하려면 한 개발자가 매일 반나절 이상 배포관리만 해야 합니다. 특히나 글쓴이분 케이스에서는 리더가 배포 관리를 겸하시는 것 같은데 상황상 이게 말이 안된다 생각합니다. 그냥 말 그대로 소스 merge해서 에러 나나 안나나 정도의 체크면 모를까. 글쓴이분 의도처럼 버그 줄이기 위한 관리라면 테스트가 빠질 수가 없는데 리소스가 가능한가 싶어서요. 별도의 배포 관리자가 따로 있지 않는한 불가능하다고 생각됩니다.

최근까지 이렇게 했습니다. master가 있습니다. 다음 버전이 1.0.1이고 대규모(여러 작업이 필요한) 신규 기능이 renewal인 경우 1. master에서 1.0.1를 생성 2. renewal에서 1.0.1를 생성 3. 1.0.1에 버전 상향 PR(PR은 1명 이상 리뷰해야 병합 버튼 활성) 4. 단일 작업인 경우 1.0.1에 바로 병합 renewal 작업은 renewal에 병합 6. renewal 작업 완료시 renewal branch만 배포해서 1차 테스트 7. (renewal은 작업 중 1.0.1이 출시된 경우 1.0.1를 rebase) 8. 1차 테스트 완료 시 1.0.1에 병합 9. 1.0.1 QA 진행 10. 1.0.1 출시 11. master에 1.0.1 병합 앱 기준입니다. 서버는 아마 이렇게 하긴 힘들지 않을까 싶네요. 각자 로컬 환경의 서버를 클라이언트에 붙일 수 있는 환경이어야 가능하지 않을지

1. 작업 순서가 일반적인 것은 아닙니다. 작업 순서는 조직 및 프로젝트에 따라 다를 수 있으며, 팀의 요구 사항과 프로세스에 따라 결정됩니다. 하지만 일반적으로 개발자들이 개별적으로 개발한 기능을 머지하고 테스트하며 점진적으로 배포하는 방식은 일반적인 워크플로우입니다. 2. test 브랜치부터 배포까지 개발 리더가 담당하는 것은 팀의 조직 문화와 프로세스에 따라 다를 수 있습니다. 개발 리더가 해당 역할을 수행하는 경우도 있지만, 개발자들이 각자 테스트 브랜치를 머지하고 배포하는 경우도 있습니다. 주요한 것은 품질 보증을 위한 적절한 검토와 테스트 과정을 거쳐야 한다는 것입니다. 팀원들이 충분한 검토와 테스트를 수행할 수 있는 방법을 모색하는 것이 중요합니다. 3. 개발자들이 각 스테이지별로 소스 관리와 배포를 수행하는 것은 가능합니다. 그러나 이 경우 충분한 테스트와 검토 절차를 갖추지 않을 수 있으며, 버그가 발생할 가능성이 높아질 수 있습니다. 따라서 충분한 검토와 테스트를 보장하기 위해 품질 보증 역할을 수행하는 개발 리더나 품질 보증 담당자를 두는 것이 좋습니다. 개발 리더나 품질 보증 담당자는 팀원들의 작업을 검토하고 품질 보증을 위한 절차를 수행하여 안정적인 배포를 보장할 수 있습니다. 프로젝트의 특성과 조직의 문화에 따라서 워크플로우와 역할 분담이 달라질 수 있습니다. 중요한 것은 모든 팀원들이 충분한 검토와 테스트를 수행하고, 안정적인 배포를 위해 적절한 프로세스를 따르는 것입니다. 팀원들과 함께 효율적이고 안정적인 프로세스를 고민하고 개선하는 것이 중요합니다.