이 페이지에서 사용하는 용어에 대한 자세한 내용은 용어 정리를 참고합니다.

브레이킹 체인지 정책#

고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 한다면 그 변경은 모두 브레이킹 체인지에 해당합니다.

브레이킹 체인지는 다음과 같은 곳에서 비롯될 수 있습니다.

• 의도적인 제품 변경
• 구성 업데이트
• 서드파티의 지원 중단
• 그 밖의 여러 원인

많은 사용자에게 GitLab은 티어 제로 시스템입니다. 사용자의 비즈니스를 만들고, 릴리스하고, 운영하고, 확장하는 데 핵심적인 역할을 합니다. 따라서 브레이킹 체인지의 결과는 심각할 수 있습니다.

제품 관리자와 엔지니어링 관리자는 자신이 플랫폼에 가한 변경으로 발생하는 고객 영향에 대해 책임을 집니다. 변경 관리의 부담은 고객이 아니라 GitLab에 있습니다.

GitLab은 모든 브레이킹 체인지를 없애는 것을 목표로 합니다. 대안을 모두 검토했고 브레이킹 체인지를 허용해야 할 타당한 근거가 있다고 판단된다면, 아래 절차에 따라 예외를 요청할 수 있습니다.

브레이킹 체인지 진행 승인 절차#

기본적으로 아래 절차를 거쳐 브레이킹 체인지 구현 계획이 명시적으로 승인되지 않는 한 어떤 브레이킹 체인지도 허용되지 않습니다.

1. Breaking Change Exception 템플릿으로 이슈를 열고 필수 섹션을 모두 작성합니다.
2. 해당 브레이킹 체인지가 아래 기준 중 하나에 해당한다면 요청에 그 점을 밝힙니다. 승인을 보장하지는 않지만 근거를 강화하는 데 도움이 됩니다. 승인되는 브레이킹 체인지는 대부분 다음 중 최소 하나에 해당합니다.
   1. 고객의 조치가 필요 없는 자동 마이그레이션으로 브레이킹 체인지의 영향이 완전히 완화되었습니다.
   2. GitLab Self-Managed, GitLab.com, GitLab Dedicated 전반의 실제 제품 사용 추적으로 측정했을 때 고객 영향이 미미합니다. 예를 들어 GitLab 고객 기반의 1% 미만에 영향을 미치는 경우입니다.
   3. 심각도 1 또는 2 수준의 중대한 보안 위험 때문에 브레이킹 체인지를 구현합니다.
3. 이슈가 검토 준비되면 템플릿의 안내에 따라 승인 절차를 시작할 대상자를 태그합니다.
4. 승인을 받기 전에는 소식을 공개하거나 제안한 일정을 확정하지 않습니다. 최초 제출에서 승인 또는 거절까지 걸리는 시간은 경우에 따라 다르므로, 제안한 제거 시점보다 최소 6개월 앞서 제출합니다.

요청 템플릿에 포함되는 세부 사항#

• 요약(Executive Summary)
• 영향 평가(Impact Assessment)
• 롤아웃 및 커뮤니케이션 계획(Rollout & Communication Plan)
  • 내부 커뮤니케이션
  • 고객 커뮤니케이션

요청 템플릿

브레이킹 체인지 승인 이후 단계#

1. 해당 변경에 대해 고객에게 정본 역할을 할 공개 지원 중단 이슈를 생성합니다.
2. 아래 안내에 따라 해당 변경을 지원 중단 문서 페이지에 추가합니다.
3. 요청에서 승인된 롤아웃 및 커뮤니케이션 계획을 따릅니다.

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

지원 중단 및 제거 문서는 gitlab/data/deprecations에 있는 YAML 파일에서 생성됩니다.

YAML 파일이 추가·수정·삭제되었을 때 지원 중단 및 제거 페이지를 업데이트하려면 다음과 같이 합니다.

1. 명령줄에서 gitlab-org/gitlab 프로젝트의 로컬 클론으로 이동합니다.

2. data/deprecations 아래에서 YAML 파일을 생성·수정·삭제합니다.

