GitLab 기능 지원 중단

GitLab 기능의 지원 중단 및 제거 정책, 브레이킹 체인지 승인 절차, 문서 업데이트 방법을 설명합니다.

이 페이지에서 사용하는 용어에 대한 자세한 내용은 용어 정리 를 참고합니다. 브레이킹 체인지 정책 # 고객이 GitLab 워크플로가 중단되지 않도록 조치를 취해야 한다면 그 변경은 모두 브레이킹 체인지에 해당합니다. 브레이킹 체인지는 다음과 같은 곳에서 비롯될 수 있습니다. 의도적인 제품 변경 구성 업데이트 서드파티의 지원 중단 그 밖의 여러 원인 많은 사용자에게 GitLab은 티어 제로 시스템입니다. 사용자의 비즈니스를 만들고, 릴리스하고, 운영하고, 확장하는 데 핵심적인 역할을 합니다. 따라서 브레이킹 체인지의 결과는 심각할 수 있습니다. 제품 관리자와 엔지니어링 관리자는 자신이 플랫폼에 가한 변경으로 발생하는 고객 영향에 대해 책임을 집니다. 변경 관리의 부담은 고객이 아니라 GitLab에 있습니다. GitLab은 모든 브레이킹 체인지를 없애는 것을 목표로 합니다. 대안을 모두 검토했고 브레이킹 체인지를 허용해야 할 타당한 근거가 있다고 판단된다면, 아래 절차에 따라 예외를 요청할 수 있습니다. 브레이킹 체인지 진행 승인 절차 # 기본적으로 아래 절차를 거쳐 브레이킹 체인지 구현 계획이 명시적으로 승인되지 않는 한 어떤 브레이킹 체인지도 허용되지 않습니다. Breaking Change Exception 템플릿 으로 이슈를 열고 필수 섹션을 모두 작성합니다. 해당 브레이킹 체인지가 아래 기준 중 하나에 해당한다면 요청에 그 점을 밝힙니다. 승인을 보장하지는 않지만 근거를 강화하는 데 도움이 됩니다. 승인되는 브레이킹 체인지는 대부분 다음 중 최소 하나에 해당합니다. 고객의 조치가 필요 없는 자동 마이그레이션으로 브레이킹 체인지의 영향이 완전히 완화되었습니다. GitLab Self-Managed, GitLab.com, GitLab Dedicated 전반의 실제 제품 사용 추적으로 측정했을 때 고객 영향이 미미합니다. 예를 들어 GitLab 고객 기반의 1% 미만에 영향을 미치는 경우입니다. 심각도 1 또는 2 수준의 중대한 보안 위험 때문에 브레이킹 체인지를 구현합니다. 이슈가 검토 준비되면 템플릿의 안내에 따라 승인 절차를 시작할 대상자를 태그합니다. 승인을 받기 전에는 소식을 공개하거나 제안한 일정을 확정하지 않습니다. 최초 제출에서 승인 또는 거절까지 걸리는 시간은 경우에 따라 다르므로, 제안한 제거 시점보다 최소 6개월 앞서 제출합니다. 요청 템플릿에 포함되는 세부 사항 # 요약(Executive Summary) 영향 평가(Impact Assessment) 롤아웃 및 커뮤니케이션 계획(Rollout & Communication Plan) 내부 커뮤니케이션 고객 커뮤니케이션 요청 템플릿 브레이킹 체인지 승인 이후 단계 # 해당 변경에 대해 고객에게 정본 역할을 할 공개 지원 중단 이슈 를 생성합니다. 아래 안내에 따라 해당 변경을 지원 중단 문서 페이지에 추가합니다. 요청에서 승인된 롤아웃 및 커뮤니케이션 계획을 따릅니다. 지원 중단 및 제거 문서 업데이트 # 지원 중단 및 제거 문서는 gitlab/data/depreca