라우팅
GitLab 백엔드는 주로 Rails로 작성되었으므로 Rails 라우팅을 사용합니다. Rails의 best practice 외에도 GitLab 애플리케이션에만 해당되는 몇 가지 규칙이 있습니다. 하위 그룹을 지원하기 위해, GitLab 프로젝트 및 그룹 라우트는 와일드카드 문자를 사용하여 프로젝트 및 그룹 라우트를 일치시킵니다. 예를 들어, 다음과 같은 경로가 있을 수 있습니다:
/gitlab-com/customer-success/north-america/west/customerA
그러나 경로는 모호할 수 있습니다. 다음 예를 고려해보십시오.
/gitlab-com/edit
edit라는 하위 그룹이 있는지 또는 gitlab-com 그룹을 편집하는 특별한 엔드포인트인지 모호합니다.
모호함을 제거하고 백엔드를 더 쉽게 유지 보수할 수 있도록하기 위해 /-/ 스코프를 도입했습니다. 이것의 목적은 그룹 또는 프로젝트 경로를 나머지 라우트와 구분하는 것입니다. 또한 예약된 이름의 수를 줄이는 데 도움이 됩니다.
모든 가능한 라우트 보기
다음을 실행하여 콘솔에서 라우트를 볼 수 있습니다.
rails routes | grep crm
http://gdk.test:3000/rails/info/routes로 이동하여 브라우저에서 라우트도 볼 수 있습니다.
글로벌 라우트
몇 가지 전역 라우트가 있습니다. 예를 들면:
/-/health
/-/metrics
그룹 라우트
모든 그룹 라우트는 /-/ 스코프 내에 있어야 합니다.
예시:
gitlab-org/-/edit
gitlab-org/-/activity
gitlab-org/-/security/dashboard
gitlab-org/serverless/-/activity
이를 달성하기 위해 scope '-' 메서드를 사용합니다.
프로젝트 라우트
모든 프로젝트 라우트는 /-/ 스코프 내에 있어야 하지만, Git 클라이언트나 다른 소프트웨어가 다른 것을 요구하는 경우에는 예외입니다.
예시:
gitlab-org/gitlab/-/activity
gitlab-org/gitlab/-/jobs/123
gitlab-org/gitlab/-/settings/repository
gitlab-org/serverless/runtimes/-/settings/repository
기존 라우트 변경
기존 페이지의 URL을 변경하지 마십시오. 반드시 필요한 경우에만 변경하십시오. 변경할 경우, 사용자에게 눈에 띄지 않도록 변경하십시오. 404 Not Found를 받지 않도록 하려고합니다. 다음 표는 다른 경우에 필요한 최소한의 사항을 설명합니다:
| URL 설명 | 예시 | 해야 할 일 |
|---|---|---|
| 스크립트 및 자동화에서 사용할 수 있음 | snippet#raw
| 하나의 주요 릴리스에서 이전 URL과 새 URL 모두 지원합니다. 그런 다음, 다음 주요 릴리스에서 이전 URL에서 새 URL로의 리디렉션을 지원합니다. |
| 저장되거나 공유될 가능성이 높음 | issue#show
| 다음 주요 릴리스까지 이전 URL에서 새 URL로의 리디렉션을 추가합니다. |
| 제한적인 사용, 공유되지 않을 가능성이 높음 | admin#labels
| 추가 단계가 필요하지 않습니다. |
모든 경우에 대해 오래된 라우트는 트래픽이 충분히 줄어들 때에만 제거되어야합니다(예: 로그 또는 BigQuery에 따라). 그렇지 않으면, 제거 전에 사용자에게 폐기에 대해 알리기 위해 더 많은 노력이 필요할 수 있습니다.
스코프가 없는 라우트 이주
현재 대부분의 라우트는 /-/ 스코프 아래에 있습니다. 그러나 나머지 모두를 이주할 수 있습니다! 라우트를 이주하기 위해:
- 기존 라우트를 수정하여
-스코프를 추가합니다. -
Gitlab::Routing.redirect_legacy_paths를 사용하여 이전 라우트에 대한 리디렉션을 추가합니다. - 나중의 릴리스에서 사용하지 않는 라우트를 제거하기 위해 기술적인 부채 이슈를 만듭니다.
시작하려면 예시 MR를 확인하십시오.
도움말