通过此更新，现在可以为整个项目或组织启用或禁用高级安全性。 还可以为任何新创建的存储库或项目自动启用高级安全性。
在 Azure Pipelines 中，我们添加了一个集中控制，以提高从分支 GitHub 存储库生成的拉取请求的安全性。
请查看发行说明，了解有关这些功能的详细信息。
概况
Azure Pipelines
Azure Repos
Azure Artifacts
概况
在项目级和组织级的高级安全性启用
现在可以为整个项目或组织启用或禁用 高级安全性 。 结合在启用前显示提交者数量的新功能，在项目或组织级别选择“全部启用”将为你提供可能需要计费的新活跃提交者数量的估算。 还可以选择为相应项目或组织下的任何新创建的存储库或项目自动启用 高级安全性 。 通过此设置启用的任何存储库都将激活机密存储库扫描和推送保护。
项目级启用：
组织级别的启用：
高级安全启用期间提交者数量估计
作为您进行 高级安全 上手体验的一部分，您现在可以看到由于为特定存储库、项目或组织启用 高级安全 而可能增加的活跃提交者数量预估值。 此计数是近似值，你可能会看到提供的估计值与启用后计费报告的内容之间的细微差异。 还可以通过 API 获取此估算，关于此过程的详细说明文档将很快推出。
Azure Pipelines
审批和检查超时时重新尝试阶段
审批和检查发生超时时，其所属阶段将被跳过。 依赖于已跳过阶段的其他阶段也将被跳过。
现在可以在审批和检查过程超时时重试流程阶段。以前仅在审批超时时，这才可行。
所有环境的管理员职能
YAML 管道中的环境表示将应用程序部署到的计算资源，例如 AKS 群集或一组 VM。 它们为部署提供安全控制和可跟踪性。
管理环境可能非常具有挑战性。 这是因为，创建环境时，创建环境的人员会自动成为唯一的管理员。 例如，如果要以集中方式管理所有环境的审批和检查，则必须要求每个环境管理员以管理员身份添加特定用户或组，然后使用 REST API 配置检查。 此方法很繁琐，容易出错，并且在添加新环境时无法扩展。
使用此冲刺，我们在环境中心级别添加了 管理员角色 。 这使环境达到与服务连接或代理池相当的水平。 若要将管理员角色分配给用户或组，需要成为环境中心管理员或组织所有者。
具有此管理员角色的用户可以管理权限、管理、查看和使用任何环境。 这包括向所有管道开放环境。
在环境中心级别授予用户管理员角色时，它们将成为所有现有环境和任何未来环境的管理员。
集中控制从分叉的 GitHub 存储库生成 PR
如果从 GitHub 构建公共存储库，您必须考虑对派生构建的立场。 叉子尤其危险，因为它们来自组织外部。
可以通过查看有关如何 生成 GitHub 存储库 和 存储库保护的建议来提高生成 GitHub 公共存储库的管道的安全性。 遗憾的是，管理大量管道并确保其遵守最佳做法可能需要大量工作。
为了增强管道的安全性，我们添加了一个组织级控件，用于定义管道如何从分叉 GitHub 存储库生成 PR。 新设置被命名为 “限制从分叉的 GitHub 存储库生成拉取请求”，并适用于组织和项目级别。
组织级设置限制项目可用的设置，而项目级设置限制管道可用的设置。
让我们看看切换在组织级别的工作原理。 默认情况下，新控件处于关闭状态，因此不会普遍强制实施任何设置。
当您打开切换开关时，可以选择禁用从分叉的 GitHub 存储库中构建 PR。 这意味着，创建此类 PR 时，不会运行任何管道。
当你选择“从分叉存储库安全地生成拉取请求”选项时，组织范围内的所有管道无法将机密用于从分叉存储库生成的PR，不能赋予这些生成与正常生成相同的权限，并且必须通过PR注释触发。 项目仍可以决定 不允许 管道生成此类 PR。
选择“ 自定义 ”选项时，可以定义如何限制管道设置。 例如，当 PR 属于非团队成员和非参与者时，可以确保所有管道都需要注释才能从分支 GitHub 存储库生成 PR。 但是，您可以选择允许它们向这些构建提供机密。 项目可以决定 不允许 管道生成此类拉取请求，或者安全地生成它们，甚至可以采用比组织级别更严格的设置。
Azure Repos
新的“分支策略”阻止用户批准自己的更改
为了改进对用户批准和符合更严格法规/合规要求的更改的控制，我们提供了一个选项，除非明确允许，否则用户不能批准自己的更改。
拥有管理分支策略权限的用户现在可以在“推送新更改时”选项下，切换新添加的选项“每次迭代至少需要一次批准”。 选择此选项后，至少需要对最后一个源分支更改进行审批投票。 用户的批准不会计入该用户推送的任何先前未经批准的迭代。 因此，另一个用户需要对上次迭代进行额外的批准。
下图显示了用户 A 创建的拉取请求，以及用户 B、C、A 和 C 对该拉取请求进行的其他 4 次提交（迭代）。第二次迭代（用户 B 完成提交）完成后，用户 C 批准了该迭代。 当时，这意味着用户 A 的首次提交（在创建拉取请求时）被认可，并且新引入的策略将会成功。 在第五次迭代（用户 C 的最后一次提交）之后，用户 A 完成了审批。这意味着对用户 C 之前的提交进行了批准，但不表示对用户 A 在第四次迭代中完成的第二次提交的批准。 若要使新引入的策略成功，未经批准的迭代四必须通过用户 B、C 或任何其他尚未对拉取请求进行任何更改的用户批准。
Azure Artifacts
引入对 Cargo Crates 的 Azure Artifacts 支持（公共预览版）
我们很高兴地宣布，Azure Artifacts 现在为 Cargo 包提供本地支持。 除了 crates.io 作为上游源之外，此支持还包括与我们现有协议的功能对等性。 Rust 开发人员和团队现在可以无缝地使用、发布、管理和共享其 Cargo 箱，同时使用 Azure 的可靠基础结构并保持熟悉的 Azure DevOps 环境。
预览版无需注册;可以先导航到 Azure DevOps 项目，选择 Artifacts，然后按照说明将 Rust 项目连接到 Azure Artifacts 源来开始。
后续步骤
注释
这些功能将在未来两到三周内推出。
请去 Azure DevOps 上看看。
如何提供反馈
我们很乐意听到你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。
谢谢
Silviu Andrica