Desenvolver uma estratégia de ambiente do locatário para adotar o Power Platform em escala

A jornada de cada organização para adoção ao Microsoft Power Platform é única. Uma estratégia de ambiente do locatário estabelece as bases para ajudar a acelerar o uso de forma gerenciável e segura.

Este artigo mostra como alinhar a estratégia de ambiente do locatário do Power Platform com os recursos e a visão do produto. Você aprende a usar melhor os recursos mais recentes da plataforma para implementar uma estratégia que possa permitir sua adoção do Power Platform para atingir a escala corporativa.

Introdução

O Power Platform capacita as organizações a criar soluções low-code para inovação rápida. Essas soluções podem se concentrar na produtividade de indivíduos e pequenas equipes ou serem aplicadas em toda a organização. Também podem se estender a processos empresariais, incluindo clientes e parceiros externos. O suporte a essas soluções são ambientes do Power Platform onde os recursos low-code são criados, testados e usados. À medida que uma organização aumenta sua adoção do Power Platform, implementar uma boa estratégia de ambiente de locatário é essencial para torná-la gerenciável e segura, à medida que o número de ambientes cresce.

Para ajudá-lo a ter mais sucesso, este artigo orienta você sobre a melhor forma de usar os recursos disponíveis para estabelecer sua primeira estratégia de ambiente ou desenvolver seus planos atuais. Também descrevemos nossa visão de como esses recursos devem funcionar juntos e como eles evoluirão para gerenciamento do Power Platform em escala. Nesta diretriz, estabelecemos como rotear adequadamente novos usuários para ambientes e ambientes de grupo para aplicar consistentemente governança, regras de segurança e outros aspectos importantes de uma estratégia de ambiente de locatário. Também fornecemos etapas detalhadas para proteger seu ambiente padrão, o que é um primeiro passo crítico na implementação de uma estratégia de ambiente.

Embora muitas perspectivas estejam disponíveis para o gerenciamento de ambientes do Power Platform, a abordagem neste artigo se alinha com a direção de produto mais recente da Microsoft e usa recursos atuais e aprimoramentos planejados de curto prazo. Esta diretriz atualizada pode ajudá-lo a garantir que você use apenas os recursos e opções de ambiente que são estratégicos para a forma como a Microsoft pretende que você gerencie ambientes em escala.

Visão da estratégia de ambiente de locatário da Microsoft

Muitas organizações iniciam a jornada do Power Platform com aplicativos e automações de produtividade pessoal compilados e em execução em um ambiente central compartilhado chamado ambiente padrão. Esses recursos geralmente usam apenas os recursos básicos incluídos no Microsoft 365 e não usam os recursos do Power Platform completos. À medida que essa adoção inicial se acelera, a Microsoft fornece às organizações um acesso a uma estratégia de ambiente para adoção em escala empresarial de todos os recursos do Power Platform. Esses recursos de governança premium tornam-se disponíveis quando os usuários têm uma licença premium do Power Platform (Power Apps, Power Automate, Microsoft Copilot Studio e do Dynamics 365). O modelo de maturidade da adoção do Power Platform oferece mais insights para ajudar organizações a definir o roteiro a fim de alcançar a adoção de escala empresarial além da estratégia de ambiente. Essa abordagem pode ajudar as organizações a amadurecer da produtividade pessoal básica para a adoção em escala empresarial do Power Platform.

Os recursos administrativos, de governança e de segurança do Power Platform permitem que as organizações adotem e gerenciem o Power Platform para produtividade corporativa e o uso de aplicativos corporativos em escala. O uso de Ambientes Gerenciados ativa um conjunto de recursos premium que permitem maior visibilidade e controle e reduzem o esforço manual para administrar e proteger ambientes. Usando esses recursos, você pode garantir a aplicação consistente de suas políticas de governança e segurança. Os administradores podem fazer a transição para uma estratégia de ambiente em escala empresarial usando esses recursos. Gastar menos tempo e esforço na administração ajuda a reduzir o custo total de propriedade (TCO) geral da plataforma, à medida que sua organização dimensiona o uso.

Um elemento-chave da transição para a escala corporativa é aprimorar a estratégia de ambiente compartilhado e central para os criadores, facilitando o uso de ambientes pessoais de desenvolvimento. Em uma estratégia de ambiente central compartilhado, os criadores criam, usam e compartilham aplicativos no ambiente padrão. Essa estratégia pode resultar na falta de isolamento e na invasão dos criadores uns aos outros. Imagine se todos na empresa compartilhassem uma única pasta do OneDrive para todos os documentos. Em vez disso, use recursos de ambiente para guiar os criadores para seus próprios ambientes pessoais, onde eles podem criar seus aplicativos com segurança, protegidos de criadores que trabalham em ativos não relacionados, com governança simplificada para administradores. Os colegas de trabalho podem ser adicionados como mais criadores a esses ambientes para colaborar na criação de soluções.

Figura: Ilustração de um ambiente central compartilhado (esquerda) e uma estratégia de roteamento de ambiente (direita).

Os ambientes do criador recém-criados podem ser adicionados automaticamente a um grupo que aplica regras para garantir que os ambientes tenham políticas de governança e segurança consistentes. Os administradores podem lidar com exceções movendo o ambiente de um criador para um grupo com regras flexíveis.

Os recursos low-code elaborados pelos criadores representam o estágio inicial na jornada de gerenciamento do ciclo de vida do aplicativo (ALM) de um recurso. Como parte desse estágio inicial, é importante capturar cada versão de um recurso e poder recriá-lo, se necessário. Quando o recurso estiver pronto para ser compartilhado, o criador pode usar a integração contínua anexada ao ambiente do desenvolvedor para promovê-lo para um ambiente de produção. Os usuários podem então executar o recurso, isolados de qualquer atividade em andamento do criador.

Priorize os recursos integrados da plataforma para gerenciar ambientes sempre que possível, em vez de criar suas próprias ferramentas. Se os recursos integrados não atenderem aos requisitos específicos da sua organização, use as ferramentas de administração da plataforma para criar ferramentas personalizadas. Você deve avaliar qualquer ferramental personalizado em relação a novos recursos, à medida que ele for disponibilizado. Monitorar o roteiro da plataforma da Microsoft e alinhá-lo com o seu próprio roteiro torna esse processo mais fácil.

Estabeleça sua estratégia ambiental usando os recursos ambientais recomendados e adaptados às necessidades exclusivas da sua organização. Não pense em criar sua estratégia de ambiente como uma atividade única. Ele deve evoluir com o passar do tempo para incorporar novos recursos de ambiente, à medida que eles se tornam disponíveis.

Recursos que oferecem suporte a uma estratégia de ambiente em escala empresarial

Ambientes são um bloco de construção para administração, governança e segurança do Power Platform. Uma visão geral completa dos recursos está fora do escopo deste artigo; no entanto, esta seção destaca os recursos que dão suporte à implementação de uma estratégia de ambiente em escala empresarial.

• Tipos de ambientes descreve os diferentes usos de ambientes como parte de sua estratégia.
• Os Ambientes Gerenciados fornecem um conjunto de recursos premium que facilitam o gerenciamento dos ambientes em escala.
• A declaração automática da licença simplifica a atribuição de licenças permitindo aos usuários reivindicar licenças do Power Apps por usuário quando elas são necessárias, em vez de exigir que um administrador identifique usuários que precisem de licenças com antecedência.
• Grupos e regras de ambiente explica como gerenciar ambientes como grupos e aplicar regras a grupos para automatizar políticas de governança consistentes.
• O roteamento de ambiente padrão afasta automaticamente os criadores da criação de recursos no ambiente padrão para se tornarem seu próprio ambiente pessoal.
• Microsoft Dataverse fornece segurança aprimorada e ALM.
• As soluções preferidas ajudam os criadores a garantir que todos os ativos compilados estejam em uma solução do Dataverse, o que facilita a promoção deles para outros ambientes.
• Os Pipelines no Power Platform oferecem um processo simplificado para promover ativos desde o desenvolvimento até ambientes de produção e teste, disponibilizando a CI/CD (Integração e Implantação Contínuas) para todos os criadores.
• O Catálogo no Power Platform permite aos criadores compartilhar componentes, como aplicativos e fluxos, e pontos de partida mais avançados, como modelos.

Tipos de ambiente

A tabela a seguir descreve os tipos de ambientes que você pode criar, suas características e seus usos pretendidos.

Ao criar uma estratégia geral de ambiente para locatários, considere os diferentes tipos para dar suporte às suas recomendações.

Ambientes Gerenciados

Os ambientes têm um conjunto básico de recursos e características, dependendo do tipo de ambiente. Ambientes Gerenciados se expandem nos recursos base para fornecer um conjunto de recursos premium que permitem aos administradores gerenciar o Power Platform de forma mais fácil em escala com mais controle, menos esforço e mais insights. Esses recursos são desbloqueados quando você define um ambiente como gerenciado.

