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

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

각 설계된 사용 사례에 대한 현재 형태의 기능을 규모, 지원 및 유지 관리 부하의 가장자리 경우를 확인하기 위함.
MVC로 고려될만큼 완전하지 않지만 개발 프로세스의 일환으로 코드베이스에 추가됨.

이 권고사항에 맞지 않는 기능은 권고사항이 마련되기 이전에 개발되었거나, 팀이 대체 구현 방법이 필요하다고 판단한 경우일 수 있습니다.

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

실험

실험적인 기능:

프로덕션 환경에서 사용할 준비가 되어있지 않음.
지원사항은 없음. 해당 기능에 관한 문제는 GitLab 이슈 트래커에 열어야 함.
불안정할 수 있음.
언제든지 제거될 수 있음.
데이터 손실의 위험이 있을 수 있음.
문서가 없거나 GitLab 이슈 또는 블로그에서 제한된 정보만을 포함할 수 있음.
최종 사용자 경험이 확정되지 않았을 수 있으며, 빠른 조치 또는 API 요청을 통해서만 액세스 가능할 수 있음.

베타

베타 기능:

프로덕션 환경에서 사용할 준비가 되어있지 않을 수 있음.
상업적으로 합리적인 노력으로 지원됨이지만 문제 해결에는 개발자의 추가 시간과 지원이 필요할 수 있음.
불안정할 수 있음.
변경될 가능성이 거의 없는 구성 및 의존성을 가짐.
변경될 가능성이 거의 없는 기능 및 기능을 가짐. 그러나 주요 릴리스 이외의 시기나 일반적으로 사용 가능한 기능보다 적은 안내로 중단 가능함.
데이터 손실의 위험이 낮을 수 있음.
완료되었거나 완료에 가까운 사용자 경험을 가짐.

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

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

어떤 규모에서도 프로덕션 환경에서 사용할 준비가 됨.
완전히 지원되며 문서화됨.
GitLab 디자인 표준에 일치하는 완전한 사용자 경험을 제공함.

모든 기능은 운영 중

모든 실험, 베타 및 일반적으로 사용 가능한 기능은 GitLab.com에서 사용 가능하므로 모두 “운영 중”으로 간주됨.

GitLab 실험 및 베타 개발 지침

강력한 이유가 없는 한 제품 개발 팀은 기능을 최초부터 GA로 릴리스해야 합니다.

제품 개발 팀은 GitLab 사용자 또는 플랫폼에 중대한 위험 또는 마찰을 초래할 것으로 합리적으로 믿는 변경을 삼가야함, 예를 들어:

우리 사용자가 접근하는 기존 프로덕션 데이터의 손상 또는 유출을 위험에 빠뜨리는 것.
애플리케이션의 다른 부분을 불안정하게 만드는 것.
월간 활성 사용자(MAU) 영역에 마찰을 도입하는 것.

실험 기능

사용자를 위한 실험 상세정보 외에도 실험은 다음을 해야합니다:

압력이 적게 필요한 방식으로 선택적으로 참여하게 해야 함. 예를 들어, 피처 플래그를 전환하는 것은 너무 많은 압력이지만 UI의 그룹 또는 프로젝트 수준 설정은 그렇지 않음.
GitLab 테스팅 합의에 연결되는 선택 사항을 사용해야 함.
기능이 GitLab 테스팅 합의에 따를 것을 반영하는 문서가 있어야 함.
실험 상태를 반영하는 UI를 가져야 함.
내부 및 외부 사용자와 관련된 피드백 이슈를 가지고 있어야 함.
릴리스 글에서 발표해서는 안됨.
발견 순간을 통해 사용자 인터페이스에서 홍보되어야 할 경우.

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

베타 기능

사용자를 위한 베타 상세정보 외에도 베타는 다음을 해야합니다:

대부분의 기능에 필요하지 않거나 필수가 아니어야 함.
베타 상태를 반영하는 문서가 있어야 함.
베타 상태를 반영하는 UI를 가져야 함.
기본적으로 켜져 있는 피처 플래그 뒤에 있어야 함.
기본적으로 꺼진 토글 뒤에 있어야 함.
원하는 경우 베타 상태를 반영하는 릴리스 글에 발표되어야 함.
발견 순간을 통해 사용자 인터페이스에서 홍보되어야 할 경우.

모든 베타 기능은 검토 기준을 충족하는 경우 준비 템플릿의 베타 섹션을 포함한 모든 섹션을 완료하려면 프로덕션 준비 검토 프로세스를 따라야 함.

GA 기능

검토 기준을 충족하는 경우는 프로덕션 준비 검토를 완료하고 준비 템플릿의 GA 섹션을 모두 완료해야 함.

초기 액세스 제공

저희의 미션은 “모두가 기여할 수 있는 것”이며, 회사 외부의 사람들도 기능을 시도할 수 있다면 그것만큼 더 많은 다양성의 피드백을 받을 수 있습니다. 그래서 여분의 가치가 있는 경우에는 사용자들에게 실험적인 기능에 참여할 수 있는 기회를 제공해야합니다.

가능하다면 외부에서 실험적인 기능을 테스트하는 것이 아니라 내부에서만 테스트하거나 기능이 베타 상태가 될 때까지 기다리는 것보다 외부에서 실험적인 기능을 출시해야합니다. 기능을 오랜 기간 동안 내부에서만 유지하는 것은 불필요하게 저히를 늦추는 것을 알게 되었습니다.

실험적인 기능은 실험에만 참여하는 사람들이 보기 때문에 실수를 할 수 있습니다.

실험 및 베타 종료 기준

일반적으로 사용 가능한 상태가 되기 전의 단계가 가능한 짧기 위해 Experiment, Beta 및 제한적 사용 가능한 각 단계는 종료 기준을 포함해야 합니다. 이러한 방식은 신속한 반복을 촉진하고 사이클 타임을 줄입니다.

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

시간: 기능이 일반적으로 사용 가능한 상태가 되는 종료 날짜를 정의함.
- 예를 들어, 실험 시작 후 6개월간 고객 유지, 베타 시작 후 3개월간 무료 및 유료 사용자의 X% 성장 등의 시간당 목표 지표를 설정하는 것이 기능의 준비를 정의함
- 시장에 대한 시간, 사용자 경험 및 경험의 풍부함을 균형 잡는 데 주의해야 함.
- 일부 베타 프로그램은 1개 마일스톤에 그치거나 몇 년간 지속된 적이있음.
피드백: 피드백을 받은 최소 고객수를 정의함.
- 사용자 피드백을 종료 기준으로 사용할 때는 사용자 피드백을 수집할 수 있는 시간 기준을 고려해야함.
- 정해진 기간 동안 충분한 사용자로부터 피드백을 받을 수 없다면, 일반적인 사용 가능한 상태로 출시하는 것이 더 좋음.
제한된 기능 완료: 일반적으로 사용 가능한 상태가 되기 전에 완료되어야 하는 기능을 결정함.
- “한 가지만 더” 포함에 주의해야합니다. 더 많은 사용자의 피드백으로 반복이 더 쉽고 효과적이기 때문에 일반적으로 사용 가능한 상태에 도달하는 것이 선호됨.
시스템 성능 메트릭: 플랫폼이 일반적으로 사용 가능한 상태에 걸맞음을 보여줄기준을 결정함.
- 응답 시간 및 초당 처리 요청 수 등의 성공 기준 예시가 있습니다.
성공 기준: 모든 기능이 일반적으로 사용 가능한 상태에 도달할 필요는 없을 수 있습니다. 초기 피드백이 다른 방향으로 전환하면 그것이 제품에 더 많은 가치나 더 나은 사용자 경험을 제공할 것으로 나타나면, 피벗하는 것은 괜찮습니다. 제품에 포함해야 할 가치나 더 나은 사용자 경험을 제공할 수 있는지 결정하기 위해 리스트업하고 답해야합니다.

AI 기능에 대한 종료 기준의 경우, UX 성숙도 요구 사항을 참조하세요.