개발자
현재 FE 일부 서비스를 monorepo 안에서 관리하고 있습니다. 이 안에서 총 4개의 서비스를 운영중이고 서로 공통으로 사용하는 컴포넌트나 helper, util 등은 shared 라는 워크스페이스로 분리하였습니다. - apps ㄴ web1 ㄴ web2 ㄴ web3 ㄴ web4 - pacjages ㄴ shared 배포할때 변경점인 change path에 대한 고민이 있었는데, 현재는 shared가 변경되면 web1,2,3,4 전체가 배포되도록 구성했습니다. 서비스별로 수정된 shared에 의존적인 프로젝트를 특정하기 어려웠기 때문인데요. 혹시 더 나은 방법으로 운영하는 방법이 있을까요?
답변 1
수라정
작성자
프론트엔드 개발자 • 2024년 06월 26일
답변 감사합니다. 중계 패키지라 함은 어떤걸 말씀하시는지 잘 감이 안오는데요. 예를 들면 Changesets 같은걸 말씀하시는걸까요?
포크코딩
별빛상단 단주 • 2024년 06월 26일
CICD 같은거 생각하면 changeset 같은 라이브러리도 좋고, 직접 다루고 싶다면 인터페이스 계층을 하나 추가하라는 의미였습니다! (SOLID 원칙에서 D)
수라정
작성자
프론트엔드 개발자 • 2024년 06월 26일
답변 감사합니다. 개념적으로 이해 시켜주셨으니 방법을 찾아봐야겠네요.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 06월 17일
모노레포의 장점 중 하나는 공유 코드를 한 곳에서 관리할 수 있다는 것입니다. 그러나, 모든 서비스가 모든 공유 변경에 의해 트리거되게 설정하면 비효율적일 수 있습니다. 더 나은 관리 방법 중 하나로는, 빌드 시스템을 사용하여 오직 변경이 발생한 패키지만 빌드하고 배포하는 것을 추천드립니다. 이는 Lerna, Nx와 같은 도구를 사용하여 달성할 수 있습니다. 예를 들어, Nx에서는 ‘affected’ 명령이 제공됩니다. 이 명령은 git diff를 기반으로 변경된 파일을 검사하고, 그에 따라 어떤 프로젝트가 영향을 받았는지 파악합니다. 따라서 shared 패키지가 변경된 경우에도, 그것에 의존하는 서비스만 빌드 및 배포하게 됩니다. 다른 접근법으로는 각각의 Shared component를 개별적인 package로 분리하고 각 서비스에서 필요한 버전을 명시적으로 가져오는 방법도 있습니다. 이렇게 하면 각 서비스들이 엄격한 버전 관리를 가져갈 수 있으며 실제 필요할 때만 해당 컴포넌트를 업데이트하게 됩니다. 이러한 프로세스를 CI/CD 파이프라인에 적용하면, "항상 모든 것을 배포하는" 방식 대신 변경된 부분만 빌드 및 배포되도록 최적화할 수 있습니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!