Melhores práticas do Azure Developer CLI

Use esta habilidade para produzir projetos azd que sejam fáceis de manter, seguros e conscientes do ambiente. Prefira convenções de repositório quando elas já forem coerentes e faça a menor alteração completa que melhore o projeto.

Comece com a descoberta do repositório

Antes de editar:

1. Encontre azure.yaml, o infra.path configurado, projetos de origem, scripts de implantação, .gitignore e definições de pipeline.
2. Leia azure.yaml antes de inferir serviços ou o provedor de IaC.
3. Identifique se a tarefa é criar, migrar, revisar, implantar ou solucionar problemas.
4. Identifique o ambiente ativo somente quando uma operação específica do ambiente for necessária.
5. Leia a referência relevante:
   • Layout do repositório ou azure.yaml: references/project-structure.md
   • Bicep, Terraform, parâmetros, saídas ou ambientes: references/iac-and-environments.md
   • Segredos, hooks, CI/CD, implantação ou solução de problemas: references/security-cicd-operations.md
   • Detalhes do produto que podem ter mudado: references/official-docs.md

Não presuma o caminho padrão infra, o provedor Bicep padrão ou um único serviço quando azure.yaml disser o contrário.

Aplique salvaguardas de segurança

• Nunca confirme .azure, arquivos de .env de ambiente, credenciais, saídas de implantação contendo segredos, estado local do Terraform ou artefatos de implantação gerados.
• Nunca coloque segredos literais em azure.yaml, arquivos de parâmetros de IaC, hooks, controle de origem, argumentos de comando que serão registrados ou saídas de IaC.
• Prefira identidades gerenciadas e RBAC. Use referências do Key Vault e azd env set-secret quando um segredo for inevitável.
• Antes de um comando que pode criar, modificar ou excluir recursos do Azure, confirme o ambiente de destino, a assinatura, o locatário, a região e o escopo esperado.
• Trate uma solicitação explícita do usuário para implantar, provisionar, destruir ou configurar um pipeline como aprovação para essa ação nomeada. Caso contrário, pergunte antes de executar azd up, azd provision, azd deploy, azd down ou azd pipeline config.
• Não substitua Bicep por Terraform, Terraform por Bicep ou um serviço de hospedagem estabelecido, a menos que o usuário solicite essa alteração arquitetônica.
• Preserve recursos e estado de propriedade fora do projeto azd atual.

Use estes padrões

Fluxo de trabalho de implementação

1. Modelagem do aplicativo

• Defina uma entrada services para cada componente implantável independentemente.
• Mantenha as chaves de serviço estáveis, pois elas participam da descoberta de recursos e da implantação.
• Mapeie cada serviço para seu project, language e host reais.
• Mantenha a infraestrutura compartilhada em IaC em vez de inventar um serviço implantável fictício.
• Declare dependências com campos azure.yaml suportados em vez de depender da ordem dos arquivos.

2. Modelagem da infraestrutura

• Mantenha main.bicep ou main.tf como o ponto de entrada de orquestração.
• Divida a infraestrutura reutilizável ou compreensível independentemente em módulos.
• Parametrize valores específicos do ambiente; não crie forks da árvore de IaC por ambiente.
• Saída apenas valores estáveis e não secretos necessários para configuração de implantação ou aplicativo.
• Use nomes determinísticos e tags consistentes que incluam o projeto e o ambiente.
• Adicione atribuições de função a identidades em vez de distribuir chaves de serviço.
• Use camadas de infraestrutura apenas quando escopos separados ou dependências de ciclo de vida as justificarem.

3. Modelagem de ambientes

…