Steuern von Bereitstellungen mit GitHub Umgebungen

Abgeschlossen

Proseware automatisiert die Modellbereitstellung, aber das Team möchte nicht, dass jede erfolgreiche Workflow-Ausführung den Produktions-Traffic sofort ändert. Automatisierte Tests sollten zuerst die Bereitstellung überprüfen. Ein Prüfer sollte dann entscheiden, ob die Nachweise die Werbung unterstützen.

Bereitstellungsphasen darstellen

Eine GitHub-Umgebung ist ein benanntes Bereitstellungsziel in einem Repository, wie staging oder production. Ein Workflowauftrag verweist auf die Umgebung, auf die er abzielt. GitHub wertet die Schutzregeln dieser Umgebung aus, bevor der Auftrag ausgeführt wird oder auf geheime Umgebungsschlüssel zugreift.

Der Umgebungsname erstellt keine Azure Ressource. Sie entscheiden, wie jede GitHub Umgebung Azure Machine Learning Ressourcen zugeordnet ist. So können z. B. Staging und Produktion separate Arbeitsbereiche für eine stärkere Isolierung oder separate Endpunkte in einem Arbeitsbereich für einen geringeren Verwaltungsaufwand verwenden.

Hinweis

Eine GitHub Umgebung steuert Bereitstellungsaufträge. Eine Azure Machine Learning Umgebung definiert das Betriebssystem, die Pakete und andere Abhängigkeiten, die zum Ausführen von Machine Learning-Code verwendet werden. Die beiden Konzepte sind unabhängig.

Schützen der Höherstufung in die Produktion

GitHub Umgebungsschutzregeln können einen Prüfer erfordern, Bereitstellungen auf ausgewählte Verzweigungen oder Tags beschränken oder einen Wartezeittimer hinzufügen. Bei Proseware können nur Ausführungen von main in die Produktion gelangen. Ein erforderlicher Prüfer untersucht die Staging-Testergebnisse, bevor der Auftrag zur Höherstufung in die Produktion fortgesetzt werden kann.

Dieses Tor trennt zwei Entscheidungen. Automatisierte Prüfungen bestimmen, ob die Bereitstellung definierte Anforderungen erfüllt. Der Prüfer entscheidet, ob die Veröffentlichung jetzt fortgesetzt werden soll, wobei Nachweise und operativer Kontext berücksichtigt werden sollen.

Bereichskonfiguration und Zugriff

Umgebungsvariablen können nicht vertrauliche Zieleinstellungen enthalten, z. B. die Azure Machine Learning Arbeitsbereichs- und Endpunktnamen. Geheimnisse einer Umgebung sind nur für Jobs verfügbar, die auf diese Umgebung verweisen, und erst nachdem deren Schutzregeln erfüllt sind.

Bei OIDC speichern Sie keinen geheimen Clientschlüssel. Sie können weiterhin unterschiedliche Verbundidentitäten für Staging und Produktion verwenden und dann jeder Identität nur die Azure Berechtigungen erteilen, die für den Auftrag erforderlich sind. Dieser Ansatz verhindert, dass ein Stagingauftrag den Produktionszugriff erhält, weil beide Aufträge dasselbe Repository verwenden.

Ein einfacher Workflow trennt die Bereitstellung von der Höherstufung. Ein Auftrag stellt das neue Modell ohne Produktionsverkehr bereit und testet es. Ein späterer Auftrag verweist auf die geschützte production-Umgebung und ändert den Datenverkehr erst nach der Freigabe.

Tip

Bevor Sie eine Genehmigung hinzufügen, identifizieren Sie, welche Nachweise der Prüfer benötigt. Eine Prüfung ohne klare Akzeptanzkriterien verzögert die Bereitstellung, ohne die Entscheidung zu verbessern.

Erfahren Sie mehr über das Verwalten von GitHub-Umgebungen für die Bereitstellung.