使用GitHub环境控制部署
Proseware 将模型部署自动化，但团队并不希望每次工作流成功运行后都立即切换生产流量。 自动测试应首先验证部署。 然后，审阅者应决定这些证据是否支持晋升。
表示部署阶段
GitHub环境是存储库中的命名部署目标，例如staging或production。 工作流作业会关联到其所针对的环境。 GitHub在作业运行或访问环境机密之前评估该环境的保护规则。
环境名称不会创建Azure资源。 决定每个GitHub环境如何映射到Azure 机器学习资源。 例如，可以为过渡和生产环境分别使用不同的工作区，以获得更强的隔离性；也可以在同一工作区内使用不同的终结点，从而减少管理开锁。
注释
GitHub环境控制部署作业。 Azure 机器学习环境定义用于运行机器学习代码的操作系统、包和其他依赖项。 这两个概念是独立的。
保护生产升级
GitHub环境保护规则可能需要审阅者、将部署限制为所选分支或标记，或添加等待计时器。 对于 Proseware，只有来自 main 的运行才能以生产环境为目标。 所需的审阅者在允许生产升级作业继续之前会先检查过渡测试结果。
该门将两个决策分开。 自动检查确定部署是否符合定义的要求。 审阅者结合证据和运行环境，决定是否应立即发布。
作用域配置和访问权限
环境变量可以保留非敏感目标设置，例如Azure 机器学习工作区和终结点名称。 环境机密仅适用于引用该环境的作业，并且仅在其保护规则通过之后可用。
使用 OIDC 时，不会存储客户端密码。 你仍然可以使用不同的联合标识进行暂存和生产，然后仅向每个标识授予其作业所需的Azure权限。 这种方法可防止过渡作业仅仅因为两个作业使用同一个存储库而获得生产环境的访问权限。
实际工作流将部署与提升区分开来。 一个任务在没有生产流量的情况下部署并测试新模型。 后续作业会引用受保护的 production 环境，并且仅在获得批准后才切换流量。
Tip
在添加审批之前，请确定审阅者需要的证据。 缺乏明确验收标准的关卡会拖延部署，却无助于改善决策。
详细了解如何管理部署GitHub环境。