• 모듈간 통신
• 모듈 경계 강제를 위해 Packwerk 사용하기
  • 긍정적인 결과
  • 도전 과제
• 프론트엔드 소팅 모자
• 프론트엔드 자산 집계

모듈형 모놀리식: PoC

우리의 모놀리식를 모듈화하는 것은 복잡한 프로젝트입니다. 많은 미지수가 있을 것입니다. 우리가 위험을 완화하고 핵심 통찰을 제공하는 한 가지 방법은, 초기에 전달할 Proof-of-Concepts(콘셉트 증명)입니다. 이를 통해 더 잘 이해할 수 있을 것입니다.

모듈간 통신

전달할 PoC 중 하나는 모듈간 통신의 PoC입니다. 모듈을 분리할 필요를 인식하지만, 여전히 잘 정의된 인터페이스를 사용하여 함께 통신할 수 있도록하는 것입니다. 모듈은 페이서드 클래스(일반적으로 라이브러리가 하는 것처럼)나 이벤트 시스템을 통해 통신할 수 있습니다. 두 가지 방식 모두 중요합니다.

주요 질문은: 우리는 인터페이스를 어떻게 정의하고 통신 채널을 어떻게 설계하고 싶은가요?

우리의 목표 중 하나는 모듈을 분리하여 일부 모듈을 별도의 서비스로 운영할 수 있도록하는 것입니다. 이는 향후 GitLab.com을 쉽게 배포하고 핵심 도메인을 확장할 수 있게 합니다. 이 목표를 달성하는 한 가지 방법은 인터페이스로 protobuf를 사용하고 통신 채널로 gRPC를 사용하여 모듈 간 통신을 설계하는 것입니다. 모듈이 플러그인되면 gRPC와 직렬화를 우회하고 프로토콜 버퍼를 인터페이스로 사용한 내부 통신 원시 형식을 사용할 것입니다. 모듈이 플러그아웃될 때, gRPC가 모듈 간 메시지를 운반할 것입니다.

모듈 경계 강제를 위해 Packwerk 사용하기

Packwerk는 루비에서 모듈 경계를 정의하고 강제하는 데 도움을 주는 정적 분석기입니다.

이 PoC Merge Request에서 우리는 모놀리식를 별도의 모듈로 분리한 가능한 디렉터리 구조를 보여줍니다.

이 PoC는 EE 확장과 (그리고 JH도) Rails 자동로더를 Core 코드베이스만로드할지 또는 모든 확장을로드할지에 따라 조정 할 수 있도록 하는 문제를 해결하고자합니다.

이 PoC는 또한 ‘Ci::’ 네임스페이스의 작은 일부를 components/ci Packwerk 패키지로 이동시키기를 시도했습니다. 지금까지 탐구 된 가장 반복적인 접근법인 것 같습니다.

Packwerk 채택하기 위해 사용할 수있는 다양한 접근 방식이 있습니다. 다른 PoC도 같이 탐구되었습니다. 그 중 하나는 CI 패키지의 대규모 추출이며, 주요 CI 클래스 2개를 패키지로 이동하는 것입니다.

이 3가지 PoC 모두 Packwerk 패키지 및 설정 도입에서 부터 어떤 패키지와 작업하기위한 경로 설정까지 많은 공통점이 있습니다. 다양한 Merge Request들 사이에서 바뀌는 것은 첫 번째로 이동할 파일을 선택하는 방법입니다.

PoC의 주요 목표는 다음과 같습니다:

• GitLab 코드베이스에서 Packwerk를 사용할 수 있는지 이해하기
• 개발자의 학습 곡선 이해하기
• EE 및 JH 확장 지원 확인하기
• 점진적 모듈화 허용하기

긍정적인 결과

