개발 블로깅/팀 문화 및 시스템
-
TBD(Trunk Based Development) 전략이란?개발 블로깅/팀 문화 및 시스템 2022. 6. 17. 00:00
이번에 팀에서 모노레포로 프로젝트를 관리하게 되면서 팀 내 워크플로우 방식을 Trunk Based Development 방식으로 변경하게 되었다. 이전에는 Git Flow, Github Flow 정도밖에 몰랐는데, 이번에 새롭게 알게 된 TBD(Trunk Based Development) 방식에 대해 정리해보려고 한다. TBD의 목적 평소 소규모 팀에서는 코드가 많지 않고 인원이 적은 만큼 서로 각자 작업하고 반영하는 사항에 대해서 충돌이나 컨텍스트가 꼬이는 상황이 매우 적다. 그러나 어느 정도 규모가 커질수록 많은 개발자가 같은 코드를 유지하는 것이 어려워지며 이러한 문제는 내가 작업한 사항을 Trunk 브랜치에 반영하려고 할 때 충돌로 이어질 수 있다. 이러한 충돌을 줄이기 위해 팀 내에서 최대한 동..
-
팀워크를 위한 모노레포(Monorepo) 시스템 구축, 그리고 회고개발 블로깅/팀 문화 및 시스템 2022. 5. 30. 00:34
꽤 오랜 시간 동안 모노레포 이전 및 안정화 작업을 계속 진행해왔다. 그래도 이제는 상대적 주요 프로젝트들은 모두 모노레포로 이전이 완료되었고, 팀원들이 이제 모두 모노레포 내에서 작업이 가능한 수준으로 안정화를 시키게 된 것 같다. 콴다 팀 블로그에도 해당 블로그 글을 쓰긴 했지만, 내 스스로도 좋은 경험 및 큰 성장 과정이 되었던 것 같아서 내 블로그에도 기록을 남겨보고 싶어 이렇게 한번 더 작성을 해본다. (비록 내용이 거의 중복이 되겠지만..) 우리 팀은 이번 모노레포를 통해 새로운 팀워크 방향성이 생기면서, 이를 통해 향상된 팀 협업 요소들을 정리해 보려고 한다. 우선 그전에, 우리가 어떤 계기로 인해 팀 전체가 모노레포 시스템을 이용하기로 결정하게 되었는지 배경을 먼저 소개하고 싶다. 모노레포..
-
[애자일] 함께 자라기-자기계발은 복리로 돌아온다개발 블로깅/팀 문화 및 시스템 2022. 5. 29. 10:25
우리는 학교에서 받은 수업 방식인 교육학습이 아닌, 현재와, 사회에서 정답이 정해져 있지 않고 무분별한 요소들과 명확하지 않는 야생 학습이 되어야 한다. 당신은 몇 년 차? 강한 놈이 오래 가는 게 아니라, 오래 가는 놈이 강한 거더라. 자기계발은 복리로 돌아온다 애자일은 피드백을 짧은 주기로 받고, 다음 사이클에서 동일한 활동을 하게될 때 더 나은 방식으로 진행할 수 있도록 하는 것이다. 이는 소프트웨어 뿐 아니라, 모든 활동에서 그렇다. 예시) 골프 골프 연습 후 빠른 피드백을 받으라. 골프를 치고 1년뒤에 받는 피드백은 의미가 없다. 자신을 곱하라. 더하기 사고. - 쓸데없이 낭비되는 시간을 줄이고 잠자는 시간을 줄여서 일하는 시간을 늘리는 것. 곱하기 사고. - 집단의 지능을 높이는 것. 어떻게 ..
-
모노레포 환경을 더욱 가볍게 - git sparse checkout개발 블로깅/팀 문화 및 시스템 2022. 5. 28. 00:46
현재 모노레포를 사용하면서 어떻게 하면 우리 팀원 모두가 모노레포를 더욱 안정적으로 사용할 수 있을지 많은 고민과 실험 중에 있다. 여러 개선할 점 중 하나가, 모노레포를 내 로컬에서 이용할 때 너무 무거운 느낌, 그리고 여러 프로젝트가 함께 섞여 있다 보니 파일 찾는 점에 어려움이 있다는 단점이 많은 팀원들의 의견이다. 그래서 어떻게 하면 많은 파일들을 가지고 있는 모노레포를 조금이라도 안정적으로 가볍게 사용해볼 수 있을까 리서치를 하다가 팀원 중 능력자 @yeoul을 통해 git sparse checkout라는 멋진 git 커맨드를 알게 되어서 이를 한번 정리해 보려고 한다. 그전에 우리가 평소 사용하던 git checkout이란 기능에 대해 더 자세히 알 필요가 있다. 우리가 흔히 새로운 브랜치를 ..
-
[Github] Code Owner로 Auto Assign 하기개발 블로깅/팀 문화 및 시스템 2022. 3. 29. 01:47
Code Owner란 Github에는 Code Owner라는 기능이 있는데, Repository 내에 특정 파일이나 특정 디렉토리, 원하면 특정 확장자 별로도 Owner를 지정하여 파일 및 코드를 관리할 수 있는 방식이다. 이를 활용하면 코드리뷰를 위해 PR 생성 시, 작업한 파일에 관련된 Owner들을 자동으로 PR(Pull Request) Reviewer로 지정할 수 있다. Code Owner 사용법 사용법은 아주 간단하다. 프로젝트의 Root 경로에 '.github/CODEOWNERS' 파일을 생성 후, 패턴에 맞게 오너를 설정해주면 된다. # .github/CODEOWNERS 아래 패턴을 참고하여 작성하면 된다. # 이것은 주석입니다. # 담당자를 지정할 때는 github ID 혹은 github ..
-
[2020.06.13] 더 좋은 커밋 메시지를 남기자개발 블로깅/팀 문화 및 시스템 2020. 6. 13. 14:09
오랜만에 내 github에 있는 옛날 프로젝트 코드들을 살펴보았다. 지금처럼 git에 익숙지 않던 때인지라, commit도 그렇겠지만, 무엇보다 커밋 메시지가 매우 엉망이었다. 내가 남긴 과거의 프로젝트 커밋 메시지... 너무 창피한 이력들.. 요즘 드는 생각이 있다면, 영어 메시지로 남긴다면 더 좋기야 하겠지만, 어설픈 영어로 작업한 내용에 대한 설명이 부실해진다면 차라리 한글로 더 명확하게 메시지를 남기는 것이 좋겠다는 생각이다. 트레바리에서 일하면서는 주로 한글로 커밋 메시지를 남기고 있다. 이렇게 메시지 한 줄을 이용해서 과거에 작업했던 내용을 더욱 자세히 알 수 있게 된 것 같다. 그런데 문득, 더 좋은 커밋 메시지를 작성할 수 있지 않을까 라는 생각이 들었다. 그래서 인터넷에 찾아보니 좋은 커..