InfoGrab DocsInfoGrab Docs

GitLab 기능 지원 중단

요약

이 페이지에서 사용되는 용어에 대한 자세한 내용은 용어 설명을 참조하세요. 고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 하는 경우, 해당 변경은 브레이킹 체인지로 간주됩니다. 브레이킹 체인지는 다음과 같은 다양한 원인에서 발생할 수 있습니다:

이 페이지에서 사용되는 용어에 대한 자세한 내용은 용어 설명을 참조하세요.

브레이킹 체인지 정책#

고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 하는 경우, 해당 변경은 브레이킹 체인지로 간주됩니다.

브레이킹 체인지는 다음과 같은 다양한 원인에서 발생할 수 있습니다:

  • 의도적인 제품 변경

  • 구성 업데이트

  • 서드파티 지원 중단

  • 기타 다양한 원인

많은 사용자에게 GitLab은 티어 제로 시스템입니다. 사용자의 비즈니스를 생성, 릴리스, 운영, 확장하는 데 있어 매우 중요한 역할을 합니다. 브레이킹 체인지의 결과는 심각할 수 있습니다.

제품 및 엔지니어링 매니저는 플랫폼에 적용하는 변경으로 인한 고객 영향에 대해 책임을 집니다. 변경 관리의 부담은 고객이 아닌 GitLab이 부담합니다.

GitLab은 모든 브레이킹 체인지를 없애는 것을 목표로 합니다. 대안을 모두 검토한 후에도 브레이킹 체인지가 허용되어야 한다고 판단되는 타당한 이유가 있는 경우, 아래의 절차에 따라 예외를 요청할 수 있습니다.

브레이킹 체인지를 진행하기 위한 승인은 어떻게 받나요?#

기본적으로, 아래 절차에 따라 브레이킹 체인지 구현 계획에 대한 명시적 승인이 부여되지 않는 한 어떠한 브레이킹 체인지도 허용되지 않습니다.

  • 브레이킹 체인지 예외 템플릿을 사용하여 이슈를 생성하고 필수 항목을 모두 작성하세요.

  • 브레이킹 체인지가 아래 기준 중 하나라도 해당하는 경우, 요청에 이를 명시하세요. 승인을 보장하지는 않지만 좋은 근거를 제시하는 데 도움이 됩니다. 승인되는 대부분의 브레이킹 체인지는 아래 카테고리 중 최소 하나에 해당합니다:

브레이킹 체인지의 영향이 고객의 조치가 필요 없는 자동화된 마이그레이션을 통해 완전히 완화되었습니다.

  • 브레이킹 체인지는 GitLab Self-Managed, GitLab.com, GitLab Dedicated 전반의 실제 제품 사용 추적을 기준으로 고객 영향이 미미합니다. 예를 들어 GitLab 고객 기반의 1% 미만에 영향을 미치는 경우입니다.

  • 브레이킹 체인지가 Severity 1 또는 2에 해당하는 심각한 보안 위험으로 인해 구현됩니다.

  • 이슈가 검토 준비가 되면 템플릿의 지침에 따라 승인 절차를 시작하기 위해 태그할 담당자를 지정하세요.

  • 공개적으로 소식을 공유하거나 제안된 일정을 확정하기 전에 승인을 받을 때까지 기다리세요. 초기 제출에서 승인 또는 거부까지의 시간은 다양하므로, 제안된 제거 일정보다 최소 6개월 전에 제출하세요.

요청 템플릿에 포함되는 세부 사항은 무엇인가요?#

  • 요약 (Executive Summary)

  • 영향 평가 (Impact Assessment)

  • 롤아웃 및 커뮤니케이션 계획 (Rollout & Communication Plan)

내부 커뮤니케이션 (Internal Communication)

  • 고객 커뮤니케이션 (Customer Communication)

요청 템플릿

