I. 배경

대규모 웨어하우스 R&D 프로세스의 시험 과정에서 프론트엔드 모노레포에는 여러 비즈니스 도메인의 애플리케이션, 공유 구성 요소 라이브러리, 도구 및 기능, 코드 공유 실현, 종속성 관리 편의성, 팀 협업 개선 등 정적 리소스가 포함되었지만 대규모 웨어하우스 코드 파일 권한 문제도 직면하게 되었습니다. 다양한 비즈니스 도메인의 R&D가 웨어하우스 모드에서 원활하게 개발되도록 하는 방법은 효과적인 권한 관리 방법과 떼려야 뗄 수 없는 관계입니다. 좋은 권한 관리 방식은 R&D 친구들이 혼동이나 불필요한 복잡성 없이 프로젝트의 다른 부분을 쉽게 찾고 이해할 수 있도록 하며, 동시에 R&D 친구들이 협업하고 함께 작업할 수 있도록 하고 코드의 품질과 안정성을 유지하기 위해 코드 병합 변경 사항이 코드 검토를 받도록 해야 합니다. 이 글에서는 프론트엔드 다키마쿠라 모노레포가 실제로 직면한 몇 가지 문제와 점차 자리를 잡아가고 있는 모범 사례를 통해 권한을 어떻게 생각하고 설계하는지 설명합니다.

사전 연구

Google의 소스 코드는 회사의 가장 중요한 자산 중 하나이므로 보안 기능은 Piper의 설계에서 핵심적인 고려 사항입니다. Piper는 파일 수준 액세스 제어 목록을 지원합니다. 대부분의 리포지토리는 모든 Piper 사용자가 볼 수 있지만, 중요한 사항은 다음과 같습니다. 대부분의 리포지토리는 모든 Piper 사용자가 볼 수 있지만 중요한 구성 파일이나 비즈니스 크리티컬 알고리즘을 포함한 파일은 더 엄격하게 제어할 수 있습니다. 또한 Piper의 파일에 대한 읽기 및 쓰기 액세스가 기록됩니다. 민감한 데이터가 실수로 Piper에 커밋된 경우 해당 파일을 삭제할 수 있습니다. 관리자는 읽기 로그를 통해 문제가 있는 파일이 제거되기 전에 누가 해당 파일에 액세스했는지 확인할 수 있습니다.

일반적으로 Google은 파일 수준 액세스 제어 목록을 지원하기 위해 내부적으로 Piper를 개발했으며, 대부분의 리포지토리는 모든 Piper 사용자가 볼 수 있지만 중요한 구성 파일이나 비즈니스에 중요한 알고리즘이 포함된 파일은 더 엄격하게 제어할 수 있고 Piper의 파일에 대한 읽기 및 쓰기 액세스는 기록됩니다.

• Git에서 제공하는 후크 기능을 기반으로 파일 쓰기 권한 제어 가능: Git 자체는 코드 개발 과정에서 다양한 후크 기능을 제공하는 분산 파일 시스템으로, 파일 내부의 다양한 후크 기능에서 체크섬을 수행하고 코드 파일 쓰기 권한 제어는 할 수 있지만 코드 파일 읽기 권한 제어는 할 수 없습니다;
• 파일 및 디렉터리 권한을 제어하는 Gitlab의 기능을 기반으로 구축: Gitlab은특정 파일 또는 디렉터리에 대한 권한을 설정하고 파일에 대한 '관리자' 권한을 가진 사용자 또는 사용자 그룹을 지정할 수 있는"보호 환경" 이라는 개념을 도입했습니다. '관리자' 권한은 파일 변경 및 병합 요청을 관리할 수 있는 권한으로, 보다 세분화된 파일 수준 권한 제어에 사용할 수 있습니다. 물론 이 방법은 코드 파일 쓰기 권한만 제어할 수 있고 코드 파일 읽기 권한은 제어할 수 없습니다.

