Compartilhar via


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 white paper mostra como alinhar sua estratégia de ambiente de 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.

Observação

Você pode salvar ou imprimir este white paper selecionando Imprimir no seu navegador e, em seguida, selecionando Salvar como PDF.

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 muitos Perspectivas estejam disponíveis para gerenciar Power Platform ambientes, a abordagem neste artigo se alinha com a direção mais recente do produto Microsoft e usa recursos atuais e aprimoramentos planejados para curto prazo. Esta orientação atualizada pode ajudar você a garantir que você use apenas os recursos e opções de ambiente que são estratégicos para a maneira como você pretende gerenciar ambientes em escala. Microsoft

MicrosoftVisão da estratégia do ambiente do inquilino

Muitas organizações iniciam sua jornada do Power Platform com aplicativos e automações de produtividade pessoal criados e executados 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 acelera, Microsoft fornece às organizações uma rampa de acesso para uma estratégia de ambiente para adoção em escala empresarial de todos os Power Platform recursos. 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 pode fornecer mais insights para ajudar as organizações a definir seu roteiro para alcançar a adoção em escala empresarial, além de sua estratégia ambiental. 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 seus documentos. Em vez disso, você pode usar os recursos do ambiente para orientar os criadores para seu próprio ambiente pessoal, onde eles podem criar seus aplicativos com segurança protegidos contra criadores que trabalham em ativos não relacionados, com governança simplificada para os administradores. Os colegas de trabalho podem ser adicionados como mais criadores a esses ambientes para colaborar na criação de soluções.

Ilustração de uma estratégia de ambiente compartilhado central com quatro criadores usando o ambiente padrão à esquerda e uma estratégia de roteamento de ambiente com quatro criadores roteando para ambientes de desenvolvedor separados à direita.

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 poderá usar a integração contínua anexada ao ambiente do desenvolvedor para promovê-lo a um ambiente de produção, no qual os usuários poderão executar o recurso isolado de qualquer atividade contínua do criador.

Você deve priorizar os recursos internos da plataforma para gerenciar ambientes quando possível, em vez de criar suas próprias ferramentas. Se os recursos internos não atenderem aos requisitos exclusivos da sua organização, você poderá usar as ferramentas de administração da plataforma para criar ferramentas personalizadas. Você deve avaliar qualquer ferramenta personalizada em relação a novos recursos, à medida que eles se tornam disponíveis. Ficar de olho no roteiro da plataforma e manter seu próprio roteiro pode ajudar a tornar isso mais fácil. Microsoft

Você deve estabelecer sua estratégia de ambiente usando os recursos de ambiente recomendados adaptados às necessidades exclusivas de sua organização. Não pense em criar sua estratégia de ambiente como uma atividade única. Deve evoluir ao longo do tempo para incorporar novos recursos de ambiente, conforme que 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 Power Platform administração, governança e segurança. Uma visão geral completa do recurso está fora do escopo deste documento; no entanto, esta seção destaca os recursos que dão suporte à implementação de uma estratégia de ambiente em escala corporativa.

Tipos de ambiente

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

Tipo Características e usos
Padrão O ambiente que acompanha cada locatário. Muitas experiências do Microsoft 365 usam esse ambiente para personalizações e automações. Este ambiente não se destina a trabalho de longo prazo ou permanente, além dos cenários pessoais, de produtividade do Microsoft 365.
Produção Este ambiente destina-se ao uso para trabalhos permanentes em uma organização. Os ambientes de produção oferecem suporte à retenção estendida de backup de sete para até 28 dias.
Área restrita Esses são ambientes de não produção oferecem suporte a ações de ambiente, como copiar e redefinir. As áreas restritas são usadas melhor em ambientes de teste e criação de ALM.
Developer Esses ambientes especiais destinam-se a espaços de trabalho de desenvolvimento pessoais dos criadores, que isolam ativos low-code de usuários e de outros criadores. Os criadores podem ter até três ambientes de desenvolvedor. Eles não contam na capacidade do locatário. Os ambientes do desenvolvedor que não foram usados por 90 dias serão automaticamente desativados e removidos do seu locatário, se o proprietário não responder às notificações. Os aplicativos do Dynamics 365 estão disponíveis em ambientes de desenvolvedor.
Avaliação Esses ambientes destinam-se a dar suporte a testes e provas de conceito de curto prazo. Eles são limitados a um por usuário. Os ambientes de avaliação são removidos automaticamente de seu locatário após um curto período.
Microsoft Dataverse for Teams Esses ambientes são criados automaticamente quando você cria um aplicativo no Teams ou instala um aplicativo do catálogo de aplicativos. O modelo de segurança para esses ambientes se alinha à equipe à qual estão associados.
Suporte Esses são ambientes especiais criados pelo Suporte para permitir que engenheiros solucionem problemas. Microsoft Esses ambientes não contam na capacidade do locatário.