브레이킹 체인지 승인 후 다음 단계는 무엇인가요?#

  • 변경 사항에 관한 고객의 단일 진실 공급원(Single Source Of Truth, SSOT)으로 사용될 공개 지원 중단 이슈를 생성하세요.

  • 아래 지침에 따라 해당 변경 사항이 지원 중단 문서 페이지에 추가되도록 하세요.

  • 요청에서 승인된 롤아웃 및 커뮤니케이션 계획을 따르세요.

지원 중단 및 제거 문서 업데이트#

지원 중단 및 제거 문서는 gitlab/data/deprecations에 위치한 YAML 파일로부터 생성됩니다.

YAML 파일이 추가, 편집 또는 제거될 때 지원 중단 및 제거 페이지를 업데이트하려면:

커맨드 라인에서 gitlab-org/gitlab 프로젝트의 로컬 클론으로 이동하세요.

data/deprecations 아래에 YAML 파일을 생성, 편집 또는 제거하세요.

지원 중단 및 제거 문서를 컴파일하세요:

bin/rake gitlab:docs:compile_deprecations

필요한 경우 다음 명령으로 문서가 최신 상태인지 확인할 수 있습니다:

bin/rake gitlab:docs:check_deprecations

업데이트된 문서를 커밋하고 변경 사항을 푸시하세요.

지원 중단 및 제거 템플릿을 사용하여 머지 리퀘스트를 생성하세요.

관련 핸드북 페이지:

브레이킹 체인지 윈도우 문서 업데이트#

브레이킹 체인지 윈도우 문서는 gitlab/data/deprecations에 위치한 YAML 파일로부터 생성됩니다.

다음 조건을 모두 충족하는 경우 지원 중단 항목이 브레이킹 체인지 윈도우 페이지에 포함됩니다:

  • removal_milestone이 타깃 마일스톤(예: 19.0)과 일치합니다.

  • breaking_change가 true입니다.

  • gitlab_com이 false가 아닙니다. 필드가 없으면 기본값은 true입니다. GitLab.com에 영향을 미치지 않는 브레이킹 체인지(예: Self-managed 인스턴스에만 영향을 미치는 변경 사항)의 경우 gitlab_com: false로 설정하세요.

윈도우 할당#

모든 해당 지원 중단 항목은 YAML 파일의 window 값에 관계없이 기본적으로 **기본 윈도우(primary window)**에 할당됩니다.

**긴급 대응 윈도우(contingency window)**는 대체 수단으로 사용할 수 있습니다. 브레이킹 체인지를 긴급 대응 윈도우로 이동하려면 해당 YAML 파일에서 window: 2를 설정하세요. 긴급 대응 윈도우 섹션은 최소 하나의 지원 중단 항목이 할당된 경우에만 페이지에 표시됩니다.

페이지 업데이트 방법#

커맨드 라인에서 gitlab-org/gitlab 프로젝트의 로컬 클론으로 이동하세요.

data/deprecations 아래에 YAML 파일을 생성, 편집 또는 제거하세요.

브레이킹 체인지 윈도우 문서를 컴파일하세요:

bin/rake gitlab:docs:compile_windows

지원 중단 문서를 업데이트하세요:

bin/rake gitlab:docs:compile_deprecations

필요한 경우 다음 명령으로 문서가 최신 상태인지 확인할 수 있습니다:

bin/rake gitlab:docs:check_windows

업데이트된 문서를 커밋하고 변경 사항을 푸시하세요.

머지 리퀘스트를 생성하세요.

브레이킹 체인지 윈도우 페이지에서 사용되는 YAML 필드#

필드 필수 여부 설명
title 예 지원 중단 항목 링크로 표시되는 제목
removal_milestone 예 타깃 마일스톤과 일치해야 합니다.
breaking_change 예 true여야 합니다.
gitlab_com 아니요 페이지에서 제외하려면 false로 설정합니다. 기본값은 true입니다.
window 아니요 긴급 대응 윈도우에 할당하려면 2로 설정합니다. 다른 값(또는 없음)은 기본 윈도우에 할당됩니다.
impact 아니요 테이블에 표시됩니다. 문자열 또는 배열일 수 있습니다.
scope 아니요 테이블에 표시됩니다. 문자열 또는 배열일 수 있습니다.
check_impact 아니요 테이블에 표시되는 URL입니다. 값이 있는 경우에만 렌더링됩니다.

