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 Produktionsförderung

GitHub Umgebungsschutzregeln können einen Prüfer erfordern, Bereitstellungen auf ausgewählte Verzweigungen oder Tags beschränken oder einen Wartezeittimer hinzufügen. Für Proseware können nur Ausführungen von main gegen die Produktion ausgeführt werden. Ein erforderlicher Prüfer untersucht die Staging-Testergebnisse, bevor der Produktionsförderungsauftrag 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 praktischer Workflow trennt die Bereitstellung von der Heraufufung. Ein Job stellt das neue Modell ohne Produktivverkehr bereit und testet es. Ein späterer Job 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. Ein Tor 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.