À medida que você elabora uma estratégia geral de ambiente de locatário, os diferentes tipos são relevantes para dar suporte às recomendações de estratégia.

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.

Mais visibilidade Mais controle Menos esforço
Insights de uso

Administrador hash

Relatórios de licença

Exibição de política de dados

Exportar dados para o Azure Application Insights

Descrições geradas por IA para todos os aplicativos
Limites de compartilhamento

Políticas de dados para fluxos de desktop

Verificador de soluções

Conteúdo de boas-vindas do criador

Firewall de IP

Ligação de cookie IP


Chaves gerenciadas pelo cliente

Caixa de segurança do cliente

Backups estendidos
Ativação fácil

Power Platform oleodutos

Roteamento de ambiente

Grupos e regras ambientais


Power Platform consultor

Reivindicação automática de licença

As políticas de reivindicação automática automatizam a atribuição de Power Apps e Power Automate licenças aos 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.

Após a configuração de uma política, 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 premium do Power Automate.

É recomendável configurar a reivindicação automática de licença, se a sua estratégia de ambiente incluir 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 mantém as configurações do grupo, mas agora um administrador de ambiente pode alterá-las. Isso é 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.

Conceituação de uma estratégia de ambiente para um Locatário da Contoso

Figura: Conceitualização de uma estratégia ambiental para um inquilino 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.

Exemplo de implementação de grupos de ambientes conceituais no locatário real

Figura: Exemplo de implementação dos grupos de ambiente 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 de ambiente redireciona os criadores para seu próprio ambiente de desenvolvimento pessoal e cria novos ambientes de desenvolvedor, conforme necessário.

Diagrama de um criador redirecionado automaticamente para um ambiente de desenvolvedor pessoal, em vez do ambiente padrão ao criar aplicativos

Figura: Um criador é redirecionado automaticamente para um ambiente pessoal, ambiente de desenvolvedor, em vez do ambiente padrão ao criar 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 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 oferece suporte ao roteamento de criadores novos e existentes para 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.

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 Dataverse recurso de solução é aquele que você usa para 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 de origem como o Azure DevOps e 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 ao criar 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. Isso facilita para os ativos estarem prontos para o ALM.

Soluções preferidas

Quando um criador cria um ativo do Dataverse em um ambiente do Dataverse, e não começa a partir de uma solução personalizada, o ativo é associado à solução padrão e talvez também à solução padrão do Common Data Service. A solução padrão é compartilhada por todos os criadores que criam ativos no ambiente. Não há uma maneira fácil de identificar qual criador criou quais componentes ou quais ativos pertencem a quais aplicativos. Isso pode dificultar a promoção de um aplicativo popular para outro ambiente para compartilhamento com um público maior. Você teria que promover todos os ativos na solução padrão, o que não é o cenário 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 criado por eles 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 no 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.

Diagrama que ilustra um pipeline para automatizar a promoção de um ativo armazenado no controle de origem, desde o desenvolvimento, passando pelo teste, até a produção

Figura: Um pipeline automatiza a promoção de um ativo que é armazenado no controle de origem, 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 armazenam as definições de cada pipeline em um ambiente host que gerencia por padrão. Power Platform Microsoft No entanto, você pode definir vários ambientes de host em seu locatário que gerencia, permitindo que você lide com requisitos exclusivos.

