极狐 GitLab Logo

在不同开发阶段的功能支持

极狐GitLab 有时会在不同的开发阶段发布功能，如实验性或测试版。用户可以选择加入并测试新的体验。发布此类功能的一些原因包括：

  • 验证当前形式的功能在每种设计用例中的规模、支持和维护负担的边界情况。
  • 功能不够完整，无法被视为 MVC，但作为开发过程的一部分添加到代码库中。

如果某些功能是在这些建议实施之前开发的，或者团队确定需要另一种实现方法，则可能不符合这些建议。

所有其他功能都被视为公开可用。

实验#

实验功能：

  • 尚未准备好用于生产环境。
  • 不提供支持。
  • 可能不稳定。
  • 可能随时被移除。
  • 可能存在数据丢失的风险。
  • 可能没有文档，或信息仅限于极狐GitLab 议题或博客。
  • 可能没有最终的用户体验，可能只能通过快速操作或 API 请求访问。

测试版#

测试版功能：

  • 可能尚未准备好用于生产环境。
  • 可能不稳定。
  • 配置和依赖项不太可能改变。
  • 功能和功能不太可能改变。但是，可能会在主要版本之外或一般可用功能的通知时间较短时发生重大更改。
  • 数据丢失的风险较低。
  • 用户体验已完成或接近完成。
  • 可以等同于合作伙伴的“公共预览”状态。

公开可用性#

有两种类型的公开发布：

  • 限定可用性
  • 一般可用

这两种类型都已准备好用于生产，但范围不同。

限定可用性#

限定可用性功能：

  • 已准备好在减少的规模上用于生产。
  • 可以最初在一个或多个极狐GitLab 平台（JihuLab.com、极狐GitLab 私有化部署、极狐GitLab 专用）上可用。
  • 可能最初是基础版，然后在一般可用时变为付费。
  • 可能在成为一般可用之前提供折扣。
  • 可能在一般可用时商业条款会更改新合同。
  • 用户体验完整，与极狐GitLab 设计标准一致。

一般可用#

一般可用功能：

  • 在任何规模上都已准备好用于生产。
  • 用户体验完整，与极狐GitLab 设计标准一致。
  • 必须在所有极狐GitLab 平台上可用（JihuLab.com、极狐GitLab 私有化部署、极狐GitLab 专用）。

开发指南#

团队应从一开始就将功能发布为一般可用，除非有强烈的理由首先将其发布为实验性、测试版或限定可用性。

产品开发团队应避免进行可能会为极狐GitLab 用户或平台带来重大风险或摩擦的更改，例如：

  • 冒着损坏或泄露用户访问的现有生产数据的风险。
  • 使应用程序的其他部分不稳定。
  • 在高月活跃用户（MAU）区域引入摩擦。

测试版功能#

除了用户的测试版详细信息之外，测试版功能还应：

  • 不需要或对大多数功能不是必须的。
  • 具有反映测试版状态的文档。
  • 具有反映测试版状态的 UI。
  • 通过反馈议题与内部和外部用户互动。
  • 在默认开启的功能标志后面。
  • 在默认关闭的切换后面。
  • 如果需要，可以在发布帖子中反映测试版状态。
  • 如有必要，通过发现时刻在用户界面中推广。

公开可用的功能#

公开可用的功能必须：

  1. 符合审核标准。
  2. 完成生产准备审查。
  3. 完成所有部分，包括准备模板中的一般可用性部分。

提供更早的访问#

我们的使命是“每个人都可以贡献”，这只有在公司外部的人可以尝试功能时才有可能。如果来自不同组织的人尝试某个功能，我们会获得更高质量（更多样化）的反馈，因此在有足够价值时，让用户能够选择加入实验功能。

在可能的情况下，将实验功能外部发布，而不是仅在内部测试或等待功能达到测试版状态。我们了解到，长时间将功能仅限于内部使用会不必要地减慢我们的速度。

实验功能仅在人们或组织选择加入实验时显示，因此我们可以在这里犯错误并进行真正的实验。

实验和测试版退出标准#

为了确保在一般可用性之前的阶段尽可能短，每个实验、测试版和限定可用性阶段都应包括退出标准。这鼓励快速迭代并减少周期时间。

极狐GitLab 产品经理在决定对其实验和测试版功能应用哪些退出标准时必须考虑以下因素：

  • 时间：定义一个结束日期，届时该功能将一般可用。
    • 考虑设定一个时间限制的目标指标，该指标将定义退出一般可用性的准备情况。例如，在实验启动后的 6 个月内，客户保持 MoM 的数量，测试版启动后的三个月内基础版和付费用户的 X% 增长，或类似情况。
    • 注意平衡上市时间、用户体验和体验的丰富性。一些测试计划持续一个里程碑，而其他计划则持续了几年。
  • 反馈：定义已入职和采访的最低客户数量。
    • 在将用户反馈用作离开阶段的退出标准时，也可以考虑设定时间限制。如果经过一段时间后，我们无法从足够多的用户那里获得反馈，那么最好在那时发布我们已有的内容并作为一般可用性进行迭代，而不是维持预一般可用状态。
  • 有限功能完成：确定在转向一般可用性之前应完成的功能。
    • 注意不要包含“仅此一个”功能。通过更多用户的更多反馈，迭代更容易、更有效，因此，获得一般可用性是首选。
  • 系统性能指标：确定平台在准备好一般可用性之前显示的标准。示例包括响应时间和成功处理每秒特定数量的请求。
  • 成功标准：并不是所有功能都会一般可用。如果早期反馈表明不同的方向会提供更多的价值或更好的用户体验，则可以转向。如果有待解答的开放性问题需要回答以确定该功能是否值得放入产品中，请列出并回答这些问题。