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

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

현재 설계된 사용 사례마다 기능의 규모, 지원 및 유지 보수 부담의 테두리 사례를 확인합니다.
MVC로 간주할 만큼 충분히 완성되지 않은 기능이지만 개발 프로세스의 일부로 코드베이스에 추가됩니다.

일부 기능은 권장 사항과 일치하지 않을 수 있습니다. 이는 해당 권장 사항이 아직 적용되기 전에 개발되었거나 대체 구현 접근 방식이 필요하다고 팀에서 결정했을 수 있습니다.

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

실험

실험적인 기능은 다음과 같습니다:

프로덕션에 사용하기에 준비되지 않습니다.
지원 서비스를 받을 수 없습니다. 이에 대한 문제는 GitLab 이슈 트래커에서 열어야 합니다.
불안정할 수 있습니다.
언제든지 제거될 수 있습니다.
데이터 손실의 위험이 있을 수 있습니다.
문서가 없거나 GitLab 이슈 또는 블로그에서 제한된 정보만 있을 수 있습니다.
최종적인 사용자 경험이 확정되어 있지 않을 수 있고, 빠른 조치나 API 요청을 통해서만 액세스할 수 있을 수 있습니다.

베타

베타 기능은 다음과 같습니다:

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

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

일반적으로 사용 가능한(GA) 기능은 다음과 같습니다:

어느 규모에서도 프로덕션에 사용할 준비가 되어 있습니다.
전체로 지원되며 문서화되어 있습니다.
GitLab 디자인 표준에 맞춘 완전한 사용자 경험을 갖고 있습니다.

모든 기능은 프로덕션 환경에 있습니다

GitLab.com에서 모든 실험, 베타 및 일반적으로 사용 가능한 기능이 사용 가능하기 때문에 이들은 모두 “프로덕션 환경에 있음”으로 간주됩니다.

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

강력한 이유가 없는 한 팀은 기능을 실험적이거나 베타 버전으로 출시하기 전에 처음부터 GA로 출시해야 합니다.

제품 개발 팀은 다음과 같은 GitLab 사용자나 플랫폼에 중대한 리스크나 마찰을 초래할 것으로 합리적으로 믿는 변경을 삼가야 합니다:

사용자가 액세스하는 기존 프로덕션 데이터의 손상 또는 유출에 대한 위험.
응용 프로그램의 다른 부분을 불안정하게 만드는 것.
사용자 활성(MAU)이 높은 영역에 마찰을 도입하는 것.

실험 기능

사용자를 위한 실험 상세에 추가로, 실험에는 다음이 필요합니다:

최소한의 마찰로 참여할 수 있는 방법을 제공해야 합니다. 예를 들어, 기능 플래그를 전환해야 하는 것은 마찰이 너무 많습니다. 그러나 UI에서 그룹 또는 프로젝트 수준 설정이 필요합니다.
GitLab 테스팅 협의에 대한 참여를 나타내야 합니다.
기능이 GitLab 테스팅 협의의 대상인 것을 반영하는 문서를 가져야 합니다.
실험 상태를 반영하는 UI를 가져야 합니다.
내부 및 외부 사용자와 참여하기 위한 피드백 이슈를 가져야 합니다.
릴리스 게시에서 발표되어서는 안 되지만, 필요한 경우 발견 순간를 통해 사용자 인터페이스에서 홍보되어야 합니다.

모든 심사 기준을 충족하는 실험 기능은 프로덕션 준비 리뷰를 시작하고 준비도 템플릿의 실험 섹션을 완료해야 합니다.

베타 기능

사용자를 위한 베타 세부 정보에 추가로, 베타에는 다음이 필요합니다:

