This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @grzesiek @fabiopitino 2023-07-05

모듈식 단일체: PoC

우리의 모놀리식 시스템의 모듈화는 복잡한 프로젝트입니다. 알려지지 않은 사항이 많을 것입니다. 리스크를 완화하고 주요 통찰을 제공할 수 있는 것 중 하나는 초기에 제공할 수 있는 Proof-of-Concepts(검증사례)입니다. 이를 통해 무엇을 해야 할지 더 잘 이해할 수 있습니다.

모듈 간 통신

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

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

우리의 목표 중 하나는 모듈을 분리하여 일부를 별도의 서비스로 사용할 수 있도록 하는 것입니다. 이렇게 하면 나중에 GitLab.com을 쉽게 배포하고 핵심 도메인을 확장할 수 있습니다. 이 목표를 달성하는 한 가지 방법은 프로토콜 버퍼를 인터페이스로 사용하고 gRPC를 통신 채널로 사용하여 모듈 간 통신을 설계하는 것입니다. 모듈이 연결되면 gRPC와 직렬화를 우회하고 사용 중인 프로토콜 버퍼를 여전히 인터페이스로 사용하면서 프로세스 내 통신 원시형을 사용할 수 있을 것입니다. 모듈이 연결 해제되면 gRPC가 모듈 간 메시지를 전달할 것입니다.

Packwerk 사용하여 모듈 경계 강제화

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

이 PoC 합병 요청에서 우리는 모놀리식을 별도의 모듈로 분할한 가능한 디렉토리 구조를 보여줍니다.

이 PoC는 또한 EE 확장(EA도 포함)의 문제를 해결하고 레일즈 오토로더를 핵심 코드베이스만 로드할지 또는 어떤 확장도 로드할지에 따라 조정할 수 있게 하려고 시도했습니다.

또한 이 PoC는 Ci:: 네임스페이스의 작은 부분만 components/ci Packwerk 패키지로 이동하려고 시도했습니다. 이것은 지금까지 시도한 가장 반복적인 접근 방식으로 보입니다.

Packwerk를 도입하는 데 사용할 수 있는 다양한 방법이 있습니다. 다른 PoC도 CI 패키지의 큰 추출주요 CI 클래스를 패키지로 이동 등을 탐색했습니다.

세 가지 PoC는 Packwerk 패키지 및 구성의 도입에서부터 모든 패키지와 함께 작동하도록 오토로더 경로를 설정하는 데까지 많은 공통점이 있습니다. 다양한 합병 요청에서 바뀌는 것은 처음에 어떤 파일을 먼저 이동할지 선택하는 방식입니다.

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

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

긍정적인 결과

  • Packwerk를 사용하면 루비 온레일스 코드베이스에서 주로 작동하도록 설계되었기 때문에 GitLab에서 매우 간단할 것입니다.
  • 도메인 코드의 구성을 MVC 패턴을 따르는 대신 모듈 중심으로 변경할 수 있습니다. 이를 위해 레일즈 오토로딩이 새로운 디렉토리 구조를 지원하도록 작은 초기 변경이 필요하며, 이는 Packwerk에서 강요되는 것은 아닙니다. 이후에 새로운 최상위 패키지/바운디드 컨텍스트를 등록하는 것은 한 줄의 변경이 될 것입니다.
  • PoC에서 나타낸 올바른 디렉토리 구조를 사용하면 패키지에 EE 및 JH 확장을 포함하여 모든 코드를 포함하는 것이 가능합니다.
  • 점진적 모듈화가 가능하며, 초기 강제화 없이 시작하여 메모리 내 마이크로서비스 환경을 모방하는 완전한 격리까지 원하는 만큼의 모듈화를 갖을 수 있습니다.
  • Packwerk 패키지로 파일을 이동하는 것은 반드시 상수를 이름을 변경하는 것을 의미하지는 않습니다. 장기적으로 권장되지는 않지만, 도구가 제공하는 여분의 유연성입니다.
    • 예를 들어: Ci:: 모듈을 Packwerk 패키지로 추출하는 경우 CI 도메인에 속하지만 네임스페이스가 없는 CommitStatusGitlab::Ci::와 같이 다른 네임스페이스를 가진 상수들이 있을 수 있습니다. Packwerk는 이러한 상수를 ci 패키지 안으로 이동시키고 올바르게 경계 위반을 플래그 처리할 수 있습니다.
    • RubyAtScale 도구에서의 Packwerk 개선 사항은 패키지 내의 모든 상수가 동일한 루비 네임스페이스를 공유하도록 강제하는 것을 허용합니다. 우리는 결국 이를 활용하고 싶어할 것입니다.
  • RubyAtScale은 모듈화 및 채택에 대한 메트릭을 추적하는 도구도 제공합니다. 이는 우리가 감시하고 엔지니어링 조직으로 이끌어내야 하는 것입니다.
  • Packwerk에는 (예: VSCode용) IDE 확장도 있어 위반 사항에 대한 실시간 피드백을 제공합니다(예: Rubocop). 개발 워크플로우 중에 CLI를 통해 단일 패키지에 대해 실행할 수도 있습니다. 코드 리뷰 중에 pre-push Git 훅이나 Danger에 통합할 수 있습니다.

