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

가끔 GitLab은 기능을 실험 또는 베타로 출시하며, 사용자는 새로운 경험을 선택하고 테스트할 수 있습니다. 이러한 종류의 기능 출시에 대한 몇 가지 이유는 다음과 같습니다.

현재 설계된 사용 사례별로 현재 형태의 기능의 규모, 지원 및 유지 관리 부담의 엣지 케이스를 확인합니다.
최소한의 실용적 변경(MVC)로 간주할만큼 완전하지 않지만 개발 프로세스의 일부로 코드베이스에 추가됩니다.

이 권장 사항과 부합하지 않는 기능은 권고사항이 수립되기 전에 개발된 경우 또는 대체 구현 방법이 필요하다고 팀이 결정한 경우에 해당할 수 있습니다.

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

실험

실험 기능:

프로덕션에서 사용할 준비가 되지 않았습니다.
지원이 제공되지 않음. 해당 기능과 관련된 문제는 GitLab 이슈 트래커에서 열어야 합니다.
불안정할 수 있습니다.
언제든지 제거될 수 있습니다.
데이터 손실의 위험이 있을 수 있습니다.
문서가 없을 수 있거나 GitLab 이슈나 블로그에 제한된 정보가 있을 수 있습니다.
완성된 사용자 경험을 갖추고 있지 않을 수 있으며 빠른 조치나 API 요청으로만 액세스할 수 있을 수 있습니다.

베타

베타 기능:

프로덕션에서 사용할 준비가 되지 않을 수 있습니다.
상업적으로 합리적인 노력에 따라 지원됩니다. 그러나 문제 해결에 대해 추가 시간과 개발부서의 지원이 필요합니다.
불안정할 수 있습니다.
변경될 가능성이 거의 없는 구성 및 의존성을 갖습니다.
변경될 가능성이 거의 없는 기능 및 기능을 갖습니다. 그러나 주요 릴리스 외부에서나 일반적으로 사용 가능한 기능보다 덜 알려진 변경이 발생할 수 있습니다.
데이터 손실 위험이 낮을 수 있습니다.
완료되거나 완료에 가까운 사용자 경험을 갖습니다.

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

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

어떤 규모에서도 프로덕션에서 사용할 준비가 되어 있습니다.
완전히 지원되며 문서화되어 있습니다.
GitLab 디자인 표준에 부합하는 완전한 사용자 경험을 갖습니다.

모든 기능은 프로덕션 환경에서 실행됩니다

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

GitLab 실험 및 베타 개발 가이드라인

강력한 이유가 없는 한 팀은 기능을 실험 또는 베타 버전으로 릴리스하려는 경우를 제외하고 처음부터 GA로 릴리스해야 합니다.

제품 개발 팀은 다음과 같은 경우 GitLab 사용자나 플랫폼에 중대한 위험이나 마찰을 초래할 것으로 합당하게 믿는 변경을 하지 말아야 합니다.

사용자가 액세스하는 기존 프로덕션 데이터의 손상이나 무단 유출의 위험.
응용 프로그램의 다른 부분을 불안정하게 만들어서는 안 됨.
고활성 사용자(MAU) 영역으로 마찰을 도입하지 말아야 함.

실험 기능

실험의 세부 정보에 추가로, 실험은 다음을 해야 합니다:

최소한의 마찰로 참여할 수 있는 방법을 제공해야 합니다. 예: 피처 플래그를 뒤집는 것은 너무 많은 마찰이지만 UI에서 그룹 또는 프로젝트 수준 설정이 아닐 경우는 괜찮습니다.
GitLab 테스팅 계약에 대한 옵트인으로 연결해야 합니다.
해당 기능이 GitLab 테스팅 계약의 영향을 받는 것으로 반영하는 문서가 있어야 합니다.
실험 상태를 반영하는 UI가 있어야 합니다.
내부 및 외부 사용자와 연계할 피드백 이슈가 있어야 합니다.
릴리스 포스트에서 발표되어서는 안 됩니다.
검색 순간에서 사용자 인터페이스에서 홍보되어야 하며 필요한 경우에 한합니다.

모든 실험 기능은 검토 기준을 충족하는 경우 프로덕션 준비 리뷰 시작해야 하며 준비 템플릿의 실험 섹션을 완료해야 합니다.

베타 기능

