메로그

왜 실과 팀, 각각의 그라운드룰이 필요했을까?실 차원에서 별도의 그라운드룰을 만들자는 논의가 나왔고, 우리 팀은 이미 팀 차원에서 자체적인 그라운드룰을 운영하고 있었기 때문에 실 그라운드룰 작성을 맡아서 진행하게 되었습니다. 그래서 이제 진행하면서 느낀 부분에 대해서 말씀드리겠습니다.먼저 실과 팀의 그라운드룰은 성격 자체가 다르다는 점에서 출발했고 그래서 각각의 기준을 명확히 잡는 것이 우선이라고 판단하였고 거기에 대한 분리부터 시작해야 한다고 생각이 들었습니다.실 그라운드룰의 성격‘실’ 단위는 단순히 한 팀 내부의 약속을 넘어서는, 조직 전체의 정합성과 방향성을 맞추는 상위 개념의 기준입니다!그래서 이 룰은 자주 변경되면 안 되고, 구성원 모두가 신뢰하고 따를 수 있는 기준이 되어야하고 너무 디테일하거..

프로젝트에 Git Flow를 도입해 브랜치 전략을 체계적으로 운영하고 있었지만, prod 배포 시마다 수동으로 태그를 만들고 릴리즈 노트를 작성하는 작업은 여전히 개발자의 몫이었음. 이런 반복적인 업무는 개발에만 집중할 수 없는 환경을 만들게 되었고, 이를 해결하기 위해 배포 시점에 자동으로 버전 태그를 생성하고, 커밋 로그 기반으로 릴리즈 노트를 자동 생성하는 GitHub Actions 워크플로우를 구축.시나리오우선 도입한 깃플로우 전략에 따라서 release/, feature/, hofix/ 이렇게 별도 브랜치를 구분해서 완료시켜 dev, prod 로 브랜치 병합 작업을 진행했음.예를 들어, release/v1.0.0 브랜치를 prod로 머지한다고 가정하면, 이 브랜치명에서 v1.0.0이라는 버전 정..