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:

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

Múltiplas soluções num único 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 a média escala com áreas funcionais distintas e independentes que não partilham componentes.

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 mais informações, consulte Camadas de solução e comportamento de fusão.

O que precisa de saber antes de trabalhar com múltiplas soluções no mesmo ambiente

Siga estas práticas ao trabalhar com múltiplas soluções não geridas num único ambiente de desenvolvimento:

• Utilize apenas um fabricante 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 importar uma tabela personalizada gerida através da Solução A com o Publisher X, não pode depois mover essa tabela para a Solução B com o Publisher Y. A única opção é eliminar a tabela, atualizar a Solução A para remover a tabela do sistema de destino, depois recriar a tabela na Solução B com o Publisher Y e importar a Solução B. Este processo de remoção resulta na perda de todos os dados armazenados na tabela personalizada, a menos que a migre antecipadamente.
• Utilize uma única solução não gerida no seu ambiente de desenvolvimento. Se precisar de personalizar um componente gerido a partir de outra solução gerida, adicione o componente à sua solução não gerida. Para personalizar o componente gerido, as propriedades geridas devem ser definidas como personalizáveis. Em seguida, exporte a solução não gerida como gerida para implementação noutros ambientes. Para mais informações, consulte Propriedades Geridas.
• Se usares várias soluções, não incluas o mesmo componente não gerido em mais do que uma solução.
• Se utilizar várias soluções, tenha apenas uma solução que inclua todas as tabelas Não tenha duas soluções diferentes onde ambas contêm tabelas. Esta condição existe porque há frequentemente riscos associados a uma relação única entre tabelas, o que cria uma dependência entre soluções e causa problemas de atualização ou eliminação de soluções no ambiente de destino posteriormente.
• Se usares várias soluções, evita 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 importar apenas a solução cloud flow para o ambiente de destino, o processo de importação pode não reconhecer a dependência da coluna personalizada. Como resultado, a solução de fluxo instala-se com sucesso, mas o fluxo não funciona. Para mais informações, veja Exemplos de dependências criadas por múltiplas soluções.

O que evitar ao trabalhar com múltiplas soluções no mesmo ambiente

Aqui está um exemplo em que a plataforma não permite desinstalar nem atualizar nenhuma das soluções geridas porque as duas soluções de fabricantes diferentes tentam atualizar o mesmo componente. A situação:

• Duas soluções geridas de diferentes fornecedores estão instaladas no mesmo ambiente.
• Pelo menos um componente (Componente 1) pertence ao Publisher A mas é alargado pelo Publisher B. A solução do Publisher A é a camada base desse componente, e a solução do Publisher B assenta por cima dele.
• Pelo menos outro componente (Componente 2) pertence ao Publisher B e é expandido pelo Publisher A. Esta condição é o inverso do ponto anterior.

Este problema ocorre porque apresenta uma dependência circular do componente com ambas as soluções e a plataforma não permite desinstalar ou atualizar o componente. Neste exemplo:

• O Sol A não pode ser desinstalado porque possui o Componente 1 e há uma personalização por cima de uma solução pertencente ao Publisher B. Para desinstalar o Sol A tem primeiro de desinstalar o Sol B.
• O Sol B não pode ser desinstalado porque possui o Componente 2 e há uma personalização por cima de uma solução pertencente ao Publisher A. Para desinstalar o Sol B, tem primeiro de desinstalar o Sol A.

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.

Múltiplas soluções com múltiplos 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.

Como criar a camada da sua solução

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.
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.

Artigos relacionados

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