Catálogo no Power Platform

Organizações nas quais desenvolvedores e criadores criam e compartilham componentes, como aplicativos e fluxos, e modelos, que são pontos de partida mais avançados para obter mais valor do Power Platform. O Power Platform catálogo facilita para os criadores compartilharem seus componentes e modelos entre ambientes de forma mais eficaz.

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 com vários ambientes com um catálogo instalado.

Roteiro do recurso

À medida que Microsoft continuam a evoluir os recursos do Power Platform que oferecem suporte à governança e administração, você pode acompanhar em 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 exclusivos da sua organização; portanto, vamos começar com um exemplo básico antes de nos voltarmos para como adaptar uma estratégia para atender às suas necessidades.

Neste exemplo, a liderança da Contoso deseja capacitar os funcionários a tirar proveito 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 criou a seguinte topologia de ambiente:

Diagrama de uma topologia de ambiente com quatro grupos de ambientes: Desenvolvimento, Desenvolvimento Compartilhado, UAT e Produção com logotipos para os aplicativos do Power Platform que cada um deve suportar

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

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 prevenção contra perda de dados e as restrições ao compartilhamento limitam outros tipos de atividade dos criadores e colocam barreiras de proteção em torno do que os criadores podem criar nesse ambiente.

Apenas administradores podem criar ambientes de avaliação, área restrita e produção. Os criadores usam um formulário personalizado ou outro processo para solicitar um novo ambiente. Microsoft O Kit de Início do Centro de Excelência (Coe) 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 de Desenvolvimento direciona os criadores do ambiente padrão para seus 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.

Algo que está faltando nesta topologia proposta são pipelines para automatizar a promoção entre ambientes de desenvolvimento, teste e produção. Vamos adicioná-los agora.

Diagrama da mesma topologia de ambiente com a adição de um ambiente de host de pipeline e pipelines entre o host e o UAT de desenvolvimento e ambientes de produção

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

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

Diagrama que ilustra a adição de criadores com mais habilidades a um ambiente para criadores avançados que tem governança flexível

Figura: Adicione mais criadores capazes a um ambiente com regras de governança mais 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.

Diagrama que ilustra o roteamento de ambientes, criando ambientes de desenvolvedor no grupo designado que são movidos para grupos estruturalmente específicos

Figura: Depois que o roteamento de ambiente criar ambientes de desenvolvedor no grupo designado, mova-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. No entanto, 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.

Diagrama que ilustra dois aplicativos corporativos em desenvolvimento em ambientes dedicados e depois testados e implantados em ambientes compartilhados com outros aplicativos

Figura: Dois aplicativos corporativos em desenvolvimento em ambientes dedicados, 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. Isso tem o benefício de proporcionar maior isolamento ao criador, mas pode tornar a combinação do trabalho individual em um ambiente de integração mais complicado. Embora trabalhar isoladamente possa ser útil para equipes maiores e sofisticadas, ele pode adicionar sobrecarga desnecessária a equipes menores que podem ter mais sucesso colaborando em um ambiente de desenvolvimento compartilhado.

Diagrama ilustrando um aplicativo empresarial em desenvolvimento em ambientes individuais combinados em um ambiente de integração compartilhada e depois testados e implantados em ambientes compartilhados com outros aplicativos

Figura: Dois criadores trabalhando no mesmo aplicativo em ambientes de desenvolvedores individuais devem combinar seu trabalho em um ambiente de integração compartilhado antes de passar para testes 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.

Diagrama de duas versões de um aplicativo em desenvolvimento, teste e produção simultaneamente

Figura: A versão 1.0 deve ser corrigida, testada e implantada enquanto 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. Mas 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 entre locatários para ajudar a minimizar o risco de exfiltração de dados entre locatários.
  • Restrinja a criação de novos ambientes de produção de rede aos administradores. Limitar a criação de ambientes é benéfico para manter o controle em geral: tanto para evitar o consumo de capacidade não contabilizado quanto para reduzir o número de ambientes a serem gerenciados. Se os usuários tiverem que solicitar ambientes a partir da TI central, será mais fácil visualizar em que as 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 ao 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 prevenção contra perda de dados (DLP) para o ambiente padrão que bloqueie novos conectores e restrinja os criadores 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.