대부분의 기능에서 필요하지 않거나 필수적이지 않아야 합니다.
베타 상태를 반영하는 문서를 가져야 합니다.
베타 상태를 반영하는 UI를 가져야 합니다.
내부 및 외부 사용자와 참여하기 위한 피드백 이슈를 가져야 합니다.
기본적으로 켜진 기능 플래그 뒤에 있어야 합니다.
기본적으로 꺼진 토글 뒤에 있어야 합니다.
원하는 경우 베타 상태를 반영하는 릴리스 게시에 발표되어야 합니다.
필요한 경우 발견 순간를 통해 사용자 인터페이스에서 홍보되어야 합니다.

모든 심사 기준을 충족하는 베타 기능은 베타 섹션까지 완료하고 프로덕션 준비 리뷰 프로세스를 따라야 합니다.

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

심사 기준을 충족하는 일반적으로 사용 가능한(GA) 기능은 프로덕션 준비 리뷰를 시작하고 .gitlab/issue_templates/production_readiness.md#general-availability까지 모든 섹션을 완료해야 합니다.

이른 액세스 제공

우리의 미션은 “모두가 기여할 수 있는 것”이며, 이것은 회사 외부 사람들이 기능을 시도할 수 있는 경우에만 가능합니다. 다양한 조직의 사람들이 시도하면 더 높은 품질(다양성)의 피드백을 받을 수 있습니다. 따라서 충분한 가치가 있을 때 사용자들이 실험적인 기능을 선택할 수 있게 해주세요.

가능하다면, 실험적인 기능을 내부 테스트만 하는 것이 아니라 외부에서도 발표하고 기다리는 대신에 베타 상태까지 기능을 외부에 공개합니다. 우리는 기능을 내부에서만 오랫동안 유지하는 것이 불필요하게 우리의 속도를 늦춘다는 것을 배웠습니다.

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

실험과 베타 종료 기준

일반 가용성 이전 단계를 가능한 한 짧게 유지하기 위해 실험, 베타, 한정적 가용성 각 단계에는 종료 기준이 포함되어야 합니다. 이는 빠른 반복을 촉진하고 사이클 시간을 줄입니다.

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

시간: 기능이 일반적으로 사용 가능해질 시점에 대한 종료 날짜를 정의합니다.
- 예를 들어, 실험 출시 이후 6개월간 X명의 고객 유지, 베타 출시 이후 3개월간 무료 및 유료 사용자의 X% 성장 등 기간 제한된 목표 지표를 설정하는 것을 고려해 보세요.
- 시장 진입 시간, 사용자 경험, 경험의 풍부성을 균형 있게 고려하세요. 베타 프로그램은 한 마일스톤 동안 진행된 경우도 있고 몇 년 동안 지속된 경우도 있습니다.
피드백: 온보드된 고객의 최소 수를 정의합니다.
- 피드백을 종료 기준으로 사용할 때 기간을 고려하는 것도 좋습니다. 충분한 사용자로부터 피드백을 얻지 못하는 경우, 일반적 가용 상태보다는 해당 시점에서 우리가 가진 것을 출시하고 그에 대해 반복하는 것이 더 나은 선택입니다.
한정된 기능 완성: 일반적 사용 가능 상태로 이동하기 전에 완료해야 할 기능을 결정합니다.
- “하나 더” 기능을 포함하는 것에 주의하세요. 더 많은 사용자로부터의 피드백으로 반복이 더 쉽고 효과적하기 때문에, 일반적 가용성을 달성하는 것이 더 좋습니다.
시스템 성능 지표: 일반적으로 사용 가능해지기 전에 플랫폼이 보여야 하는 기준을 결정합니다. 응답 시간 및 초당 특정 수의 요청을 성공적으로 처리하는 등의 예시가 있습니다.
성공 기준: 모든 기능이 GA에 도달하는 것은 아닙니다. 초기 피드백이 해당 제품에 더 많은 가치나 더 나은 사용자 경험을 제공할 것으로 나타나면 피벗하는 것은 괜찮습니다. 제품에 넣을 가치가 더 많은지 또는 더 나은 사용자 경험을 제공할 것으로 나타나기 위해 답해야 할 열린 질문이 있다면, 그것을 목록화하고 답하세요.

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