29、实验、A|B 测试与 GitHub 企业版使用指南

实验、A|B 测试与 GitHub 企业版使用指南

在软件开发和业务运营中，实验、A|B 测试以及有效的代码管理和协作至关重要。下面将详细介绍 Flagger 进行实验和 A|B 测试的方法、OKR 与实验的结合，以及 GitHub 企业版的相关信息。

1. Flagger 与实验、A|B 测试

Flagger（https://flagger.app/）是一种用于 Kubernetes 的交付操作符，可与服务网格 Istio 配合使用。它常用于向 Kubernetes 集群进行金丝雀发布，也能根据 HTTP 匹配条件路由流量。

例如，为所有带有内部人员 cookie 的用户创建一个为期 20 分钟的实验：

analysis:
  # 调度间隔（默认 60 秒）
  interval: 1m
  # 总迭代次数
  iterations: 20
  # 回滚前失败指标检查的最大次数
  threshold: 2
  # 金丝雀匹配条件
  match:
    - headers:
        cookie:
          regex: “^(.*?;)?(type=insider)(;.*)?$”

Flagger 可以与来自 Prometheus、Datadog、Dynatrace 等的指标结合使用。更多信息可参考 Flagger 文档（https://docs.flagger.app/），还有 Stefan Prodan 的教程：GitOps recipe for Progressive Delivery with Flux v2, Flagger and Istio（https://github.com/stefanprodan/gitops-istio）。

不过，Flagger 和 Istio 的解决方案虽然带来了很大的灵活性，但也相当复杂，不适合初学者。如果已经在使用 Kubernetes 和 Istio 并进行金丝雀发布，那么 Flagger 可能是一个强大的框架。

市面上有许多可帮助进行实验和 A|B 测试的解决方案，从专注于 CMS 和活动的工具到 Kubernetes 操作符，有各种各样的方法。最佳解决方案取决于很多因素，主要是现有的工具链、定价和支持。重要的是关注过程和数据分析，提供应用的两个版本不应是挑战，理解数据可能才是。

2. OKR 与实验

OKR（目标与关键结果）是一种透明地定义和跟踪目标及其结果的框架。它有助于组织在战略目标上实现高度一致，同时为各个团队保持最大程度的自主性。

工程团队资源宝贵，众多利益相关者不断向他们提出需求，如测试人员提交错误、客户请求新功能、管理层希望赶上竞争对手并向重要客户做出承诺。团队如何有自由进行实验，以及从哪些实验开始最好呢？

OKR 可以让团队在与高层目标保持高度一致的同时，自主决定构建什么以及如何构建。假设公司希望以 75% 的市场份额成为市场领导者，这需要新注册用户持续增长。团队的关键结果是每月 20% 的增长率，这将设定团队的优先级。团队可能首先调查有多少人最初来到注册页面，以及来自哪些推荐渠道。有多少人点击“立即注册”按钮？有多少人完成对话框？他们在什么阶段不再回来？此时，他们会自动形成假设并进行实验来验证。

OKR 也有利于跨团队协作，因为团队的 OKR 可能具有很高的协同效应，都与高层目标一致。例如，团队可能想与营销部门交流，因为他们可能有类似的 OKR，并且可能有自己的实验想法来提高通往注册页面的着陆页的参与率。

3. 实验所需的成熟度

实验、A|B 测试和基于假设的开发是具有挑战性的主题，需要在多个方面达到较高的成熟度：
- 管理 ：团队需要自主决定构建什么以及如何构建。
- 文化 ：需要一种信任文化，让人们不害怕失败。
- 跨团队协作 ：团队必须能够跨学科工作，因为实验通常需要不同部门的协作。
- 技术能力 ：必须能够在很短的时间内将更改发布到生产环境，并针对特定的客户群体。
- 洞察力 ：必须具备强大的分析能力，并能结合来自不同来源的数据和指标。

4. GitHub 企业版相关信息

4.1 托管选项和定价

GitHub 有多种不同的许可证和托管选项，了解这些对于企业做出正确选择很重要。
| 托管选项 | 描述 | 特点 |
| ---- | ---- | ---- |
| GitHub Enterprise Cloud（GHEC） | 由 GitHub 提供的 SaaS 服务，完全托管在美国的云基础设施中 | 可应用额外安全措施，支持用户单点登录，可托管私有和公共存储库，保证 99.9% 的月正常运行时间，即每月最长停机时间为 45 分钟 |
| GitHub Enterprise Server（GHES） | 可在任何地方托管的系统，如自己的数据中心或 Azure、AWS 等云环境 | 可使用 GitHub Connect 连接到 GitHub.com，共享许可证并利用开源资源。基于与 GHEC 相同的源代码，但有些云环境提供的功能需要自己处理，如 GitHub Actions 中的运行器 |
| GitHub Enterprise AE（GHAE） | 目前处于针对超过 500 个席位客户的私有测试阶段，在选定的 Microsoft Azure 区域提供完全隔离的托管服务 | 提供完整的数据驻留和合规性，但目前不清楚何时公开可用、定价和最低席位数量 |