• Packwerk를 사용하면 Rails 코드베이스에서 주로 작동하도록 설계되었기 때문에 GitLab에서 사용하기가 매우 간단할 것입니다.
• 도메인 코드의 구성을 MVC 패턴을 따르는 대신 모듈 지향적으로 변경할 수 있습니다. 새로운 디렉터리 구조를 지원하기 위해 Rails 자동로딩을 조정하는 작은 초기 변경이 필요합니다. 그 후에 새로운 최상위 패키지/바운디드-컨텍스트를 등록하는 것은 1줄의 코드 변경이 될 것입니다. 방법에 의해 Packwerk 패키지가 모든 코드를 포함 할 수있는 PoC의 올바른 디렉터리 구조를 사용하기 위해서 EE 및 JH 확장을 모두 지원할 수 있습니다.
• 점진적 모듈화가 가능하고 우리는 원하는 만큼의 모듈화 정도를 가질 수 있으며, 초기 강제 실행에서 메모리 내 마이크로 서비스 환경을 시뮬레이팅하게됩니다.
• Packwerk 패키지로 파일을 이동하는 것은 반드시 상수를 이름 바꾸는 것을 의미하는 것은 아닙니다. 장기적으로 권장되지는 않지만 도구가 제공하는 추가적인 유연성입니다.
  • 예를 들어: Ci:: 모듈을 Packwerk 패키지로 추출하는 경우, CommitStatus와 같이 네임스페이스가없는 영역에 속한 상수 또는 다른 네임 스페이스인 Gitlab::Ci::와 같이 다른 네임 스페이스를 가진 상수가 될 수 있습니다. Packwerk는 이러한 상수를 ci 패키지 내부로 이동시키고 올바르게 경계 위반을 플래그 처리할 수 있습니다.
  • RubyAtScale 도구에서 Packwerk 향상 기능을 사용하여 패키지 내의 모든 상수가 동일한 Ruby 네임스페이스를 공유하도록 강제 할 수 있습니다. 우리는 결국 그것을 활용하고 싶을 것입니다.
• RubyAtScale은 모듈화 및 채택에 대한 메트릭을 추적하는 도구 또한 제공합니다. 우리는 공학 조직으로서 이를 모니터링하고 이끌기 위해서 필요할 것입니다.
• Packwerk에는 실시간 위반에 대한 리얼타임 피드백을 제공하는 IDE 확장 기능(VS Code의 경우)도 존제합니다(RuboCop과 유사). 개발자들이 단일 패키지에 대해 개발 작업 흐름 중에도 CLI를 통해 실행할 수 있습니다. 그것은 pre-push Git 훅이나 리뷰 동안에 Danger로 통합 될 수 있습니다.

도전 과제

이러한 도전 과제 중 일부는 도구/접근 방법으로서 Packwerk에 특정한 것이 아닙니다. PoC 기간 동안 관찰된 것이고 모듈화 프로세스와 더 관련된 것입니다.

• Packwerk 패키지 도입 시 올바른 또는 틀린 방법은 없습니다. 최상의 결정을 내릴 수 있도록 개발자들에게 도구를 제공하기 위해 명확한 지침을 정의해야합니다:
  • 때로는 비어 있는 패키지를 만들어서 점진적으로 파일을 이동하는 것일 수 있습니다.
  • 때로는 이미 잘 설계되고 격리 된 코드베이스를 랩핑하는 것일 수 있습니다.
  • 때로는 처음부터 새 패키지를 만드는 것일 수 있습니다.
• 다른 디렉터리 구조로 코드를 옮기면 JiHu를 관여할 필요가 있습니다. 그들이 현재의 디렉터리 구조를 따르면 확장을 관리하고 있기 때문입니다. 우리는 일부 모듈이 부분적으로 이전되고 있는 상태일 수 있으며 JiHu가 현재 진행 상황을 잘 알고 있는지 확인해야합니다.
• 개인 정보/의존성 검사가 활성화되면 Packwerk는 상수 참조로 인한 많은 위반 사항을 기록할 것입니다(RuboCop TODO와 유사).
  • 패키지를 소유하는 팀은 패키지에 대한 비전을 정의해야합니다. 모든 위반 사항이 수정된 후에 패키지는 어떻게 보일 것인가요? 이것은 시스템의 컨텍스트 맵에 패키지가 어떻게 맞는지를 명세 할 수 도 있습니다. 현재 패키지가 다른 패키지 ‘A’에 의해 사용될 방식과 다른 패키지를 어떻게 사용해야하는지 등을 포함 할 수 있습니다.
  • 위에 설명된 비전은 개발자들에게 시간이 지남에 따라 위반 사항을 어떻게 수정해야하는지 알려야합니다. 특정한 상수를 공개해야합니까? 패키지 디렉터리에 다른 패키지를 종속시켜야합니까? 특정 시나리오에서 이벤트를 사용해야합니까?
  • 팀은 그것을 하는데 있어서 지침이 필요할 것입니다. 우리는 엔지니어링 팀을 가지고 있을지 모르겠지만, 매우 폭넓은 도메인 지식을 가진 유지 보수 직군이 지원하여 이 노력을 지원해야 할 수도 있습니다.
• CI 구성 변경 및 Knapsack 및 선택적 테스팅 조정 변경은 PoC 동안 무시되었습니다.

프론트엔드 소팅 모자

프론트엔드 소팅 모자는 여러 도메인을 결합하여 GitLab의 전체 페이지(메뉴 및 여러 별도의 도메인에서 가져온 항목을 포함)을 렌더링하는 PoC 입니다.

프론트엔드 자산 집계

프론트엔드 자산 집계는 마이크로 프론트엔드의 분리 가능성에 대한 PoC입니다.