Partilhar via

Organizar as suas soluções

Antes de criar soluções, reserve algum tempo para planejar com antecedência sua estratégia de ambiente e sua estratégia de solução. Considere os seguintes aspetos:

Aspeto Consideração
Âmbito de aplicação Sua implementação abrange vários aplicativos, como Vendas, Atendimento ao Cliente, Field Service, Finanças, etc.?
Cadência de lançamento Com que frequência você planeja implantar atualizações na produção?
Sua metodologia de entrega é baseada em práticas ágeis como ciclos de sprint?
Apoio à produção Como você lida com correções urgentes na produção sem introduzir novos recursos prematuramente?
Arquitetura de soluções Quantas soluções gerencia?
Estas soluções partilham componentes ou dependem umas das outras?
Planeamento do ambiente Quantos ambientes Microsoft Dataverse você precisa para dar suporte ao seu ciclo de vida de desenvolvimento?
Você precisa de ambientes separados para desenvolvimento, teste e produção?
Os desenvolvedores trabalham de forma colaborativa em um ambiente compartilhado ou exigem ambientes isolados para trabalhar de forma independente?

As seções a seguir descrevem três estratégias, organizadas das mais simples às mais complexas, e destacam suas respetivas vantagens e desvantagens.

Estratégia de solução única

Todas as personalizações são agrupadas em uma solução não gerenciada durante o desenvolvimento, que é posteriormente exportada como uma única solução gerenciada para implantação.

Recomendado para:

  • Implementações de pequena e média escala
  • Cenários em que a modularização futura é improvável
Vantagem Desvantagem
Configuração e gerenciamento simplificados de ambientes. Requer mais esforço para dimensionar ou modularizar mais tarde, se necessário.
Implantação simplificada. Com apenas uma solução para gerenciar, exportar e importar entre ambientes é simples e menos propenso a erros. Uma única solução contendo um grande número de personalizações pode resultar em tempos de implantação mais longos. Para reduzir o tamanho da solução, use a segmentação de tabela. Para reduzir os tempos de importação, vá para recomendações de desempenho.
Mais fácil de localizar, auditar e gerenciar alterações. Quando vários programadores trabalham no mesmo ambiente de desenvolvimento, correm o risco de sobrescrever as alterações dos outros. Esse risco pode ser reduzido implementando o versionamento do código-fonte, adotando uma estratégia de ramificação e usando um ambiente de desenvolvimento dedicado para cada ramificação. O controle de versão do código-fonte e a estratégia de ramificação fornecem controle de alterações, suporte à colaboração e mecanismos de resolução de conflitos. Mais informações: Adote uma estratégia de ramificação Git.

Nota

Melhorias recentes no Microsoft Power Platform reduziram os tempos de importação para soluções gerenciadas, incluindo aquelas que usam a opção de atualização. Essas otimizações incluem melhor manuseio de dependências de componentes e redução de sobrecarga para componentes inalterados. Para saber como beneficiar-se dessas melhorias, vá para Recomendações de Desempenho.

Várias soluções no mesmo ambiente de desenvolvimento

Várias soluções não gerenciadas são mantidas em um único ambiente de desenvolvimento, cada uma normalmente dedicada a recursos ou módulos não relacionados.

Recomendado para:

  • Implementações de pequena e média escala com áreas funcionais distintas e independentes que não compartilham componentes.
Vantagem Desvantagem
Configuração e gerenciamento simplificados de ambientes. A manutenção de várias soluções não gerenciadas no mesmo ambiente de desenvolvimento aumenta a probabilidade de conflitos de dependência. Por exemplo, você pode encontrar uma situação em que a Solução A não pode ser importada porque depende da Solução B, enquanto a Solução B não pode ser importada porque depende da Solução A.
As áreas funcionais podem ser implantadas independentemente umas das outras. Vários desenvolvedores que trabalham no mesmo ambiente de desenvolvimento podem sobrescrever as alterações uns dos outros. Trabalhar em uma solução não gerenciada não fornece isolamento. Todas as modificações são aplicadas diretamente ao ambiente, independentemente da solução que está sendo editada.

Nota

Quando você tem várias soluções no mesmo ambiente de desenvolvimento, depois de importar as soluções gerenciadas para o ambiente de destino, geralmente está criando camadas. Para obter mais informações: Camadas de solução e comportamento de mesclagem

