Contrôler les déploiements avec des environnements GitHub

Proseware automatise le déploiement de modèles, mais l’équipe ne souhaite pas que chaque exécution réussie d’un workflow modifie immédiatement le trafic de production. Les tests automatisés doivent d’abord vérifier le déploiement. Un évaluateur doit ensuite décider si les éléments justifient une promotion.

Représenter les étapes de déploiement

Un environnement GitHub est une cible de déploiement nommée dans un référentiel, par stagingproductionexemple. Une tâche de workflow référence l’environnement qu’elle cible. GitHub évalue les règles de protection de cet environnement avant l'exécution du travail ou accède aux secrets d'environnement.

Le nom de l'environnement ne crée pas de ressource Azure. Vous décidez de la façon dont chaque environnement GitHub est mappé aux ressources Azure Machine Learning. Par exemple, la mise en lots et la production peuvent utiliser des espaces de travail distincts pour une isolation plus forte ou des points de terminaison distincts dans un espace de travail pour réduire la surcharge de gestion.

Protéger la promotion de la production

GitHub règles de protection de l’environnement peuvent nécessiter un réviseur, restreindre les déploiements aux branches ou balises sélectionnées, ou ajouter un minuteur d’attente. Pour Proseware, seules les exécutions issues de main peuvent cibler la production. Un réviseur requis examine les résultats des tests intermédiaires avant d’autoriser le travail de promotion de production à continuer.

Cette porte sépare deux décisions. Les vérifications automatisées déterminent si le déploiement répond aux exigences définies. Le réviseur décide si la mise en production doit se poursuivre maintenant, compte tenu de la preuve et du contexte opérationnel.

Configuration de l’étendue et accès

Les variables d’environnement peuvent contenir des paramètres cibles non sensibles, tels que les noms d’espace de travail et de point de terminaison Azure Machine Learning. Les secrets d’environnement sont disponibles uniquement pour les tâches qui font référence à cet environnement, et uniquement après validation de ses règles de protection.

Avec OIDC, vous ne stockez pas de secret client. Vous pouvez toujours utiliser différentes identités fédérées pour la préproduction et la production, puis accorder à chaque identité uniquement les autorisations Azure son travail nécessite. Cette approche empêche un travail intermédiaire d’accéder à la production simplement parce que les deux travaux utilisent le même référentiel.

Un flux de travail pratique sépare le déploiement de la promotion. Une tâche déploie et teste le nouveau modèle sans trafic de production. Une tâche ultérieure fait référence à l’environnement protégé production et ne modifie le trafic qu’après validation.

En savoir plus sur la gestion des environnements GitHub pour le déploiement.