GitHub 的定价基于三个不同的层级：Free、Team 和 Enterprise，按用户每月计费。
| 层级 | 适用范围 | 特点 |
| ---- | ---- | ---- |
| Free | 仅适用于 GitHub.com | 公共存储库免费，包含许多免费功能，如 Actions、Packages 和许多安全功能。私有存储库免费但功能有限，有 2000 个 Action 分钟和 500 MB 存储 |
| Team | 仅适用于 GitHub.com | 包含受保护的分支、代码所有者和其他高级拉取请求功能，可访问 Codespaces（需单独付费），有 3000 个 Action 分钟和 2 GB 包存储 |
| Enterprise | 适用于 GHEC、GHES、GHAE | 包含所有企业功能，如单点登录、用户管理、审计和策略，有 50000 个 Action 分钟和 50 GB 包存储，可购买额外的附加组件，如高级安全或高级支持 |

此外，还有一些按使用量付费的项目，如 Actions、Packages、Codespaces、Marketplace 按使用付费的应用程序。可以在组织或企业级别配置支出限制。

4.2 GitHub Connect

GitHub Connect 可将服务器连接到 GitHub，激活以下功能：
- 许可证同步 ：管理企业内多个服务器或组织的许可证使用情况，确保一个用户无论在哪里登录都只消耗一个许可证。
- 统一搜索 ：可在服务器上搜索并获取 GitHub.com 上公共存储库的结果，也可搜索属于企业的私有存储库（需用户有访问权限）。
- GitHub.com 操作 ：启用此选项可在工作流中加载公共操作，否则必须将所有操作分叉到服务器并引用。
- 统一贡献 ：启用后，用户在服务器上的贡献将显示在其公共资料中，仅发送贡献数量（如提交、问题、讨论或拉取请求），不暴露敏感数据。

4.3 创建 GitHub 账户

如果还没有 GitHub 账户，可以按以下步骤创建：
1. 访问 https://github.com 并点击“Sign up”。
2. 输入电子邮件地址，点击“Continue”或按回车键。
3. 输入强密码，点击“Continue”。
4. 输入唯一的用户名，GitHub 会提示该名称是否可用，可用则点击“Continue”。
5. 选择是否接收电子邮件通信，输入“y”（是）或“n”（否），然后点击“Continue”或按回车键。
6. 通过点击图像的指定部分解决验证码问题（验证码可能以浏览器首选语言显示）。
7. 检查电子邮件账户，将收到的代码粘贴到相应字段。
8. 后续对话框可用于个性化体验，可选择跳过。
9. 可以选择免费的 30 天 GitHub Enterprise 试用版。

创建账户后，建议立即进行以下操作：
1. 访问 https://github.com/settings/security，启用双因素认证以保护账户。
2. 在 https://github.com/settings/profile 填写个人资料并选择一个好的头像。
3. 在 https://github.com/settings/appearance 选择喜欢的主题，可以选择单一的浅色或深色主题，也可以选择与系统同步主题。
4. 在 https://github.com/settings/emails 选择如何处理电子邮件地址，可以选择保持电子邮件地址私有。GitHub 在执行基于 Web 的 Git 操作时将使用特殊的电子邮件地址： + @users.noreply.github.com。如果要阻止包含真实电子邮件地址的命令行推送，需在本地配置该地址：

$ git config --global user.email <email address>

4.4 企业安全

企业可以使用 SAML 单点登录（SSO）与身份提供者（IdP）保护 GitHub Enterprise 资源。GHEC 可在企业和组织级别配置 SSO，GHES 只能为整个服务器配置。

SAML SSO 可与支持 SAML 的任何 IdP 配置，但并非所有都支持跨域身份管理系统（SCIM），兼容的有 Azure AD（AAD）、Okta 和 OneLogin。