위의 세 가지 연구 구현에서 파일 시스템 읽기 및 쓰기 액세스 제어를 완전히 달성하려면 R & D 프로세스 및 비즈니스 시스템에 적합한 파일 시스템 세트에 대한 연구가 불가피하고이 구현에 드는 비용이 매우 크며 고려해야 할 실제 적용 시나리오를 기반으로 할 때 그다지 필요하지 않습니다. 따라서 이 글에서는 주로 Git과 Gitlab 기반 기능에 기반한 훅 기능을 중심으로 실습 과정을 상세히 설명합니다.

디자인 구현

프론트엔드 모노레포 실무에서 권한 모듈의 설계는 잘 고려하지 않으면 매우 나쁜 R&D 경험을 가져올 수 있으며, 권한 구현은 코드 로직 수준뿐만 아니라 여러 측면을 고려해야 합니다. 실제로는 분기 모델의 정의, 역할 권한의 배포, 파일 디렉터리 권한, 권한 제어의 개발 프로세스를 네 가지 영역에서 구체적으로 고려해야 합니다.

브랜칭 모델의 정의

브랜칭 모델의 정의, 즉 큰 저장소 아래에 있는 여러 비즈니스 도메인의 파일 디렉터리 정의, 명확한 디렉토리 구조와 파일 명명 규칙은 R&D가 필요한 파일을 매우 빠르게 검색할 수 있도록 하는 데 매우 중요합니다. 프론트엔드 사일로의 분기 모델은 다음과 같이 정의됩니다:

• 앱: 비즈니스 도메인의 카탈로그 교차점

  • 공유: 비즈니스 도메인의 일반 종속성 카탈로그
  • 해외-크롬-마이크로: 특정 애플리케이션 이름
  • ...이후 추가된 애플리케이션이 비즈니스 도메인 디렉터리에 있습니다.
  • 컴포넌트: 비즈니스 도메인의 일반 컴포넌트 카탈로그
  • ... 확장 카탈로그를 사용자 지정할 수 있습니다.
  • 글로벌: 국제 비즈니스 도메인 애플리케이션 카탈로그
  • ... 이후 비즈니스 도메인 디렉터리에 추가되는 항목은 App 디렉터리에 있습니다.

• 패키지: 프론트엔드 플랫폼 일반 컴포넌트, 도구 기능, 구성 파일, Hook 종속성

  • 구성 요소: 플랫폼 공통 구성 요소 카탈로그
  • 훅: 플랫폼 공통 훅 카탈로그
  • ... 확장 카탈로그를 사용자 지정할 수 있습니다.

파일과 디렉터리의 시맨틱 네이밍을 사용하면 혼동과 오류가 줄어들고 브랜칭 모델이 보다 명확하게 정의되며, R&D 구성원은 집중하고 있는 비즈니스 애플리케이션이 어느 디렉터리에 있는지 명확하게 알 수 있고 동시에 다른 비즈니스 도메인의 코드가 필요한 경우 쉽게 검색할 수 있습니다.

위는 웨어하우스 B측 애플리케이션의 분기 모델, C측 H5 애플리케이션과 노드 서비스 애플리케이션의 융합에 대한 정의일 뿐이며, 웨어하우스 카탈로그는 상대적으로 더 복잡하므로 여기서는 자세히 다루지 않겠습니다.

역할과 권한 할당하기

사일로 모드에서 역할 권한은 다른 방향으로 이동하지 않고 Gitlab이 이미 가지고 있는 권한인 소유자, 관리자 및 개발자를 따릅니다.