É importante que você:

  • Não inclua o mesmo componente não gerenciado em mais de uma solução.
  • Tenha apenas uma solução que inclua todas as suas tabelas. Não tenha duas soluções diferentes onde ambas contêm tabelas. Isto porque existem frequentemente riscos de uma relação única entre tabelas, o que cria uma dependência de soluções cruzadas e provoca problemas atualização de versão ou de eliminação da solução posteriormente.
  • Use apenas um fornecedor de soluções. O editor da solução possui os componentes de uma solução gerenciada e sua associação não pode ser alterada posteriormente. Por exemplo, se uma tabela personalizada for importada como gerenciada por meio da Solução A com o Publisher X, você não poderá movê-la posteriormente para a Solução B com o Publisher Y. A única opção é excluir a tabela, atualizar a Solução A para remover a tabela do sistema de destino e, em seguida, recriar a tabela na Solução B com o Editor Y e importar a Solução B. Esse processo resulta na perda de todos os dados armazenados na tabela personalizada, a menos que sejam migrados previamente.
  • Evite criar dependências entre soluções. As dependências impõem uma ordem de importação e podem causar problemas. Por exemplo, se tiver uma solução para tabelas e outra para fluxos de cloud, e um fluxo depender de uma coluna personalizada, funciona em desenvolvimento porque a coluna existe. No entanto, se apenas a solução de fluxo de nuvem for importada para o ambiente de destino, o processo de importação pode não reconhecer a dependência na coluna personalizada. Como resultado, a solução de fluxo é instalada com êxito, mas o fluxo em si não funciona. Para obter mais informações: Exemplos de dependências criadas por várias soluções

Exemplos de dependências criadas por várias soluções

  • Frisos de aplicação. Quando várias soluções modificam a faixa de opções do aplicativo ou o mapa do site do mesmo aplicativo.
  • Plugins ou fluxos na nuvem. Se o plug-in ou fluxo for acionado numa coluna personalizada ou atualizar uma tabela personalizada, o objeto irá depender dessas tabelas personalizadas.
  • Funções de segurança. Quando existem tabelas personalizadas, as funções de segurança normalmente dependem dessas tabelas para acesso do usuário.

Várias soluções com ambientes de desenvolvimento dedicados

Essa estratégia envolve o desenvolvimento de cada solução não gerenciada em seu próprio ambiente de desenvolvimento Dataverse isolado. Essa estratégia é comumente usada em arquiteturas modulares onde, por exemplo, diferentes aplicativos — como Vendas, Atendimento ao Cliente ou Field Service — são criados e mantidos de forma independente. Uma solução base contendo componentes comuns (por exemplo, tabelas de contas e contatos) é criada e implantada como uma solução gerenciada em cada ambiente de desenvolvimento específico do aplicativo. Cada aplicação tem a sua própria solução não gerida, em camadas sobre a solução gerida base, permitindo que as equipas estendam a funcionalidade sem alterar a base.

Recomendado para:

  • Projetos empresariais de grande escala.
  • Equipas com vários programadores ou parceiros
  • Cenários que exigem governação rigorosa e pipelines de CI/CD.
Vantagem Desvantagem
Mais fácil de crescer e evoluir o seu sistema adicionando ou atualizando módulos sem afetar outros. Maior infraestrutura e despesas gerais de manutenção.
Várias equipes podem trabalhar em paralelo em diferentes módulos sem entrar em conflito com as mudanças umas das outras. Requer uma estratégia ambiental e uma governação sólidas.
Mais fácil de implementar testes automatizados e práticas de DevOps. Implantação mais complexa.
Soluções menores são mais rápidas de implantar, especialmente em pipelines de CI/CD se você precisar implantar apenas um aplicativo específico.
Erros ou regressões são mais fáceis de rastrear quando as alterações estão isoladas em módulos específicos.

Como criar a camada da sua solução

Nota

Antes de criar as soluções nas etapas a seguir, use o mesmo editor para todas as suas soluções em seus ambientes. Mais informações: Fabricante de soluções

  1. No ambiente de desenvolvimento "base", você tem sua solução base com as tabelas não gerenciadas comuns e nenhuma outra tabela. Em seguida, exporte esta solução como gerida.
  2. Você configura um segundo ambiente de desenvolvimento para a extensão ou camada "app" que mais tarde residirá na parte superior da camada base.
  3. Você importa a camada base gerenciada para o ambiente de desenvolvimento da camada de aplicativo e cria uma solução não gerenciada para a camada de aplicativo. Camadas de solução adequadas utilizando múltiplas soluções com vários ambientes.
  4. Agora você pode estender o modelo de dados adicionando tabelas, colunas, relações de tabela, plugins, fluxos e assim por diante adicionais à solução específica de "aplicativo". Em seguida, exporte a solução de aplicações como gerida. Observe que a solução do aplicativo ainda depende da solução de camada base, mas gerenciar várias soluções dessa maneira é uma abordagem melhor. Considere o exemplo mencionado anteriormente do fluxo que depende de uma coluna personalizada. Na maioria dos casos, a coluna personalizada e o fluxo residem na mesma solução de aplicativo. Mas mesmo que a coluna personalizada faça parte da solução base, você deve concluir e implantar essa solução base como gerenciada primeiro, caso contrário, o fluxo dentro da solução de aplicativo não poderá ser criado.
  5. No seu ambiente de produção, importa a camada base gerida e, em seguida, importa a camada de aplicações gerida. Isso cria duas camadas gerenciadas no ambiente com dependências claras entre as soluções gerenciadas.
  6. Repita este padrão para ter tantas soluções diferentes quanto precise manter. Embora recomendemos que mantenha o número de soluções o mais pequena possível para manter a sua solução em camadas manejáveis.

Usar segmentação de tabela
Cenário 5: Suportar desenvolvimento de equipa

  • Last updated on