관련 문서 업데이트#

기능이 지원 중단 및 제거될 때 관련 문서를 업데이트하세요.

API 지원 중단 및 브레이킹 체인지#

API에는 지원 중단 및 브레이킹 체인지에 관한 특별 규칙이 있습니다.

REST API v4#

REST API v4는 이전에 실험 또는 베타로 표시된 API 기능이 아닌 한 브레이킹 체인지를 적용할 수 없습니다.

브레이킹 체인지 대신 무엇을 해야 하나요?를 참조하세요.

GraphQL API#

GraphQL API는 브레이킹 체인지를 적용하기 전에 표준 주기보다 더 긴 지원 중단 주기를 요구합니다.

GraphQL 지원 중단 프로세스를 참조하세요.

웹훅 브레이킹 체인지#

웹훅 페이로드에는 브레이킹 체인지를 적용할 수 없습니다.

웹훅 페이로드의 브레이킹 체인지 기준 목록 및 대안에 대해서는 웹훅 브레이킹 체인지 가이드를 참조하세요.

지원 중단 기능에 대한 커뮤니티 기여는 어떻게 처리되나요?#

지원 중단 기능에 대한 개발은 Priority 1 / Severity 1 버그 수정으로 제한됩니다. 지원 중단 기능에 대한 커뮤니티 기여는 마일스톤 계획 중에 우선순위가 부여되지 않을 가능성이 높습니다.

그러나 GitLab에서는 팀 멤버에게 자율성을 부여합니다. 따라서 기여와 관련된 팀의 멤버가 재량에 따라 검토 및 병합을 결정할 수 있습니다.

기타 지침#

구성 제거에 대해서는 Omnibus 지원 중단 정책을 참조하세요.

버전 관리 및 업그레이드 세부 정보에 대해서는 릴리스 및 유지보수 정책을 참조하세요.

GitLab 기능 지원 중단

GitLab v19.1
원문 보기
요약

이 페이지에서 사용되는 용어에 대한 자세한 내용은 용어 설명을 참조하세요. 고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 하는 경우, 해당 변경은 브레이킹 체인지로 간주됩니다. 브레이킹 체인지는 다음과 같은 다양한 원인에서 발생할 수 있습니다:

이 페이지에서 사용되는 용어에 대한 자세한 내용은 용어 설명을 참조하세요.

브레이킹 체인지 정책#

고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 하는 경우, 해당 변경은 브레이킹 체인지로 간주됩니다.

브레이킹 체인지는 다음과 같은 다양한 원인에서 발생할 수 있습니다:

  • 의도적인 제품 변경

  • 구성 업데이트

  • 서드파티 지원 중단

  • 기타 다양한 원인

많은 사용자에게 GitLab은 티어 제로 시스템입니다. 사용자의 비즈니스를 생성, 릴리스, 운영, 확장하는 데 있어 매우 중요한 역할을 합니다. 브레이킹 체인지의 결과는 심각할 수 있습니다.

제품 및 엔지니어링 매니저는 플랫폼에 적용하는 변경으로 인한 고객 영향에 대해 책임을 집니다. 변경 관리의 부담은 고객이 아닌 GitLab이 부담합니다.

GitLab은 모든 브레이킹 체인지를 없애는 것을 목표로 합니다. 대안을 모두 검토한 후에도 브레이킹 체인지가 허용되어야 한다고 판단되는 타당한 이유가 있는 경우, 아래의 절차에 따라 예외를 요청할 수 있습니다.

브레이킹 체인지를 진행하기 위한 승인은 어떻게 받나요?#

