Controllare le distribuzioni con ambienti GitHub

Proseware automatizza la distribuzione dei modelli, ma il team non vuole che ogni esecuzione corretta del flusso di lavoro modifichi immediatamente il traffico di produzione. I test automatizzati devono prima verificare la distribuzione. Un revisore deve quindi decidere se l'evidenza supporta l'innalzamento di livello.

Rappresentare le fasi di distribuzione

Un ambiente GitHub è una destinazione di distribuzione denominata in un repository, ad esempio staging o production. Un processo di flusso di lavoro fa riferimento all'ambiente a cui è destinato. GitHub valuta le regole di protezione di quell'ambiente prima che il job venga eseguito o acceda ai secret dell'ambiente.

Il nome dell'ambiente non crea una risorsa Azure. Decidi come ogni ambiente GitHub viene associato alle risorse di Azure Machine Learning. Ad esempio, la gestione temporanea e la produzione possono usare aree di lavoro separate per un isolamento più forte o endpoint separati in un'area di lavoro per ridurre il sovraccarico di gestione.

Proteggere la promozione di produzione

GitHub regole di protezione dell'ambiente possono richiedere un revisore, limitare le distribuzioni a rami o tag selezionati o aggiungere un timer di attesa. Per Proseware, solo le esecuzioni provenienti da main possono avere come destinazione l'ambiente di produzione. Un revisore designato esamina i risultati dei test dell'ambiente di staging prima di consentire al processo di promozione in produzione di proseguire.

Questa porta separa due decisioni. Controlli automatizzati determinano se la distribuzione soddisfa i requisiti definiti. Il revisore decide se il rilascio deve procedere ora, considerando le prove e il contesto operativo.

Configurazione e accesso dell'ambito

Le variabili di ambiente possono contenere impostazioni di destinazione non sensibili, ad esempio i nomi dell'area di lavoro e degli endpoint Azure Machine Learning. I segreti dell'ambiente sono disponibili solo per i processi che fanno riferimento all'ambiente e solo dopo il superamento delle regole di protezione.

Con OIDC non si archivia un segreto client. È comunque possibile usare identità federate diverse per la gestione temporanea e la produzione, quindi concedere a ogni identità solo le autorizzazioni Azure necessarie per il processo. Questo approccio impedisce a un job di staging di ottenere l'accesso all'ambiente di produzione semplicemente perché entrambi i job utilizzano lo stesso repository.

Un flusso di lavoro pratico separa la distribuzione dalla promozione. Un'attività distribuisce e testa il nuovo modello senza traffico in produzione. Un processo successivo fa riferimento all'ambiente protetto production e modifica il traffico solo dopo l'approvazione.

Altre informazioni sulla gestione degli ambienti GitHub per la distribuzione.