3. 지원 중단 및 제거 문서를 컴파일합니다.

   bin/rake gitlab:docs:compile_deprecations
   

4. 필요하다면 다음 명령으로 문서가 최신 상태인지 확인할 수 있습니다.

   bin/rake gitlab:docs:check_deprecations
   

5. 업데이트된 문서를 커밋하고 변경 사항을 푸시합니다.

6. Deprecations and Removals 템플릿으로 머지 리퀘스트를 생성합니다.

관련 핸드북 페이지:

• https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes
• https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#update-the-deprecations-doc

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

브레이킹 체인지 윈도우 문서는 gitlab/data/deprecations에 있는 YAML 파일에서 생성됩니다.

다음 조건을 모두 만족할 때 지원 중단 항목이 브레이킹 체인지 윈도우 페이지에 포함됩니다.

• removal_milestone 이 대상 마일스톤과 일치합니다(예: 19.0).
• breaking_change가 true 입니다.
• gitlab_com 이 false가 아닙니다. 이 필드가 없으면 기본값은 true 입니다. GitLab.com에 영향을 주지 않는 브레이킹 체인지(예: Self-Managed 인스턴스에만 영향을 주는 변경)에는 gitlab_com: false를 설정합니다.

윈도우 할당#

일치하는 모든 지원 중단 항목은 YAML 파일의 window 값과 관계없이 기본적으로 기본 윈도우에 할당됩니다.

예비 수단으로 긴급 대응 윈도우를 사용할 수 있습니다. 브레이킹 체인지를 긴급 대응 윈도우로 옮기려면 해당 YAML 파일에 window: 2를 설정합니다. 긴급 대응 윈도우 섹션은 최소 한 개의 지원 중단 항목이 할당되었을 때만 페이지에 표시됩니다.

페이지 업데이트 방법#

1. 명령줄에서 gitlab-org/gitlab 프로젝트의 로컬 클론으로 이동합니다.

2. data/deprecations 아래에서 YAML 파일을 생성·수정·삭제합니다.

3. 브레이킹 체인지 윈도우 문서를 컴파일합니다.

   bin/rake gitlab:docs:compile_windows
   

4. 지원 중단 문서를 업데이트합니다.

   bin/rake gitlab:docs:compile_deprecations
   

5. 필요하다면 다음 명령으로 문서가 최신 상태인지 확인할 수 있습니다.

   bin/rake gitlab:docs:check_windows
   

6. 업데이트된 문서를 커밋하고 변경 사항을 푸시합니다.

7. 머지 리퀘스트를 생성합니다.

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

관련 문서 업데이트#

기능이 지원 중단되고 제거되면 관련 문서를 업데이트합니다.

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

GitLab의 API에는 지원 중단과 브레이킹 체인지에 관한 별도 규칙이 있습니다.

REST API v4#

REST API v4는 해당 API 기능이 앞서 실험 또는 베타로 표시되지 않은 한 브레이킹 체인지를 적용할 수 없습니다.

브레이킹 체인지 대신 할 수 있는 일을 참고합니다.

GraphQL API#

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

GraphQL 지원 중단 절차를 참고합니다.

웹훅 브레이킹 체인지#

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

어떤 경우가 웹훅 페이로드의 브레이킹 체인지에 해당하는지와 그 대신 할 일의 목록은 웹훅 브레이킹 체인지 가이드를 참고합니다.

지원 중단 기능에 대한 커뮤니티 기여 처리 방식#

지원 중단된 기능에 대한 개발은 우선순위 1 / 심각도 1 버그 수정으로 제한됩니다. 지원 중단된 기능에 대한 커뮤니티 기여는 마일스톤 계획에서 우선순위가 부여될 가능성이 낮습니다.

다만 GitLab은 팀 구성원에게 자율성을 부여합니다. 따라서 해당 기여와 관련된 팀의 구성원이 재량으로 이를 검토하고 머지하기로 결정할 수 있습니다.

기타 지침#

구성 제거에 대해서는 Omnibus 지원 중단 정책을 참고합니다.

버전 관리와 업그레이드에 대한 자세한 내용은 릴리스 및 유지 관리 정책을 참고합니다.