기본적으로, 아래 절차에 따라 브레이킹 체인지 구현 계획에 대한 명시적 승인이 부여되지 않는 한 어떠한 브레이킹 체인지도 허용되지 않습니다.

  • 브레이킹 체인지 예외 템플릿을 사용하여 이슈를 생성하고 필수 항목을 모두 작성하세요.

  • 브레이킹 체인지가 아래 기준 중 하나라도 해당하는 경우, 요청에 이를 명시하세요. 승인을 보장하지는 않지만 좋은 근거를 제시하는 데 도움이 됩니다. 승인되는 대부분의 브레이킹 체인지는 아래 카테고리 중 최소 하나에 해당합니다:

브레이킹 체인지의 영향이 고객의 조치가 필요 없는 자동화된 마이그레이션을 통해 완전히 완화되었습니다.

  • 브레이킹 체인지는 GitLab Self-Managed, GitLab.com, GitLab Dedicated 전반의 실제 제품 사용 추적을 기준으로 고객 영향이 미미합니다. 예를 들어 GitLab 고객 기반의 1% 미만에 영향을 미치는 경우입니다.

  • 브레이킹 체인지가 Severity 1 또는 2에 해당하는 심각한 보안 위험으로 인해 구현됩니다.

  • 이슈가 검토 준비가 되면 템플릿의 지침에 따라 승인 절차를 시작하기 위해 태그할 담당자를 지정하세요.

  • 공개적으로 소식을 공유하거나 제안된 일정을 확정하기 전에 승인을 받을 때까지 기다리세요. 초기 제출에서 승인 또는 거부까지의 시간은 다양하므로, 제안된 제거 일정보다 최소 6개월 전에 제출하세요.

요청 템플릿에 포함되는 세부 사항은 무엇인가요?#

  • 요약 (Executive Summary)

  • 영향 평가 (Impact Assessment)

  • 롤아웃 및 커뮤니케이션 계획 (Rollout & Communication Plan)

내부 커뮤니케이션 (Internal Communication)

  • 고객 커뮤니케이션 (Customer Communication)

요청 템플릿

브레이킹 체인지 승인 후 다음 단계는 무엇인가요?#

  • 변경 사항에 관한 고객의 단일 진실 공급원(Single Source Of Truth, SSOT)으로 사용될 공개 지원 중단 이슈를 생성하세요.

  • 아래 지침에 따라 해당 변경 사항이 지원 중단 문서 페이지에 추가되도록 하세요.

  • 요청에서 승인된 롤아웃 및 커뮤니케이션 계획을 따르세요.

지원 중단 및 제거 문서 업데이트#

지원 중단 및 제거 문서는 gitlab/data/deprecations에 위치한 YAML 파일로부터 생성됩니다.

YAML 파일이 추가, 편집 또는 제거될 때 지원 중단 및 제거 페이지를 업데이트하려면:

커맨드 라인에서 gitlab-org/gitlab 프로젝트의 로컬 클론으로 이동하세요.

data/deprecations 아래에 YAML 파일을 생성, 편집 또는 제거하세요.

지원 중단 및 제거 문서를 컴파일하세요:

bin/rake gitlab:docs:compile_deprecations

필요한 경우 다음 명령으로 문서가 최신 상태인지 확인할 수 있습니다:

bin/rake gitlab:docs:check_deprecations

업데이트된 문서를 커밋하고 변경 사항을 푸시하세요.

지원 중단 및 제거 템플릿을 사용하여 머지 리퀘스트를 생성하세요.

관련 핸드북 페이지:

브레이킹 체인지 윈도우 문서 업데이트#

브레이킹 체인지 윈도우 문서는 gitlab/data/deprecations에 위치한 YAML 파일로부터 생성됩니다.

다음 조건을 모두 충족하는 경우 지원 중단 항목이 브레이킹 체인지 윈도우 페이지에 포함됩니다:

  • removal_milestone이 타깃 마일스톤(예: 19.0)과 일치합니다.

  • breaking_change가 true입니다.

  • gitlab_com이 false가 아닙니다. 필드가 없으면 기본값은 true입니다. GitLab.com에 영향을 미치지 않는 브레이킹 체인지(예: Self-managed 인스턴스에만 영향을 미치는 변경 사항)의 경우 gitlab_com: false로 설정하세요.

