Automatização da plataforma e DevOps para o acelerador de zonas de destino Gestão de API
Este artigo fornece considerações de conceção e recomendações para a automatização da plataforma e o DevOps ao utilizar o acelerador de zonas de destino Gestão de API. A automatização da plataforma e o DevOps proporcionam oportunidades para modernizar a sua abordagem à implementação ambiental com opções de infraestrutura como código.
Saiba mais sobre a automatização da plataforma e a área de design de DevOps .
Considerações de design
- Cada equipa de API pode enviar atualizações do repositório de programadores para a sua própria instância de desenvolvimento Gestão de API.
- O que significa isto do ponto de vista do planeamento de rede?
- E outros ambientes de não produção (como a GQ ou o teste)?
- Considere como os produtos e outras entidades devem ser geridos ou com controlo de versões, especialmente se várias equipas utilizarem os mesmos produtos.
- Considere a estratégia de teste para APIs e políticas.
Recomendações de conceção
- Uma equipa central (por exemplo, uma equipa de administração Gestão de API) gere o ambiente de Gestão de API de produção.
- Gestão de API configurações são representadas como modelos Resource Manager ou modelos bicep ou Terraform equivalentes e deve ser aceite uma mentalidade de infraestrutura como código.
- A equipa de administração do Gestão de API publicará alterações de configuração no ambiente de Gestão de API de produção a partir de um repositório git (repositório do publicador) propriedade da equipa de administração do Gestão de API.
- Cada equipa de API individual pode criar um fork do repositório do publicador para ter o seu próprio repositório de programadores a partir do qual trabalhar.
- Cada equipa pode utilizar o Gestão de API APIOps ou a extensão de Gestão de API do Visual Studio Code para extrair os artefactos relevantes da instância de Gestão de API de desenvolvimento. Estes artefactos baseiam-se no Azure Resource Manager e devem ser consolidados no repositório Git da equipa de API.
Nota
Não utilize a integração Gestão de API Git.
- Os modelos de serviço e os modelos partilhados devem estar em repositórios separados.
- As alterações aos artefactos devem ser efetuadas aos artefactos extraídos e, em seguida, consolidadas no Git. Estes devem ser implementados num ambiente de desenvolvimento.
- Para promover para os ambientes centralizados (teste, produção, etc.), as equipas de API podem submeter um pedido Pull (PR) para intercalar as alterações ao repositório do publicador.
- A equipa de administração do Gestão de API valida o PR.
- Idealmente, a maioria das validações são automatizadas como parte da submissão de um PEDIDO Pull.
- Os modelos de infraestrutura como código devem estar num repositório diferente e implementados num pipeline de implementação.
- Separe a implementação da infraestrutura da implementação de aplicações. A infraestrutura principal é alterada com menos frequência do que as aplicações. Trate cada tipo de implementação como um fluxo e pipeline separados.
- Depois de as alterações serem aprovadas e intercaladas com êxito, a equipa de administração do Gestão de API pode implementar as alterações no ambiente gerido centralmente (teste, produção) em coordenação com os agendamentos da equipa de API acordados.
Pressupostos à escala de grandes empresas
Seguem-se pressupostos que entraram no desenvolvimento do acelerador de zonas de destino Gestão de API:
- Utilizar ficheiros Bicep de infraestrutura como código para implementar Gestão de API infraestrutura e back-ends.
- Implementação de modelos de infraestrutura com pipelines.