A tabela a seguir lista os recursos de Ambientes Gerenciados disponíveis no momento da redação deste artigo. Novos recursos são adicionados com frequência, portanto, verifique a documentação para obter a lista mais recente. Embora todos os recursos possam ajudar você a criar uma estratégia de ambiente, os recursos em itálico são mais relevantes para a estratégia descrita neste artigo.

Autodeclaração da licença

Políticas de declaração automática automatizam a atribuição de licenças do Power Apps e do Power Automate a usuários quando eles precisam de uma para usar determinados aplicativos ou recursos. A automação pode ajudar a reduzir o número de licenças consumidas e evitar a sobrecarga de atribuir licenças manualmente.

Depois que uma política for configurada, qualquer usuário da organização que precise de uma licença individual do Power Apps receberá uma licença automaticamente sob as seguintes condições:

• Se um usuário sem uma licença autônoma do Power Apps iniciar um aplicativo que exija uma licença premium, o sistema receberá automaticamente uma licença por usuário do Power Apps.

• Se um usuário sem uma licença autônoma do Power Apps iniciar um aplicativo em um Ambiente Gerenciado, o sistema receberá automaticamente uma licença por usuário do Power Apps.

Da mesma forma, depois que uma política for configurada, qualquer usuário da organização que precise de uma licença individual do Power Automate receberá uma licença automaticamente sob as seguintes condições:

• O usuário dispara, salva ou ativa um fluxo da nuvem premium com RPA (Automação Robótica de Processos) assistida.

• O usuário solicita uma licença do Power Automate Premium.

É recomendável configurar a autodeclaração da licença caso a estratégia de ambiente inclua Ambientes Gerenciados. Os usuários de aplicativos e fluxos encontram a menor quantidade de atrito de licenciamento e você só consome licenças para usuários que estão executando aplicativos ativamente ou usando o Power Automate.

Grupos e regras de ambiente

Conforme a adoção do Power Platform em seu locatário aumenta, também aumenta o número de ambientes que exigem administração e governança. À medida que o número de ambientes aumenta, mais desafiador se torna garantir que você tenha aplicado configurações e políticas de governança consistentes nos ambientes. O recurso de grupos de ambientes facilita isso, permitindo que você crie grupos nomeados e associe ambientes a eles, como a colocação de documentos relacionados em uma pasta de arquivos.

Tenha em mente as seguintes considerações ao pensar sobre o uso de grupos de ambientes:

• Um ambiente deve ser gerenciado para ser incluído em um grupo.
• Um ambiente pode estar em apenas um grupo por vez.
• Um ambiente pode ser movido de um grupo para o outro.
• Os ambientes em um grupo podem ser de várias regiões geográficas.
• Os grupos não podem conter outros grupos.

Para ajudá-lo a aplicar configurações e governança consistentes, os grupos de ambientes podem ter uma ou mais das seguintes regras configuradas e ativadas:

• Compartilhamento de controles para aplicativos de tela
• Insights de uso
• Conteúdo de boas-vindas para criadores
• Imposição do verificador de solução
• Retenção de backup
• Descrições geradas por IA

Uma regra torna-se ativa quando é publicada. As regras ativas são aplicadas a todos os ambientes associados ao grupo.

Quando uma regra de grupo estiver gerenciando uma configuração, as configurações de ambiente individuais serão bloqueadas. A única maneira de alterá-las é modificar a regra. Se o ambiente for removido do grupo, ele manterá as configurações do grupo, mas um administrador de ambiente poderá alterá-las. Essa abordagem é importante para uma estratégia de ambiente porque garante que um administrador de ambiente não possa substituir as políticas definidas para o grupo.

O uso de grupos de ambientes permite que você organize seus ambientes de maneiras lógicas, semelhantes à estrutura de sua organização, hierarquia de serviço de produto ou outras estruturas que exploraremos posteriormente. O diagrama a seguir é um exemplo conceitual de como a organização Contoso pode pensar em organizar seus grupos de ambientes.

Figura: Conceitualização de uma estratégia de ambiente de um locatário da Contoso.

Ao planejar as regras a serem configuradas, pense no que você pode aplicar em cada nível da hierarquia conceitual. Embora ainda não seja possível configurar a hierarquia de grupos, você pode usar uma combinação de convenções de nomenclatura e configuração de regras para implementar seu design conceitual. Por exemplo, dada a conceituação de locatário da Contoso mostrada anteriormente, a ilustração a seguir representa os grupos de ambientes que a organização poderia usar para implementar seu design.

Figura: exemplo de implementação dos grupos de ambientes conceituais no locatário real

Mais adiante neste artigo, exploraremos mais maneiras de usar grupos de ambientes como parte de uma estratégia de ambiente de locatário.

Roteamento de ambiente padrão

Uma parte fundamental da estratégia de ambiente que descrevemos neste artigo é afastar os criadores da criação de recursos no ambiente padrão. O recurso de roteamento do ambiente redireciona criadores para o ambiente de desenvolvimento pessoal e cria novos ambientes de desenvolvedor, conforme necessário.

Figura: um criador redirecionado automaticamente para um ambiente de desenvolvedor pessoal, em vez do ambiente padrão durante a compilação de aplicativos.

Os ambientes de desenvolvedor criados pelo roteamento são gerenciados por padrão. Os usuários com licenças do Plano de desenvolvedor estão limitados a criar e visualizar recursos no ambiente. Para executar os recursos como usuário, eles precisam de uma licença apropriada.

É possível usar o roteamento de ambiente sozinho, mas a maneira recomendada é usá-lo com grupos de ambientes. Quando usado dessa forma, qualquer ambiente criado é associado ao grupo que você designar para conter todos os novos ambientes de desenvolvedor, garantindo que ele seja imediatamente coberto por suas políticas de governança.

Os criadores recebem automaticamente uma direito de acesso que os torna administradores de ambiente de seu ambiente de desenvolvedor. Quando o ambiente faz parte de um grupo de ambientes, o criador, como administrador do ambiente, não pode alterar as configurações do ambiente porque elas são gerenciadas pelas regras do grupo de ambientes. Somente os administradores, que podem modificar as regras do grupo, podem fazer alterações.

Você pode impor ainda mais controle de duas maneiras. Primeiro, você pode impedir a criação manual de ambientes de desenvolvedor em suas configurações de locatário. Quando essa opção é definida, os criadores não podem criar ambientes no portal de administração. Eles também não terão um criado automaticamente pela política de roteamento. Em segundo lugar, você pode especificar um grupo de segurança, na política de roteamento, para limitar quem pode criar automaticamente um ambiente.

Inicialmente, o roteamento de ambiente dá suporte ao roteamento de criadores novos e existentes de fora do ambiente padrão quando eles usam make.powerapps.com. Com o tempo, outros serviços do Power Platform oferecerão suporte ao recurso de roteamento do ambiente.

Conteúdo de boas-vindas para criadores

Forneça conteúdo de boas-vindas personalizado para ajudar os criadores a começar a usar o Power Apps e o Copilot Studio. Quando você adiciona seu próprio conteúdo de ajuda, ele substitui a experiência de ajuda inicial padrão do Power Apps para os criadores. A mensagem de boas-vindas personalizada pode informar os criadores sobre as regras da empresa e o que eles podem fazer em cada ambiente ou grupo de ambientes.

Aqui estão algumas sugestões de como sua organização pode usar a mensagem de boas-vindas em cada tipo de ambiente. Inclua uma imagem que identifica o tipo de ambiente ou os proprietários para ajudar na adoção do usuário e na prevenção de erros.

Ambiente padrão

O ambiente padrão geralmente é o mais restrito, com políticas de dados e controles de compartilhamento. Crie uma mensagem de boas-vindas que alerte seus criadores sobre restrições e possíveis limitações e inclua um link para o site ou documento de política da sua organização.

Por exemplo, convém informar os criadores a utilizarem o ambiente padrão somente para soluções relacionadas aos aplicativos do Microsoft 365, evitar a utilização de aplicativos de produção neste ambiente e compartilhar seus aplicativos de tela com um número restrito de pessoas. O exemplo a seguir mostra como criar essa mensagem nas configurações de Ambientes Gerenciados:

Exemplo de entrada em Markdown:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to Contoso Personal Productivity Environment

### Before you start, here are some considerations

Use this environment if you plan to build apps that integrate with Office 365.

Before you start, be aware of these limitations:

1. You can't share your apps with more than five users.
1. The data in Dataverse is shared with everyone in the organization.
1. You can only use Office 365 connectors.

