增强的安全管理
通过此更新，现在可以选择为整个项目或组织启用或禁用高级安全性。 还可以为新创建的任何存储库或项目自动启用高级安全性。
在 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。 但是，可以选择允许他们向此类生成提供机密。 项目可以决定 不允许 管道生成此类 PR，或安全地生成它们，或者具有组织级别指定的更严格的设置。
Azure Repos
阻止用户批准其自己的更改的新“分支策略”
为了改进对用户批准哪些更改的控制，并符合更严格的法规/合规性要求，我们确实提供了一个选项来防止用户批准自己的更改，除非明确允许。
能够管理分支策略的用户现在可以在“推送新更改时”下切换新添加的选项“每次迭代至少需要一次审批”。 选择此选项后，至少需要对最后一个源分支更改进行一次批准投票。 用户的批准不计入该用户之前推送的任何未经批准的迭代。 因此，另一个用户需要对上次迭代进行额外的批准。
下图显示了用户 A 创建的拉取请求，以及用户 B (、C、A 和 C) 针对该拉取请求进行的另外 4 个提交。用户 B) 完成第二次迭代 (提交后，用户 C 批准了该操作。 此时，它意味着在创建拉取请求时批准用户 A (的首次提交，) 新引入的策略将成功。 在第五次迭代 (最后一次提交用户 C) 之后，审批由用户 A 完成。此默示批准用户 C 完成的早期提交，但并不表示批准用户 A 在第四次迭代中完成的第二次提交。 若要使新引入的策略成功，未经批准的迭代 4 必须得到用户 B、C 或尚未对拉取请求进行任何更改的任何其他用户的批准。
Azure Artifacts
介绍 Azure Artifacts 对 Cargo Crates 的支持 (公共预览版)
我们很高兴地宣布，Azure Artifacts 现在为 Cargo 箱提供本机支持。 除了作为上游源提供 crates.io 外，此支持还包括与现有协议相关的功能奇偶一性。 Rust 开发人员和团队现在可以无缝地使用、发布、管理和共享其 Cargo 箱，同时使用 Azure 的可靠基础结构并停留在熟悉的 Azure DevOps 环境中。
预览版无需注册;首先，导航到 Azure DevOps 项目，选择“项目”，然后按照说明将 Rust 项目连接到 Azure Artifacts 源。
后续步骤
注意
这些功能将在未来两到三周内推出。
前往 Azure DevOps 并查看。
如何提供反馈
我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
此致
西尔维乌·安德里卡