| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@thomasrandolph
@patrickbajao
@igor.drozdov
@jerasmus
@iamphill
@slashmanov
@psjakubowska
|
@ntepluhina
| devops create | 2023-10-10 |
재사용 가능한 빠른 차이 (RRD)
요약
GitLab의 차이는 각 영역이 각각의 방법을 사용하여 여러 곳에 걸쳐 퍼져 있습니다. 우리의 목표는 응용 프로그램 전체에 걸쳐 차이가 렌더링되는 단일하고 성능이 좋은 방법을 개발하는 것입니다. 여기서 우리의 목표는 차이 생성부터 차이를 렌더링하는 프론트엔드까지 모든 영역의 차이 렌더링을 개선하는 것입니다.
이 문서와 관련된 모든 차이 기능은 전용 페이지에 나와 있습니다.
동기
목표
- 지각된 성능 향상
- 유지 관리성 개선
- 모든 시나리오의 일관된 커버리지
비목표
이 노력은 다음을 하지 않을 것입니다:
- MR 또는 리포지터리 커밋의 현재 차이 구현을 개선하는 데 기여하지 않을 것입니다.
목표 우선 순위
모든 목표가 중요하긴 하지만 일관적인 선택을 돕기 위해, 더 중요한 목표를 가이드하는 노력으로 아래와 같이 정의하였습니다.
지각된 성능은 유지 관리성보다 우선이며, 일관된 커버리지보다 우선입니다.
예시:
- 제안이 유지 관리성을 향상시키지만 지각된 성능을 희생하는 경우: ❌ 대안을 고려해야 합니다.
- 제안이 특정 상황에서 기능을 제거하고 커버리지에 손상을 입히지만 지각된 성능이나 유지 관리성에 영향을 미치지 않는 경우: ❌ 다시 고려해야 합니다.
- 제안이 지각된 성능을 향상시키지만 특정 상황의 기능을 제거하는 경우: ✅ 유효하며 제품/UX와 논의되어야 합니다.
- 제안이 일관된 커버리지를 보장하고 지각된 성능이나 유지 관리성에 영향을 미치지 않는 경우: ✅ 유효합니다.
실제로, 우리는 각 결정에 모든 목표를 만족시키려 노력하지만 더 중요한 목표에 우선 순위를 둘 것입니다.
프로세스
작업 공간 및 아티팩트
- 우리는 메트릭, 버전 및 개발 및 아키텍처 패턴과 같은 구현 세부 정보를 문서에 저장할 것입니다.
- 우리는 연구 결과, 감사 결과 등 대규모의 연구 내용을 RRD 프로젝트의 위키에 저장할 것입니다.
- 우리는 오디오 및 비디오 녹화를 Code Review / RRD 재생 디렉터리에 공개된 YouTube 채널에 저장할 것입니다.
- 우리는 초안, 회의록 및 기타 일시적 문서를 공개 Google 문서에 저장할 것입니다.
제안
BE DB <–> BE Cache <–> BE DS <–> BE BE <–> API API <–> FE FE –> Display
subgraph Rails
direction LR
BE[백엔드]
API[웹 API]
end ```
*: 프론트엔드는 많은 탐험되지 않은 단계를 숨깁니다. 프론트엔드는 아마도 캐시, 데이터베이스, API 추상화(네트워크 연결 등과 같은 하위 모듈 위에 있는 API 추상화) 및 기타 요소가 필요할 것입니다. 이러한 내용은 미확장되었지만, 여기서 “프론트엔드”는 해당 복잡성을 대표합니다.
Gitaly
차이점을 가져오기 위해 Gitaly는 두 가지 기본 유틸리티를 제공합니다.
- 일련의 리비전에 대해 수정된 파일 디렉터리과 연결된 사전 및 사후 이미지 blob ID를 검색합니다.
- 지정된 파일 집합에 대한 사전 및 사후 이미지 blob ID를 사용하여 Git 차이점 세트를 검색합니다.
데이터베이스
캐시
- 차이점의 새로운 렌더링
- 차이점의 반복된 렌더링
차이점 리포지터리
백엔드
- 페이지 로드시 처음에 렌더링된 파일
- 미래 파일을 렌더링하고 프론트엔드로 스트리밍
웹 API
웹 API는 차이점에 대한 내부 및 공개 액세스를 위해 백엔드 구현을 제공합니다.
이 다이어그램은 애플리케이션 또는 사용자가 상호 작용할 수 있는 각 엔드포인트를 표시하고 각 엔드포인트가 기대하는 것과 반환하는 것을 보여줄 수 있도록 확장(및 분할)되어야 합니다.
이는 비즈니스 로직 및 구현 세부 정보를 설명하는 백엔드 다이어그램과 별개입니다. API 엔드포인트는 소비자를 대상으로 하기 때문에 요구 사항과 구조가 다릅니다.
###### 완전한 단일 렌더
```mermaid
sequenceDiagram
actor 사용자
participant UI
participant 상호 작용 핸들러인 UX
participant Front-end 동작인 FeApp
participant 데이터 추상화인 FeData
participant 네트워크 연결인 FeNet
participant 웹 API인 API
participant 백엔드인 BE
participant xxx
participant 캐시
participant 데이터베이스
participant Gitaly
사용자 -->> BE: (MR 페이지 로드)
BE ->> xxx: ???
xxx ->> 캐시: ???
캐시 ->> xxx: ???
xxx ->> 데이터베이스: ???
데이터베이스 ->> xxx: ???
xxx ->> Gitaly: ???
Gitaly ->> xxx: ???
xxx ->> BE: 렌더링된 HTML
BE ->> User: MR용 렌더링된 차이 페이지
접근성
재사용 가능한 빠른 차이는 웹 콘텐츠 접근성 지침 2.1에 대한 웹 기반 콘텐츠 및 저작 도구 접근성 지침 2.0에 대한 사용자 인터페이스의 AA 수준과 일치하는 방식으로 표시되어야 합니다.
GitLab의 차이를 사용하는 접근성 있는 경험을 위해서는 차이를 표시하고 상호 작용할 때의 규정 준수를 확인해야 합니다. 이것이 바로 접근성 감사 및 추가 권장 사항이 변경 사항을 검토하는 데 사용되는 콘텐츠 편집기와 같은 기능을 보장해야 하는 이유입니다.
ATAG 2.0 AA
차이의 성격상, 다음 가이드라인에 주목할 것입니다:
- 가이드라인 A.2.1: (저작 도구 사용자 인터페이스용) 저자에게 대체 콘텐츠 제공
- 가이드라인 A.3.1: (저작 도구 사용자 인터페이스용) 저자 기능에 대한 키보드 액세스 제공
- 가이드라인 A.3.4: (저작 도구 사용자 인터페이스용) 콘텐츠 구조를 통한 탐색 및 편집 강화
- 가이드라인 A.3.6: (저작 도구 사용자 인터페이스용) 환경설정 관리
HTML 구조
차이의 HTML 구조는 보조 기술을 지원해야 합니다. 이러한 이유로 표는 제시된 데이터 간의 논리적인 관계를 나타내고 키보드를 사용하는 스크린 리더 사용자가 탐색하기 쉽기 때문에 선호될 수 있습니다. 라벨이 지정된 열은 줄 번호와 같은 정보가 코드 조각과 관련될 수 있도록 보장합니다.
가능한 구조는 다음과 같습니다:
<table>
<caption class="gl-sr-only">파일 index.js에 대한 변경 사항. 10개의 줄이 변경되었으며, 삭제된 줄 5개, 추가된 줄 5개입니다.</caption>
<tr hidden>
<th>원본 줄 번호: </th>
<th>차이 줄 번호: </th>
<th>줄 변경:</th>
</tr>
<tr>
<td>1234</td>
<td></td>
<td>.tree-time-ago ,</td>
</tr>
[…]
</table>
구현 가이드라인을 위해 WAI 테이블 자습서를 참조하세요.
각 파일 테이블에는 다음을 표시하는 변경 사항에 대한 간단한 요약이 포함되어야 합니다:
- 변경된 총 줄 수,
- 추가된 줄 수,
- 제거된 줄 수.
테이블 콘텐츠의 요약은 <caption> 요소 내에 또는 테이블 앞에 aria-describedby로 참조되는 요소 내에 배치될 수 있습니다.
두 가지 접근 방식에 대한 자세한 정보는 WAI(Web Accessibility Initiative)에서 확인할 수 있습니다:
<caption>요소 내의 요약 내포-
aria-describedby사용하여 테이블 요약 제공](https://www.w3.org/WAI/tutorials/tables/caption-summary/#using-aria-describedby-to-provide-a-table-summary)
그러나 이러한 구조가 차이 표시의 다른 기능 측면을 저해한다면, 일반적인 요소와 ARIA 지원과 함께 사용할 수 있습니다.
시각적 표시기
각 시각적 표시기에는 해당 표시 기호의 의미를 나타내는 스크린 리더 텍스트가 있어야 합니다. 필요한 경우 시갠러 사용자에게는 표시되지만 시각적으로 보이지 않도록 하기 위해 gl-sr-only 또는 gl-sr-only-focusable 클래스를 사용합니다.
보조 기술을 위한 대체품이 필요한 시각적 표시기 중 일부는 다음과 같습니다:
-
+또는 빨간 하이라이팅은추가됨으로 읽히어야 합니다. -
-또는 녹색 하이라이팅은제거됨으로 읽히어야 합니다.
높은 수준의 구현
대체 솔루션
역사적 맥락
재사용 가능한 빠른 차이는 우리가 차이를 렌더링하는 접근 방식에 패러다임 전환이었습니다. 이 제안된 아키텍처 이전에 차이를 렌더링하는 두 가지 다른 접근 방식이 있었습니다:
- Merge Request에서는 주로 클라이언트 측 렌더링을 사용했습니다.
- 다른 모든 페이지에서는 주로 JavaScript로 구현된 서버 측 렌더링을 사용했습니다.
Merge Request에서는 대부분의 렌더링 작업이 클라이언트에서 수행되었습니다:
- 백엔드는 차이 데이터가 포함 된 JSON 응답을 생성했습니다.
- 클라이언트는 차이를 그리고 사용자 입력에 반응하는 데 책임이 있었습니다.
이로 인해 대규모 차이 파일 디렉터리의 렌더링을 크게 가속화하는 가상 스크롤 솔루션을 채택했습니다.
이것은 매우 높은 유지 관리 비용과 지속적인 버그로 인해 불행하게도 유지 관리가 어려웠으며 페이지에 방문할 때 차이를 바로 표시할 수 없었고, 먼저 JSON 응답을 기다려야 했기 때문에 사용자 경험이 악화되었습니다. 마지막으로 이 접근 방식은 다른 페이지에서 사용된 서버 렌더링 차이와 완전히 병렬로 이루어졌으며, 결과적으로 차이에 대한 두 개의 완전히 별개의 코드베이스가 되어 버렸습니다.
시도된 대체 솔루션 요약
지난 시도한 전략 디렉터리은 다음과 같습니다:
- 서버 측 전체 렌더링 (채택 및 Vue 앱으로 대체): Merge Request 변경 탭의 Vue 재구성 이전에 차이는 완전히 서버에서 렌더링되었습니다. 이로 인해 페이지가 렌더링되기 전에 오랜 기다림이 발생했습니다.
- 프런트엔드 템플릿 (Vue) 서버 측 렌더링 (테스트됨): 결과 및 영향이 설득력이 없었으며 부분적인 서버 측 렌더링 방향을 가리켰다. (PoC MR)
- 차이 분할 (채택): 차이를 비동기적으로 페이지별 요청으로 분할하여 크기를 증가시킬 수 있도록 함 (느린 시작). 부트스트래핑 시간이 불만족스러웠으며, 지각된 성능은 여전히 내용이 없는 페이지의 긴 시간을 포함했습니다.
- 가상 스크롤링 (채택): 네이티브 검색 기능을 완전히 사용할 수 없음, 스크롤 시 요소에 대한 간섭 및 이상한 동작, 브라우저의 전체적인 다시 흐름 및 페인팅에 대한 부담 등 여러 알려진 부작용이 있음 (이 청사진에서 제안된 접근 방식과의 비교)
- 리포지터리 커밋 세부 정보가 너무 큰 경우 페이징됨(채택): 중간 해결책으로, 리포지터리의 매우 큰 커밋 차이는 이제 UX에 부정적인 영향을 끼쳐 여러 페이지로 숨겨짐.
- 마이크로 코드 리뷰 프런트엔드 PoC (테스트됨):이 접근 방식은 지난 과거에 사용된 응용 프로그램 설계와 크게 다른 접근으로, 미래 방향으로 심각하게 탐구되지 않았습니다. 특정 디자인의 일부 - 사용자 지정 요소 및 이벤트에 대한 의존성 - 가 대체적인 접근방식으로 통합되었습니다. (마이크로 코드 리뷰 프런트엔드 PoC)
- 노드 서버를 사용한 스트리밍 차이(테스트됨): 전용 노드js 서버와 스트리밍을 결합. 이 청사진에서 제안된 SSR 접근방식의 전조. (PoC: 스트리밍 차이 앱)
변경 제안
이러한 변경 사항(임의의 “디자인 A”와 같은 이름으로 표시됨)은 이 청사진의 제안된 최종 진로를 제안하지만, 권위 있는 콘텐츠로 아직 승인되지는 않았습니다.
- 최상위 계층 제목에 디자인 이름을 표시하세요. 동일한 수준의 여러 제목을 변경하는 경우 모두 동일한 이름으로 표시하세요. 이렇게 하면 추론하기 쉬운 고수준 목차가 생성됩니다.
프론트 엔드 (디자인 A)
고수준 구현
(기술 아키텍처 설계에 대한 새로운 차이점 참조하여 이 차트의 시각적인 표현 확인)