Tópicos do workshop sobre ALM
Nesta unidade, analisaremos tudo o que deve ser considerado na hora de preencher e avaliar o modelo de workshop do ALM (gerenciamento do ciclo de vida do aplicativo). Estes tópicos foram criados para ajudar o arquiteto de soluções a avaliar as informações coletadas durante o workshop e gerar as descobertas e recomendações. É importante lembrar de que não existe um ALM que atenda a todos os casos de uso. O grau e o detalhamento do ALM devem ser decididos de acordo com cada projeto. Para começar a entender o ALM com o Dynamics 365 e o Microsoft Power Platform, leia e examine os tópicos em Gerenciamento do ciclo de vida do aplicativo com o Microsoft Power Platform nesta página de documentação.
Estratégia geral
É importante saber a metodologia de desenvolvimento que foi usada pela equipe de projeto para criar a solução. É importante também saber o número de equipes envolvidas, especialmente na criação de personalizações. A estratégia de ALM deve ser influenciada para ajudar essas equipes e permitir que as equipes de projeto trabalhem com eficácia.
Elementos importantes para analisar
Falta de metodologia de desenvolvimento. É arriscado começar um projeto e "ver no que vai dar".
Não são recomendadas abordagens mais tradicionais em cascata com projetos do Microsoft Power Platform e do Dynamics 365. A maioria das equipes encontra algum tipo de abordagem ágil ou iterativa para tornar a entrega de um projeto bem-sucedida.
É um risco quando não existe um entendimento claro das pessoas envolvidas nas alterações e de como elas serão coordenadas.
Há uma ferramenta disponível para rastrear itens de trabalho, incluindo a atribuição de itens de trabalho?
Evolução do ALM
Nem todos os clientes automatizam totalmente o processo de ALM desde o início. Alguns optam por uma abordagem de "rastejar, caminhar, correr".
Não gerenciado no desenvolvimento
Rastejar:
- Exportar/Importar
- Exportar/Salvar em arquivo
- Sistema/Importar
Caminhar:
- Várias soluções sem controle de origem
- Introduzir dados mestre
- Introduzir controle do código-fonte baseado em solução
Correr:
- Introduzir automação com implantações de pacote
- Controle de versão habilitado com o Pacote de Soluções
Gerenciado em todos os lugares upstream
- Compilações automatizadas e gerenciamento de instâncias
- Azure DevOps com controle do código-fonte automatizado
Ambientes
Os ambientes devem ser criados para dar suporte à estratégia de ALM que está sendo implementada. Em geral, o projeto deve ter pelo menos um ambiente de desenvolvimento, teste e produção. O tipo desses ambientes deve ser de área restrita ou de produção, e não de avaliação ou de comunidade. Além disso, considere ter um ambiente de hotfix para alterações que precisam ser aplicadas à produção após a ativação.
Se houver necessidade de criar ambientes em regiões geográficas diferentes, as equipes deverão estar cientes de que eles serão atualizados em horários distintos. Por exemplo, se o desenvolvimento acontece na região do Canadá e a produção acontece na região da América do Norte, é possível que o Canadá tenha recursos que a América do Norte ainda não tenha. Ao usar várias regiões geográficas, é necessário uma coordenação maior com as atualizações e os recursos da Microsoft.
Cada solução Microsoft Dataverse deve ter pelo menos um ambiente de desenvolvimento que atenda aos membros da equipe que fazem as personalizações. Com um modelo centrado no código-fonte, vários ambientes de desenvolvimento são possíveis, mas exigem coordenação para resolver conflitos de mesclagem à medida que ocorrem. Os ambientes de desenvolvimento únicos são mais simples de gerenciar por meio de coordenação básica, mas vários ambientes permitem mais isolamento do desenvolvedor e velocidade da equipe. O controle de acesso adequado deve ser implementado para garantir que apenas os membros da equipe certos tenham acesso aos diversos ambientes. Isso também ajuda a garantir que as pessoas não façam alterações fora do ambiente de desenvolvimento atribuído.
Elementos importantes para analisar em relação aos ambientes
Um número de ambientes razoável foi identificado? Deve haver pelo menos um ambiente de desenvolvimento, teste e produção. Um número excessivo de ambientes sem uma finalidade definida pode levar a uma complexidade difícil de gerenciar.
Há planos de armazenar soluções descompactadas no controle do código-fonte?
Os ambientes de avaliação estão sendo usados? Em caso afirmativo, há risco de expirar e perder as personalizações inesperadamente.
A capacidade de armazenamento disponível atende ao plano do ambiente?
Controle do código-fonte
Também é importante saber como as personalizações e outros ativos de código evoluem do desenvolvimento para os ambientes diferentes de teste até a produção. Uma parte importante deste processo é observar o que será considerado fonte da verdade para personalização e ativos de código. Antes, os projetos eram centrados no ambiente, sendo o ambiente de desenvolvimento, por exemplo, a fonte da verdade para personalizações. Neste modelo, as personalizações avançam diretamente do desenvolvimento para o teste e a produção. As alterações são transportadas como uma solução exportada do desenvolvimento.
Se você está aprimorando uma implantação existente que já foi concluída, ela pode ser o modelo usado para o projeto original. Novos projetos devem usar o controle do código-fonte como fonte da verdade para todas as personalizações e os ativos de código do projeto. Por exemplo, os repositórios git do Azure DevOps podem ser usados para armazenar tudo. Usando esse modelo, a equipe de projeto faz check-in das personalizações no controle do código-fonte. A solução gerenciada que será implantada é gerada do controle do código-fonte e usada para promover as personalizações a teste e, por fim, à produção. Essa abordagem torna os ambientes de desenvolvimento descartáveis. Outro benefício da abordagem centrada no controle do código-fonte é que ela mantém informações detalhadas sobre o que foi alterado e facilita uma estratégia de ramificação. A ramificação é essencial para habilitar a versão de produção de um serviço enquanto a próxima versão está sendo criada. Além disso, vinculando as solicitações de pull ou as confirmações a itens de trabalho, você cria rastreamentos que aprimoram o processo de desenvolvimento geral.
Elementos importantes para analisar em relação ao controle do código-fonte
Se antes era usada uma abordagem centrada no ambiente, e não no controle do código-fonte, existe um plano para mudar para o controle do código-fonte?
Um número de ambientes razoável foi identificado? Deve haver pelo menos desenvolvimento, teste e produção. Um número excessivo de ambientes pode levar a uma complexidade difícil de gerenciar.
As soluções gerenciadas estão sendo usadas em todos os ambientes que não sejam de desenvolvimento?
Soluções
Quando possível, todos os ativos de projeto que são componentes com reconhecimento de solução devem ser gerenciados em uma solução Dataverse. A maioria dos projetos dedicados a uma única linha de negócios ou processo empresarial deve usar uma única solução personalizada. A equipe de projeto deve associar um fornecedor de soluções personalizado que representa a empresa ou o produto que está criando, e não usar o fornecedor padrão. Não use vários editores, a menos que haja um caso de negócios para isso.
No caso de várias soluções, elas devem ser usadas com uma finalidade específica de resolução. Por exemplo, um projeto que pode ser colocado em uma solução separada é um componente reutilizável com planos de ser usado várias vezes. As soluções podem ser segmentadas por linha de negócio ou processo empresarial. Essas soluções segmentadas podem compartilhar uma base comum, mas devem ser isoladas apenas para suas personalizações e não ter dependências umas em relação às outras. No entanto, isso pode aumentar rapidamente a complexidade e deve ser avaliado quanto às vantagens em ter soluções separadas.
Cada solução deve ter o próprio ambiente de desenvolvimento, mantendo-as isoladas umas das outras. Quando uma solução é dependente de outra, a versão gerenciada da solução dependente deve ser instalada no ambiente de desenvolvimento. A estrutura da solução permite o conceito de soluções de patch, mas elas não são recomendadas ao usar um modelo centrado no código-fonte.
Elementos importantes para analisar em relação às soluções
Um fornecedor personalizado foi criado com uma pré-correção exclusiva apropriada e a equipe não está usando o fornecedor padrão?
A arquitetura da solução proposta usa um número razoável de soluções, cada uma com uma finalidade definida?
O plano do ambiente acomoda o número de soluções usadas no projeto para garantir o isolamento adequado da solução?
Plano de build
Nesta seção, analisaremos como a equipe planeja gerenciar a criação de soluções usando vários ambientes. As soluções devem ser criadas no ambiente de desenvolvimento em que os componentes são modificados. O plano de ALM deve garantir que as alterações sejam feitas somente no ambiente de desenvolvimento. O ambiente de desenvolvimento deve ser o único local em que as soluções não gerenciadas são usadas. Todos os outros ambientes devem ter soluções gerenciadas instaladas. Cada ambiente de desenvolvimento deve ter apenas uma solução não gerenciada.
São permitidas a exportação e a importação manuais de soluções, mas o procedimento de build ideal inclui um pouco de automação para criar um processo repetível.
Elementos importantes para analisar em relação aos planos de build
Os ambientes de desenvolvimento têm apenas uma solução não gerenciada?
As soluções gerenciadas são usadas em todos os ambientes que não sejam de desenvolvimento?
As restrições de acesso ou outros mecanismos foram implementados para garantir que as modificações sejam feitam somente no desenvolvimento?
Nem todos os componentes têm reconhecimento de solução, portanto, deve haver um plano para lidar com eles (por exemplo, visualizações do Power BI).
Pacote de soluções
O Pacote de soluções deve ser usado para preparar uma solução não gerenciada que estava em desenvolvimento para armazenamento em um repositório de controle do código-fonte. O Pacote de soluções divide o arquivo único da solução em vários arquivos separados, que representam cada componente da solução. Esse processo é conhecido como "descompactar a solução". O check-in da saída do pacote de soluções é feito no repositório de controle do código-fonte. A versão da qual o check-in foi feito agora representa a fonte da verdade para o projeto.
O Pacote de soluções também pode compactar a pasta do controle do código-fonte, recriando o arquivo único da solução. É assim que os arquivos dos quais o check-in foi feito no controle do código-fonte são usados para criar as soluções que serão importadas para os outros ambientes.
Elementos importantes para analisar em relação aos pacotes de soluções
Um pacote de soluções e um repositório de controle do código-fonte foram planejados?
A solução implantada para teste e produção foi criada do repositório de controle do código-fonte?
Verificador de solução
Como o Power Automate e o Power Apps são usados para personalizar uma implantação do Dynamics 365, cada um oferece os próprios verificadores de aplicativos embutidos que são úteis para a resolução de problemas em tempo real. No entanto, o verificador de solução pode verificar toda a solução, fazer uma análise estática e gerar uma lista detalhada de todos os problemas encontrados. (Há mais detalhes disponíveis em Usar o verificador de solução para validar os aplicativos baseados em modelo no Power Apps.)
O verificador de solução deve ser executado regularmente em qualquer solução não gerenciada que você cria em seus ambientes de desenvolvimento. O Verificador de Solução pode analisar fluxos do Power Apps e do Power Automate e ativos de código, como plug-ins criados por desenvolvedores. A equipe de projeto pode executar manualmente o Verificador de Solução no Maker Portal, selecionando a solução e executando o verificador.
É possível também automatizar o verificador de solução para ser executado como parte de um processo de build usando as tarefas de pipeline do PowerShell ou do Azure DevOps. Com a automatização da execução do verificador de solução, ele pode se tornar parte integrante do processo de build e até ser configurado para interromper a criação se houver muitos erros. A simples execução do Verificador de Solução não é suficiente para que a equipe seja bem-sucedida; ela também deve ter um plano para avaliar e resolver regularmente os problemas identificados.
Elementos importantes para analisar em relação aos verificadores de solução
Um plano foi elaborado para executar o verificador de solução como parte do processo de build?
Os resultados do verificador de solução são analisados regularmente e incorporados ao processo?
O verificador de solução foi integrado à automação de build para ser executado sem trabalho manual?
Automatizar a implantação
Uma área tão importante quanto a parte do plano de build é identificar a automação que pode ser usada para fazer com que o processo seja repetível. Há várias ferramentas disponíveis, tanto da Microsoft quanto da comunidade, que podem ser usadas para automatizar o processo de compilação. As tarefas do Azure DevOps e do Microsoft Power Platform são uma opção que pode ser usada para automatizar as tarefas de gerenciamento e implantação de soluções.
Por exemplo, uma equipe pode ter um pipeline do Azure DevOps que ela extrai do desenvolvimento todos os dias às 19h e registra em um repositório git. O mesmo pipeline também pode ser usado para executar o Verificador de Solução, de modo que, quando a equipe iniciar o trabalho de manhã, ela saiba imediatamente se algum problema foi identificado na compilação da noite anterior.
O pipeline também pode importar a solução para um ambiente de build limpo que permitirá a detecção de qualquer dependência que tenha sido introduzida involuntariamente durante o desenvolvimento do dia. Isso garante que todo o check-in feito no controle do código-fonte seja uma versão limpa pronta para implantação em outros ambientes. É possível também usar os pipelines para automatizar o teste de forma que seja apenas outra etapa no pipeline.
Os Azure Pipelines também são usados para gerar o artefato da solução gerenciada que será usado nos pipelines de lançamento para implantar os ambientes de upstream, como teste e produção. O mesmo artefato da solução que foi usado no teste é sempre usado até a produção. Isso garante que não sejam feitas novas alterações inesperadas à medida que a promoção avança pela série de ambientes que termina na produção. Também é possível usar o Azure Pipelines para criar ativos de código do desenvolvedor a fim de garantir que não sejam criados em uma estação de trabalho de desenvolvedor local.
GitHub Actions é outra opção para automatizar implantações.
Elementos importantes para analisar em relação à automatização da implantação
O Azure DevOps ou outra ferramenta de automação é usada para automatizar o processo de compilação ou a equipe ainda precisa trabalhar manualmente?
O Verificador de Solução foi integrado como parte do pipeline automatizado?
Todos os ativos de código do desenvolvedor são criados por meio de um processo de build, e não na máquina local de um desenvolvedor específico?
Controle de versão
Outro elemento do plano de build que deve ser avaliado é a estratégia para gerenciar várias versões ativas. Por padrão, conforme as alterações avançam do desenvolvimento para o teste e a produção, isso representa um único fluxo de trabalho de alterações. Se um problema for identificado na produção, você poderá corrigi-lo no desenvolvimento e depois promovê-lo por uma série de ambientes de volta à produção. Um único fluxo de trabalho como esse funciona bem se nenhum desenvolvimento novo for feito.
Se a equipe de desenvolvimento já passou para a versão dois no ambiente de desenvolvimento e depois corrigiu um bug identificado na produção, quando a correção passa para produção, todo o trabalho em andamento da versão dois também é passado, porque tudo estava misturado. A ação ideal é que a alteração seja feita em um ambiente de desenvolvimento de fluxo de trabalho separado que represente somente o que já estava em produção, e o que foi promovido inclua apenas a correção, e não tudo da versão dois. Isso exige que a equipe de projeto planeje e tenha uma estratégia para gerenciar várias versões ativas. Isso pode ser tão simples quanto um fluxo ativo de desenvolvimento e um fluxo de manutenção para permitir a produção. Projetos mais complexos podem até mesmo ter vários fluxos de desenvolvimento ativos ao mesmo tempo.
O processamento simultâneo dos fluxos ativos tanto de desenvolvimento quanto de manutenção costuma ser feito por uma combinação de ambientes e branches de controle do código-fonte do Dataverse. Os branches permitem ter uma cópia dos ativos do projeto e uma forma isolada de fazer alterações em um ambiente associado a eles. As alterações de um branch podem ser mescladas com outro branch. A estratégia de ramificação deve ser a mais simples possível para evitar ter que resolver vários conflitos durante a mesclagem dos branches.
Elementos importantes para analisar em relação ao controle de versão
A equipe considerou como vai manter o trabalho de desenvolvimento separado das correções de bugs para a produção?
A estratégia de ramificação identificada é muito complexa?
A ramificação do controle do código-fonte está coordenada com o plano do ambiente?
Existe um processo de gerenciamento de alterações para verificar se as correções de bugs retornam ao ambiente de desenvolvimento principal?
Estratégia de teste
A estratégia de teste tem um workshop próprio, mas o processo de teste em si deve ser integrado como parte da estratégia geral de ALM. Por exemplo, se você planeja que a equipe de controle de qualidade faça testes diários do trabalho do dia anterior, de alguma forma, precisa verificar se a equipe tem um ambiente atualizado com as alterações de ontem prontas para uso antes de iniciar os testes.
A automação dos testes também deve ser considerada e pode ser integrada como parte do processo de build. Isso pode incluir o provisionamento de um ambiente de teste, o carregamento dos dados de teste e a execução dos testes. Os resultados do teste podem ser usados para direcionar o andamento dos pipelines de build e evitar que eles continuem quando houver erros.
O Power Apps baseado em modelo pode ser testado usando o EasyRepro. Os aplicativos de tela do Power Apps podem ser testados usando o Power Apps Test Studio. O Test Studio funciona gravando ações no aplicativo e reproduzindo-o para automatizar os testes. O Easy Repro usa scripts para definir as etapas de teste a serem realizadas. Depois que é concluída a gravação ou a geração de scripts, os testes podem ser incluídos como uma tarefa em um pipeline do Azure DevOps.
Durante o teste, ele identifica os problemas que precisarão ser avaliados e corrigidos. A estratégia geral de ALM deve especificar como registrar, fazer a triagem e priorizar os problemas. Se uma equipe de desenvolvimento tiver que parar tudo o que está fazendo para corrigir cada bug assim que eles ocorrem, isso prejudicará todo o processo. Normalmente, um projeto deve estabelecer um processo de controle de alterações para garantir que cada problema passe por uma triagem e receba a prioridade em relação a quando ele será introduzido como uma correção.
Elementos importantes para analisar em uma estratégia de teste
A estratégia de ALM está alinhada à estratégia de teste geral?
Existe um processo de controle de alterações para rastrear e gerenciar todos os problemas identificados?
Há pelo menos algum teste integrado ao processo de automação de build?
Lançamento e implantação
Depois que a solução é criada, ela deve avançar pelos ambientes de teste até a produção. Geralmente, isso envolve mais do que apenas importar uma solução para esses ambientes. Para quem está começando, é preciso saber o estado inicial do ambiente. Por exemplo, você deseja que o teste sempre comece com alguns dados padrão ou do ponto de partida da última rodada de testes? Cada ambiente provavelmente terá um tipo de dados de configuração (por exemplo, variáveis de ambiente) que deve ser configurado pelo menos durante a primeira implantação. Para ambientes de teste, também é necessário verificar se eles não estão em contato com os serviços de produção na maioria dos casos. Normalmente, enviar um email de teste para todos os clientes reais não é bem visto.
Elementos importantes para analisar em relação ao lançamento e à implantação
Há um plano para a aparência de cada ambiente de teste de uma perspectiva de dados e de suas conexões com qualquer serviço?
As variáveis de ambiente da solução necessárias foram criadas para garantir que a solução possa ser adaptada a cada ambiente?
Dados de referência
A maioria das soluções tem alguma forma de dados de referência que deve ser gerenciada entre os diversos ambientes. A ferramenta de migração de configuração pode ajudar na exportação dos dados de um ambiente e na importação deles para outros ambientes. A ferramenta de migração de configuração funciona com a definição de um esquema dos dados que serão exportados, incluindo campos e relacionamentos. Quando a exportação é executada, um arquivo de dados zip é criado com todos os dados exportados. A ferramenta de migração de configuração também pode realizar a importação dos dados para um ambiente onde o arquivo de dados pode ser usado com a ferramenta Package Deployer. Essa ferramenta evita duplicatas usando condições de exclusividade que foram definidas para cada entidade, com base em uma combinação de campos. Se um registro correspondente for encontrado, ele será atualizado, caso contrário, um novo registro será criado.
Elementos importantes para analisar em relação aos dados de referência
Há um conhecimento claro do que constitui os dados de referência da solução?
Está claro o que é a cópia mestra dos dados de referência e onde ela será armazenada e rastreada?
Há um plano de gerenciamento dos dados de referência entre ambientes?
Package Deployer
Outra ferramenta útil para o gerenciamento de lançamento e implantação é o Package Deployer. Com ele, você pode criar um pacote que inclui várias soluções, os dados da ferramenta de migração de configuração e a lógica de código do desenvolvedor que é executada antes e depois do término da importação do pacote. Em muitos aspectos, você pode pensar no Package Deployer como um assistente de instalação do Microsoft Power Platform. É possível executar o Package Deployer de modo interativo para importar manualmente os pacotes e os dados para um ambiente. O Package Deployer também pode ser executado usando o PowerShell, que permite a automação e a integração com o Azure Pipeline.
Elementos importantes para analisar em relação ao Package Deployer
- A equipe considerou a utilidade do Package Deployer em sua estratégia de implantação?
Pipelines de lançamento
Anteriormente nesta unidade, falamos sobre a automação do processo de build, que prepara a solução para implantação e a cria como um artefato de build. O Azure Pipeline também apoia o conceito de pipelines de lançamento para gerenciar o lançamento em um ou mais ambientes. Os pipelines de lançamento têm a finalidade de implantar os artefatos de build (por exemplo, um arquivo de solução gerenciada) em ambientes de teste ou de produção. Os pipelines de lançamento podem incorporar processos de aprovação entre cada um dos ambientes. É possível usar as aprovações para coordenar a decisão de lançamento de vários participantes à medida que o lançamento avança pelas camadas dos ambientes.
Elementos importantes para analisar em relação aos pipelines de lançamento
O Azure Pipeline ou uma ferramenta semelhante é usada para implantar as soluções criadas entre os ambientes?
Como as aprovações serão processadas à medida que a implantação avançar entre os ambientes?
Modelo de execução
Agora é o momento de analisar a estratégia após a ativação. Supomos que você já tenha feito a implantação inicial e agora vai trabalhar na implantação e fazer melhorias. Como são os usuários que utilizam o que você criou, eles identificam funcionalidades que desejam alterar ou aperfeiçoar para aumentar a produtividade. A equipe de projeto deve ter uma ferramenta disponível para capturar essas solicitações de alteração e uma maneira de avaliar, priorizar e categorizar essas solicitações em atualizações.
Por exemplo, essas alterações podem ser facilmente agrupadas em três categorias: crítica, secundária e importante.
Ao pensar em como gerenciar suas alterações contínuas, é necessário ter processos em vigor para lidar com pelo menos esses três tipos de mudanças. Por exemplo, as alterações críticas devem ter uma forma de implantação quase imediata, já que elas impedem os usuários de concluir seu trabalho. Normalmente, elas não podem esperar por uma implantação semanal; portanto, você precisa de uma maneira de resolvê-las em produção, sem esperar por uma compilação planejada e pela implantação da próxima atualização agendada. É importante ter um processo para resolver esses problemas críticos, já que você deseja evitar ter que fazer alterações no ambiente de produção para solucionar o problema.
Elementos importantes para analisar em relação à estratégia após a ativação
A estratégia de ramificação de controle do código-fonte e do ambiente permite a implantação imediata de correções críticas?
Existe um plano para colocar todos os registros acumulados de problemas anteriores à ativação em um ciclo de manutenção e de aprimoramento?
Há um controle de alterações disponível para rastrear e fazer a triagem dos problemas identificados no aplicativo em operação?
Há um processo para garantir que as correções críticas feitas rapidamente sejam incorporadas ao processo de lançamento normal?
Ciclo de atualização da Microsoft
Além das atualizações que sua equipe cria para melhorar ou corrigir problemas, a Microsoft também faz o mesmo com os aplicativos do Microsoft Power Platform e do Dynamics 365. A Microsoft costuma lançar atualizações semanais que normalmente não interrompem a experiência do usuário. Essas atualizações são distribuídas usando uma prática de implantação segura que tenta minimizar qualquer impacto em seus ambientes. Você pode controlar quando essas atualizações são aplicadas ao seu ambiente de produção por meio da ferramenta de Administração.
A maioria das alterações nos aplicativos do Dataverse e do Dynamics 365 é distribuída por região. Para garantir que não haja efeitos adversos em suas personalizações, uma estratégia é testá-las em um ambiente que resida em uma região que receba as atualizações antes da sua e executar testes automatizados para identificar quaisquer problemas. Mesmo que isso não seja viável, você ainda pode executar testes automatizados semanais para funcionalidades críticas para garantir que suas personalizações não sejam afetadas negativamente.
No momento, duas vezes por ano (abril e outubro), a Microsoft lança atualizações que são mais significativas e pode incluir alterações que possam causar interrupção na experiência do usuário do aplicativo existente. Essas atualizações são planejadas e anunciadas seguindo um plano de lançamentos publicado com os detalhes das alterações futuras. Isso acontece vários meses antes que a atualização seja de fato aplicada automaticamente.
Como parte do processo que leva à atualização automática, os ambientes podem ter as alterações habilitadas manualmente pelos administradores antes de serem aplicadas automaticamente a todos os ambientes. Dessa forma, você pode copiar um ambiente de produção para um ambiente de área restrita que não seja de produção e testar as alterações antes de serem implantadas na produção. Quando o teste é bem-sucedido, ele permite que você opte pelas alterações de acordo com sua própria agenda, em vez de aguardar as atualizações automáticas.
Elementos importantes para analisar em relação aos ciclos de atualização
A equipe avaliou se é necessário fazer testes semanais e tem planos disponíveis?
O cliente sabe como funciona o processo de atualização e como ele pode aceitar testes antecipados duas vezes por ano?
Gerenciamento de capacidade
O gerenciamento de capacidade é importante antes da implantação e também para gerenciar o uso depois que o projeto entra em vigor. O armazenamento é o elemento fundamental do gerenciamento de capacidade, mas ele também envolve outros aspectos. Outra capacidade importante para monitorar são as solicitações de API. Você precisa garantir o cumprimento das suas alocações de licença e, quando necessário, adicionar solicitações de API complementares. Outros produtos e complementos, incluindo o AI Builder e o Power Virtual Agents, também têm capacidade que você deve considerar em sua tarefa de gerenciamento de capacidade geral.
Do ponto de vista da capacidade de armazenamento, a do Dataverse é dividida em banco de dados, log e arquivo. Cada uma delas é rastreada, e é possível adicionar armazenamento individualmente com base no uso real. Para criar ambientes em seu locatário, você deve ter pelo menos um GB de capacidade de banco de dados restante. É importante considerar isso porque, à medida que você cria sua estratégia de ALM, ela incluirá vários ambientes. Se a sua estratégia de ALM envolve ambientes temporários, eles apenas consumirão a capacidade quando estiverem realmente em uso. No entanto, para criá-los usando um processo automatizado, a capacidade deve estar disponível no momento em que a automação é executada, caso contrário, a automação falhará.
Para a capacidade de banco de dados, você deve estimar a capacidade inicial com base nos dados que serão migrados para o Dataverse quando entrar em produção. Isso inclui os dados que podem existir também nos ambientes que não sejam de produção. Uma primeira etapa importante neste processo é saber o número de registros que você tem por entidade. Assim que você puder migrar parte dos seus dados, poderá começar a receber insights extrapolando a carga de dados de tamanho máximo, com base no exemplo carregado no Dataverse. Quando você conseguir fazer uma carga completa dos dados que planeja migrar, deverá conseguir obter informações de dimensionamento para esse ambiente. O Centro de administração do Microsoft Power Platform oferece ferramentas para você analisar o uso do armazenamento das principais entidades. Além da capacidade inicial, é importante considerar o crescimento contínuo à medida que sua solução é executada em um ambiente ativo. Saber a taxa de crescimento das entidades principais pode ajudar você a determinar as necessidades de capacidade continuamente.
O uso da capacidade de arquivo depende do quanto você usa anexos e tipos de dados de arquivo de imagem em registros. A capacidade de arquivo também é usada se você tem um ou mais aplicativos do Insights instalados. Estimar o armazenamento é como a capacidade do banco de dados, e é essencial saber o número de registros e o tamanho médio dos arquivos desses registros.
O uso da capacidade de log depende se você usa o recurso de auditoria e de rastreamento de plug-in. Mesmo que use alguma capacidade, a auditoria é um recurso valioso que deve ser habilitado. A auditoria é controlada no nível do ambiente, da entidade e do campo e deve ser habilitada quando houver necessidade. A auditoria é importante em cenários de negócios para saber quem fez qual alteração e para solucionar desafios do sistema. Aproveite o recurso que permite definir um período de retenção se ele atender às suas necessidades de negócios.
Você pode monitorar o uso do armazenamento no Centro de Administração do Microsoft Power Platform. Para obter mais informações, veja Análise do Dataverse.
Elementos importantes para analisar em relação à capacidade
A equipe tem um bom conhecimento do volume de registros por entidade?
Há um plano para monitorar a capacidade após a ativação inicial para garantir que a capacidade adequada seja provisionada?
Gerenciamento de capacidade de solicitações de API
As solicitações de API incluem todas que são provenientes dos conectores, todas as ações das etapas do Power Automate e o uso das APIs do Dataverse. Uma lista completa do que é considerado está disponível em Limites e alocações de solicitações. Cada licença que você tem do Power Apps, do Power Automate e do Dynamics 365 oferece uma alocação de solicitações de API por 24 horas. Geralmente, a alocação licenciada inclui muitas solicitações de API para uso normal dos aplicativos licenciados. Se você exceder suas alocações regularmente, poderá comprar mais solicitações de API por meio do licenciamento de complementos. A causa mais comum de excedente são as integrações ou a lógica personalizada ao realizar processamentos em massa. Em geral, elas podem ser ajustadas para um processamento mais eficiente para evitar o excesso de solicitações de API. Os arquitetos de soluções devem prestar mais atenção a esses tipos de processos para garantir a otimização do uso da API o máximo possível.
Além do rastreamento da alocação de solicitações de API, o Dataverse também implementa limites de proteção de serviço. Eles foram projetados para garantir a disponibilidade e o desempenho consistentes a todos os usuários do serviço. Novamente, o uso normal não deve disparar a proteção de serviço. No entanto, as integrações de alto volume podem ocasionalmente encontrar erros causados pelo disparo da proteção de serviço. Os limites de proteção de serviço são avaliados a cada cinco minutos usando uma janela deslizante. O uso avaliado é o número de solicitações enviadas por um usuário, o tempo de execução combinado das solicitações e as solicitações simultâneas feitas por um usuário.
Os limites de proteção de serviço não podem ser substituídos pela compra de mais alocações de licença e devem ser resolvidos nos aplicativos por uma lógica de repetição apropriada. Você pode ler mais sobre os limites de proteção de serviço e como resolver repetições em Limites da API de proteção de serviço.
Elementos importantes para analisar em relação a solicitações de API
A equipe identificou todos os possíveis pontos de acesso de solicitações de API que podem causar problemas?
A lógica de repetição foi adicionada a todas as integrações ou ao trabalho de API em massa?
Há um plano para monitorar o uso da API e ajustar a capacidade conforme necessário?