도전과제

이러한 도전과제 중 일부는 Packwerk가 도구/접근 방법으로 특정되지 않습니다. 이들은 PoC 동안 관찰되었으며 모듈화 프로세스와 더 관련이 있습니다:

  • Packwerk 패키지를 도입할 때 옳고 그른 방법은 없습니다. 우리는 개발자들에게 최선의 결정을 내릴 수 있는 도구를 제공하기 위해 명확한 지침을 정의해야 합니다:
    • 때로는 빈 패키지를 만들고 그 안으로 파일을 점진적으로 이동하는 것이 좋을 수 있습니다.
    • 때로는 이미 잘 설계되고 격리된 코드베이스 일부를 감싸는 것이 좋을 수 있습니다.
    • 때로는 처음부터 새로운 패키지를 만드는 것이 좋을 수 있습니다.
  • 코드를 다른 디렉토리 구조로 이동하는 경우 현재 디렉토리 구조를 따르는 확장 프로그램을 관리하는 JiHu를 참여시켜야 합니다. 일부 모듈이 일부분만 이주했을 수 있으며 현재 진행 사항을 JiHu가 업데이트했는지 확인해야 합니다.
  • 개인정보/의존성 확인이 활성화된 후, Packwerk는 Rails 코드베이스의 상수 참조가 매우 얽히게 되어 Rubocop TODO와 같은 많은 위반 사항을 기록할 것입니다.
    • 패키지를 소유한 팀은 패키지에 대한 비전을 정의해야 합니다. 모든 위반 사항이 고쳐졌을 때 패키지는 어떻게 보일까요? 이는 시스템의 컨텍스트 맵에 패키지가 어떻게 맞는지를 명시할 수 있습니다. 현재 패키지가 다른 패키지 A에서 어떻게 사용되어야 하며 다른 패키지를 어떻게 사용해야 하는지를 언급할 수 있습니다.
    • 위의 비전은 개발자에게 시간이 지남에 따라 이러한 위반 사항을 어떻게 고쳐야 하는지 알려주어야 합니다. 특정 상수를 공개해야 하는가? 다른 패키지를 종속성으로 나열해야 하는가? 시나리오에 이벤트를 사용해야 하는가?
    • 팀은 아마도 그것을 하는 데 안내가 필요할 것입니다. 우리는 아마도 도메인에 대한 매우 광범위한 이해를 가진 유지보수자와 같은 엔지니어팀이 이러한 노력을 지원하는 데 필요할지도 모릅니다.
  • CI 구성의 변경으로 Knapsack 및 선택적 테스트를 조정하는 것이 PoC 동안 무시되었습니다.

프론트엔드 분류 모자

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

프론트엔드 자산 집계

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