• 소유자: 즉, 코드 저장소의 소유자로, 소유자는 가장 높은 권한을 가진 역할이며 프로젝트에 대한 모든 권한을 가집니다. 프로젝트 멤버를 추가 및 제거하고 액세스 수준, 브랜치 보호 규칙 및 통합 설정을 포함한 프로젝트 설정을 수정할 수 있습니다. 프로젝트의 소유자만 프로젝트를 이전하거나 삭제할 수 있으며, 권한 구성 역할은 TL입니다.
• 메인테이너: 프로젝트의 코드, 이슈, 병합 요청 등을 관리할 수 있는 코드 리포지토리의 메인테이너입니다. 브랜치 생성 및 관리, 파일 추가 및 삭제, 이슈 생성 및 닫기, 브랜치 병합 및 푸시 등의 작업을 할 수 있습니다. 메인테이너는 프로젝트의 액세스 수준을 변경하거나 새 메인테이너를 추가할 수 없으며, 권한 구성 역할은 TL/PM입니다.
• 개발자: 코드 리포지토리의 개발자로, 코드를 변경하고 커밋할 수 있는 권한을 가진 프로젝트의 일반 멤버입니다. 이슈를 만들고 할당하고, 요청을 병합하고, 코드를 보고, 변경 사항을 커밋하고, 브랜치를 푸시 및 풀링할 수 있습니다. 권한 구성 역할은 Developer입니다.

여기서 고려해야 할 점은 개발자가 개발자 권한만 있으면 웨어하우스의 모든 디렉토리에서 코드를 수정할 수 있고 로컬로 제출할 수 있기 때문에 로컬 소스 코드 종속의 위험이 크며, 로컬 코드 빌드와 운영 환경 빌드 간에 불일치가 발생하여 R&D 프로세스에서 상황을 잘 인지하지 못하면 온라인 문제가 쉽게 발생할 수 있다는 점입니다 . 코드 공유 원칙에 따라 코드 파일에 대한 읽기 액세스를 제어하지 않고 R&D가 코드를 수정할 수 있도록 허용하지만, 수정된 코드의 실행에 대해서는 강력한 프로세스 제어가 이루어집니다. 여기에는 Gitlab의 브랜치 보호 메커니즘과 파일 소유자 권한 구성이 포함됩니다.

파일 디렉터리 권한 구성

GitLab은 파일 디렉토리 권한을 지원하지 않으며, 파일 디렉토리 권한 제어는 주로 스테이징 영역에서 변경된 파일을 식별하고 코드가 제출될 때 파일 권한을 확인하는 Git의 후크 기능에 의존합니다. 프로세스 설계는 그리 복잡하지 않으며 파일 디렉토리와 개발 간의 권한 매핑을 구성하기 위한 추가 플랫폼만 개발하면 됩니다. 깃랩은 파일 디렉터리 권한을 지원하기 시작하여 보다 세분화된 파일 수준의 권한 제어에 사용할 수 있으며, 내부적으로 파일 디렉터리와 R&D 간의 권한 매핑 관계를 지원합니다. 구성 페이지는 다음과 같습니다:

해당 파일 또는 디렉토리 경로 아래의 파일에 변경 사항이 있는 경우 CodeReview 프로세스 중에 해당 소유자 멤버가 이를 확인해야 MR 코드가 허용됩니다. 예를 들어

• 허스키/는 MR이 허용되기 전에 특정 파일 소유자가 검토하고 승인해야 하는 .husky 디렉터리의 파일 변경을 나타냅니다;
• Apps/XXX/crm/ 디렉터리에 있는 파일에 대한 변경은 해당 파일 소유자 중 한 명이 승인해야 MR이 허용된다는 의미입니다.

깃랩에서 제공하는 파일 디렉토리 권한 설정을 사용하면 R&D가 어떤 디렉토리에 있는 파일의 코드를 수정하더라도 해당 파일 소유자가 CodeReview 프로세스에서 검토를 확인해야 하므로 R&D가 실수로 변경해서는 안 되는 파일의 코드를 제출하는 것을 방지하고 온라인상의 문제 발생을 방지할 수 있습니다.

R&D 프로세스의 권한 제어

앞서 언급한 브랜칭 모델의 정의, 역할 권한 할당, 파일 및 디렉터리 권한 구성은 모두 합의가 필요한 규칙이지만 실제 R&D 프로세스에서는 고려해야 할 시나리오가 훨씬 더 복잡합니다. 예를 들어 R&D에서는 MR 프로세스를 우회하여 로컬에서 코드를 릴리스 브랜치에 직접 병합할 수 있습니다. 이러한 시나리오의 경우, 큰 저장소 아래의 브랜치는 MR&CodeReview 프로세스에서 규제되고 강력하게 제어됩니다.