以 AAD 为例，配置 SAML SSO 的步骤如下：
1. 在 GitHub 的企业或组织设置中，找到“Authentication security (/settings/security) | SAML single sign-on”，获取消费者 URL 以配置 IdP。
2. 在 AAD 中创建新的企业应用程序，搜索 GitHub 模板并选择相应的（企业、组织或服务器）。
3. 分配用户或组以访问 GitHub，在“Set up single sign on”中进行重要配置：
- 使用组织或企业 URL 作为标识符，去掉 /saml/consume 作为实体 ID。
- 添加 /saml/consume 作为回复 URL，/sso 作为登录 URL。
4. 调整 AAD 中字段的映射，默认设置在 AAD 未自定义时应能正常工作。
5. 下载用于签署 SAML 令牌的 Base64 证书。
6. 复制登录 URL 和 Azure AD 标识符 URL。
7. 返回 GitHub，将登录 URL 信息粘贴到“Sign on URL”字段，Azure AD 标识符 URL 粘贴到“Issuer”字段，在文本编辑器中打开证书并将内容粘贴到“Public certificate”字段。
8. 点击“Test SAML configuration”，使用 AAD 凭据登录。如果一切成功，可勾选“Require SAML authentication”以强制使用 SAML 访问。GitHub 将检查哪些用户未通过 IdP 获得访问权限，并在确认后删除他们。

综上所述，无论是进行实验、A|B 测试，还是使用 GitHub 企业版进行代码管理和协作，都需要根据自身情况选择合适的方法和工具，并不断提升相关能力。

实验、A|B 测试与 GitHub 企业版使用指南（续）

5. 实验与 GitHub 企业版的结合思路

将实验和 A|B 测试与 GitHub 企业版结合使用，可以为企业带来更高效的软件开发和业务运营。以下是一些结合的思路：
- 基于实验结果进行代码迭代 ：通过实验和 A|B 测试得到的数据和反馈，可以指导开发团队对代码进行针对性的改进。例如，如果实验发现某个功能的用户参与率较低，可以在 GitHub 上创建相关的 issue 进行跟踪，并组织开发团队进行优化。
- 利用 GitHub 进行实验代码管理 ：可以在 GitHub 上创建专门的分支或仓库来管理实验代码。这样可以清晰地将实验代码与稳定版本的代码分开，便于团队成员协作和管理。例如，创建一个名为 experiment-feature-x 的分支，在该分支上进行新功能的实验开发。
- 结合 GitHub Actions 自动化实验流程 ：GitHub Actions 可以帮助自动化实验和 A|B 测试的流程。例如，可以设置一个工作流，当有新的代码提交到实验分支时，自动部署到测试环境进行实验，并收集相关数据。以下是一个简单的 GitHub Actions 工作流示例：

name: Experiment Deployment
on:
  push:
    branches:
      - experiment-feature-x
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Deploy to test environment
        run: |
          # 这里可以添加部署到测试环境的脚本
          echo "Deploying to test environment..."
      - name: Collect experiment data
        run: |
          # 这里可以添加收集实验数据的脚本
          echo "Collecting experiment data..."

6. 实验和 GitHub 企业版使用的注意事项

在进行实验、A|B 测试以及使用 GitHub 企业版时，还需要注意以下事项：
- 数据安全 ：无论是实验数据还是 GitHub 上的代码和数据，都需要确保其安全性。在进行实验时，要注意对用户数据的保护，遵守相关的法律法规。在使用 GitHub 企业版时，要合理配置安全策略，如使用 SAML SSO 进行身份验证，设置访问权限等。
- 成本控制 ：GitHub 的一些功能是按使用量付费的，如 Actions、Packages 等。在使用这些功能时，要合理规划和控制使用量，避免不必要的成本支出。可以在组织或企业级别配置支出限制，确保费用在预算范围内。
- 团队协作与沟通 ：实验和软件开发都需要团队成员之间的密切协作和沟通。在 GitHub 上，要充分利用其提供的协作功能，如 issues、pull requests、discussions 等，及时交流实验进展、代码问题和业务需求。同时，要建立良好的沟通机制，确保团队成员之间信息畅通。

7. 总结与展望

实验、A|B 测试和 GitHub 企业版在软件开发和业务运营中都具有重要的作用。通过合理运用这些工具和方法，可以帮助企业更好地了解用户需求，优化产品功能，提高开发效率和质量。

在未来，随着技术的不断发展，实验和 A|B 测试的方法可能会更加智能化和自动化，GitHub 企业版也可能会提供更多强大的功能和工具。企业需要不断关注这些发展趋势，持续提升自身的能力和竞争力。

以下是一个 mermaid 流程图，展示了从实验规划到代码部署的整体流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(实验规划):::process --> B(假设形成):::process
    B --> C(实验设计):::process
    C --> D(代码开发):::process
    D --> E{实验执行}:::process
    E -->|成功| F(数据分析):::process
    E -->|失败| D
    F --> G(代码迭代):::process
    G --> H(部署到生产):::process

总之，企业要根据自身的需求和实际情况，选择合适的实验方法和 GitHub 企业版的功能，不断探索和实践，以实现更好的业务发展。