一下子在所有地方启用Code Quality意味着每个团队都会在同一天开始在其拉取请求中看到Code Quality发现，这可能会让人措手不及，并造成干扰。 在本教程中，你将了解如何分阶段推出它：先将发现引入小组，校准阈值，然后展开。 在推广到整个组织之前，你将先验证其价值。
先决条件
- 企业所有者已允许在你的企业中使用 Code Quality。 请参阅“允许在您的企业中使用 GitHub Code Quality”。
- 你是组织所有者，因此可以在组织级别启用 Code Quality 和配置规则集。
规划您的试点
从小型试点组开始 ，而不是整个组织。 合适的试点对象可以是一个工程团队，或一组相关应用；它们应当足够活跃，能够产出有意义的发现，并且由能够就结果提供反馈的人负责。
若要以该组为目标，请使用组织的存储库访问设置来针对Code Quality。 对于试点，有两个很好的选择：
- 所选存储库： 手动选取试点存储库的固定列表。 当试点组较小且稳定时，最好。
- 匹配筛选器： 启用与定义的条件匹配的每个存储库，如自定义属性
code-quality-enabled: true。 最好是希望试点随着团队标记更多存储库而自动增长。
以自定义属性为目标，而不是逐个命名存储库，意味着以后只需在更多存储库上设置属性即可扩大试点范围。 如果要使用自定义属性：
- 创建自定义属性。 请参阅“管理组织中存储库的自定义属性”。
- 在组织级别为与筛选条件匹配的仓库启用 Code Quality。 请参阅“面向各类组织和企业的代码质量赋能”。
在评估模式下启用质量规则集
首先在评估模式下启用质量阈值。 在此模式下，Code Quality会显示哪些拉取请求会被阻止，而不会实际阻止这些请求，因此试点团队可以在其开始强制执行之前了解其影响。
将阈值设为一个适用于试点仓库的组织规则集，并使其保持在评估模式，直到收集到足够多的拉取请求活动以评估其影响，通常为 一两周。 请参阅“为拉取请求设置代码质量阈值”。
调整阈值
使用评估模式结果校准阈值。 查看规则集洞察（规则集的历史记录），以准确了解哪些拉取请求本会被阻止及其原因。 如果会有太多拉取请求被阻止，那么你的阈值可能设置得比当前代码库所能适应的更严格。 如果几乎没有任何内容会被拦截，你可能需要把这些规则设得更严格一些。 调整，直到该门槛体现出你真正想要执行的质量标准。
移动到强制模式
当评估模式结果看起来正确时，请将规则集从“评估”切换到“活动”。 这些阈值现在开始阻止不满足这些阈值的拉取请求。 试点团队会先经过这一强制门控环节，让你在进一步扩大推广范围之前做最后一次检查。
扩展到整个组织
利用你从试点中获得的经验扩大推广范围。 可以通过两种方式扩大它：
- 将 存储库添加到所选存储库 列表，或在与筛选器匹配的更多存储库上设置自定义属性。
- 确信阈值后，请将 存储库访问 设置切换到 “所有存储库 ”，以在单个更改中在整个组织中应用 Code Quality 。
关于组织级启用的运作方式，有几点需要了解，以便你选择合适的方法：
- 存储库访问选项适用于现有存储库和将来的存储库，因此以后创建的存储库会自动继承你的选择。 这适用于所有 存储库、 匹配筛选器和 无存储库。
- 启用 强制访问，以确保实施一项存储库管理员也无法覆盖的基线要求。 请将其关闭，或选择 “让存储库决定”，让团队选择在其自己的时间线上加入。
- 启用Code Quality不会自动启用代码覆盖率。 覆盖范围按存储库选择加入。 它仅在某人添加上传覆盖数据的工作流后开始报告，以便团队可以先采用 Code Quality ，稍后再添加覆盖范围。 请参阅“为存储库设置代码覆盖率”。
有关访问选项的完整列表以及强制实施方式，请参阅 面向各类组织和企业的代码质量赋能。
通过编程进行扩展
对于大多数推广场景，通过 UI 启用是最佳起点：这样你可以直接筛选并指定目标仓库，而这在脚本中更难复现。
如果你需要为发布流程实现自动化，可以通过 REST API 获取 Code Quality 发现结果，这有助于在逐步扩大范围时报告进展。 还可以通过 REST API 在存储库上启用 Code Quality ，以便跨组织编写启用脚本，而不是在 UI 中启用每个存储库。 请参阅“代码质量的 REST API 端点”。
后续步骤
- 评估整个组织的健康状况。 请参阅“探索组织中的 GitHub 代码质量结果”。