서로 성격은 다르지만 관련 있는 여러 프로젝트를 어떻게 통합(or 하지 않는걸) 선호하시나요?
예를 들어, 동일 서비스에 대해 front-end, back-end(api), serverless, batch, pipeline, ... 등등 있다면
-
Mono-repo
서비스가 같다면 레포지토리는 하나다! 각 프로젝트는 패키지/폴더 구조로
-> 커밋 관리는 어떻게..? CI/CD나 pre-commit 같은 hook 복잡해질텐데.. -
Git Submodules
성격이 다르면 최소한 git 히스토리는 따로 관리해야지! 그래도 최대한 하나로 묶어서..
-> sub module sync 등 러닝 커브.. 머지도 복잡해지고.. 다른 개발자들이 따라올까? -
각자 도생 repo
심플하게! 다른 프로젝트면 레포도 다르게!
-> A 서비스 보려면 무슨 레포 봐야해요? 어 이거랑, 저거랑,.. 또 뭐 있더라...
정답은 없는것 같지만 어떤 걸/왜 선호하시는지 궁금합니다!
- API 서버를 직접 구현하는 경우에는 API 규약을 맞추기 위해서 프론트엔드-백엔드 모노레포를 사용했습니다
- Supabase와 같이 DB에 의존성이 강한 2티어 아키텍처 프로젝트의 경우에는 스키마 자동 생성 도구에 의존해서 프론트엔드와 백엔드를 별도의 레포로 분리했습니다
- 디자인 시스템의 경우에는 아직 완전히 해결하진 못했는데 일단 서브모듈은 학습 곡선이 가팔라서 철회했고 프로젝트 템플릿이 나은 방향이라고 생각중입니다
저희 회사의 경우에는 프로젝트 당 팀원이 적고 프론트엔드와 백엔드의 언어와 기술스택이 분리되어있어서 직무간 교차 기여는 거의 없었습니다. 모든 IT 시스템과 마찬가지로 결국 조직 구성을 따라가는 것 같네요
제가 Mono-repo 경험이 없어서 궁금한게 하나 있는데요. Mono Repo로 할 때, 여러 프로젝트나 서비스에 공통적인 모듈(ex. 디자인 시스템)은 각각 Mono Repo에 들어가는 식이 되나요? 아니면 얘는 어쩔 수 없이 별도의 Repo로 빠져서 참조하는 식으로 하나요?
저는 회사에서나 개인 프로젝트에서느 프론트 백엔드 배치 등 구분하지 않고 하나의 git으로 관리하고 있습니다.
하위호환을 지키기보다 둘을 같이 수정하면 편한 경우도 있고요. 둘 다 팀 규모가 작아서 괜히 나눠서 좋을 게 없다고 할지... 깃허브 액션은 변경된 부분만 돌게 설정해두는 수고 정도는 감수할 만 했습니다. 무엇보다도 백엔드 프론트 구분보다는 서로가 서로에게 기여할 수 있는 게 좋다고 할까요. (프롬트 작업하다가 백엔드에 필요한 게 있으면 직접 추가하거나, 에러도 직접 고치는 등...)
음 확실히 규모가 작거나 역할군이 엄격하지 않으면 모노레포를 선호하시는거 같군요! 깃 히스토리가 섞이는? 것도 크게 게의치 않으시나요? (어차피 다 보는 코드니까?)
모듈이 별로 크지 않다면 모노레포
모듈이 크다면 서브모듈
아니면 오픈소스 배포할 때 서브모듈만 기여하게 하고 메인레포는 자체적으로 관리하게 설정하고 싶다면
서브모듈로 분리하는 것 같습니다.
근데 서브모듈 끼면 오픈소스할 때 다른 사용자가 기여를 위해 테스트나 빌드관련해서 문서 작성하기가 조금은 복잡해지는 것 같긴합니다.
그래서 개인적으로는 둘의 기여가 다른 경우가 아니라면 모노레포로 하거나
다른 깃헙으로 하는데 각각을 패키지로 배포하거나, 도커이미지로 하는 방식으로 관리하기는 것 같습니다