If you're not sure you're in the right place, follow **[this guidance](#)**.

Aqui está a mensagem de boas-vindas renderizada:

Ambientes de produção

Os ambientes de produção normalmente são usados para implantar soluções que dão suporte à produtividade da empresa e da equipe. É importante que os aplicativos e os dados estejam em conformidade com as políticas organizacionais. Como você precisa controlar quais usuários têm acesso ao ambiente de produção, é uma boa ideia informar os usuários se você tem uma política de atualização do acesso. Você pode permitir mais conectores e aumentar os limites de compartilhamento em um ambiente de produção. Você também pode usar a mensagem de boas-vindas para informar os criadores para entrarem em contato para obter suporte. O exemplo a seguir mostra como criar essa mensagem:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to HR Europe Environment

### Before you start, here are some considerations

Use this environment if you're on the HR team and your data is located in Europe.

Before you start, be aware of these limitations:

1. You can only share apps with security groups. [Follow this process](#) to share your apps.
1. The data in Dataverse is stored in Europe.
1. You can only use social media connectors with read actions.
1. If you need more connectors, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Aqui está a saída de exemplo:

Ambientes de desenvolvedor

Os ambientes de desenvolvedor geralmente são onde os desenvolvedores criam suas soluções. Como os desenvolvedores estão trabalhando nos aplicativos, eles não estão em produção e a escalabilidade é limitada. Normalmente, os ambientes de desenvolvimento têm políticas de dados mais relaxadas devido à natureza dos criadores. Para evitar que os desenvolvedores usem ativos de produção em seus ambientes de desenvolvimento, limite os recursos de compartilhamento e use uma política de dados específica para esse tipo de ambiente. Aqui está um exemplo de uma mensagem de boas-vindas para um ambiente de desenvolvimento:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to a Developer Environment

### Before you start, here are some considerations

Use this environment if you're a developer and you're building solutions.

Before you start, be aware of these limitations:

1. You can only share resources with up to two members of your team. If you need to share with more people, [submit a change request](#).
1. Use resources only while you're developing a solution.
1. Be mindful of the connectors and data you're using.
1. If you need more connectors, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Aqui está a saída de exemplo para um ambiente de desenvolvedor:

Ambientes de sandbox

Normalmente, ambientes de área restrita são usados para testar soluções. Como alguns testes envolvem um número significativo de usuários, esses ambientes podem aumentar sua capacidade, até um ponto, e têm mais capacidade do que um ambiente de desenvolvedor. Os ambientes de área restrita também são comumente usados como ambientes de desenvolvimento e normalmente são compartilhados por vários desenvolvedores. Aqui está um exemplo de uma mensagem de boas-vindas para esse ambiente:

![Contoso](https://i.ibb.co/SNSTCx3/something.png)
## Welcome to a Test Environment

### Before you start, here are some considerations

Use this environment only if you're testing solutions.

Before you start, be aware of these limitations:

1. You can only share resources with your team. If you need to share with more people, [submit a change request](#).
1. You're not allowed to edit or import solutions directly in this environment.
1. Be mindful of the test data and compliance.
1. If you need help from a security export or IT support, [submit a request](#).

If you're not sure you're in the right place, follow **[this guidance](#)**.

Aqui está um exemplo de saída para um ambiente de sandbox ou de teste:

Limitar compartilhamento

Os administradores podem limitar a forma como os usuários podem compartilhar aplicativos de tela, fluxos e agentes. No entanto, o limite só se aplica ao compartilhamento futuro. Se você aplicar um limite de compartilhamento de 20 a um ambiente com recursos que já são compartilhados com mais de 20 usuários, esses recursos continuarão a funcionar para todos os usuários com os quais os recursos foram compartilhados. Crie um processo para informar aos criadores de aplicativos, fluxos e agentes compartilhados com mais do que o novo limite para que eles possam reduzir o número de usuários com os quais seus recursos são compartilhados. Em alguns casos, você pode decidir mover a solução para outro ambiente. Os limites de compartilhamento se aplicam a canvas apps, fluxos e agentes.

Normalmente, os administradores precisam controlar como os criadores compartilham seus aplicativos, fluxos e agentes quando:

• Os recursos são compartilhados em um ambiente de produtividade pessoal. Se você tiver um ambiente em que os usuários possam criar recursos para seu próprio trabalho, recursos sem valor comercial global ou recursos sem suporte da TI, é importante que você não permita que os criadores os compartilhem em toda a organização. Se os recursos começarem como recursos de produtividade pessoal, mas mais tarde se tornarem populares e forem amplamente usados, esteja atento ao limite que você estabelece para o compartilhamento. Um limite comum é entre 5 e 50 usuários.

• Os recursos são compartilhados com grupos de segurança ou com todos. Os recursos compartilhados com um grupo de segurança podem ser executados por todos os membros do grupo. Em um ambiente de desenvolvedor, talvez você queira que o desenvolvedor controle como os recursos são compartilhados em vez de depender da associação ao grupo. Em outros cenários, talvez você queira permitir o compartilhamento com todos. Se a política da sua organização é que os recursos são compartilhados com um grupo de segurança que inclui todos os usuários autorizados a executar o recurso e é gerenciado pelo departamento de TI, talvez você queira impedir que os criadores compartilhem com outros grupos de segurança.

Aqui estão os limites comuns de compartilhamento para cada tipo de ambiente:

• Padrão: selecioneExcluir compartilhamento com grupos de segurança, selecione Limitar o total de pessoas que podem compartilhar e selecione 20 para o valor.

• Desenvolvedor: Selecione Excluir compartilhamento com grupos de segurança, selecione Limitar o total de pessoas que podem compartilhar e selecione 5 para o valor.

• Sandbox: selecione Excluir compartilhamento com grupos de segurança e deixe Limitar o total de indivíduos que podem compartilhar desmarcado. Use essa opção se os aplicativos forem compartilhados com um grupo de segurança gerenciado por TI que inclua os usuários autorizados a executar o aplicativo. Se o criador, o usuário ou a equipe puder gerenciar quais usuários têm permissão para testar uma solução, selecione Não definir limites (padrão).

• Produção: Selecione Não definir limites (padrão). Para controlar o compartilhamento com base em um grupo de segurança específico, selecione Excluir compartilhamento com grupos de segurança e deixe Limite total de indivíduos que podem compartilhar com pessoas não selecionadas .

Microsoft Dataverse

O Dataverse armazena e gerencia dados de forma segura que são usados pelos aplicativos. No contexto de uma estratégia de ambiente, o Recurso da solução do Dataverse permite transportar aplicativos e componentes de um ambiente para outro. Os criadores constroem seus ativos em contêineres, soluções, que rastreiam o que eles criam. As soluções podem ser facilmente transportadas para outros ambientes. Usando essa abordagem, você pode separar os ambientes de desenvolvedor, onde os criadores criam recursos, dos ambientes de produção onde eles são usados. Tanto os criadores quanto os usuários se beneficiam. Os criadores podem continuar evoluindo seus recursos e os usuários não se surpreendem com mudanças repentinas. Quando os criadores estão prontos para publicar suas alterações, eles podem solicitar a promoção do recurso atualizado para o ambiente de produção.

As soluções do Dataverse são mecanismos para implementar o ALM nos produtos do Power Platform, como Power Apps e Power Automate. Os pipelines no Power Platform usam soluções para automatizar a CI/CD de ativos que os criadores criam. As soluções podem ser exportadas do Dataverse e armazenadas em um controle do código-fonte como o Azure DevOps ou o GitHub. A solução no controle do código-fonte se tornará a fonte da verdade se você precisar recriar o ambiente de desenvolvimento. Por exemplo, se um criador criou um aplicativo popular e depois excluiu o ambiente do desenvolvedor, uma solução exportada armazenada no controle do código-fonte pode ser usada para recriar um ambiente de desenvolvimento viável.

Outra consideração importante durante a criação de um ambiente com o Dataverse é se algum aplicativo do Dynamics 365 será implantado no ambiente. Se o potencial existir, você deverá habilitar o Dynamics 365 ao criar o ambiente ou não poderá instalar os aplicativos do Dynamics 365 posteriormente.

Recomendamos que você provisione o Dataverse em qualquer ambiente onde os criadores criem ativos que serão compartilhados com outros usuários. Essa estratégia facilita a preparação dos ativos para o ALM.

Soluções preferidas

Quando um criador cria um ativo do Dataverse em um ambiente do Dataverse e não começa por uma solução personalizada, o ativo é associado à solução padrão e também pode estar associado à solução padrão do Common Data Service. A solução padrão é compartilhada por todos os criadores que criam ativos no ambiente. Identificar qual criador criou componentes específicos ou quais ativos pertencem a aplicativos específicos é desafiador, tornando mais difícil promover um aplicativo popular em outro ambiente para compartilhamento com um público maior. Para fazer isso, você precisa promover todos os ativos na solução padrão, o que não é o ideal.

Para dar suporte à sua estratégia de ambiente e facilitar o trabalho, os criadores devem criar uma solução personalizada em seu ambiente de desenvolvimento e, em seguida, defini-la como a solução preferida no ambiente. Os criadores definem a solução preferida em um ambiente para indicar a qual solução um ativo que eles criaram deve ser associado. As soluções preferidas podem ajudar a garantir que, quando os criadores usam pipelines para promover seus recursos para outros ambientes, a solução promovida contenha todos os ativos necessários. Pense nisso como uma preparação dos ativos para estarem prontos para o ALM.

Pipelines do Power Platform

Como vimos, um princípio fundamental de uma boa estratégia ambiental é isolar o local onde um ativo é criado de onde é implantado e usado. Essa separação garante que os usuários que estão tentando usar um ativo não encontrem tempo de inatividade porque um criador o está atualizando. No entanto, isso exige que os ativos sejam promovidos para um ambiente de produção, de preferência, como parte de uma solução do Dataverse, antes que eles possam ser usados.

As soluções do Dataverse podem ser manualmente transportadas entre ambientes. No entanto, você pode automatizar o processo, e implementar políticas para garantir que o gerenciamento adequado de alterações ocorra, usando pipelines. Dependendo das regras do ambiente definidas no verificador de solução, os pipelines impõem automaticamente todas as regras antes de a solução ser implantada, evitando mais erros de implantação. O diagrama a seguir ilustra como os pipelines podem automatizar a promoção de um ativo do desenvolvimento à produção.

Figura: Um pipeline automatiza a promoção de um ativo armazenado no controle do código-fonte, desde o desenvolvimento, passando pelo teste, até a produção.

Você pode configurar o número de ambientes e processos, como aprovações, que precisam ser incluídos em um pipeline.

Os pipelines funcionam em conjunto com grupos de ambientes. Eles podem ser pré-configurados para ambientes de desenvolvimento para permitir que os criadores iniciem facilmente o processo de promoção respondendo a um prompt quando tentarem compartilhar seus ativos com outros usuários. Como parte de uma solicitação de implantação usando pipelines, os criadores podem propor com quem compartilhar seus ativos e as funções de segurança necessárias. Um administrador de pipeline pode aprovar ou rejeitar a solicitação antes da implantação, garantindo privilégios mínimos para o criador que a originou.

Os pipelines no Power Platform armazenam as definições de cada pipeline em um ambiente de host que a Microsoft gerencia por padrão. No entanto, você pode definir vários ambientes de host em seu locatário que gerencia, permitindo que você lide com requisitos exclusivos.

Imposição do verificador de solução

É comum que uma equipe do Centro de Excelência (CoE) configure guardrails para reduzir o risco de usuários importarem soluções não compatíveis em um ambiente. Os administradores podem impor facilmente verificações avançadas de análise estática de soluções em relação a um conjunto de regras de prática recomendada para identificar padrões problemáticos. As organizações com CoEs descentralizados geralmente acham necessário ativar a aplicação do verificador de solução junto com o envio de um email para entrar em contato proativamente com os criadores para oferecer suporte.

A aplicação do verificador de solução oferece três níveis de controle: Nenhum, Avisar e Bloquear. Os administradores configuram o efeito da verificação, se ela fornece um aviso, mas permite a importação ou bloqueia totalmente a importação, ao mesmo tempo em que fornecem o resultado da importação para o fabricante.

As organizações que usam esse recurso o configuram de forma diferente, dependendo do tipo de ambiente. É normal ter exceções, e essa orientação sempre deve estar alinhada às suas necessidades. No entanto, aqui estão as configurações mais comuns para a imposição do verificador de solução em cada tipo de ambiente:

• Padrão: selecione Bloquear e Enviar emails.
• Desenvolvedor: Selecione Avisar e deixe Enviar emails não selecionados.
• Sandbox: selecione Avisar e deixe Enviar emails não selecionado.
• Produção: Selecione Bloquear e Enviar emails.
• Ambiente do Teams: selecione Bloquear e Enviar emails.

Catálogo no Power Platform

Organizações nas quais os desenvolvedores e os criadores compilam e compartilham componentes como aplicativos, fluxos e modelos, pontos de partida avançados, tendem a agregar mais valor do Power Platform. O catálogo do Power Platform facilita para os criadores compartilhar os componentes e os modelos nos ambientes.

O catálogo é instalado em um ambiente e pode ser instalado com o host do pipeline no mesmo ambiente. Também é possível lidar com requisitos exclusivos de segmentação de recursos tendo vários ambientes com um catálogo instalado.

Organizações que incentivam desenvolvedores e fabricantes a criar e compartilhar componentes e modelos no catálogo derivam mais valor de seu investimento no Power Platform. Simplesmente construir não é suficiente. Compartilhar os artefatos, em escala, promove comunidades e apoia grupos que podem desbloquear valor de um conjunto diversificado de funcionários na organização. Na verdade, as organizações que são mais bem-sucedidas com o Power Platform adotam um modelo de equipe de fusão, em que desenvolvedores, criadores e administradores profissionais trabalham juntos para ajudar seus colegas a derivar o valor mais alto possível da plataforma reutilizando soluções, modelos e componentes.

Roteiro do recurso

À medida que a Microsoft continua a desenvolver os recursos do Power Platform que oferecem suporte à governança e administração, você pode acompanhar o planejador de lançamentos. Você aprende o que está planejado, o que está no próximo ciclo de lançamentos e o que você pode experimentar agora. Você pode até criar seu próprio plano de versão salvando os itens que deseja seguir.

Base de uma estratégia de ambiente em escala empresarial

Discutimos nossa visão para uma estratégia de ambiente de locatário em escala empresarial e os principais recursos de ambiente que a suportam. Agora, veremos como você pode usar esses recursos juntos como parte de uma estratégia de ambiente. Sua estratégia deve ser baseada nos requisitos específicos da sua organização, então vamos começar com um exemplo básico antes de adaptar uma estratégia para atender às suas necessidades.

Neste exemplo, a liderança da Contoso deseja capacitar os funcionários a obter vantagens do Power Platform e identificou os seguintes requisitos de alto nível:

• Os funcionários precisam ser capazes de criar processos automatizados, de aprovação de documento e outras personalizações do Power Platform com o Microsoft 365.
• Os funcionários devem ser capazes de criar automações do Power Apps e do Power Automate para melhorar sua produtividade pessoal.
• Os criadores que estão trabalhando no aplicativo Rastreador de Conformidade da empresa devem ser capazes de desenvolvê-lo e mantê-lo.

Para dar suporte a esses requisitos, a equipe de administração e governança da Contoso desenvolveu a seguinte topologia de ambiente:

Figura: Topologia de ambiente proposta para o projeto em escala do Power Platform da Contoso.

Vamos explorar esse diagrama de topologia de ambiente em detalhes.

O ambiente padrão é usado para criar personalizações de produtividade do Microsoft 365. As políticas de dados e as restrições de compartilhamento limitam outros tipos de atividade do criador e colocam guardrails em torno do que os fabricantes podem criar nesse ambiente.

Apenas administradores podem criar ambientes de avaliação, área restrita e produção. Os criadores usam um Microsoft Form personalizado ou outro processo para solicitar um novo ambiente. O Kit de início do CoE (Centro de Excelência) do Microsoft Power Platform inclui uma solicitação de ambiente que pode ser usada.

Quatro grupos de ambientes são criados: Desenvolvimento, Desenvolvimento Compartilhado, UAT (teste de aceitação do usuário) e Produção.

• Uma política de roteamento de ambiente definida para o grupo Desenvolvimento afasta os criadores do ambiente padrão para os próprios ambientes de desenvolvedor. À medida que novos ambientes de desenvolvimento são criados, eles são automaticamente associados ao grupo de desenvolvimento e suas regras são aplicadas.

• O grupo Desenvolvimento Compartilhado dá suporte a ambientes que contêm projetos com vários criadores.

• O grupo UAT contém ambientes que são usados para testar recursos antes de serem promovidos para produção.

• O grupo Produção contém ambientes que hospedam aplicativos, fluxos e outros artefatos para uso em produção.

Essa topologia proposta não tem pipelines para automatizar a promoção entre ambientes de produção, desenvolvimento e teste. Vamos adicioná-los agora.

Figura: A mesma topologia de ambiente com pipelines conectando um ambiente de host do pipeline a ambientes de produção, desenvolvimento e teste.

No diagrama de topologia do ambiente revisado, adicionamos um ambiente de host de pipeline e dois pipelines. Um pipeline move recursos de desenvolvimento para ambientes de teste e depois para ambientes de produção. A regra do pipeline no Grupo de desenvolvimento será modificada para usar esse pipeline. O outro pipeline move recursos do ambiente de desenvolvimento compartilhado para teste e, em seguida, para produção. A regra do pipeline no grupo de Desenvolvimento Compartilhado será modificada para usar esse pipeline.

Essa estratégia básica de ambiente fornece uma base que você pode desenvolver para outros casos de uso, que exploraremos a seguir.

Estratégias de ambiente para cenários específicos

Aqui estão alguns casos de uso comuns que talvez você precise incorporar na estratégia de ambiente de locatário da base.

Controlar quais criadores podem criar ambientes de desenvolvedor

Por padrão, qualquer pessoa que tenha uma licença Premium do Power Platform, uma licença do Plano para Desenvolvedores ou uma função de administrador de locatário do Power Platform pode criar um ambiente de desenvolvedor no portal de administração.

Na estratégia de ambiente de base, o roteamento de ambiente garante que os criadores sejam direcionados do ambiente padrão para um novo ambiente de desenvolvedor criado no grupo designado. No entanto, os criadores ainda podem criar manualmente ambientes de desenvolvedor que não são colocados em um grupo de ambientes e não têm suas regras aplicadas.

Para refinar quais criadores são elegíveis para roteamento de ambiente, especifique um grupo de segurança na configuração de roteamento. Quando um grupo de segurança é configurado, apenas os membros do grupo de segurança são roteados. Todos os outros retornam ao ambiente padrão.

Fornecer mais flexibilidade a criadores avançados

Na estratégia de ambiente de base, todos os novos ambientes do criador são roteados para um grupo de ambientes de desenvolvedor designado. Geralmente, esse grupo de ambientes possui um conjunto bastante restritivo de regras de governança aplicadas.

À medida que os criadores se tornam mais avançados, você pode permitir que eles solicitem acesso a mais recursos. Em vez de removê-los do grupo de ambiente original e gerenciar manualmente a exceção, você pode usar outro grupo de ambientes para rastrear esses criadores avançados.

Figura: adicione criadores mais capazes a um ambiente que tenha regras de governança flexíveis.

Organizar ambientes de desenvolvedor por região ou unidade de negócios

Na implementação atual de roteamento de ambiente, todos os novos ambientes de desenvolvedor são criados em um único grupo de ambientes. E se você quiser organizar os ambientes de desenvolvedor dos criadores por região, por exemplo, ou unidade de negócios?

Use o roteamento para direcionar criadores para um novo ambiente de desenvolvedor criado no grupo designado. Em seguida, você pode movê-lo para outro grupo baseado em região, unidade organizacional ou outros critérios, onde pode aplicar regras de governança mais granulares.

Figura: depois que o roteamento de ambientes cria ambientes do desenvolvedor no grupo designado, migre-os para grupos estruturalmente mais específicos.

Mover ambientes é uma ação manual hoje, mas você poderá automatizá-la quando o conector de administração do Power Platform oferecer suporte ao recurso de grupo em uma atualização futura.

Desenvolver um aplicativo para uso corporativo

Uma equipe em sua organização pode estar desenvolvendo um aplicativo para uso corporativo. A equipe pode ser orientada por TI ou incluir usuários de TI e de negócios (o que é conhecido como equipe de fusão).

Na estratégia de ambiente mais simples, a equipe do projeto cria em um ambiente compartilhado que é um tipo de produção ou área restrita. Um tipo de ambiente de desenvolvedor não é a melhor maneira de oferecer suporte à colaboração de vários criadores em um recurso. Os criadores precisam se comunicar entre si para evitar colisões e conflitos no ambiente compartilhado.

Ambientes de teste e produção dedicados não são necessários. O aplicativo pode ser testado e implantado em ambientes de teste e produção de toda a organização que hospedam vários aplicativos.

Figura: dois aplicativos empresariais em desenvolvimento em ambientes dedicados e depois testados e implantados em ambientes compartilhados com outros aplicativos.

Em uma variação mais avançada, cada criador tem um ambiente de desenvolvedor individual. Essa estratégia tem o benefício de proporcionar mais isolamento ao criador, mas pode deixar a combinação do trabalho individual em um ambiente de integração mais complicada. Embora trabalhar isoladamente possa ser útil para equipes maiores e sofisticadas, isso pode adicionar sobrecarga desnecessária a equipes menores que podem ter mais sucesso colaborando em um ambiente de desenvolvimento compartilhado.

Figura: dois criadores que trabalham no mesmo aplicativo em ambientes de desenvolvedor individuais devem combinar o trabalho em um ambiente de integração compartilhado antes de migrar para teste e produção.

Essa variação geralmente incorpora uma estratégia de controle do código-fonte, com cada ambiente de desenvolvimento representado como uma ramificação no controle do código-fonte que é mesclada quando as alterações estão prontas para serem promovidas. É importante levar em conta como o aplicativo será mantido após o lançamento inicial.

Por exemplo, a versão 1.0 do aplicativo pode estar em produção enquanto a equipe avança para a criação da versão 2.0. Sua estratégia de ambiente deve oferecer suporte à correção de um problema na versão 1.0 enquanto o desenvolvimento da versão 2.0 está em andamento.

Figura: a versão 1.0 deve ser corrigida, testada e implantada, e a versão 2.0 está sendo desenvolvida, testada e implantada.

Os grupos de ambientes oferecem várias abordagens para lidar com esse cenário de aplicativo empresarial. Por exemplo, pode ser um único grupo de aplicativos ou pode envolver grupos separados para cada estágio de desenvolvimento. Na seção de melhores práticas, exploramos como avaliar as opções.

Minimizar o uso de ambientes de desenvolvedor

Ambientes de desenvolvedor individuais são a maneira recomendada de fornecer aos criadores um espaço de trabalho para criar soluções com pouco código. Eles oferecem o mais alto nível de isolamento de outros fabricantes. Se sua organização deseja minimizar o número de ambientes de desenvolvedor, vários ambientes compartilhados são melhores do que incentivar os criadores a criar ativos no ambiente padrão.

Nesse cenário, você restringiria a criação de ambientes de desenvolvedor e criaria ambientes de desenvolvimento compartilhados do tipo produção. Você pode organizar esses ambientes compartilhados por estrutura organizacional, região ou outros critérios. Um grupo de ambientes pode contê-los para garantir que tenham regras de governança consistentes aplicadas. Conceder permissão aos criadores para criar ativos low-code no ambiente atribuído a eles.

Segurança como parte da estratégia do seu ambiente

Os ambientes são um componente principal do uso do Power Platform de forma segura. Eles representam limites de segurança dentro do locatário que ajudam a proteger aplicativos e dados. Como parte de sua estratégia de ambiente, você deve considerar como seus requisitos de segurança influenciam o número e a finalidade dos ambientes em seu locatário.

Os ambientes permitem que você crie vários limites de segurança em seu locatário para proteger aplicativos e dados. A proteção fornecida pelo ambiente pode ser ajustada para atender à proteção de segurança necessária, aplicando um conjunto configurável de recursos de segurança no ambiente. Uma discussão detalhada dos recursos de segurança de ambiente individual está além do escopo deste artigo. No entanto, nesta seção, oferecemos recomendações sobre como pensar na segurança como parte de sua estratégia de ambiente de locatário.

Segurança no nível do locatário

A maioria das configurações de segurança que afetam os ambientes são definidas para cada ambiente individualmente. No entanto, você pode fazer algumas alterações no nível do locatário para ajudar a dar suporte à sua estratégia de ambiente.

• Considere desativar o recurso Compartilhar com Todos no Power Platform. Somente administradores poderiam compartilhar um ativo com todos.
• Considere proteger a integração com o Exchange.
• Aplique isolamento do locatário para ajudar a minimizar o risco de exfiltração dos dados entre locatários.
• Restrinja a criação de novos ambientes de produção de rede aos administradores. A limitação da criação de ambientes é benéfica para manter o controle no geral, tanto para evitar o consumo de capacidade não contabilizada quanto para reduzir o número de ambientes a serem gerenciados. Se os usuários tiverem que solicitar ambientes na TI central, será mais fácil ver quais pessoas estão trabalhando se os administradores forem os gatekeepers.

Proteger o ambiente padrão

O ambiente padrão tem uma função no suporte a personalizações de produtividade do Microsoft 365. Como parte da estratégia ambiental recomendada, porém, é melhor minimizar seu uso o máximo possível. Em vez disso, os criadores devem criar em seus próprios ambientes isolados. Embora não seja possível bloquear o acesso ao ambiente padrão, você poderá minimizar o que pode ser feito nele.

Primeiro, use o roteamento de ambiente para direcionar os criadores para seu próprio espaço de trabalho, a fim de criar ativos low-code.

• Revise quem tem acesso de administrador de ambiente padrão e limite-o às funções necessárias.

• Considere renomear o ambiente padrão para algo mais descritivo, como "Produtividade pessoal".

  • Estabeleça uma política de dados para o ambiente padrão que bloqueia novos conectores e restringe os fabricantes a usar apenas conectores básicos e desbloqueáveis. Mova todos os conectores que não podem ser bloqueados para o grupo de dados corporativos. Mova todos os conectores bloqueáveis para o grupo de dados bloqueados.

  • Crie uma regra para bloquear todos os padrões de URL usados por conectores personalizados.

Proteger o ambiente padrão é uma prioridade. Implemente-o com segurança em nível de locatário como parte da primeira etapa da sua estratégia de ambiente. Sem essas medidas, os criadores podem adicionar mais ativos ao ambiente padrão. Com essas medidas e o encaminhamento do ambiente implementados, os criadores são incentivados a usar o próprio ambiente.

Saiba mais: Proteger o ambiente padrão

Proteger outros ambientes

Se sua organização é como a maioria, você tem vários ambientes, além do ambiente padrão. O nível de segurança que cada um requer pode variar dependendo dos aplicativos e dados que ele contém. Os ambientes do desenvolvedor normalmente têm regras mais flexíveis do que os ambientes de produção. Alguns ambientes de produção exigem a maior proteção possível.

Como parte do estabelecimento de sua estratégia de ambiente, identifique níveis comuns de segurança para seus ambientes e os recursos que protegem cada nível, como no exemplo a seguir.

Figura: um exemplo de três camadas de segurança do ambiente e os recursos de segurança que se aplicam aos ambientes em cada camada.

Incorpore os níveis de segurança identificados à sua estratégia de grupo e, sempre que possível, use regras para habilitar os recursos de segurança em seus ambientes. Neste exemplo, uma regra limita o compartilhamento em todos os ambientes designados como segurança normal ou média.

Alinhar ambientes à sua estratégia de política de dados

As políticas de dados são outra parte importante de um esforço geral de governança para controlar os serviços usados por recursos low-code em um ambiente. Os grupos de ambiente não têm uma regra para aplicar uma política de dados a um ambiente. No entanto, você pode alinhar sua estratégia de política de dados com seus grupos de ambiente. Por exemplo, você pode criar uma política de dados com o mesmo nome ou um nome semelhante a um grupo de ambiente e aplicá-la a ambientes nesse grupo.

Saiba mais sobre como implementar uma estratégia de política de dados.

Figura: Neste exemplo, os ambientes no grupo desenvolvimento pessoal seguem uma política de prevenção contra perda de dados (DLP) que bloqueia todos os conectores que não são da Microsoft.

Adaptar uma estratégia de ambiente para a sua organização

Em seções anteriores, descrevemos nossa visão de como as organizações podem gerenciar ambientes em escala. Exploramos os recursos essenciais, como eles contribuem para uma estratégia de ambiente e como pode ser a aparência de uma topologia de ambiente base que os usa. Demos exemplos de como construir sobre essa base para acomodar cenários comuns. Como cada organização é única, a próxima etapa será adaptar uma estratégia de ambiente que atenda às necessidades da organização.

Comece onde você está

Se a sua organização é nova para o Power Platform ou está sendo utilizada há anos, o primeiro passo é avaliar a sua situação. Avalie, em alto nível, o que há em seu ambiente padrão, quais outros ambientes você tem e para que eles estão sendo usados. Muitas vezes, uma estratégia de ambiente é feita como parte de um esforço geral para estabelecer a governança do Power Platform em uma organização. Se esse for o caso, talvez você já tenha estabelecido parte da visão de governança necessária para adaptar uma estratégia para sua organização.

As informações da organização que você deve conhecer incluem:

• Qual a visão de como o Power Platform será utilizado na organização?
• Quem na organização criará ativos low-code?

Você precisa tomar algumas decisões importantes:

• Como os criadores obterão novos ambientes?
• Você agrupará seus ambientes e, em caso afirmativo, como?
• Quais níveis de segurança são necessários para diferentes ambientes e como os ambientes são classificados?
• Como você decidirá se um aplicativo, automação ou Copilot usará um ambiente existente ou um novo?
• Existem lacunas entre os recursos de linha de base da plataforma e seus requisitos que exigem um processo de governança personalizado?
• Como você lidará com os ativos existentes no ambiente padrão?
• Você tem uma estratégia de política de dados de locatário e ambiente e, nesse caso, como ela se alinha com a estratégia de ambiente que você está criando?

Você pode se inspirar nos modelos operacionais de nuvem que fazem parte do Cloud Adoption Framework para Azure.

Preencher lacunas usando a plataforma

Você quase sempre encontrará requisitos que os recursos internos da plataforma não satisfazem. Ao avaliar essas lacunas, considere os seguintes possíveis resultados de sua avaliação:

• A lacuna é aceitável.
• A lacuna pode ser preenchida usando o Kit de Início do Centro de Excelência do Power Platform.
• A lacuna pode ser preenchida usando os recursos da plataforma, como APIs, conectores e aplicativos personalizados ou automações.
• A lacuna pode ser preenchida usando uma ferramenta ou aplicativo de terceiros.

Kit de início do CoE

O Kit de Início do Centro de Excelência do Power Platform é um conjunto de componentes e ferramentas projetados para ajudar sua organização a adotar e dar suporte ao uso de vários componentes do Power Platform. Um aspecto fundamental do kit de início é sua capacidade de coletar dados sobre o uso da plataforma em seus ambientes, o que pode ser útil à medida que você desenvolve e evolui sua estratégia de ambiente.

Por exemplo, o painel Ambientes do Power BI oferece uma visão geral que ajuda você a entender quais ambientes existem em seu locatário, quem os criou e quais ativos eles contêm.

Figura: o painel Ambientes no Power BI.

O kit inclui pontos de partida ou inspiração, como um processo que os criadores podem usar para solicitar novos ambientes e alterações nas políticas de dados para seus ambientes.

Figura: fluxograma ilustrando um processo de gerenciamento do ambiente no Kit de Início do CoE.

Programação e extensibilidade da plataforma

Uma das grandes coisas sobre uma plataforma low-code é que você pode usá-la para criar aplicativos, automações, portais e copilotos para ajudá-lo a gerenciá-la. Você também tem acesso a ferramentas de nível inferior que podem ser usadas para preencher lacunas no suporte à sua estratégia de ambiente.

Você pode usar os seguintes conectores para criar aplicativos e fluxos:

• Power Platform for Admins e Power Platform for Admins V2
• Power Apps for Admins e Power Apps para Criadores
• Gerenciamento do Power Automate

Você pode usar a CLI (Interface de linha de comando) do Power Platform para desenvolver automações para ajudá-lo a gerenciar o ciclo de vida do ambiente e outras tarefas relacionadas às práticas de DevOps.

Com os cmdlets do PowerShell para criadores e administradores do Power Platform, você pode automatizar muitas tarefas de monitoramento e gerenciamento.

O SDK de DLP do Power Platform pode ajudá-lo a gerenciar seu locatário e as políticas de prevenção contra perda de dados do locatário e do ambiente.

Melhores práticas e recomendações

Nesta seção do artigo, criamos as recomendações nas seções de base e específicas do cenário.

Novos ambientes

Como parte do desenvolvimento de sua estratégia, considere quando criar ambientes para dar suporte a uma carga de trabalho. Sua avaliação deve equilibrar os benefícios do isolamento que um ambiente oferece, como bloquear ambientes específicos para melhor segurança, com as desvantagens, como o atrito que os usuários enfrentam ao compartilhar dados entre aplicativos.

Ao avaliar se um aplicativo ou uma automação pertence a seu próprio ambiente, avalie separadamente os diferentes estágios do ciclo de vida do aplicativo. Durante o desenvolvimento, o isolamento de outros aplicativos é importante. Quando vários aplicativos são desenvolvidos em um único ambiente, você corre o risco de criar dependências entre aplicativos.

Como recomendação geral, quando possível, os ambientes de desenvolvimento devem ser de uso único, descartáveis e facilmente recriados.

Testar vários aplicativos no mesmo ambiente fará sentido se eles forem executados juntos na produção. Na verdade, se você não testar com os aplicativos que serão executados na produção, corre o risco de não descobrir problemas de compatibilidade.

Ao avaliar o ambiente de produção de um aplicativo, lembre-se das seguintes considerações:

• O aplicativo é compatível com aplicativos existentes no ambiente? Por exemplo, dois aplicativos que usam a tabela Contato do Dataverse para fins diferentes podem não ser compatíveis. Os aplicativos são compatíveis de uma perspectiva de política de dados?

• Existem requisitos normativos ou de conformidade especiais para a separação de dados? Por exemplo, a confidencialidade dos dados exige que eles sejam isolados? Existe um requisito de que os dados não possam ser incluídos em outros dados?

• Os dados são altamente confidenciais ou sensíveis? A exfiltração causaria danos monetários ou reputacionais à organização? O isolamento em um ambiente separado pode permitir mais controle sobre a segurança.

• O aplicativo precisa de dados de outros aplicativos e precisa ser colocado com eles? Por exemplo, dois aplicativos que usam sua tabela Cliente devem ser hospedados juntos. Separá-los criaria cópias de dados redundantes e geraria problemas na manutenção dos dados.

• Os dados exigem residência de dados regionais? Em alguns cenários, o mesmo aplicativo ou automação pode ser implantado em ambientes regionais para garantir o isolamento e a residência de dados apropriados.

• A maioria dos usuários está na mesma região do ambiente? Se o ambiente estiver na EMEA, mas a maioria dos usuários do aplicativo residirem nos EUA, compartilhar um ambiente pode não fornecer o melhor desempenho.

• Novos administradores serão necessários ou os administradores existentes serão suficientes? Se o novo aplicativo exigir mais administradores, eles serão compatíveis com os administradores existentes (já que todos terão permissões de administrador em todos os aplicativos no ambiente)?

• Qual é a expectativa de vida útil do aplicativo? Se o aplicativo ou a automação for temporário ou de curta duração, talvez não seja recomendado instalá-lo em um ambiente com aplicativos mais duradouros.

• Os usuários terão dificuldade em usar vários ambientes para aplicativos diferentes? Isso pode afetar tudo, desde encontrar um aplicativo no dispositivo móvel até relatórios de autoatendimento que precisam extrair dados de vários ambientes.

Capacidade

Cada ambiente, exceto os ambientes de desenvolvedor e avaliação, usa 1 GB de provisionamento inicialmente. A capacidade é compartilhada entre o locatário, portanto, precisa ser alocada para aqueles que precisam.

Conserve capacidade ao:

• Gerenciar ambientes de teste e de produção compartilhados. Ao contrário dos ambientes de desenvolvimento compartilhados, as permissões em ambientes de teste e produção devem ser limitadas ao acesso do usuário para teste.
• Automatize a limpeza de ambientes de desenvolvimento temporários e incentive o uso de ambientes de avaliação para trabalhos de experimentação ou prova de conceito.

Grupos de ambientes

Os grupos de ambientes são flexíveis e permitem acomodar vários casos de uso exclusivos de suas organizações. Aqui estão algumas maneiras pelas quais você pode considerar o agrupamento de ambientes como parte de sua estratégia de ambiente:

• Por serviço ou componente; por exemplo, uma árvore de serviço do ServiceNow
• Desenvolvimento, teste e produção
• Departamentos, grupos de negócios ou centros de custo
• Por projetos
• Por local, se a maioria dos ambientes em um local tiver necessidades de governança semelhantes; isso também pode ajudar a atender a conformidade regulatória e legal regional semelhante

Figura: Grupos de ambientes para dois departamentos diferentes com regras distintas.

Nomenclatura de ambientes e grupos

Como parte de sua estratégia, considere como os ambientes e os grupos são nomeados.

• Os nomes dos ambientes ficam visíveis para administradores, criadores e usuários. Geralmente, somente os administradores usam grupos de ambientes, mas os criadores podem encontrá-los se tiverem privilégios para criar ambientes.

• Os ambientes de desenvolvedor que são criados automaticamente seguem o <Ambiente> do nome do usuário; padrão, por exemplo, "Ambiente de Júlio Almeida." Os grupos de ambiente não são nomeados automaticamente.

• Os nomes de ambiente e grupo de ambientes não precisam ser exclusivos. No entanto, para evitar confusão, a melhor prática é evitar nomes duplicados.

• Os nomes são limitados a 100 caracteres. Nomes mais curtos são mais fáceis de usar.

Convenções de nomenclatura

Estabeleça convenções de nomenclatura consistentes.

• Nomes consistentes ajudam os administradores a saber qual é o propósito do grupo e quais ambientes ele gerencia. Nomes consistentes também facilitam a automação e a geração de relatórios.

  • Uma prática comum é incluir o estágio do ciclo de vida no nome de um ambiente; por exemplo, Desenvolvimento da Contoso, Teste da Contoso, Produção da Contoso. O objetivo é separar claramente os ambientes que têm o mesmo conteúdo, mas finalidades diferentes.

  • Outra prática comum é incluir o departamento ou a unidade de negócios no nome quando o ambiente for dedicado a esse grupo de usuários.

  Por exemplo, você pode decidir que todos os nomes de ambiente ou grupo de ambiente devem seguir o padrão <estágio do ciclo de vida>-<região>-<unidade de negócios>-<finalidade> (Prod-EUA-Finanças-Folha de Pagamento).

• Mantenha os nomes curtos, significativos e descritivos.

• Evite incluir informações confidenciais nos nomes. Elas podem ficar visíveis para qualquer pessoa que tenha acesso ao centro de administração.

• Pense em como seus grupos evoluirão e crescerão ao longo do tempo, e certifique-se de que sua convenção de nomenclatura possa acomodar essas necessidades em evolução.

Ativos no ambiente padrão

Sua estratégia de ambiente deve incentivar (ou impor) o uso de ambientes pessoais de desenvolvimento para reduzir o que é criado no ambiente padrão. No entanto, você deve observar o que os criadores já criaram no ambiente padrão e avaliar como lidar com cada caso de uso. É apropriado deixá-lo no ambiente padrão ou deve ser migrado para outro ambiente?

Uma parte fundamental desse esforço de higiene é identificar aplicativos amplamente utilizados na sua organização que precisam de um ambiente de desenvolvimento protegido, separado do ambiente de produção.

A tabela a seguir lista exemplos de casos de uso e ações de migração. Por fim, sua organização precisa identificar seus próprios casos de uso e fatores de risco associados à saída de ativos no ambiente padrão. Saiba mais sobre quando migrar ativos do ambiente padrão.

Ativos nos ambientes do Dataverse for Teams

Microsoft Dataverse for Teams permite que os usuários criem aplicativos, bots e fluxos personalizados no Microsoft Teams usando o Power Apps, Microsoft Copilot Studio e o Power Automate. Quando o proprietário de uma equipe adiciona esse recurso à sua equipe, um ambiente do Microsoft Power Platform com um banco de dados do Dataverse for Teams é criado e vinculado à sua equipe. Aprenda como estabelecer políticas de governança para gerenciar os ambientes do Microsoft Dataverse for Teams.

Estratégia de ambiente internamente na Microsoft

A Microsoft se considera "Cliente Zero" porque adota internamente o Power Platform para impulsionar a automação e a eficiência para os funcionários. Os números a seguir mostram a escala de uso no locatário interno da Microsoft.

• 50.000-60.000 criadores ativos a cada mês
• Mais de 250.000 aplicativos e mais de 300.000 fluxos
• Mais de 20.000 ambientes

A Microsoft está mudando de sua estratégia de ambiente anterior para uma que usa os recursos de governança do Power Platform mais recentes, incluindo Ambientes Gerenciados, grupos de ambiente e regras.

Como parte da estratégia aprimorada, a Microsoft planeja agrupar cenários com base no tipo de desenvolvimento, propriedade organizacional e nível de risco. Como muita coisa está sendo criada na empresa, é difícil focar em todos os cenários possíveis e personalizar cada caso de uso. Dada a escala de inovação e mudança, a automação é necessária, juntamente com o máximo de controles prontos para uso possível.

A Microsoft está estruturando os ambientes do Power Platform em três categorias amplas que abrangem sete casos de uso, refletindo diferentes graus de risco e controle: produtividade pessoal, colaboração em equipe e desenvolvimento empresarial.

• Produtividade pessoal: para usuários que só queiram compilar um aplicativo ou um fluxo para si, sem colaborar com outras pessoas. Esses usuários são encaminhados para ambientes de desenvolvimento pessoal. Esses ambientes bloqueados usam recursos de Ambiente Gerenciado, incluindo restrição de compartilhamento e controle de outras ações. Conectores e ações nesses ambientes são muito restritos. Esses ambientes são os menos arriscados. O uso de ambientes pessoais bloqueados permite que os usuários evitem o processo de conformidade mais rigoroso necessário para criar aplicativos e fluxos de produtividade pessoal.

• Colaboração em equipe: para usuários que estejam criando ferramentas, automação e processos para a equipe. Para esse cenário, a Microsoft recomenda o uso de ambientes do Dataverse for Teams. O ciclo de vida, o gerenciamento de acesso e a rotulagem de dados são controlados no nível de grupo do Microsoft 365, eliminando a necessidade de passar tempo gerenciando esses usuários de uma perspectiva de governança do Power Platform. Esse nível de uso é o próximo passo no espectro de risco.

• Nível de desenvolvimento/produção empresarial usado por todos os funcionários: para usuários que compilem ferramentas ou soluções usadas de maneira mais abrangente em toda a empresa. Esses ambientes podem armazenar os dados mais confidenciais, usar conectores mais avançados e exigir mais governança. Este nível apresenta o maior risco e, portanto, um esforço significativo é despendido em governança. O ALM é necessário, com o trabalho de pré-produção acontecendo em ambientes de área restrita e apenas soluções gerenciadas permitidas em ambientes de produção. Esses ambientes devem estar vinculados ao ServiceTree, que impõe revisões recorrentes de segurança e privacidade. As regras do grupo de ambientes são personalizadas com base em metadados e sinais do ServiceTree. Muitos grupos e regras de ambiente são usados para gerenciar e controlar esses ambientes.

A estratégia de governança da Microsoft não é estática. É fluida e muda para se adaptar a novos desafios e incorporar novos recursos do Power Platform.

Desenvolve sua estratégia de ambiente de locatário

Neste artigo, descrevemos como estabelecer uma estratégia de ambiente de locatário em escala empresarial. A estratégia cresce junto com o seu negócio, independentemente de onde você esteja começando a jornada. Organizações de qualquer tamanho podem se beneficiar da estratégia que apresentamos; no entanto, para organizações que já estão em maior escala, os benefícios são maiores.

Desenvolver uma estratégia de ambiente do locatário não é uma atividade única. É uma jornada. Desenvolva sua estratégia ao longo do tempo conforme suas necessidades mudam. Sua estratégia também deve se ajustar para adotar novos recursos da plataforma e enfrentar novos desafios.

Como todas as jornadas, diferentes organizações se juntam em diferentes pontos ao longo do caminho, mas todas têm o mesmo destino em mente. O que se segue são possíveis acessos que representam onde sua organização está hoje.

Iniciada

Sua organização está no início de sua jornada para adotar o Power Platform. Esse estágio costuma ser conhecido como cenário novo. Você está começando sua jornada no melhor lugar porque não precisa se preocupar com os ambientes existentes ou com o impacto que as novas políticas podem ter sobre como as pessoas em sua organização estão usando o Power Platform. Este é o melhor momento para implementar uma estratégia de ambiente em escala empresarial alinhada com os recursos e as melhores práticas do produto.

Explore os principais recursos e estratégias de ambiente descritos neste artigo. Reserve um tempo para entender os principais temas e as considerações e decisões que você precisa tomar para projetar e implementar uma estratégia de ambiente de locatário que melhor se adapte às suas necessidades.

Estabelecer uma base sólida agora é essencial para evitar ter que lidar com uma situação fora de controle que pode ocorrer mais tarde se você começar sem uma estratégia definida. Planeje a aceleração rápida de seu uso do Power Platform, mas evite a tentação de projetar demais sua estratégia de ambiente, adicionando complexidade que não é necessária. Lembre-se, esta é uma jornada, e você pode continuar a evoluir sua estratégia à medida que suas necessidades mudam.

Align

Sua organização tem e está executando uma estratégia de ambiente que precisa ser modificada para estar alinhada com novos recursos e melhores práticas do Power Platform. Esse estágio costuma ser conhecido como cenário existente. Ao contrário das organizações que estão começando, você precisa considerar o impacto na sua organização da mudança de sua estratégia de ambiente.

Explore os principais recursos e estratégias do ambiente descritos neste artigo e avalie o que é necessário para evoluir sua estratégia para estar mais alinhada. Normalmente, tudo o que é necessário são ajustes incrementais. Quando possível, planeje a distribuição de alterações para minimizar o impacto sobre os usuários.

As sugestões a seguir são alterações incrementais comuns que você pode implementar:

• Para iniciar o alinhamento sem afetar os ambientes existentes, crie um grupo de ambientes que contenha novos ambientes de desenvolvedor e estabeleça regras de como você deseja controlá-los. Ative o roteamento do ambiente para garantir que todos os ambientes de desenvolvedor novos sejam criados no grupo designado.

• Avalie sua estratégia de agrupamento e, se necessário, crie grupos para dar suporte aos ambientes existentes. Estabeleça regras para os grupos que se alinhem com as restrições e exceções existentes. Mova os ambientes existentes para esses grupos.

• Identifique aplicativos amplamente populares que são criados e usados no ambiente padrão. Use pipelines para publicá-los em um ambiente de produção onde os usuários da sua organização possam executá-los. Em seguida, trabalhe na migração do desenvolvimento desses aplicativos para um ambiente de desenvolvedor individual ou um ambiente de desenvolvimento dedicado.

• Crie um plano para identificar, colocar em quarentena e remover ativos no ambiente padrão que não estão sendo usados.

Melhorar

A estratégia de ambiente que você está executando já está alinhada com os recursos e práticas recomendadas mais recentes, mas sua organização deseja adicionar mais controles ou recursos.

Comunique a estratégia de seu ambiente para sua organização

Você implementará sua estratégia de ambiente de locatário com mais êxito se seus usuários do Power Platform entenderem e estiverem alinhados com o que você está tentando alcançar. Se você simplesmente ativar sua estratégia sem qualquer comunicação, os usuários verão as mudanças como restrições e procurarão maneiras de contorná-las.

Como parte do desenvolvimento ou da evolução de sua estratégia, decida como informar os usuários sobre os principais elementos da estratégia que afetam seu uso do Power Platform. Eles não precisam de todos os detalhes técnicos da sua estratégia, apenas do essencial que os ajuda a permanecer produtivos. Por exemplo, comunicar:

• O objetivo do seu ambiente padrão
• Onde eles devem criar novos ativos low-code
• Como eles devem usar seu ambiente de desenvolvedor pessoal
• Como solicitar ambientes personalizados para unidades de negócios ou projetos específicos
• Políticas gerais de uso de conectores e como solicitar mais privilégios de conector para seus ambientes
• Como compartilhar o que eles constroem com outras pessoas
• As responsabilidades de um criador, por exemplo:
  • Manter o locatário limpo. Excluir seus ambientes, aplicativos e fluxos se eles não forem mais necessários. Usar ambientes de teste durante a experimentação.
  • Compartilhar de forma eficiente. Atentar-se ao compartilhamento excessivo dos seus ambientes, aplicativos, fluxos e conexões compartilhadas.
  • Proteger os dados da organização. Evitar mover dados de fontes de dados confidenciais ou altamente confidenciais para um armazenamento externo ou não protegido.
• Quando sua estratégia mudar, compartilhe como as alterações afetam seus usuários para que eles saibam o que fazer de maneira diferente

Um bom começo é ativar o conteúdo de boas-vindas do criador no grupo de ambientes onde novos criadores são adicionados.

Figura: Use o conteúdo de boas-vindas para ajudar novos criadores a serem bem-sucedidos.

Outra abordagem eficaz para se comunicar com seus usuários é estabelecer um hub interno do Power Platform. O hub pode ser um lugar para as pessoas colaborarem em projetos, compartilharem ideias e descobrirem novas maneiras de aplicar a tecnologia para alcançar mais. O hub é onde você também pode compartilhar informações detalhadas sobre sua estratégia ambiental que sejam relevantes para seus usuários. Aprenda a criar um hub interno do Power Platform.

Conclusão

Neste artigo, exploramos os recursos projetados para ajudar sua organização a gerenciar ambientes do Power Platform em escala empresarial e incorporá-los à sua estratégia de ambiente de locatário.

Conforme sua organização adota o Power Platform e o uso acelera, a necessidade de ambientes pode mudar rapidamente. Você precisa de uma abordagem ágil que ajude sua estratégia de ambiente a acompanhar as mudanças e continuar a atender aos requisitos de governança em evolução da sua organização.

Um fator-chave para o sucesso de uma estratégia de ambiente de locatário é comunicar-se com seus criadores e usuários e obter o apoio deles. Certifique-se de que as pessoas que criam aplicativos low-code e automações saibam como seguir a estratégia de ambiente da sua organização e onde devem criar seus ativos low-code.

A jornada de cada organização para adoção ao Power Platform é única. Apresentamos algumas ideias para ajudar você a começar. Sua equipe de conta Microsoft ou parceiro do Power Platform pode ajudá-lo a criar uma estratégia de ambiente de locatário mais personalizada para sua organização.

Informações relacionadas

• Grupos de ambiente
• Roteamento de ambiente
• Segurança empresarial com Power Platform (white paper)
• Segurança e governança low-code
• Conceitos de solução no ALM