단일 보고서 시작

단일 보고서 시작

mono: 단일repo: 창고
말 그대로 단일 창고로 여러 프로젝트를 관리하는 것이다

예컨대.

하나의 서비스

sample-project-backend: 백엔드

sample-project-user: 사용자 헬프데스크

sample-project-partner: 협력업체용 관리 화면

sample-project-staff: 사내 관리 화면

이처럼 여러 창고를 통해 하나의 서비스를 구축하는 경우가 많다.
단일 리포트로 구성되면 이렇게 하나의 창고로 관리할 수 있다

apps/
 └ user-front-sp
 └ user-front-pc
 └ backend
 └ partner
 └ staff
libs/
 └ shared/
   └ constants/
   └ components/

세분화(Uber의 예)

├── apps
│   ├── iphone-driver
│   ├── iphone-eats
│   ├── iphone-rider
├── libraries
│   ├── analytics
│   ├── …
│   └── utilities
└── vendor
   ├── fbsnapshottestcase
   ├── …
   └── ocmock

참조
https://eng.uber.com/ios-monorepo/
Tips: 이 개념을 채택한 주요 기업

Google

Facebook

Microsoft

Uber

Airbnb

Twitter

단일 보고서의 이점

리소스 공유

같은 창고에서 import

가능

linter 등의 설정을 통일적으로 관리할 수 있음

각 프로젝트의 자유로운 디자인, 기술 선택

때문에, 웨이트 서비스 등과도 잘 어울린다

생기는 의문

포장 버전 관리 힘들죠?

CI/CD가 느려지겠죠?

의존 관계를 모르면 예상치 못한 변경이 생기겠죠?

공통 부분에 파괴적인 변경이 있을 경우 영향 범위가 확대되겠죠?

포장 버전 관리 힘들죠?

A. 힘들 때도 있어요.
공구Nx에서 원칙적으로 이 창고 안의 물건은 같은 포장의 버전 관리 하에 있다.
따라서 버전을 올리려면 다 올려야 돼요.lerna에서 각 디렉토리의 다른 패키지 관리
이것들은 모두 길고 짧기 때문에 자신의 서비스와 팀의 상태를 고려하여 선택해야 한다

CI/CD가 느려지겠죠?

A.안 돼요.Nx 도구와 CI/CD의 조합이 더 빠를 수 있음Nx 등 도구 관리 코드의 의존 관계는 변경 가능한 부분만 재구성하고 재테스트한다.
캐시에 사용되는 다른 내용은 수정과 무관한 부분의 구축과 테스트 시간을 단축할 수 있다.

예컨대

relay와 user의 부분만 바뀌면 다음과 같은 의존 관계의 영향을 받을 수 있다.user-e2e 및 components의 경우 재구축 및 재테스트 필요 없음

의존 관계를 모르면 예상치 못한 변경이 생기겠죠?

이 가능하다, ~할 수 있다,...그러나 도구를 정확하게 사용하면 이런 가능성을 줄일 수 있다

Code Owners

Giithub 및 Gitlab의 기능CODE_OWNERS
다음과 같은 방법으로 권한을 설정할 수 있습니다.

apps/app-a/* @kobori.hikaru
apps/app-b/* @tarou
libs/components/* @kobori.hikaru @tarou

이렇게 설정하면 변경에 따른 영향을 감지할 수 있습니다.

의존 관계의 구속

constants와 같은 도구에서는 메타데이터를 추가하여 import 범위를 줄일 수 있다
예컨대

apps/
 └ user-front-sp
 └ user-front-pc
 └ backend
 └ admin
 └ sadmin
libs/
 └ components
   └ user/
   └ admin/
 └ api-client
 └ constants

이러한 구조로 구성될 때 Nx 또는 libs/components/user/*에서 가져오는 것을 원하지 않는다admin메타데이터 추가

이렇게 오류를 표시할 수 있습니다.

공통적으로 파괴적인 변경이 있을 경우 영향 범위가 확대되겠죠?

이 가능하다, ~할 수 있다,...
의존 관계가 있는 프로젝트에서는 반드시 여러 버전을 제작하는 데 공을 들여 구버전에서 신버전으로 이행해야 한다

개인 의견 총결산

Good

리소스 공유

각 프로젝트의 자유로운 기술 선택, 디자인

잘하면 건축시간 단축

반드시 주의해야 할 일

리소스의 공유 범위

도구를 사용하려면 엄격하게 제한해야 한다

설계

각 프로젝트가 분산된 디자인이 될 수 있음

의존성이 강한 라이브러리의 초기 설정을 꼼꼼히 설정해야 한다

이후 파괴적인 변경이 많으면 힘들어