베타 세부 정보에 추가로, 베타 기능은 다음을 해야 합니다:

대부분의 기능에 필수적인 것이 아니어야 합니다.
베타 상태를 반영하는 문서가 있어야 합니다.
베타 상태를 반영하는 UI가 있어야 합니다.
기본적으로 켜진 피처 플래그 뒤에 있어야 합니다.
기본적으로 꺼진 토글 뒤에 있어야 합니다.
원하는 경우 릴리스 포스트에서 베타 상태를 반영해야 합니다.
검색 순간에서 사용자 인터페이스에서 홍보되어야 하며 필요한 경우에 한합니다.

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

GA 기능

검토 기준을 충족하는 모든 일반적으로 사용 가능한 기능은 프로덕션 준비 리뷰를 시작하고 준비 템플릿의 GA 섹션까지 완료해야 합니다.

이전 액세스 제공

저희의 미션은 “모두가 기여할 수 있는 것”이고, 이것은 회사 외부 사용자도 기능을 시도할 수 있는 경우에만 가능합니다. 다양한 조직의 사용자들이 무언가를 시도하면 높은 품질(다양성)의 피드백을 받을 수 있으므로 충분한 가치가 있는 경우에 사용자들이 실험적인 기능을 선택할 수 있도록 합니다.

가능한 경우, 기능이 베타 상태가 되기를 기다리거나 내부 테스트만 하는 대신 실험 기능을 외부에 공개로 릴리스합니다. 우리는 기능을 불필요하게 긴 시간 동안 내부에서만 유지하는 것이 우리를 불필요하게 늦출 수 있다는 것을 배웠습니다.

실험적인 기능은 사람/조직이 실험에 참여할 때에만 표시되므로 여기에서 실제로 실험을 할 수 있고 실수를 할 수 있습니다.

실험 및 베타 종료 기준

GA(General Availability)(GA) 상태가 되기 전의 각 단계가 가능한 짧도록 하기 위해 실험, 베타, 제한된 이용 가능 상태의 각 단계에는 종료 기준이 포함되어야 합니다. 이는 신속한 반복을 촉진하고 사이클 시간을 줄입니다.

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

시간: 기능이 GA(General Availability) 상태가 될 시점의 종료일을 정의합니다.
- 예를 들어, 실험 릴리스 시작 후 6개월간 X개의 고객 유지, 베타 시작 후 3개월간 무료 사용자 및 유료 사용자의 X% 성장 등을 정의할 시간에 제한된 목표 지표를 설정해보세요.
- 출시 시기, 사용자 경험, 경험의 풍부함을 균형 있게 고려해야 합니다. 일부 베타 프로그램은 한 마일스톤 동안 지속되었지만 다른 것들은 몇 년 동안 지속되었습니다.
피드백: 온보딩된 고객의 최소한의 수를 정의합니다.
- 피드백을 종료 기준으로 사용할 경우 시간 제한을 고려해봅니다. 충분한 사용자로부터의 피드백을 얻지 못하는 경우, GA(General Availability) 상태보다는 해당 시점에서 출시하고 반복하는 것이 나을 수 있습니다.
제한된 기능 완료: GA(General Availability) 상태로 이동하기 전에 완료되어야 할 기능이 있는지 판단합니다.
- “딱 한 가지 더”를 포함해야 하는지 주의해야 합니다. 반복은 더 많은 사용자로부터 더 많은 피드백을 통해 더 쉽고 효과적입니다. 따라서 GA(General Availability) 상태로 이동하는 것이 선호됩니다.
시스템 성능 지표: GA(General Availability) 상태가 되기 전에 플랫폼이 표시해야 하는 기준을 결정합니다. 응답 시간 및 초당 특정 요청의 성공적인 처리 등의 예시가 있습니다.
성공 기준: 모든 기능이 GA(General Availability) 상태에 도달하지는 않을 수 있습니다. 초기 피드백이 해당 제품에 더 많은 가치나 더 나은 사용자 경험을 제공할 수 있는 다른 방향이 있다는 것이 완전히 괜찮습니다. 제품에 추가할 가치가 있는지 또는 사용자 경험이 더 나은지 판단해야 하는 질문이 다수 있으면 기록하고 답변합니다.

AI 기능의 종료 기준에 대해서는 위에 언급된 것에 더해서 UX 성숙 요구사항을 참조해보세요.