브랜치 보호

빅빈 R&D 모델에는 다음과 같은 명명 규칙을 따르는 네 가지 주요 유형의 브랜치가 있습니다:

• 개발 브랜치 이름 지정 규칙: 기능-[애플리케이션 식별자]-버전 번호-사용자 지정
• 테스트 브랜치 이름 지정 규칙: 테스트-[애플리케이션 식별자]-버전 번호
• 릴리스 브랜치 이름 지정 규칙: 릴리스-[애플리케이션 식별자]-버전 번호
• 핫픽스 브랜치 이름 지정 규칙: 핫픽스-[애플리케이션 식별자]-버전 번호

기능 브랜치는 개발 브랜치로 개발자가 만들고 유지 관리합니다. 릴리스 브랜치와 핫픽스 브랜치는 보호 브랜치로 개발자와 관리자가 모두 만들 수 있지만 개발자 역할은 기능 브랜치를 릴리스 또는 핫픽스 브랜치에 병합할 수 있는 권한이 없습니다. 개발자 역할은 기능 브랜치를 릴리스 또는 핫픽스 브랜치에 병합할 수 있는 권한이 없으므로 유지 관리자 역할이 유지 관리한다. 테스트 브랜치는 다른 테스트 환경에 배포하기 위해 다른 비즈니스 도메인에서 만드는 경우가 많으므로 보호 브랜치로 설정되지 않습니다. 물론 Matser 브랜치도 보호 브랜치이며 소유자 역할만 브랜치 코드를 마스터 브랜치에 직접 병합할 수 있는 권한이 있습니다.

다양한 유형의 브랜치를 정의하고 GitLab에서 제공하는 보호된 브랜칭 기능을 기반으로 R&D에서 로컬로 코드를 병합할 필요가 없도록 하여 기능 브랜칭 코드가 최종적으로 코드에 병합되기 전에 R&D 프로세스의 MR&CodeReview 프로세스를 거쳐야 합니다.

훅 함수

브랜치 제약의 보호를 통해 로컬 직접 릴리스 브랜치의 위험을 피하기 위해 로컬 코드 제출 프로세스에서 권한 확인을 수행하지 않으면 권한이 부족한 코드 검토 프로세스에서 파일 소유자가있을 수 있으므로 변경되지 않은 파일 제출의 코드 제출 단계에서 식별 할 수 있도록 여기서는 Git의 후크 기능을 기반으로 권한 확인을 수행합니다. 프로세스는 다음과 같습니다:

Git Hook은 사전 커밋 및 사전 푸시 노드를 제공하여 오류를 방지하기 위한 권한 검사를 수행합니다. 사전 커밋은 필요하지 않으며, 코드 제출의 효율성에 영향을 미치는 경우 이 단계를 건너뛸 수 있고, 사전 푸시는 필수이며 소유자가 아닌 사람은 로컬 게시를 할 수 없습니다.

물론 반복의 릴리스 브랜치가 마스터 브랜치보다 뒤처지면 마스터 브랜치를 기반으로 생성된 기능 브랜치가 릴리스 브랜치와 일치하지 않아 필수적이지 않은 변경 파일이 많이 생성되고, 개발자는 수정되지 않은 변경 파일이 왜 있는지 의아해할 수 있다는 문제가 있습니다. 이 문제는 웨어하우스 개발 모드에서는 피할 수 없습니다. 분석 결과, 대부분의 변경이 비즈니스 도메인 아래의 앱에서 이루어지고 최상위 레벨의 파일은 거의 수정되지 않기 때문에 로컬 커밋 단계에서 Apps 디렉터리의 체크섬을 필터링하고 일부 핵심 파일의 권한 체크섬만 웨어하우스 최상위 레벨에 유지했습니다.

MR&CodeReview

브랜치 제약 조건을 보호하고 일부 핵심 파일을 훅 함수로 검사함으로써 MR & CodeReview에서 발생할 수 있는 많은 문제를 줄일 수 있습니다. 파일 소유자 권한에 따른 MR 및 CodeReview 흐름: 커밋 단계 -> 푸시 단계 -> MR 생성 -> CodeReview -> MR 실행, 각 단계의 흐름은 다음과 같습니다:

• 커밋 단계에서는 코어 파일의 소유자 확인을 통해 코어 파일이 변경되는 경우를 방지할 수 있습니다;
• 코드 검토 단계에서는 파일 소유자 권한을 확인하여 자신의 비즈니스 도메인 이외의 비즈니스 도메인에 대한 수정 사항이 다른 비즈니스 도메인의 소유자에게 알려지도록 합니다.

마스터 코드의 릴리스 브랜치 라운드가 임시 MR을 만들 때이 프로세스에는 파일 소유자 권한 검사도 있으며 파일 소유자 CR의 다른 비즈니스 도메인이 작동하도록 전달해야하지만 코드의 마스터는 실제로 이미 CR이며 CR을 반복 할 필요가 없으며 동기화가 빈번하며 종종 CR이 될 것입니다. 동기화가 빈번하면 CR이 많이 발생하여 코드 라운드의 효율성이 매우 낮아집니다. 여기서 우리는 효율성 기술 측에 브랜칭 라운드의 마스터 코드를 릴리스할 때 파일 소유자의 유효성 검사를 수행하지 않도록 요청했습니다.

R&D 프로세스에서 권한을 위에서 제어함으로써 로컬 코드 빌드와 프로덕션 환경 빌드 간의 불일치를 방지하고 제출된 코드의 품질과 안정성을 보장합니다.

아이디어의 확장

위의 설계 구현을 통해 기본적으로 대형 창고 아래의 권한 설계는 기존 연구 개발 모델을 충족 할 수 있습니다. 파일 읽기 권한 제어의 단점을 보완하기 위해 프로세스뿐만 아니라 액세스 제어 목록 및 파일 액세스 로그의 구현도 고려했지만 궁극적으로 그다지 필요하다고 생각하지 않으며 창고에 적용되지 않습니다. 여기에서는 몇 가지 아이디어의 액세스 제어 목록 및 파일 액세스 로깅 구현을 공유 할 수 있습니다.

액세스 제어 목록

액세스 제어 목록은 중요한 정보 또는 중요한 코드에 대한 액세스를보다 정확하게 제어하기 위해 큰웨어 하우스 아래의 파일 디렉토리에 대한 액세스 제어입니다. 구글과 메타는 자체 개발한 파일 시스템을 통해 달성했다고 언급했지만, 자체 개발하지 않았다면 반드시 달성하지 못한 것은 아닙니다.

VSCode파일 숨기기 설정하기

파일을 표시하거나 보이지 않게 하려면 다음과 같이 사일로 디렉터리의 .vscode/settings.json 파일에서 files.exclude 속성을 구성하면 됩니다:

{
 "files.exclude": {
 "**/scripts": true
 }
}

위의 구성은 사일로 디렉터리에 있는 스크립트 디렉터리가 표시되지 않는다는 것을 의미합니다.

문제점: .vscode/settings.json 구성을 알고 있는 경우 로컬에서 직접 True를 False로 변경할 수 있으며 구성이 무효화됩니다. 또한 모든 개발자가 VSCode IDE를 사용하는 것은 아니며 다른 IDE를 사용하는 개발자가 많고 모든 개발자의 개발 습관이 다르기 때문에 강력한 제약을 가하기 어렵습니다.

MAC에서 파일 숨기기

MAC에서는 다음과 같이 셸 명령을 통해 파일의 공개 여부를 설정할 수 있습니다:

chflags hidden **/scripts

위의 셸 명령은 사일로에서 스크립트 디렉터리를 숨깁니다. 사일로 개발 모델에서 제공하는 온디맨드 코드 가져오기 기능과 결합하여 코드 가져오기 프로세스가 끝날 때 위 명령을 실행하여 해당 파일을 숨길 수 있습니다.