A proteção do ambiente padrão deve ser uma prioridade. Faça isso junto com a segurança em nível de locatário como parte da primeira etapa na implementação de sua estratégia de ambiente. Sem que elas sejam implementadas, os criadores têm mais oportunidades de adicionar ativos ao padrão. Com eles em vigor junto com o roteamento de ambiente, os criadores são incentivados a usar seu próprio ambiente.

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.

Três níveis de segurança do ambiente: normal, médio-alto e os recursos de segurança que protegem cada um, como políticas DLP e Sistema de Proteção de Dados do Cliente

Figura: Um exemplo de três níveis de segurança ambiental e os recursos de segurança que se aplicam aos ambientes em cada nível.

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.

Alinhe ambientes à sua estratégia de prevenção contra perda 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 ambientes não têm uma regra para aplicar uma política DLP a um ambiente. No entanto, você pode alinhar sua estratégia de DLP com seus grupos de ambiente. Por exemplo, você pode criar uma política DLP com um nome igual ou semelhante a um grupo de ambientes e aplicá-la a ambientes nesse grupo.

Saiba mais sobre como estabelecer uma estratégia de DLP.

Diagrama que ilustra a relação entre grupos de ambientes e políticas de prevenção contra perda de dados com nomes semelhantes que se aplicam a eles

Figura: Neste exemplo, os ambientes no grupo Desenvolvimento Pessoal seguem uma política de DLP que bloqueia todos os conectores não 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 DLP de locatário e ambiente e, nesse caso, como ela se alinha à estratégia de ambiente que você está criando?

Você também pode encontrar alguma inspiração 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 importante do kit de início é sua capacidade de coletar dados sobre o uso da plataforma em seus ambientes, que podem ser úteis à 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.

Captura de tela do painel de visão geral dos ambientes no Power BI mostrando gráficos de blocos numéricos e filtros de relatório

Figura: O painel Ambientes em 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 DLP para seus ambientes.

Fluxograma que ilustra funções e ações de administrador e criador em um processo para solicitar um novo ambiente ou modificar uma política DLP aplicada a um ambiente

Figura: Diagrama de fluxo ilustrando um processo de geranciamento ambiental no Kit Inicial 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:

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 ao criar ambientes para dar suporte a uma carga de trabalho. Sua avaliação deve equilibrar os benefícios do isolamento que um ambiente oferece, por exemplo, ser capaz de bloquear determinados ambientes mais do que outros é útil de uma perspectiva de segurança, com as desvantagens, como o fato de que o isolamento cria atrito para os usuários que tentam 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 da perspectiva da política DLP?

  • 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 criaria problemas com a 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 porque todos eles 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 (além dos ambientes de teste e de desenvolvedor) consume 1 GB para o provisionamento inicial. 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 teste 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

Um diagrama mostrando um grupo de ambientes de finanças e um grupo de ambientes de RH com regras diferentes

Figura: Grupos de ambiente para dois departamentos diferentes têm regras diferentes.

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

Estabeleça uma convenção de nomenclatura consistente.

  • Nomes consistentes ajudam os administradores a saber qual é a finalidade do grupo e quais ambientes ele gerencia, além de facilitar 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.

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.

Evite incluir informações confidenciais nos nomes. Elas podem ficar visíveis para qualquer pessoa que tenha acesso ao centro de administraçã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 da execução desse esforço de proteção é identificar aplicativos que são amplamente usados em sua organização e que devem ter seu próprio 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 mover ativos do ambiente padrão.