윈도우 할당#

모든 해당 지원 중단 항목은 YAML 파일의 window 값에 관계없이 기본적으로 **기본 윈도우(primary window)**에 할당됩니다.

**긴급 대응 윈도우(contingency window)**는 대체 수단으로 사용할 수 있습니다. 브레이킹 체인지를 긴급 대응 윈도우로 이동하려면 해당 YAML 파일에서 window: 2를 설정하세요. 긴급 대응 윈도우 섹션은 최소 하나의 지원 중단 항목이 할당된 경우에만 페이지에 표시됩니다.

페이지 업데이트 방법#

커맨드 라인에서 gitlab-org/gitlab 프로젝트의 로컬 클론으로 이동하세요.

data/deprecations 아래에 YAML 파일을 생성, 편집 또는 제거하세요.

브레이킹 체인지 윈도우 문서를 컴파일하세요:

bin/rake gitlab:docs:compile_windows

지원 중단 문서를 업데이트하세요:

bin/rake gitlab:docs:compile_deprecations

필요한 경우 다음 명령으로 문서가 최신 상태인지 확인할 수 있습니다:

bin/rake gitlab:docs:check_windows

업데이트된 문서를 커밋하고 변경 사항을 푸시하세요.

머지 리퀘스트를 생성하세요.

브레이킹 체인지 윈도우 페이지에서 사용되는 YAML 필드#

필드 필수 여부 설명
title 예 지원 중단 항목 링크로 표시되는 제목
removal_milestone 예 타깃 마일스톤과 일치해야 합니다.
breaking_change 예 true여야 합니다.
gitlab_com 아니요 페이지에서 제외하려면 false로 설정합니다. 기본값은 true입니다.
window 아니요 긴급 대응 윈도우에 할당하려면 2로 설정합니다. 다른 값(또는 없음)은 기본 윈도우에 할당됩니다.
impact 아니요 테이블에 표시됩니다. 문자열 또는 배열일 수 있습니다.
scope 아니요 테이블에 표시됩니다. 문자열 또는 배열일 수 있습니다.
check_impact 아니요 테이블에 표시되는 URL입니다. 값이 있는 경우에만 렌더링됩니다.

관련 문서 업데이트#

기능이 지원 중단 및 제거될 때 관련 문서를 업데이트하세요.

API 지원 중단 및 브레이킹 체인지#

API에는 지원 중단 및 브레이킹 체인지에 관한 특별 규칙이 있습니다.

REST API v4#

REST API v4는 이전에 실험 또는 베타로 표시된 API 기능이 아닌 한 브레이킹 체인지를 적용할 수 없습니다.

브레이킹 체인지 대신 무엇을 해야 하나요?를 참조하세요.

GraphQL API#

GraphQL API는 브레이킹 체인지를 적용하기 전에 표준 주기보다 더 긴 지원 중단 주기를 요구합니다.

GraphQL 지원 중단 프로세스를 참조하세요.

웹훅 브레이킹 체인지#

웹훅 페이로드에는 브레이킹 체인지를 적용할 수 없습니다.

웹훅 페이로드의 브레이킹 체인지 기준 목록 및 대안에 대해서는 웹훅 브레이킹 체인지 가이드를 참조하세요.

지원 중단 기능에 대한 커뮤니티 기여는 어떻게 처리되나요?#

지원 중단 기능에 대한 개발은 Priority 1 / Severity 1 버그 수정으로 제한됩니다. 지원 중단 기능에 대한 커뮤니티 기여는 마일스톤 계획 중에 우선순위가 부여되지 않을 가능성이 높습니다.

그러나 GitLab에서는 팀 멤버에게 자율성을 부여합니다. 따라서 기여와 관련된 팀의 멤버가 재량에 따라 검토 및 병합을 결정할 수 있습니다.

기타 지침#

구성 제거에 대해서는 Omnibus 지원 중단 정책을 참조하세요.

버전 관리 및 업그레이드 세부 정보에 대해서는 릴리스 및 유지보수 정책을 참조하세요.