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 T