Controla implementações com ambientes GitHub

A Proseware automatiza a implementação dos modelos, mas a equipa não quer que cada execução de workflow bem-sucedida altere imediatamente o tráfego de produção. Testes automatizados devem verificar primeiro a implementação. Um revisor deve então decidir se as evidências apoiam a promoção.

Representar as fases de implementação

Um ambiente GitHub é um destino de implementação nomeado num repositório, como staging ou production. Uma tarefa de fluxo de trabalho faz referência ao ambiente a que se destina. O GitHub avalia as regras de proteção desse ambiente antes de o trabalho ser executado ou aceder aos segredos do ambiente.

O nome do ambiente não cria um recurso Azure. Decides como cada ambiente GitHub se relaciona com os recursos do Azure Machine Learning. Por exemplo, o teste e a produção podem usar espaços de trabalho separados para um maior isolamento, ou pontos de extremidade separados num único espaço de trabalho para um menor esforço de gestão.

Proteger a promoção da produção

As regras de proteção do ambiente do GitHub podem exigir um revisor, restringir implementações a ramos ou etiquetas selecionadas, ou adicionar um temporizador de espera. No caso da Proseware, só as execuções de main podem ter como destino a produção. Um revisor obrigatório examina os resultados do teste de encenação antes de permitir que o trabalho de promoção de produção continue.

Este portão separa duas decisões. Verificações automáticas determinam se a implementação cumpre os requisitos definidos. O revisor decide se a divulgação deve avançar agora, tendo em conta as provas e o contexto operacional.

Configuração e acesso do âmbito

As variáveis de ambiente podem conter definições de alvo não sensíveis, como o espaço de trabalho Azure Machine Learning e nomes de endpoints. Os segredos ambientais estão disponíveis apenas para empregos que fazem referência a esse ambiente e só depois de as suas regras de proteção serem aprovadas.

Com o OIDC, não se guarda um segredo do cliente. Ainda podes usar diferentes identidades federadas para staging e produção, e depois conceder a cada identidade apenas as permissões do Azure que o seu trabalho exige. Esta abordagem impede que uma tarefa de teste obtenha acesso à produção simplesmente porque ambas as tarefas utilizam o mesmo repositório.

Um fluxo de trabalho prático separa a implementação da promoção. Um trabalho implementa e testa o novo modelo sem tráfego de produção. Um trabalho posterior faz referência ao ambiente protegido production e só altera o tráfego após aprovação.

Saiba mais sobre como gerir ambientes GitHub para deployment.