실험, 베타 및 일반적으로 사용 가능한 기능에 대한 지원

GitLab은 때때로 기능을 실험적이나 베타로 출시하며, 사용자는 새로운 경험을 시험해볼 수 있습니다.

이러한 종류의 기능 출시를 위한 몇 가지 이유는 다음과 같습니다:

모든 설계된 사용 사례에 대해 현재 형태의 기능의 스케일, 지원 및 유지 관리 부담의 엣지 케이스를 검증합니다.
아직 MVC로 간주될 정도로 충분히 완전하지 않지만, 개발 과정의 일환으로 코드베이스에 추가됩니다.

일부 기능은 이러한 권장 사항이 설정되기 전에 개발되었거나, 팀이 대안을 결정한 경우에는 권장 사항과 정렬되지 않을 수 있습니다.

모든 기타 기능은 일반적으로 사용 가능(GA)으로 간주됩니다.

실험

실험적 기능:

생산 사용을 위한 준비가 되어 있지 않습니다.
지원이 제공되지 않습니다. 이러한 기능에 대한 문제는 GitLab 이슈 트래커에 등록해야 합니다.
불안정할 수 있습니다.
언제든지 제거될 수 있습니다.
데이터 손실 위험이 있을 수 있습니다.
문서화가 없거나 정보가 GitLab 이슈나 블로그로 제한될 수 있습니다.
최종 사용자 경험이 없을 수 있으며, 빠른 작업이나 API 요청을 통해서만 접근할 수 있습니다.

베타

베타 기능:

생산 사용을 위한 준비가 되어 있지 않을 수 있습니다.
상업적으로 합리적인 노력을 기반으로 지원됩니다. 하지만 문제를 해결하기 위해 개발팀의 추가 시간과 지원이 필요하다는 예상이 필요합니다.
불안정할 수 있습니다.
변경될 가능성이 낮은 구성 및 종속성이 있습니다.
변경될 가능성이 낮은 기능 및 기능이 있습니다. 그러나 주요 릴리스 외부에서 또는 일반적으로 사용 가능한 기능보다 적은 통지로 파손된 변경이 발생할 수 있습니다.
낮은 데이터 손실 위험이 있습니다.
완전하거나 거의 완전한 사용자 경험을 가지고 있습니다.

일반적으로 사용 가능(GA)

일반적으로 사용 가능한 기능:

모든 규모에서 생산 사용을 위한 준비가 되어 있습니다.
완전히 지원되며 문서화되어 있습니다.
GitLab 디자인 표준에 맞춘 완전한 사용자 경험을 가지고 있습니다.

모든 기능이 생산 중입니다

모든 실험적, 베타 및 일반적으로 사용 가능한 기능은 GitLab.com에서 사용할 수 있으므로 모두 “생산 중”으로 간주됩니다.

GitLab 실험 및 베타 개발 지침

팀은 강력한 이유가 없는 한 처음부터 기능을 GA로 출시해야 합니다.

제품 개발 팀은 다음과 같은 GitLab 사용자나 플랫폼에 대해 상당한 위험이나 마찰을 초래할 수 있다고 합리적으로 믿는 변경을 피해야 합니다:

사용자가 접근하는 기존 생산 데이터의 손상 또는 유출 위험.
애플리케이션의 다른 부분 불안정화.
월간 활성 사용자(MAU)가 많은 영역에 마찰 도입.

실험 기능

사용자를 위한 실험 세부 사항에 추가하여, 실험은 다음을 포함해야 합니다:

마찰을 최소화하여 선택할 수 있는 방법을 제공합니다. 예를 들어, 기능 플래그를 전환해야 하는 것은 너무 많은 마찰이며, 그러나 UI에서 그룹 또는 프로젝트 수준의 설정은 그렇지 않습니다.
선택 시 GitLab 테스트 계약서로 연결합니다.
해당 기능이 GitLab 테스트 계약서의 적용을 받는다는 내용을 반영하는 문서가 있어야 합니다.
실험 상태를 반영하는 UI가 있어야 합니다.
내부 및 외부 사용자와 소통하기 위한 피드백 이슈가 있어야 합니다.
릴리스 게시물에서 발표하지 않아야 합니다.
필요 시 발견 순간 을 통해 사용자 인터페이스에 홍보되어야 합니다.

모든 실험적 기능은 검토 기준을 충족해야 하며,
생산 준비 검토를 시작해야 하고,
준비 템플릿의 실험 섹션을 완료해야 합니다.

베타 기능

사용자에 대한 베타 세부정보 외에도, 베타 기능은 다음과 같아야 합니다:

대부분의 기능에 대해 필수적이지 않거나 필요하지 않아야 합니다.
베타 상태를 반영하는 문서가 있어야 합니다.
베타 상태를 반영하는 UI가 있어야 합니다.
내부 및 외부 사용자와 소통하기 위한 피드백 이슈가 있어야 합니다.
기본적으로 활성화된 기능 플래그 뒤에 있어야 합니다.
기본적으로 비활성화된 토글 뒤에 있어야 합니다.
원할 경우 베타 상태를 반영하는 릴리즈 게시물에서 발표되어야 합니다.
필요할 경우 디스커버리 모먼트를 통해 사용자 인터페이스에서 홍보되어야 합니다.

검토 기준을 충족하는 모든 베타 기능은 준비 템플릿의 베타 섹션까지 모든 섹션을 완료해야 하며, 생산 준비 검토 프로세스를 따라야 합니다.

일반 제공 기능

일반적으로 제공 가능한 기능은 검토 기준을 충족해야 하며, 생산 준비 검토를 완료하고 준비 템플릿의 GA 섹션까지 모든 섹션을 완료해야 합니다.

조기 액세스 제공

우리의 사명은 “모두가 기여할 수 있다”는 것이며, 이는 회사 외부 사람들이 기능을 시도할 수 있을 때만 가능합니다. 다양한 조직의 사람들이 어떤 것을 시도하면 더 높은 품질의 (더 다양한) 피드백을 받게 되므로, 충분한 가치가 있을 때 사용자가 실험적 기능에 옵트인할 수 있도록 하십시오.

가능한 한, 내부 테스트만 하거나 기능이 베타 상태가 되기를 기다리기보다는 실험적 기능을 외부에 출시하십시오. 우리는 기능을 내부 전용으로 오랜 기간 유지하면 불필요하게 속도가 느려진다는 것을 배웠습니다.

실험적 기능은 사람들이/조직이 실험에 옵트인할 때만 표시되므로, 우리는 여기서 실수를 하고 문자 그대로 실험할 수 있습니다.

실험 및 베타 종료 기준

일반 제공 이전 단계가 가능한 한 짧게 유지되도록 각 실험, 베타 및 제한된 가용성 단계는 종료 기준을 포함해야 합니다. 이는 빠른 반복을 장려하고 주기 시간을 줄입니다.

GitLab 제품 관리자는 실험적 및 베타 기능에 적용할 종료 기준을 결정할 때 다음 사항을 고려해야 합니다:

시간: 기능이 일반 제공되는 종료 날짜를 정의하십시오.
- GA로의 종료 준비를 정의할 시간 제한 목표 지표를 설정하는 것도 고려하십시오. 예를 들어, 실험 출시 후 6개월 동안 MoM에서 유지되는 고객 수 X명, 베타 출시 후 3개월 이내의 무료 및 유료 사용자 성장률 X% 등입니다.
- 시장 출시 시간, 사용자 경험 및 경험의 풍부함의 균형을 염두에 두십시오. 어떤 베타 프로그램은 한 마일스톤 동안 지속되었고, 어떤 것은 몇 년 동안 지속되었습니다.
피드백: 온보딩되고 인터뷰된 최소 고객 수를 정의하십시오.
- 단계 종료 기준으로 사용자 피드백을 사용할 때 시간 제한을 설정하는 것도 고려하십시오. 주어진 시간이 지나고 충분한 사용자로부터 피드백을 요청할 수 없다면, 우리가 가진 것을 배송하고 그 시점에서 GA로 반복하는 것이 낫습니다.
제한된 기능 완료: 일반 제공으로 이동하기 전에 완료해야 할 기능이 있는지 결정하십시오.
- “단 하나 더” 기능을 포함하는 데 주의하십시오. 더 많은 사용자의 피드백을 통해 더 빠르고 효과적인 반복이 가능하므로, 일반 제공으로 가는 것이 선호됩니다.
시스템 성능 지표: 플랫폼이 일반 제공을 위해 준비되기 전에 보여줘야 할 기준을 결정하십시오. 예를 들어 반응 시간 및 특정 요청 수를 초당 성공적으로 처리하는 것이 포함됩니다.
성공 기준: 모든 기능이 GA에 도달할 수 있는 것은 아닙니다. 초기에 받은 피드백이 다른 방향으로 전환하는 것이 더 큰 가치나 더 나은 사용자 경험을 제공한다고 판단되면 전환하는 것이 괜찮습니다. 제품에 기능을 배치할 가치가 있는지를 결정하기 위해 해결해야 할 개방 질문을 나열하고 답변하십시오.

AI 기능의 종료 기준에 대해서는 위의 내용 외에 UX 성숙도 요구사항을 참조하십시오.