문제: MAC에서 파일을 표시하는 방법을 알고 있는 경우 셸 터미널에서 chflags nohidden **/scripts를 실행하면 스크립트가 표시되지만 최종 효과를 얻지 못합니다.

액세스 권한 목록의 제어는 실제로 다른 방법으로 달성 할 수 있지만 아이디어의 구현은 기본적으로 문제의 근본 원인이며 많은 역할을 할 수 없으므로 결국 실시 예 내부의 R & D 프로세스의 큰 창고에 있지 않습니다.

파일 액세스 로그

파일 액세스 로깅이란 개발자가 파일을 열 때 로그를 서버로 전송하고 저장하여 민감한 정보가 포함 된 구성 파일을 수신하고 감사 로그 및 모니터링을 설정하여 누가 무엇을했는지 추적하고 이상 발생시 문제를 신속하게 식별하고 대응할 수 있도록하는 것을 의미합니다. VSCode 플러그인을 통해 달성 할 수 있으며, VSCode 시작, 해당 파일 디렉토리 경로를 제공하여 이벤트를 열 수있는 해당 파일 디렉토리 경로를 제공하고, 파일 개발이 열리면 이벤트를 수신하도록 트리거 할 수 있으며, 로그 전달과 관련된 로직 내에서 로깅을 수행하기 위해 이벤트를 수신하여 파일 액세스 로깅 기능을 달성 할 수 있습니다. 구현은 다음과 같습니다:

export function monitorPermissionOfTargetFile(targetFilePath: string, repoRootPath: string) {
 const targetFileFullPath = repoRootPath + targetFilePath;
 // 프로젝트 디렉토리에 있는 파일을 여는 콜백 함수입니다.
 vscode.workspace.onDidOpenTextDocument(textDocument => {
 // 열린 파일의 경로 가져오기
 const filePath = textDocument.uri.fsPath;
 if (filePath === targetFileFullPath) {
 // 로그 전송 로직 추가하기
 }
 });
}

문제점: 이 기능은 VSCode IDE에 크게 의존하며, 모든 R&D가 VSCode를 사용하는 것은 아니며, 파일 클릭 이벤트를 실시간으로 수신하면 시스템 오버헤드 비용도 발생합니다. 현재 컴퓨터는 이미 여러 개의 VSCode IDE가 열려 있는 상태에서 느리게 실행되고 있으며, 이 기능을 사용하면 성능 손실이 더욱 커질 것으로 예상됩니다.

위의 내용은 연습 과정에서 큰 창고 권한이 아이디어의 두 가지 확장에 착륙하지 않았으며 파일 읽기 권한 제어를 달성하기위한 다른 더 나은 아이디어가 있으면 언제든지 의사 소통을 환영합니다.

V. 요약

프론트엔드 모노레포 사일로 권한 설계는 구현 과정에서 많은 문제에 직면했습니다. 아이디어는 매우 좋지만 실제 R&D 프로세스에서는 비즈니스 도메인 시나리오에 따라 다른 문제가 발생하기도 합니다. 예를 들어 마스터를 기반으로 기능을 브랜치할 것인지 릴리스를 기반으로 브랜치할 것인지에 대한 문제가 특히 두드러집니다. 처음에는 마스터를 기반으로 기능을 브랜치할 때 R&D 팀이 릴리스를 브랜치할 때 변경되지 않은 파일이 많아서 CR이 어떤 파일을 봐야 할지 정확히 알 수 없다는 문제가 있었습니다. 릴리스 브랜치를 기반으로 브랜치할 경우 릴리스 브랜치 코드 중 일부가 누락되는 문제가 발생하여 결국 마스터 브랜치를 기반으로 브랜치하기로 결정했습니다. 빅 웨어하우스에 대한 권한 설계는 R&D 프로세스 전환에 참여한 파트너와 성능 기술 작업을 한 파트너에게도 꼭 필요한 부분인데요, 그 과정에서 빅 웨어하우스 권한에 적응하기 위해 R&D 프로세스 전환과 깃랩 기능 확장도 많이 했으니 이 글이 독자들에게 도움이 되었으면 좋겠습니다.

*문자/청구서