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

GitLab은 때때로 기능을 실험 또는 베타로 출시하며, 사용자는 이를 선택하여 새로운 경험을 시험해 볼 수 있습니다. 이러한 종류의 기능 출시 이유에는 다음과 같은 것들이 있습니다:

모든 디자인된 사용 사례에 대한 현재 형태의 기능의 규모, 지원 및 유지보수 부담의 엣지 케이스를 확인.
최소한의 변경 가능한(MVC)로 간주할 만큼 기능이 완전하지 못한 경우에도 개발 과정의 일부로서 코드베이스에 추가.

이 권고에 부합하지 않는 기능이 있을 수 있는데, 그러한 경우는 권고사항이 존재하지 않았을 때 해당 기능이 개발되었거나, 특정 팀이 대안적인 구현 접근 방식이 필요하다고 결정했을 때입니다.

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

실험

실험적인 기능:

프로덕션에서 사용할 준비가 되지 않음.
지원이 제공되지 않음. 해당 기능과 관련된 문제는 GitLab 이슈 트래커에 오픈해야 합니다.
불안정할 수 있음.
언제든지 제거될 수 있음.
데이터 손실의 위험이 있을 수 있음.
문서가 없을 수 있으며, GitLab 이슈나 블로그만 한정된 정보를 가질 수 있음.
최종 사용자 경험이 확정되지 않을 수 있으며, 빠른 조치나 API 요청을 통해서만 접근 가능할 수 있음.

베타

베타 기능:

프로덕션에서 사용할 준비가 되지 않을 수 있음.
상업적으로 합리적인 노력에 따라 지원이 제공됨이나, 문제 해결에는 개발팀의 추가 시간과 지원이 필요함을 예상.
불안정할 수 있음.
변경될 가능성이 적은 구성 및 종속성을 가짐.
변경될 가능성이 없는 기능과 기능을 가지고 있음. 그러나 주요 릴리스 외부에서 또는 기존 기능과는 다른 유지보수 통지로 인해 중단 사항이 발생할 수 있음.
데이터 손실의 낮은 위험이 있음.
완전한 사용자 경험 또는 완료에 가까운 사용자 경험을 가지고 있음.

일반 사용 가능한 (GA)

일반 사용 가능한 기능:

어떠한 규모에서도 프로덕션에서 사용할 준비가 됨.
완전한 지원과 문서화가 되어 있음.
GitLab 디자인 표준과 일치한 완전한 사용자 경험을 가지고 있음.

모든 기능은 프로덕션 환경에 사용 중임

모든 실험, 베타 및 일반 사용 가능한 기능은 GitLab.com에서 사용 가능하며, 따라서 모두 “프로덕션 환경”에 사용 중인 것으로 간주됩니다.

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

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

제품 개발 팀은 다음과 같은 GitLab 사용자 또는 플랫폼에 중대한 위험 또는 문제를 일으킬 수 있다고 합당하게 믿는 변경을 피해야 합니다:

우리 사용자가 액세스하는 기존 프로덕션 데이터의 손상 또는 유출의 위험.
애플리케이션의 기타 부분을 불안정하게 만드는 위험.
높은 월간 활성 사용자(MAU) 영역으로 마찬가지로 마찬가지 불편을 일으키는 위험.

실험 기능

사용자를 위한 실험의 자세한 내용에 추가하여, 실험 기능은 다음을 해야합니다:

최소한의 불편으로 선택적으로 참여할 수 있는 방법을 제공해야 함. 예를 들어, 기능 플래그를 전환하는 것은 불편함을 초래하기 때문에 UI의 그룹 또는 프로젝트 수준 설정은 불편하지 않음.
GitLab 테스트 계약서에 참조를 제공해야 함.
해당 실험적인 기능이 GitLab 테스트 계약서의 대상임을 반영하는 문서를 가지고 있어야 함.
UI에서 실험 상태를 반영해야 함.
내부 및 외부 사용자와 관련된 피드백 이슈와의 상호 작용을 할 수 있도록 피드백 이슈를 가져야 함.
릴리스 포스트에서 발표되어서는 안 되며,
필요한 경우 UI에서 발견시 기회를 통하여 프로모션되어야 함.

검토 기준을 충족하는 모든 실험 기능은 프로덕션 준비 리뷰를 시작하고 준비 템플릿의 실험 섹션을 완료해야 함.

베타 기능

사용자를 위한 베타 세부 정보에 추가하여, 베타 기능은 다음을 해야합니다:

대부분의 기능에 대해 필요하지 않거나 필수적이지 않아야 함.
베타 상태를 반영하는 문서를 가져야 함.
UI에서 베타 상태를 반영해야 함.
기본적으로 켜져 있는 기능 플래그 뒤에 있어야 함.
기본적으로 꺼져 있는 토글 뒤에 있어야 함.
원하는 경우 베타 상태를 반영하는 릴리스 포스트에 발표되어야 함.
필요한 경우 UI에서 발견시 기회를 통하여 프로모션되어야 함.

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

GA 기능

검토 기준을 충족하는 일반적으로 사용 가능한 기능은 운영 준비 검토를 완료해야 하며, 준비 상태 템플릿의 GA 섹션까지 모두 완료해야 합니다.

더 빠른 액세스 제공

우리의 미션은 “모든 사람이 기여할 수 있는 것”입이며, 이것은 회사 외부 사람들이 기능을 시도할 수 있는 경우에만 가능합니다. 다양한 조직의 사람들이 무언가를 시도하면(더 다양한) 피드백의 품질이 향상되므로, 충분한 가치가 있는 경우 사용자들이 실험 기능을 선택할 수 있도록 합니다.

가능한 경우 실험 기능을 내부 테스트만 하는 대신 외부에서 릴리스하거나 Beta 상태가 될 때까지 기다리는 것이 좋습니다. 기능을 장기간 내부 사용으로 유지하는 것은 불필요하게 우리를 늦추게 만든다는 점을 배웠습니다.

실험 기능은 사람들/조직이 실험에 참여할 때만 표시되므로, 여기서 실제로 실험할 수 있고 실제로 실험할 수 있는 것입니다.

실험 및 Beta 종료 기준

일반적으로 사용 가능 상태 이전 단계가 최대한 짧도록 보장하기 위해 실험, Beta, 그리고 제한된 사용이 포함되는 각 단계에는 종료 기준이 포함되어야 합니다. 이렇게 하면 빠른 반복을 촉진하고 사이클 시간을 줄일 수 있습니다.

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

시간: 기능이 일반적으로 사용 가능 상태가 될 시점의 종료일을 정의합니다.
- 예를 들어, 실험 시작 후 6개월 동안 X명의 고객 유지, Beta 시작 후 3개월 동안 무료 및 유료 사용자의 X% 성장 등을 정의하는 시간 제한 대상 지표를 설정해야 합니다.
- 시장 진입시간, 사용자 경험 및 사용자 경험의 풍부함을 균형 있게 고려해야 합니다. 어떤 Beta 프로그램은 한 마일스톤만 지속되었지만, 다른 것들은 몇 년 동안 지속되었습니다.
피드백: 사용자를 온보딩하고 인터뷰한 최소한의 고객 수를 정의합니다.
- 또한 사용자 피드백을 종료 기준으로 삼을 때 시간 제한을 설정하는 것도 고려해야 합니다. 충분한 사용자로부터 피드백을 수집하지 못하는 경우, 상태를 일반 사용 가능 지점에 도달하는 대신 해당 시점에서 우리가 가진 것을 출시하고 더 나은 상태로 반복하는 것이 더 낫습니다.
제한된 기능 완료: 일반 사용 가능 상태로 이동하기 전에 완료해야 할 기능을 결정합니다.
- “더 이상 한 가지만 더”를 포함시키는 데 주의해야 합니다. 더 많은 사용자로부터 더 많은 피드백을 받으면 반복이 더 쉽고 효과적이므로 일반 사용 가능 상태에 도달하는 것이 좋습니다.
시스템 성능 지표: 일반 사용 가능 상태에 준비가 된 플랫폼이 보여야 하는 기준을 결정합니다. 응답 시간 및 초당 처리해야 하는 요청 수를 성공적으로 처리하는 등의 예제가 있습니다.
성공 기준: 모든 기능이 GA에 도달하지 않을 수 있습니다. 초기 피드백이 기능의 가치를 더 많이 제공하거나 더 나은 사용자 경험을 제공할 수 있다는 것을 나타내는 경우 전환하는 것이 괜찮습니다. 제품에 추가할 가치가 있는지 결정하기 위해 답변해야 할 분명한 질문이 있으면 해당 목록을 작성하고 답변해야 합니다.

AI 기능의 종료 기준에 대한 추가 정보는 UX 성숙도 요구 사항을 참조하십시오.