Ambiente padrão Ação de migração
Produtividade pessoal do Microsoft 365 Permaneça no ambiente padrão.
Ativos com um único criador que foram usados recentemente, mas não foram compartilhados Mude para o ambiente de desenvolvedor individual do proprietário.
Ativos com um único criador que foram usados recentemente e são compartilhados Mude para o ambiente de desenvolvedor individual do proprietário e execute a partir de um ambiente de produção compartilhado.
Ativos com vários criadores que foram usados recentemente e são compartilhados Mude para um ambiente de desenvolvedor compartilhado e execute a partir de um ambiente de produção compartilhado.
Ativos que não foram usados recentemente Notifique o proprietário e passe para a quarentena, se não houver resposta.

Ativos nos ambientes do Dataverse for Teams

Microsoft Dataverse for Teams capacita os usuários a criar aplicativos, bots e fluxos personalizados em Microsoft Teams usando Power Apps, Microsoft Copilot Studio e 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 a estabelecer políticas de governança para gerenciar Microsoft Dataverse for Teams ambientes..

Estratégia ambiental interna em Microsoft

Microsoft considera-se "Cliente Zero", pois adota internamente Power Platform para impulsionar a automação e a eficiência entre seus funcionários. Os números a seguir fornecem uma ideia da escala de uso em Microsoft locatários internos.

  • 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

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

Como parte da estratégia aprimorada, planeja agrupar cenários com base no tipo de desenvolvimento, propriedade organizacional e nível de risco. Microsoft Como muita coisa está sendo construída em toda a empresa, é muito difícil se concentrar em todos os cenários possíveis e personalizar para cada caso de uso. Há muita coisa acontecendo, e ele precisa ser automatizado e utilizar o maior número possível de controles prontos para uso.

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

  • Produtividade pessoal – Isso é para alguém que quer apenas criar um aplicativo ou fluxo para si mesmo. Por exemplo, eles não estão colaborando com outras pessoas. Esses usuários são roteados para ambientes de desenvolvimento pessoal, que são bloqueados. Esses ambientes usam os recursos do Ambiente Gerenciado, incluindo restringir o compartilhamento e também controlar outras coisas que você pode fazer nos ambientes. Os conectores e as ações disponíveis são muito restritos nesse grupo de ambientes. 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 apenas para criar aplicativos e fluxos de produtividade pessoal.

  • Colaboração em equipe – Isso é para usuários que estão criando ferramentas, automação e processos para sua equipe. Para este cenário, Microsoft incentiva o uso de Dataverse for Teams ambientes. O ciclo de vida, o gerenciamento de acesso e a rotulagem de dados são controlados no nível do grupo do Microsoft 365 para que não tenhamos que gastar 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.

  • Desenvolvimento empresarial/nível de produção usado por todos os funcionários – São pessoas que criam ferramentas ou soluções usadas de forma mais ampla em toda a empresa. Esses ambientes podem armazenar os dados mais confidenciais, usar conectores mais avançados e exigir mais governança. Este é considerado o risco mais alto e a maior parte do esforço é utilizado na governança. O ALM é necessário, com o trabalho de pré-produção acontecendo em ambientes de área restrita e apenas soluções gerenciadas são 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.

MicrosoftA estratégia de governança da 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 pode crescer com o seu negócio, independentemente de onde você está começando na 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. Você deve evoluir sua estratégia ao longo do tempo à medida que 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. Isso é frequentemente chamado de 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 necessárias para criar e implementar uma estratégia de ambiente de locatário que melhor atenda à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. Isso é frequentemente chamado de já 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 desenvolvedores e estabeleça regras sobre como você deseja controlá-los. Ative o roteamento do ambiente para garantir que todos os novos ambientes de desenvolvedor 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 ajuda a garantir que eles permaneçam produtivos, como:

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

Captura de tela do conteúdo de boas-vindas para criadores no Power Platform

Figura: Use o conteúdo de boas-vindas para ajudar novos criadores a terem sucesso.

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 pode ser onde você compartilha informações mais detalhadas sobre sua estratégia de ambiente relevantes para seus usuários. Aprenda a criar um hub interno. 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 ajudá-lo a começar com o pé direito. Sua Microsoft equipe de conta ou Power Platform parceiro pode ajudar você a criar uma estratégia de ambiente de locatário mais personalizada para sua organização.

Recursos