라우팅
GitLab 백엔드는 주로 Rails로 작성되어 있으므로 Rails 라우팅을 사용합니다. Rails의 모범 사례 외에도, 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로 리디렉션을 지원하십시오. |
저장되거나 공유될 가능성이 있음 | issue#show
| 다음 주요 릴리스까지 이전 URL에서 새 URL로 리디렉션을 추가하십시오. |
사용될 가능성이 적고 공유될 가능성이 적음 | admin#labels
| 추가 조치가 필요하지 않습니다. |
모든 경우에 이전 라우트는 트래픽이 충분히 줄어들 때까지 제거해서는 안 됩니다(로그 또는 BigQuery 등의 정보에 따라). 그렇지 않으면 제거 전에 사용자에게 폐기에 대해 알리기 위해 더 많은 노력이 필요할 수 있습니다.
범위가 지정되지 않은 라우트 마이그레이션
현재 대부분의 라우트는 /-/
범위 아래에 있습니다. 그러나, 나머지 라우트의 마이그레이션에 도움이 될 수 있습니다! 라우트를 마이그레이션하려면:
- 기존 라우트를 수정하여
-
범위를 추가하십시오. -
Gitlab::Routing.redirect_legacy_paths
를 사용하여 레거시 라우트에 대한 리디렉션을 추가하십시오. - 나중의 릴리스에서 폐기된 라우트를 제거하기 위한 기술 부채 이슈를 만드십시오.
시작하려면 예시 병합 요청을 참조하십시오.