Automação de plataforma e DevOps no acelerador de zona de destino do Gerenciamento de API
Este artigo fornece considerações e recomendações de design para automação de plataforma e DevOps ao usar o acelerador de zona de destino do Gerenciamento de API. A automação de plataforma e o DevOps fornecem oportunidades para modernizar sua abordagem na implantação ambiental com opções de infraestrutura como código.
Saiba mais sobre a área de design automação de plataforma e DevOps.
Considerações sobre o design
- Cada equipe de API pode enviar atualizações por push de um repositório de desenvolvedores próprio para a respectiva instância de desenvolvimento do Gerenciamento de API.
- O que isso significa da perspectiva de planejamento de rede?
- E outros ambientes de não produção (como QA ou preparo)?
- Considere como os produtos e as outras entidades devem ser gerenciados ou terem um controle de versão, especialmente se várias equipes usarem os mesmos produtos.
- Considere a estratégia de teste para APIs e políticas.
Recomendações sobre design
- Uma equipe central (por exemplo, uma equipe de administração do Gerenciamento de API) gerencia o ambiente de produção do Gerenciamento de API.
- As configurações do Gerenciamento de API são representadas como modelos do Resource Manager ou modelos Bicep ou Terraform equivalentes, e uma mentalidade de infraestrutura como código deve ser adotada.
- A equipe de administração do Gerenciamento de API publicará alterações de configuração no ambiente de produção do Gerenciamento de API de um repositório Git (repositório do editor) de propriedade da equipe de administração do Gerenciamento de API.
- Cada equipe de API individual pode criar um fork do repositório do editor para ter o respectivo repositório de desenvolvedores do qual será feito o trabalho.
- Cada equipe pode usar o Gerenciamento de API APIOps ou a extensão Gerenciamento de API para Visual Studio Code extrair os artefatos relevantes de sua instância de Gerenciamento de API de desenvolvimento. Esses artefatos são baseados no Azure Resource Manager e devem ter o commit feito no repositório Git da equipe de API.
Observação
Não use a integração do Git do Gerenciamento de API.
- Os modelos de serviço e os modelos compartilhados devem estar em repositórios separados.
- As alterações nos artefatos devem ser feitas nos artefatos extraídos e confirmadas no Git. Elas devem ser implantadas em um ambiente de desenvolvimento.
- Para promover os ambientes centralizados (preparo, produção etc.), as equipes de API podem enviar uma PR (solicitação de pull) para mesclar as alterações no repositório do editor.
- A equipe de administração do Gerenciamento de API valida a PR.
- O ideal é que a maioria das validações seja automatizada como parte do envio de uma PR.
- Os modelos de infraestrutura como código devem estar em um repositório diferente e ser implantados em um pipeline de implantação.
- Separe a implantação de infraestrutura da implantação do aplicativo. A infraestrutura principal muda com menos frequência do que os aplicativos. Trate cada tipo de implantação como um fluxo e um pipeline separados.
- Depois que as alterações forem aprovadas e mescladas com sucesso, a equipe de administração do Gerenciamento de API poderá implantar as alterações no ambiente gerenciado centralmente (preparo, produção) em coordenação com os agendamentos de equipe de API acordados.
Suposições de escala empresarial
Estas são as suposições que entraram no desenvolvimento do acelerador de zona de destino do Gerenciamento de API:
- Uso de arquivos Bicep da infraestrutura como código para implantar a infraestrutura e os back-ends do Gerenciamento de API.
- Implantação de modelos de infraestrutura usando pipelines.