Soluções gerenciadas vs. não gerenciadas no Power Platform: o guia completo

By Mirko Peters · 2026-10-21

Saiba as diferenças essenciais entre soluções gerenciadas e não gerenciadas do Power Platform, as regras de implantação e as melhores práticas de ALM para os seus aplicativos.

Automatically translated with AI from the original post. Read the English original

Entender a diferença entre soluções gerenciadas e não gerenciadas do Power Platform é essencial para evitar exclusões catastróficas de aplicativos e implantações com falha. Este guia explica como as camadas não gerenciadas funcionam como o seu espaço de trabalho editável, enquanto as soluções gerenciadas servem como pacotes congelados e implantáveis entre os ambientes de desenvolvimento, teste e produção.

Principais conclusões

• As soluções não gerenciadas são a sua cópia de trabalho nos ambientes de desenvolvimento, onde você cria, edita e experimenta ativamente.
• As soluções gerenciadas são cópias congeladas e implantáveis, destinadas estritamente aos ambientes de teste e produção para manter a estabilidade.
• Excluir uma solução não gerenciada remove apenas o contêiner e mantém os componentes intactos, enquanto desinstalar uma solução gerenciada apaga as tabelas personalizadas e os dados associados.
• Você não pode importar uma solução gerenciada de volta para o mesmo ambiente de desenvolvimento onde a sua solução não gerenciada original foi criada.
• Tratar as soluções não gerenciadas como código-fonte e as soluções gerenciadas como artefatos de compilação alinha o seu ALM do Power Platform às práticas padrão de desenvolvimento de software.

As principais diferenças entre soluções gerenciadas e não gerenciadas

Quando você começa a criar aplicativos, fluxos e tabelas no Microsoft Power Platform, é fácil tratar os ambientes como grandes blocos de rascunho digitais. Você clica em vários pontos, cria entidades personalizadas e monta fluxos de nuvem diretamente em um espaço de trabalho padrão ou compartilhado. No entanto, quando o projeto passa da fase de prova de conceito, essa abordagem descuidada rapidamente leva a códigos difíceis de manter e à perda acidental de dados. Para criar aplicativos confiáveis, você precisa dominar a divisão fundamental entre soluções não gerenciadas e gerenciadas.

Em sua essência, uma solução é simplesmente um contêiner, um manifesto de embarque que reúne os componentes do seu aplicativo para que possam se mover com segurança entre os ambientes. Mas dentro desse modelo de contêiner existe uma dicotomia rigorosa: não gerenciada versus gerenciada. Lembrar esta frase simples ajuda a esclarecer as finalidades distintas de cada uma: não gerenciada é para editar aqui, enquanto gerenciada é para implantar lá.

Soluções não gerenciadas: o seu espaço de trabalho de desenvolvimento

Uma solução não gerenciada é a sua cópia de trabalho ativa e editável. Sempre que você estiver criando uma aplicação de tela, escrevendo regras de negócio ou modificando tabelas do Dataverse, estará trabalhando dentro de uma solução não gerenciada no seu ambiente de desenvolvimento. Cada ajuste, mudança de cor e alteração de esquema é aplicado imediatamente ao aplicativo subjacente.

O que acontece quando você exclui uma solução não gerenciada?

Uma das características de segurança mais importantes das soluções não gerenciadas é a forma como lidam com a exclusão. Se você excluir uma solução não gerenciada do seu ambiente de desenvolvimento, apenas o próprio contêiner desaparece. As personalizações, aplicativos e tabelas que você criou não são apagados; em vez disso, passam silenciosamente para a solução padrão. Embora isso evite a destruição total acidental durante o desenvolvimento, pode deixar o seu espaço de trabalho padrão desorganizado se você não tomar cuidado.

A Microsoft recomenda que você armazene suas soluções não gerenciadas diretamente em sistemas de controle de código-fonte, como GitHub ou Azure DevOps. Ao tratar a solução não gerenciada como o verdadeiro repositório do código-fonte, você mantém um registro histórico completo e auditável de cada alteração feita pela sua equipe de desenvolvimento.

Soluções gerenciadas: seu pacote de implantação para produção

As soluções gerenciadas representam a cópia final, compilada e congelada da sua aplicação. Você não edita uma solução gerenciada diretamente; em vez disso, exporta a solução não gerenciada como gerenciada e implanta esse pacote em ambientes posteriores, como os de UAT (User Acceptance Testing, teste de aceitação do usuário), SIT (System Integration Testing, teste de integração do sistema) e, por fim, produção.

A realidade de alto risco da exclusão de soluções gerenciadas

Diferentemente das suas equivalentes não gerenciadas, as soluções gerenciadas são bastante travadas por design. Você não pode editar componentes diretamente dentro de uma solução gerenciada. Mais importante ainda, desinstalar uma solução gerenciada gera o comportamento exatamente oposto ao de uma não gerenciada: como tudo o que está no pacote está vinculado àquela implantação específica, remover a solução elimina todos os seus componentes.

Um ponto crucial: essa remoção na desinstalação inclui quaisquer dados armazenados em tabelas personalizadas que faziam parte da solução, assim como dados armazenados em colunas personalizadas adicionadas a tabelas existentes. Depois que uma solução gerenciada é desinstalada de um ambiente, esses dados associados são perdidos permanentemente. Não existe um botão nativo de desfazer, o que torna a compreensão da arquitetura de implantação uma responsabilidade administrativa crítica.

Arquitetura de ambientes e regras de teste

A mecânica técnica do Power Platform impõe limites rígidos entre ambientes quanto à forma como você trata esses dois tipos de solução. Por exemplo, você não pode importar uma solução gerenciada de volta para o mesmo ambiente de desenvolvimento que contém a solução não gerenciada da qual ela foi criada. Testar uma implantação gerenciada exige um ambiente completamente separado, e é por isso que as boas práticas recomendam configurar um pipeline dedicado com múltiplos ambientes desde o início.

Uma configuração saudável de ALM (Application Lifecycle Management, gerenciamento do ciclo de vida de aplicações) consiste em pelo menos três ambientes distintos:

• Desenvolvimento: onde os criadores constroem e modificam soluções não gerenciadas.
• Teste (UAT): onde você importa a solução gerenciada para comprovar que tanto o processo de implantação quanto a funcionalidade do aplicativo funcionam corretamente.
• Produção: onde os usuários reais dependem, todos os dias, da solução gerenciada estável e congelada.

Dominando sua estratégia de implantação no Power Platform

Adotar uma separação rigorosa entre os espaços de desenvolvimento não gerenciados e as implantações gerenciadas de produção transforma sua estratégia no Power Platform de um conjunto de gambiarras frágeis em engenharia de software de nível empresarial. Ao respeitar os limites das soluções, proteger seus ambientes de produção contra edições ad hoc e manter hábitos sólidos de controle de código-fonte, você garante que suas aplicações críticas para o negócio permaneçam estáveis e resilientes à medida que crescem.

Para se aprofundar ainda mais na mecânica dos componentes do Power Platform, publishers, prefixos e camadas de solução, não deixe de ouvir o episódio completo e assinar o podcast para acompanhar conteúdos contínuos sobre o ecossistema da nuvem Microsoft.