Desenvolver uma estratégia de ambiente de inquilino para adotar o Power Platform em escala

O percurso de adoção de cada organização do Microsoft Power Platform é exclusivo. Uma estratégia de ambiente de inquilino estabelece a fundação para ajudar a acelerar a utilização de uma forma gerível e segura.

Este artigo mostra-lhe como alinhar a sua estratégia de ambiente de inquilino do Power Platform com as capacidades e a visão do produto. Fica a saber como utilizar melhor as caraterísticas mais recentes da plataforma para implementar uma estratégia que permite que a sua adoção do Power Platform alcance a escala empresarial.

Introdução

O Power Platform capacita as organizações a criar soluções low-code para inovação rápida. Estas soluções podem focar-se na produtividade de indivíduos e equipas pequenas, ou aplicar-se a toda a organização. Podem também estender-se aos processos empresariais, incluindo parceiros e clientes externos. A suportar estas soluções estão ambientes do Power Platform, onde os recursos de low-code são criados, testados e utilizados. À medida que uma organização aumenta a sua adoção do Power Platform, implementar uma boa estratégia de ambiente de inquilino é essencial para torná-la gerível e segura à medida que o número de ambientes cresce.

Para o ajudar a ter mais sucesso, este artigo orienta-o sobre a melhor forma de utilizar as caraterísticas disponíveis para estabelecer a sua primeira estratégia de ambiente ou evoluir os seus planos atuais. Também descrevemos a nossa visão sobre como estas caraterísticas devem funcionar em conjunto e como evoluirão para gerir o Power Platform em escala. Nesta orientação, estabelecemos como encaminhar adequadamente novos utilizadores para ambientes e ambientes de grupo para aplicar consistentemente a governação, as regras de segurança e outros aspetos importantes de uma estratégia de ambiente de inquilino. Também fornecemos passos detalhados para proteger o seu ambiente predefinido, que é um primeiro passo crítico na implementação de uma estratégia de ambiente.

Embora estejam disponíveis muitas perspetivas para a gestão de ambientes do Power Platform, a abordagem neste artigo alinha-se com a mais recente direção de produto da Microsoft e utiliza caraterísticas atuais e melhoramentos planeados a curto prazo. Esta orientação atualizada pode ajudá-lo a garantir que utiliza apenas as caraterísticas e opções do ambiente que são estratégicas para a forma como a Microsoft pretende que efetue a gestão de ambientes em escala.

Visão estratégica de ambiente de inquilino da Microsoft

Muitas organizações iniciam o percurso do Power Platform com aplicações de produtividade pessoais e automatizações criadas e executadas num ambiente central partilhado denominado ambiente predefinido. Frequentemente, estes recursos utilizam apenas as capacidades básicas incluídas e o Microsoft 365, e não utilizam todas as capacidades do Power Platform. À medida que esta adoção inicial acelera, a Microsoft fornece às organizações uma rampa para uma estratégia de ambiente para adoção em escala empresarial de todas as capacidades do Power Platform. Estas funcionalidades de governação premium ficam disponíveis quando os utilizadores têm uma licença premium da Power Platform (Power Apps, Power Automate, Microsoft Copilot Studio e Dynamics 365). O modelo de maturidade da adoção do Power Platform fornece mais informações para ajudar as organizações a definir o respetivo mapa de objetivos para alcançar a adoção em escala empresarial para além da sua estratégia de ambiente. Esta abordagem pode ajudar as organizações a amadurecer desde a produtividade pessoal básica até à adoção em escala empresarial do Power Platform.

As caraterísticas administrativas, de governação e de segurança do Power Platform permitem que as organizações adotem e façam a gestão do Power Platform para produtividade empresarial e da utilização de aplicações empresariais em escala. A utilização de Ambientes Geridos ativa um conjunto de capacidades premium que permitem maior visibilidade e controlo, bem como reduzem o esforço manual de administrar e proteger ambientes. Ao utilizar estas capacidades, pode assegurar a aplicação consistente das suas políticas de governação e segurança. Os admins podem efetuar a transição para uma estratégia de ambiente de escala empresarial utilizando estas capacidades. Passar menos tempo e esforço na administração ajuda a reduzir o custo total de posse (TCO) global da plataforma à medida que a sua organização dimensiona a utilização.

Um elemento-chave da transição para a escala empresarial é melhorar a estratégia de ambiente partilhado e central para os criadores, facilitando a utilização de ambientes pessoais de programação. Numa estratégia de ambiente central partilhada, os criadores criam, utilizam e partilham aplicações no ambiente predefinido. Esta estratégia pode resultar na falta de isolamento e fazer com que os criadores se sobreponham uns aos outros. Imagine se todos na empresa partilhassem uma única pasta do OneDrive para todos os documentos. Em vez disso, use as caraterísticas do ambiente para orientar os criadores para o seu próprio ambiente pessoal, onde podem criar com segurança as suas aplicações protegidas de criadores que trabalham em recursos não relacionados, com governação simplificada para administradores. Os colegas de trabalho podem ser adicionados como mais criadores a estes ambientes para colaborarem na criação de soluções.

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

Os ambientes de criador recém-criados podem ser automaticamente adicionados a um grupo que aplica regras para garantir que os ambientes têm políticas de governação e de segurança consistentes. Os admins podem processar exceções ao mover o ambiente de um criador para um grupo com regras relaxadas.

Os recursos de low-code criados pelos criadores representam a fase inicial no percurso de gestão do ciclo de vida das aplicações (ALM) de um recurso. Como parte desta fase inicial, é importante capturar cada versão de um recurso e conseguir recriá-la, se necessário. Quando o recurso está pronto para ser partilhado, o criador pode usar a integração contínua anexada ao ambiente de programação para o promover a um ambiente de produção. Os utilizadores podem então executar o recurso, isolado de qualquer atividade em curso de criador.

Priorize as caraterísticas incorporadas da plataforma para gerir ambientes quando possível, em vez de criar as suas próprias ferramentas. Se as caraterísticas incorporadas não satisfizerem os requisitos exclusivos da sua organização, use as ferramentas de administração da plataforma para criar ferramentas personalizadas. Deve avaliar quaisquer ferramentas personalizadas em relação a novas caraterísticas à medida que ficam disponíveis. Monitorizar o mapa de objetivos da plataforma da Microsoft e alinhá-lo com o seu próprio mapa de objetivos facilita este processo.

Estabeleça a sua estratégia de ambiente usando as capacidades de ambiente recomendadas adaptadas às necessidades exclusivas da sua organização. Não pense em criar a sua estratégia de ambiente como uma atividade única. Deverá evoluir ao longo do tempo para incorporar novas caraterísticas de ambiente à medida que se tornam disponíveis.

Caraterísticas que suportam uma estratégia de ambiente de escala empresarial

Os Ambientes são um bloco modular para administração, governação e segurança do Power Platform. Uma descrição geral completa da caraterística está fora do âmbito deste artigo; no entanto, esta secção realça as caraterísticas que suportam a implementação de uma estratégia de ambiente em escala empresarial.

• Tipos de ambientes descreve as diferentes utilizações de ambientes como parte da sua estratégia.
• Ambientes Geridos fornecem um conjunto de capacidades premium que facilitam a gestão de ambientes em escala.
• Reivindicação automática de licenças simplifica a atribuição de licenças ao permitir que os utilizadores afirmem licenças do Power Apps por utilizador quando forem necessárias, em vez de exigir que um administrador identifique os utilizadores que precisam de licenças com antecedência.
• Regras e grupos de ambientes explica como gerir ambientes como grupos e aplicar regras a grupos para automatizar políticas de governação consistentes.
• Encaminhamento de ambientes predefinido afasta automaticamente os criadores da criação de recursos no ambiente predefinido para o respetivo ambiente pessoal.
• Microsoft Dataverse proporciona maior segurança e ALM.
• Soluções preferidas ajudam os criadores a garantir que todos os recursos que criam estão numa solução do Dataverse, facilitando a sua promoção para outros ambientes.
• Pipelines no Power Platform fornecem um processo simplificado para promover recursos desde ambientes de programação até ambientes de teste e produção, disponibilizando integração e implementação contínuas (CI/CD) a todos os criadores.
• Catálogo no Power Platform permite que os criadores partilhem componentes, como aplicações e fluxos, bem como pontos de partida mais avançados, como modelos.

Tipos de ambientes

A tabela que se segue descreve os tipos de ambientes que pode criar, as respetivas caraterísticas e utilizações pretendidas.

Ao criar uma estratégia geral de ambiente de inquilino, considere os diferentes tipos para suportar as suas recomendações.

Ambientes Geridos

Os ambientes têm um conjunto base de funcionalidades e caraterísticas, dependendo do tipo de ambiente. Os Ambientes Geridos expandem as caraterísticas base para fornecer um conjunto de capacidades premium que permitem aos admins gerir mais facilmente o Power Platform em escala com mais controlo, menos esforço e mais informações. Estas capacidades são desbloqueadas quando define um ambiente como gerido.

A tabela que se segue lista as caraterísticas de Ambientes Geridos que estão disponíveis, até ao momento em que este artigo foi escrito. São adicionadas novas caraterísticas com frequência, por isso, consulte a documentação para obter a lista mais recente. Embora todas as caraterísticas possam ajudá-lo a criar uma estratégia de ambiente, as caraterísticas em itálico são mais relevantes para a estratégia descrita neste artigo.

Reivindicação automática de licenças

As políticas de reivindicação automática automatizam a atribuição de licenças do Power Apps e do Power Automate aos utilizadores quando estes precisam de uma para usar determinadas aplicações ou caraterísticas. A automatização pode ajudar a reduzir o número de licenças consumidas e evitar a sobrecarga da atribuição manual de licenças.

Após a configuração de uma política, qualquer utilizador na organização que necessite de uma licença do Power Apps individual recebe-a automaticamente sob as seguintes condições:

• Se um utilizador sem uma licença do Power Apps autónoma iniciar uma aplicação que exija uma licença premium, o sistema atribui automaticamente ao utilizador uma licença do Power Apps por utilizador.

• Se um utilizador sem uma licença do Power Apps autónoma iniciar uma aplicação num Ambiente Gerido, o sistema atribui automaticamente ao utilizador uma licença do Power Apps por utilizador.

Da mesma forma, após a configuração de uma política, qualquer utilizador na organização que necessite de uma licença do Power Automate individual recebe-a automaticamente sob as seguintes condições:

• O utilizador aciona, guarda ou ativa um fluxo de cloud premium com RPA (Automatização Robótica de Processos) assistida.

• O utilizador solicita uma licença do Power Automate Premium.

Recomendamos a configuração da reivindicação automática de licenças se a sua estratégia de ambiente incluir Ambientes Geridos. Os utilizadores de aplicações e de fluxos encontram a menor fricção de licenciamento e só consomem licenças para utilizadores que estão a executar aplicações ou a utilizar o Power Automate ativamente.

Grupos e regras de ambiente

À medida que a adoção do Power Platform no seu inquilino aumenta, também o número de ambientes que requerem administração e governação. À medida que o número de ambientes aumenta, mais desafiante se torna garantir que aplicou definições e políticas de governação consistentes nos ambientes. A caraterística de grupos de ambiente facilita esta tarefa, permitindo-lhe criar grupos nomeados e associar ambientes a eles, tal como colocar documentos relacionados numa pasta de ficheiros.

Tenha em mente as seguintes considerações quando pensar em utilizar grupos de ambientes:

• Um ambiente tem de ser gerido para ser incluído num grupo.
• Um ambiente só pode estar num grupo de cada vez.
• Um ambiente pode ser movido de um grupo para outro.
• Os ambientes num grupo podem ser de várias regiões geográficas.
• Os grupos não podem conter outros grupos.

Para o ajudar a aplicar definições e governação consistentes, os grupos de ambientes podem ter uma ou mais das seguintes regras configuradas e ativadas:

• Controlos de partilha para aplicações de tela
• Informações de utilização
• Conteúdo de boas-vindas para criadores
• Imposição do verificador de soluções
• Retenção de cópias de segurança
• Descrições geradas por IA

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

Quando uma regra de grupo está a gerir uma definição, as definições individuais do ambiente são bloqueadas. A única maneira de alterá-las é modificar a regra. Se o ambiente for removido do grupo, mantém as definições do grupo, mas um administrador do ambiente pode alterá-las. Esta abordagem é importante para uma estratégia de ambiente porque garante que um administrador do ambiente não pode substituir as políticas definidas para o grupo.

A utilização de grupos de ambientes permite-lhe organizar os ambientes de forma lógica, semelhante à estrutura, hierarquia de serviços de produtos da sua organização ou outras estruturas que exploraremos posteriormente. O diagrama a seguir é um exemplo conceptual de como a organização Contoso poderá pensar organizar os seus grupos de ambiente.

Figura: Concetualização de uma estratégia de ambiente para um inquilino da Contoso.

Quando estiver a planear as regras a configurar, pense no que poderá aplicar em cada nível da hierarquia conceptual. Embora ainda não possa configurar a hierarquia de grupo, pode utilizar uma combinação de convenções de nomenclatura e configuração de regras para implementar o seu design conceptual. Por exemplo, considerando a conceptualização do inquilino da Contoso mostrada anteriormente, a ilustração a seguir representa os grupos de ambientes que a organização poderia utilizar para implementar a respetiva estrutura.

Figura: Exemplo de implementação dos grupos de ambientes concetuais no inquilino real

Posteriormente neste artigo, exploramos mais formas de utilizar grupos de ambientes como parte de uma estratégia de ambiente de inquilino.

Encaminhamento de ambiente predefinido

Uma parte fundamental da estratégia de ambiente que descrevemos neste artigo é afastar os criadores da criação de recursos no ambiente predefinido. A caraterística de encaminhamento de ambiente redireciona os criadores para o respetivo ambiente de programação pessoal e cria novos ambientes de programação, conforme necessário.

Figura: Um criador redirecionado automaticamente para um ambiente de programação pessoal em vez do ambiente predefinido ao criar aplicações.

Os ambientes de programação criados por encaminhamento são geridos por predefinição. Os utilizadores com licenças do Plano de Programador estão limitados à criação e pré-visualização de recursos no ambiente. Para executar os recursos como utilizador, precisam de uma licença adequada.

Pode utilizar o encaminhamento de ambiente sozinho, mas a forma recomendada é utilizá-lo com grupos de ambientes. Quando utilizado desta forma, qualquer ambiente criado é associado ao grupo que designar para conter todos os novos ambientes de programação, garantindo que é imediatamente coberto pelas suas políticas de governação.

São atribuídos automaticamente aos criadores um direito de acesso que os torna administradores do ambiente do respetivo ambiente de programação. Quando o ambiente faz parte de um grupo de ambientes, o criador, como administrador do ambiente, não pode alterar as definições do ambiente porque são geridas pelas regras do grupo de ambientes. Apenas os admins, que podem modificar as regras de grupo, podem efetuar alterações.

Pode impor ainda mais controlo de duas maneiras. Primeiro, pode remover a permissão de criação manual de ambientes de programação nas definições do seu inquilino. Quando esta opção está definida, os criadores não podem criar ambientes no portal de administração. Também não terão um criado automaticamente pela política de encaminhamento. Em segundo lugar, pode especificar um grupo de segurança, na política de encaminhamento, para limitar quem pode obter automaticamente um ambiente criado.

Inicialmente, o encaminhamento de ambientes suporta o encaminhamento de criadores novos e existentes para longe do ambiente predefinido quando utilizam make.powerapps.com. Ao longo do tempo, outros serviços do Power Platform suportarão a caraterística de encaminhamento de ambientes.

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 adiciona o seu próprio conteúdo de ajuda, este substitui a experiência de ajuda padrão inicial 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 identifique 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 avise seus criadores sobre restrições e possíveis limitações e inclua um link para o site ou documento de políticas da sua organização.

Por exemplo, talvez você queira informar os fabricantes a usar o ambiente padrão somente para soluções relacionadas a aplicativos do Microsoft 365, evitar o uso de aplicativos de produção no ambiente padrão e compartilhar seus aplicativos de tela apenas com um número limitado de indivíduos. O exemplo a seguir mostra como criar essa mensagem nas configurações de Ambientes Gerenciados:

Exemplo de entrada 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 são normalmente usados para implantar soluções que suportam a 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ê tiver uma política de atualização de 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 sobre qual é a equipe certa com a qual devem entrar 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 programação

Os ambientes de desenvolvedores são, na maioria das vezes, 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á uma saída de exemplo para um ambiente de desenvolvedor:

Ambientes Sandbox

Normalmente, os ambientes de área restrita são usados para testar soluções. Como alguns testes envolvem um número significativo de usuários, esses ambientes são dimensionados até certo ponto e têm mais capacidade do que um ambiente de desenvolvedor. Os ambientes Sandbox 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 sandbox ou ambiente de teste.

Limitar partilha

Os administradores podem limitar a abrangência com que os utilizadores podem compartilhar aplicações de grelha, fluxos e agentes. No entanto, o limite só se aplica a partilhas futuras. 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 os 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 aplicações canvas, fluxos de trabalho e agentes.

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

• Os recursos são partilhados num ambiente de produtividade pessoal. Se você tiver um ambiente onde os usuários possam criar recursos para seu próprio trabalho, recursos sem valor comercial global ou recursos sem suporte de TI, é importante que você não permita que os criadores os compartilhem em toda a organização. Se os recursos começam como produtividade pessoal, mas depois se tornam populares e são amplamente utilizados, esteja atento ao limite que você estabeleceu para compartilhar. Um limite comum é entre 5 e 50 usuários.

• Os recursos são partilhados 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 for que os recursos sejam compartilhados com um grupo de segurança que inclua todos os usuários autorizados a executar o recurso e seja gerenciado pelo departamento de TI, convém impedir que os criadores compartilhem com outros grupos de segurança.

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

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

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

• Área restrita: selecione Excluir compartilhamento com grupos de segurança e deixe a opção Limitar o total de indivíduos que podem compartilhar como desmarcada. 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 fabricante, usuário ou 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 a opção Limitar o total de indivíduos que podem compartilhar como desmarcada.

Microsoft Dataverse

O Dataverse armazena e gere dados em segurança que são utilizados por aplicações. No contexto de uma estratégia de ambiente, a caraterística de solução do Dataverse permite-lhe transportar aplicações e componentes de um ambiente para outro. Os criadores criam os próprios recursos em contentores, soluções, que monitorizam o que criam. As soluções podem ser facilmente transportadas para outros ambientes. Com esta abordagem, pode separar ambientes de programação, onde os criadores criam recursos, dos ambientes de produção onde são utilizados. Tanto os criadores como os utilizadores são beneficiados. Os criadores podem continuar a evoluir os recursos e os utilizadores não são surpreendidos por alterações súbitas. Quando os criadores estiverem prontos para publicar as alterações, podem pedir para promover o recurso atualizado para o ambiente de produção.

As soluções do Dataverse são o mecanismo de implementação do ALM em produtos do Power Platform, como o Power Apps e o Power Automate. Os pipelines no Power Platform utilizam soluções para automatizar CI/CD de recursos criados pelos criadores. As soluções podem ser exportadas do Dataverse e armazenadas numa ferramenta de controlo de código fonte, como o Azure DevOps ou o GitHub. A solução no controlo de código fonte torna-se a origem da verdade se precisar de recriar o ambiente de programação. Por exemplo, se um criador criou uma aplicação popular e, em seguida, eliminou o ambiente de programação, uma solução exportada armazenada no controlo de código fonte poderia ser utilizada para recriar um ambiente de programação viável.

Outra consideração importante quando cria um ambiente com o Dataverse é se alguma aplicação do Dynamics 365 será implementada no ambiente. Se o potencial existir, tem de ativar o Dynamics 365 quando criar o ambiente ou não conseguirá instalar aplicações do Dynamics 365 posteriormente.

Recomendamos que aprovisione o Dataverse em qualquer ambiente onde os criadores criem recursos que serão partilhados com outros utilizadores. Esta estratégia facilita que os recursos estejam prontos para ALM.

Soluções preferenciais

Quando um criador cria um recurso do Dataverse num ambiente do Dataverse, e não inicia a partir de uma solução personalizada, o recurso é associado à solução predefinida e também pode ser associado à solução predefinida do Common Data Service. A solução predefinida é partilhada por todos os criadores que criam recursos no ambiente. Identificar que criador criou componentes específicos ou que recursos pertencem a aplicações específicas é um desafio, dificultando a promoção de uma aplicação popular noutro ambiente para partilhar com uma audiência maior. Para tal, precisa de promover todos os recursos na solução predefinida, o que não é ideal.

Para suportar a sua estratégia de ambiente e facilitar o trabalho com ela, os criadores devem criar uma solução personalizada no ambiente de programação e, em seguida, defini-la como a solução preferencial no ambiente. Os criadores definem a solução preferida num ambiente para indicar a que solução um recurso que criaram deve ser associado. As soluções preferidas podem ajudar a garantir que, quando os criadores utilizam pipelines para promover os seus recursos para outros ambientes, a solução promovida contém todos os recursos necessários. Pense nisto como preparar os recursos para estarem prontos para ALM.

Pipelines no Power Platform

Como vimos, um princípio fundamental de uma boa estratégia de ambiente é isolar onde um recurso é criado, a partir de onde é implementado e utilizado. Esta separação assegura que os utilizadores que estão a tentar utilizar um recurso não encontram tempo de inatividade porque um criador o está a atualizar. No entanto, requer que os recursos sejam promovidos para um ambiente de produção, idealmente, como parte de uma solução do Dataverse, antes de poderem ser utilizados.

As soluções do Dataverse podem ser transportadas manualmente entre ambientes. No entanto, pode automatizar o processo, e implementar políticas para garantir que ocorre uma gestão de alterações adequada, utilizando pipelines. Consoante as regras de ambiente que definir no verificador de soluções, os pipelines impõem automaticamente todas as regras antes de a solução ser implementada, evitando mais erros de implementação. O diagrama a seguir ilustra como os pipelines podem automatizar a promoção de um recurso desde o desenvolvimento até à produção.

Figura: Um pipeline que automatiza a promoção de um recurso armazenado no controlo de código fonte desde o desenvolvimento, passando pelo teste, até à produção.

Pode configurar o número de ambientes e processos, como aprovações, que necessitam de ser incluídos num pipeline.

Os pipelines funcionam em conjunto com grupos de ambientes. Podem ser pré-configurados para ambientes de programação para permitir que os criadores iniciem facilmente o processo de promoção respondendo a um pedido quando tentam partilhar os seus recursos com outros utilizadores. Como parte de um pedido de implementação que utiliza pipelines, os criadores podem propor com quem partilhar os seus recursos e os direitos de acesso necessários. Um admin de pipelines pode aprovar ou rejeitar o pedido antes da implementação, garantindo privilégios mínimos para o criador que o originou.

Os pipelines no Power Platform armazenam as definições de cada pipeline num ambiente anfitrião que a Microsoft gere por predefinição. No entanto, pode definir vários ambientes de anfitrião no seu inquilino que gere, permitindo-lhe lidar com requisitos exclusivos.

Imposição do verificador de soluções

É comum que uma equipe do Centro de Excelência (CoE) configure guarda-corpos para reduzir o risco de os usuários importarem soluções não compatíveis para um ambiente. Os administradores podem facilmente impor verificações avançadas de análise estática de soluções em relação a um conjunto de regras de práticas recomendadas para identificar padrões problemáticos. As organizações com CoEs descentralizados sentem necessidade de ativar esta aplicação do verificador de soluções, juntamente com o contacto dos criadores por e-mail para oferecer suporte.

A aplicação do verificador de soluções oferece três níveis de controlo: Nenhum, Avisar e Bloquear. Os administradores configuram o efeito da verificação, quer ela forneça um aviso, mas permita a importação ou bloqueie a importação completamente, ao mesmo tempo em que fornece o resultado da importação ao fabricante.

As organizações que usam esse recurso o configuram de forma diferente, dependendo do tipo de ambiente. É normal haver exceções, e esta orientação deve estar sempre alinhada com as 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 e-mails.
• Desenvolvedor: Selecione Avisar e deixe Enviar e-mails desmarcado.
• Sandbox: selecione Avisar e deixe Enviar e-mails desmarcado.
• Produção: selecione Bloquear e Enviar e-mails.
• Ambiente do Teams: selecione Bloquear e Enviar e-mails.

Catálogo no Power Platform

As organizações em que programadores e criadores criam e partilham componentes, como aplicações, fluxos e modelos — pontos de partida avançados — tendem a obter mais valor do Power Platform. O catálogo do Power Platform facilita aos criadores a partilha dos respetivos componentes e modelos entre ambientes.

O catálogo é instalado num ambiente e pode ser instalado com o anfitrião de pipelines no mesmo ambiente. Também é possível lidar com requisitos exclusivos de segmentação de recursos ao ter vários ambientes com um catálogo instalado.

As organizações que incentivam desenvolvedores e criadores a criar e compartilhar componentes e modelos no catálogo obtêm mais valor de seu investimento na 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 a Power Platform adotam um modelo de equipe de fusão, onde desenvolvedores, criadores e administradores profissionais trabalham juntos para ajudar seus colegas funcionários a obter o maior valor possível da plataforma reutilizando soluções, modelos e componentes.

Mapa de objetivos de caraterísticas

À medida que a Microsoft continua a evoluir as caraterísticas do Power Platform que suportam a governação e a administração, pode acompanhar no planeador de versões. Fica a saber o que está planeado, o que está para vir na próxima vaga de lançamento e o que pode experimentar agora. Pode até criar o seu próprio plano de lançamento, ao guardar os itens que pretende seguir.

Base de uma estratégia de ambiente de escala empresarial

Discutimos a nossa visão para uma estratégia de ambiente de inquilino à escala empresarial e as principais caraterísticas de ambiente que a suportam. Agora, vemos como pode utilizar essas caraterísticas em conjunto como parte de uma estratégia de ambiente. A sua estratégia deve basear-se nos requisitos exclusivos da sua organização, por isso, vamos começar com um exemplo básico antes de adaptarmos uma estratégia para satisfazer as suas necessidades.

Neste exemplo, a liderança da Contoso quer capacitar os colaboradores a tirar partido do Power Platform e identificou os seguintes requisitos de alto nível:

• Os colaboradores precisam de ser capazes de criar processos automatizados de aprovação de documentos e outras personalizações do Power Platform com o Microsoft 365.
• Os colaboradores devem ser capazes de criar automatizações do Power Apps e do Power Automate para melhorar a produtividade pessoal.
• Os criadores que estão a trabalhar na aplicação Monitorizador de Conformidade da empresa têm de conseguir desenvolvê-la e mantê-la.

Para suportar estes requisitos, a equipa de administração e governação da Contoso desenvolveu a seguinte topologia de ambiente:

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

Vamos explorar este diagrama de topologia de ambiente em detalhe.

O ambiente predefinido é utilizado 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 maker e colocam guarda-corpos em torno do que os makers podem construir nesse ambiente.

Apenas os admins podem criar ambientes de avaliação, sandbox e produção. Os criadores utilizam um Formulário Microsoft personalizado ou outro processo para pedir um novo ambiente. O Kit de Iniciação do Centro de Excelência (CoE) do Microsoft Power Platform inclui um pedido de ambiente que pode ser utilizado.

São criados quatro grupos de ambientes: Programação, Programação Partilhada, UAT (testes de aceitação de utilizador) e Produção.

• Uma política de encaminhamento de ambiente definida para o grupo Programação encaminha os criadores do ambiente predefinido para os respetivos ambientes de programação. À medida que novos ambientes de programação são criados, são automaticamente associados ao grupo Programação e aplicam-se as regras respetivas.

• O grupo Programação Partilhada suporta ambientes que contêm projetos com vários criadores.

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

• O grupo Produção contém ambientes que alojam aplicações, fluxos e outros artefactos para utilização em produção.

Faltam pipelines a esta topologia proposta para automatizar a promoção entre ambientes de programação, teste e produção. Vamos adicioná-los agora.

Figura: A mesma topologia de ambiente com pipelines a ligar um ambiente anfitrião de pipelines a ambientes de programação, teste e produção.

No diagrama de topologia de ambiente revisto, adicionámos um ambiente anfitrião de pipelines e dois pipelines. Um pipeline move recursos de programação para teste e, em seguida, para ambientes de produção. A regra de pipeline no grupo Programação será modificada para utilizar este pipeline. O outro pipeline move recursos do ambiente de programação partilhada para teste e, em seguida, para produção. A regra de pipeline no grupo Programação Partilhada será modificada para utilizar este pipeline.

Esta estratégia de ambiente básica fornece uma base que pode desenvolver para outros casos de utilização, que exploraremos em seguida.

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

Seguem-se alguns casos de utilização comum que poderá ter de incorporar na estratégia de ambiente de inquilino da fundação.

Controlar que criadores podem criar ambientes de programação

Por predefinição, qualquer pessoa que tenha uma licença do Power Platform Premium, uma licença do Plano de Programador ou uma função de admin de inquilinos do Power Platform, pode criar um ambiente de programação a partir do portal de administração.

Na estratégia do ambiente de base, o encaminhamento de ambiente garante que os criadores são direcionados para longe do ambiente predefinido para um novo ambiente de programação criado no grupo designado. No entanto, os criadores continuam a poder criar manualmente ambientes de programação que não estejam colocados num grupo de ambientes e que não tenham as respetivas regras aplicadas.

Para refinar que criadores são elegíveis para encaminhamento de ambientes, especifique um grupo de segurança na configuração de encaminhamento. Quando um grupo de segurança é configurado, apenas os membros do grupo de segurança são encaminhados. Todos os outros revertem para o ambiente predefinido.

Fornecer mais flexibilidade a criadores avançados

Na estratégia do ambiente de base, todos os novos ambientes de criador são encaminhados para um grupo de ambientes de programação designado. Normalmente, este grupo de ambientes tem um conjunto bastante restritivo de regras de governação aplicadas.

À medida que os criadores se tornam mais avançados, pode permitir-lhes pedir acesso a mais capacidades. Em vez de os remover do grupo de ambientes original e gerir manualmente a exceção, pode utilizar outro grupo de ambientes para monitorizar estes criadores avançados.

Figura: Adicione criadores mais capazes a um ambiente com regras de governação relaxadas.

Organizar ambientes de programação por região ou unidade de negócio

Na implementação atual do encaminhamento de ambientes, todos os novos ambientes de programação são criados num único grupo de ambientes. E se pretender organizar os ambientes de programação dos seus criadores por região ou unidade de negócio, por exemplo?

Utilize o encaminhamento para direcionar os criadores para um novo ambiente de programação criado no grupo designado. Em seguida, pode movê-lo para outro grupo que esteja baseado na região, unidade organizacional ou outros critérios, onde pode aplicar regras de governação mais granulares.

Figura: Depois de o encaminhamento de ambientes criar ambientes de programação no grupo designado, mova-os para grupos estruturalmente mais específicos.

Atualmente, mover ambientes é uma ação manual, mas poderá automatizá-la quando o conector de administração do Power Platform suportar a caraterística de grupo numa atualização futura.

Desenvolver uma aplicação para utilização empresarial

Uma equipa na sua organização pode estar a desenvolver uma aplicação para utilização em toda a empresa. A equipa pode ser orientada para TI ou incluir utilizadores de empresa e de TI (o que é conhecido como uma equipa de fusão).

Na estratégia de ambientes mais simples, a equipa do projeto cria num ambiente partilhado que é um tipo de sandbox ou de produção. Um tipo de ambiente de programação não é a melhor forma de suportar a colaboração de vários criadores num recurso. Os criadores precisam de comunicar entre eles para evitar colisões e conflitos no ambiente partilhado.

Não são necessários ambientes de teste nem de produção dedicados. A aplicação pode ser testada e implementada em ambientes de teste e de produção ao nível da organização que alojam várias aplicações.

Figura: Duas aplicações empresariais em desenvolvimento em ambientes dedicados e, em seguida, testadas e implementadas em ambientes partilhados com outras aplicações.

Numa variação mais avançada, cada criador tem um ambiente de programação individual. Esta estratégia tem o benefício de fornecer um maior isolamento para o criador, mas pode tornar mais complicada a combinação do trabalho individual num ambiente de integração. Embora trabalhar em isolamento possa ser útil para equipas maiores e sofisticadas, pode adicionar sobrecarga desnecessária a equipas mais pequenas que podem ter mais sucesso ao colaborar num ambiente de programação partilhado.

Figura: Dois criadores que trabalham na mesma aplicação em ambientes de programação individuais têm de combinar o trabalho num ambiente de integração partilhado antes de ser movida para teste e produção.

Normalmente, esta variação incorpora uma estratégia de controlo de código fonte, com cada ambiente de programação representado como um ramo no controlo de código fonte, que é unido quando as alterações estão prontas para serem promovidas. É importante ter em conta como a aplicação será mantida após o lançamento inicial.

Por exemplo, a versão 1.0 da aplicação pode estar em produção enquanto a equipa se move para a criação da versão 2.0. A sua estratégia de ambiente tem de suportar a correção de um problema na versão 1.0, enquanto o desenvolvimento da versão 2.0 está em curso.

Figura: A versão 1.0 tem de ser corrigida, testada e implementada enquanto a versão 2.0 está a ser desenvolvida, testada e implementada.

Os grupos de ambientes oferecem várias abordagens para lidar com este cenário de aplicações empresariais. Por exemplo, pode tratar-se de um único grupo de aplicações ou pode envolver ter grupos separados para cada fase de desenvolvimento. Na secção de melhores práticas, exploramos como avaliar as opções.

Minimizar a utilização de ambientes de programação

Os ambientes de programação individuais são a forma recomendada de fornecer aos criadores uma área de trabalho para criar soluções de low-code. Oferecem o mais alto nível de isolamento de outros criadores. Se a sua organização quiser minimizar o número de ambientes de programação, vários ambientes partilhados são melhores do que incentivar os criadores a criar recursos no ambiente predefinido.

Neste cenário, restringiria a criação de ambientes de programação e criaria ambientes de programação partilhados do tipo de produção. Pode organizar estes ambientes partilhados por estrutura organizacional, região ou outros critérios. Um grupo de ambientes pode contê-los para garantir que têm regras de governação consistentes aplicadas. Conceda permissão aos criadores para criarem recursos de low-code no ambiente que lhes é atribuído.

Segurança como parte da sua estratégia de ambiente

Os ambientes são um componente-chave da utilização do Power Platform em segurança. Representam limites de segurança no seu inquilino que ajudam a proteger aplicações e dados. Como parte da estratégia de ambiente, tem de considerar como os requisitos de segurança influenciam o número e a finalidade dos ambientes no inquilino.

Os ambientes permitem-lhe criar vários limites de segurança no seu inquilino para proteger aplicações e dados. A proteção fornecida pelo ambiente pode ser ajustada para satisfazer a proteção de segurança necessária ao aplicar um conjunto configurável de recursos de segurança no ambiente. Uma discussão detalhada dos recursos de segurança do ambiente individual está para além do âmbito deste artigo. No entanto, nesta secção, oferecemos recomendações sobre como pensar na segurança como parte da estratégia de ambiente do inquilino.

Segurança ao nível do inquilino

A maioria das definições de segurança que afetam os ambientes são configuradas individualmente para cada ambiente. No entanto, pode efetuar algumas alterações ao nível do inquilino para ajudar a suportar a sua estratégia de ambiente.

• Considere desativar a caraterística Partilhar com Todos no Power Platform. Só os admins poderão partilhar um recurso com todos.
• Considere proteger a integração com o Exchange.
• Aplique o isolamento entre inquilinos para ajudar a minimizar o risco de transferência de dados não autorizada entre inquilinos.
• Restringir a criação de novos ambientes de produção na rede aos administradores. Limitar a criação de ambientes é benéfico para manter o controlo em geral, tanto para prevenir o consumo de capacidade não contabilizada, como para reduzir o número de ambientes a gerir. Se os utilizadores têm de pedir ambientes a partir da TI Central, é mais fácil ver aquilo em que pessoas estão a trabalhar se os administradores forem os controladores de chamadas.

Proteger o ambiente predefinido

O ambiente predefinido tem uma função no suporte a personalizações de produtividade do Microsoft 365. No entanto, como parte da estratégia de ambiente recomendada, é melhor minimizar a sua utilização o máximo possível. Em vez disso, os criadores devem criar nos seus próprios ambientes isolados. Apesar de não poder bloquear o acesso ao ambiente predefinido, pode minimizar o que pode ser feito nele.

Em primeiro lugar, utilize o encaminhamento de ambiente para direcionar os criadores para a sua própria área de trabalho para criar recursos de low-code.

• Reveja quem tem acesso de administrador ao ambiente predefinido e limite-o às funções que necessitam dele.

• Considere mudar o nome do ambiente predefinido para algo mais descritivo, como "Produtividade Pessoal".

  • Estabeleça uma política de dados para o ambiente padrão que bloqueie novos conectores e restrinja 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 de negócio. Mova todos os conectores bloqueáveis para o grupo de dados bloqueado.

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

Proteger o ambiente predefinido é uma prioridade. Implemente-o com segurança ao nível do inquilino como parte do primeiro passo da sua estratégia de ambiente. Sem estas medidas, os criadores podem adicionar mais recursos ao ambiente predefinido. Com estas medidas e o encaminhamento do ambiente em vigor, os criadores são incentivados a usar o seu próprio ambiente.

Mais informações: Proteger o ambiente predefinido

Proteger outros ambientes

Se a sua organização for como a maioria, tem vários ambientes para além do ambiente predefinido. O nível de segurança que cada um requer pode variar consoante as aplicações e os dados que contiver. Normalmente, os ambientes de programação têm regras mais relaxadas do que os ambientes de produção. Alguns ambientes de produção requerem a maior proteção possível.

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

Figura: Um exemplo de três camadas de segurança de ambiente e as caraterísticas de segurança que se aplicam aos ambientes em cada camada.

Incorpore os níveis de segurança identificados na sua estratégia de grupo e, sempre que possível, utilize regras para ativar as caraterística de segurança nos seus ambientes. Neste exemplo, uma regra limita a partilha em todos os ambientes designados como segurança normal ou média.

Alinhe os ambientes à sua estratégia de política de dados

As políticas de dados são outra parte importante de um esforço de governação global para controlar os serviços utilizados por recursos de low-code num 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 ambientes 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 sejam da Microsoft.

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

Nas secções anteriores, descrevemos a nossa visão sobre a forma como as organizações podem gerir ambientes em escala. Explorámos recursos essenciais, como estes contribuem para uma estratégia de ambiente e qual o aspeto de uma topologia de ambiente de fundação que os utiliza. Demos exemplos de como criar essa base para acomodar cenários comuns. Uma vez que cada organização é única, o passo seguinte é personalizar uma estratégia de ambiente que vá ao encontro das necessidades da sua organização.

Comece onde está

Quer a sua organização seja nova no Power Platform ou já a utilize há anos, o primeiro passo é avaliar a sua situação. Avalie, a um nível alto, o que se encontra no seu ambiente predefinido, que outros ambientes tem e para que estão a ser utilizados. Muitas vezes, uma estratégia de ambiente é feita como parte de um esforço global para estabelecer a governação do Power Platform numa organização. Se for o caso, poderá já ter estabelecido alguma da visão de governação necessária para adaptar uma estratégia para a sua organização.

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

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

Precisa de tomar algumas decisões importantes:

• Como é que os criadores irão obter novos ambientes?
• Vai agrupar os seus ambientes e, em caso afirmativo, como?
• Que níveis de segurança são necessários para diferentes ambientes e como é que os ambientes são classificados?
• Como decidirá se uma aplicação, automatização ou o Copilot utilizará um ambiente existente ou novo?
• Existem lacunas entre as caraterísticas base da plataforma e os seus requisitos que exijam um processo de governação personalizado?
• Como irá processar os recursos existentes no ambiente predefinido?
• Você tem uma estratégia de política de dados de locatário e ambiente e, em caso afirmativo, como ela se alinha com a estratégia de ambiente que você está criando?

Poderá encontrar inspiração nos modelos operacionais de cloud que fazem parte do Cloud Adoption Framework para o Azure.

Preencher lacunas com a plataforma

Encontrará quase sempre requisitos que as capacidades incorporadas da plataforma não satisfazem. Ao avaliar essas lacunas, considere os seguintes resultados possíveis da sua avaliação:

• A lacuna é aceitável.
• A lacuna pode ser preenchida utilizando o Kit de Iniciação do Centro de Excelência do Power Platform.
• A lacuna pode ser preenchida utilizando as capacidades da plataforma, tais como APIs, conectores e aplicações personalizadas ou automatizações.
• A lacuna pode ser preenchida utilizando uma ferramenta ou aplicação de terceiros.

Kit de Iniciação CoE

O Kit de Iniciação do Centro de Excelência do Power Platform é uma coleção de componentes e ferramentas concebidos para ajudar a sua organização a adotar e suportar a utilização do Power Platform. Um aspeto fundamental do kit de iniciação é a capacidade de recolher dados sobre a utilização da plataforma nos seus ambientes, o que pode ser útil à medida que desenvolve e evolui a sua estratégia de ambiente.

Por exemplo, o dashboard Ambientes do Power BI oferece uma descrição geral que o ajuda a compreender que ambientes existem no inquilino, quem os criou e que recursos contêm.

Figura: O dashboard 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: Diagrama de fluxo que ilustra um processo de gestão de ambientes no Kit de Iniciação CoE.

Programação e extensibilidade da plataforma

Um dos melhores aspetos de uma plataforma de low-code é que pode utilizá-la para criar aplicações, automatizações, portais e copilotos para o ajudar a geri-la. Também tem acesso a ferramentas de nível inferior que podem ser utilizadas para preencher lacunas no suporte à sua estratégia de ambiente.

Pode utilizar os seguintes conectores para criar aplicações e fluxos:

• Power Platform for Admins e Power Platform for Admins V2
• Power Apps for Admins e Power Apps para Makers
• Gestão do Power Automate

Pode utilizar a interface de linha de comandos (CLI) do Power Platform para desenvolver automatizações para o ajudar a gerir o ciclo de vida do ambiente e outras tarefas relacionadas com práticas de DevOps.

Com cmdlets do PowerShell para criadores e administradores do Power Platform, pode automatizar várias das tarefas de monitorização e gestão.

O SDK de DLP do Power Platform pode ajudar a gerir as suas políticas de prevenção de perda de dados de inquilino e ambiente.

Recomendações de melhores práticas

Nesta secção do artigo, baseamo-nos nas recomendações das secções básicas e específicas do cenário.

Novos ambientes

Como parte do desenvolvimento da sua estratégia, considere quando criar ambientes para suportar a uma carga de trabalho. A sua avaliação deve equilibrar os benefícios do isolamento que um ambiente fornece, como bloquear ambientes específicos para melhor segurança, com as desvantagens, como o atrito que os utilizadores enfrentam ao partilhar dados entre aplicações.

Quando estiver a avaliar se uma aplicação ou uma automatização pertence ao seu próprio ambiente, avalie as diferentes fases do ciclo de vida da aplicação separadamente. Durante o desenvolvimento, o isolamento de outras aplicações é importante. Quando várias aplicações são desenvolvidas num único ambiente, corre o risco de criar dependências entre aplicações.

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

Testar várias aplicações no mesmo ambiente faz sentido se forem executadas em conjunto em produção. Na verdade, se não testar com as aplicações que serão executadas em produção, corre o risco de não descobrir problemas de compatibilidade.

Ao avaliar o ambiente de produção de uma aplicação, tenha em mente as seguintes considerações:

• A aplicação é compatível com as aplicações existentes no ambiente? Por exemplo, duas aplicações que utilizam a tabela Contacto do Dataverse para finalidades diferentes podem não ser compatíveis. As aplicações são compatíveis do ponto de vista da política de dados?

• Existem requisitos regulamentares ou de conformidade especiais para a separação de dados? Por exemplo, a sensibilidade dos dados requer que sejam isolados? Existe algum requisito para que os dados não possam ser incluídos com outros dados?

• Os dados são altamente confidenciais ou sensíveis? A transferência não autorizada causaria danos monetários ou reputacionais à organização? Isolar num ambiente separado pode permitir um maior controlo sobre a segurança.

• A aplicação precisa de dados de outras aplicações e precisa de ser colocada com eles? Por exemplo, duas aplicações que utilizam a sua tabela Cliente devem ser alojadas juntas. Separá-los criaria cópias de dados redundantes e criaria problemas com a manutenção dos dados.

• Os dados requerem residência dos dados regional? Em alguns cenários, a mesma aplicação ou automatização pode ser implementada em ambientes regionais para garantir o isolamento e a residência dos dados adequados.

• A maioria dos utilizadores está na mesma região que o ambiente? Se o ambiente estiver na EMEA, mas a maioria dos utilizadores da aplicação estiver baseada nos EUA, a partilha de um ambiente pode não fornecer o melhor desempenho.

• Serão necessários novos administradores ou os administradores existentes serão suficientes? Se a nova aplicação exigir mais administradores, estes são compatíveis com os administradores existentes (já que todos terão permissões de administrador em todas as aplicações no ambiente)?

• Qual é a esperança de vida da aplicação? Se a aplicação ou automatização for temporária ou de curta duração, pode não ser boa ideia instalá-la num ambiente com aplicações mais permanentes.

• Os utilizadores terão dificuldade em ter de utilizar vários ambientes para aplicações diferentes? Isto pode afetar tudo, desde encontrar uma aplicação no dispositivo móvel até relatórios de gestão personalizada que têm de solicitar dados de vários ambientes.

Capacidade

Cada ambiente, exceto os ambientes de avaliação e de programação, utiliza, inicialmente, 1 GB para o aprovisionamento. A capacidade é partilhada por todo o inquilino, pelo que tem de ser alocada a quem precisa.

Conservar a capacidade ao:

• Gerir ambientes de produção e teste partilhados. Ao contrário dos ambientes de desenvolvimento partilhados, as permissões nos ambientes de teste e produção devem limitar-se ao acesso de utilizador para testes.
• Automatizar a limpeza dos ambientes de desenvolvimento temporários e incentivar a utilização de ambientes de avaliação para testes ou trabalhos de prova de conceito.

Grupos de ambientes

Os grupos de ambientes são flexíveis e permitem-lhe acomodar vários casos de utilização exclusivos das suas organizações. Eis algumas formas em que poderia considerar o agrupamento de ambientes como parte da sua estratégia de ambiente:

• Por serviço ou componente; por exemplo, uma árvore de serviço do ServiceNow
• Programação, teste e produção
• Departamentos, grupos empresariais ou centros de custos
• Por Projetos
• Por localização, se a maioria dos ambientes numa localização tiver necessidades de governação semelhantes; isto também pode ajudar a satisfazer conformidade regulamentar regional e conformidade legal

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

Nomear ambientes e grupos

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

• Os nomes dos ambientes são visíveis para admins, criadores e utilizadores. Normalmente, apenas os admins utilizam grupos de ambientes, mas os criadores poderão deparar-se com ele se tiverem privilégios para criar ambientes.

• Os ambientes de programação criados automaticamente seguem o padrão Ambiente do <nome de utilizador> por exemplo, "Ambiente da Avery Howard". Os grupos de ambientes não são nomeados automaticamente.

• Os nomes do ambiente e do grupo de ambientes não precisam de ser exclusivos. No entanto, para evitar confusões, é recomendável evitar nomes duplicados.

• Os nomes estão limitados a 100 carateres. Nomes mais curtos são mais fáceis de utilizar.

Convenções de nomenclatura

Estabeleça convenções de nomenclatura consistentes.

• Nomes consistentes ajudam os administradores a saber qual é o objetivo do grupo e que ambientes este gere. Nomes consistentes também facilitam a automatização e a geração de relatórios.

  • Uma prática comum é incluir a fase do ciclo de vida no nome de um ambiente; por exemplo, Contoso Prog, Contoso Teste, Contoso Prod. O objetivo é separar claramente ambientes com o mesmo conteúdo, mas com finalidades diferentes.

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

  Por exemplo, poderá decidir que todos os nomes de ambiente ou grupo de ambientes têm de seguir o padrão <fase de ciclo de vida>-<região>-<unidade de negócio>-<finalidade> (Prod-US-Finance-Payroll).

• Mantenha os nomes curtos, significativos e descritivos.

• Evite incluir informações confidenciais em nomes. Podem estar visíveis para qualquer pessoa que tenha acesso ao centro de administração.

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

Os recursos no ambiente predefinido

A sua estratégia de ambiente deve encorajar (ou impor) a utilização de ambientes pessoais de programação para reduzir o que é criado no ambiente predefinido. No entanto, deve olhar para o que os criadores já criaram no ambiente predefinido e avaliar como lidar com cada caso de utilização. É apropriado deixar no ambiente predefinido ou deve ser migrado para outro ambiente?

Uma parte fundamental deste esforço de higiene é identificar aplicações amplamente utilizadas na sua organização que precisam de um ambiente de programação protegido separado do ambiente de produção.

A tabela que se segue enumera exemplos de casos de utilização e ações de migração. Em última análise, a sua organização precisa de identificar os seus próprios casos de utilização e fatores de risco associados a deixar recursos no ambiente predefinido. Mais informações sobre quando mover recursos do ambiente predefinido.

Recursos nos ambientes do Dataverse for Teams

Microsoft Dataverse for Teams permite que os utilizadores criem aplicações personalizadas, bots e fluxos no Microsoft Teams usando o Power Apps, o Microsoft Copilot Studio e o Power Automate. Quando um dono de equipa adiciona esta capacidade à sua equipa, é criado um ambiente Microsoft Power Platform com uma base de dados Dataverse for Teams e ligado à sua equipa. Saiba como estabelecer políticas de governação para gerir ambientes do Microsoft Dataverse for Teams.

Estratégia de ambiente internamente na Microsoft

A Microsoft considera-se "Cliente Zero" porque adota internamente o Power Platform para fomentar a automatização e a eficiência dos seus colaboradores. Os números a seguir mostram a escala de utilização no inquilino interno da Microsoft.

• 50.000-60.000 criadores ativos todos os meses
• Mais de 250.000 aplicações e mais de 300.000 fluxos
• Mais de 20.000 ambientes

A Microsoft está a mudar da sua estratégia de ambiente anterior para uma que utiliza as mais recentes caraterísticas de governação do Power Platform, incluindo Ambientes Geridos, grupos de ambientes e regras.

Como parte da estratégia avançada, a Microsoft planeia agrupar cenários com base no tipo de desenvolvimento, propriedade organizacional e nível de risco. Como muita coisa está a ser criada em toda a empresa, é difícil focar-se em todos os cenários possíveis e personalizar para cada caso de utilização. Dada a escala da inovação e da mudança, é necessária automatização, juntamente com o maior número possível de controlos prontos a utilizar.

A Microsoft está a estruturar os seus ambientes do Power Platform em três categorias amplas que abrangem sete casos de utilização, o que reflete diferentes graus de risco e controlo: produtividade pessoal, colaboração em equipa e desenvolvimento empresarial.

• Produtividade pessoal: para utilizadores que querem apenas criar uma aplicação ou um fluxo para si mesmos, sem colaborar com outras pessoas. Estes utilizadores são encaminhados para ambientes de programação pessoais. Estes ambientes bloqueados usam caraterísticas de Ambiente Gerido, incluindo a restrição de partilha e o controlo de outras ações. Os conectores e as ações nestes ambientes são fortemente restritos. Estes ambientes são os menos arriscados. O uso de ambientes pessoais bloqueados permite que os utilizadores evitem o processo de conformidade mais rigoroso necessário para criar aplicações e fluxos de produtividade pessoal.

• Colaboração em equipa: para utilizadores que estão a criar ferramentas, automatização e processos para a sua equipa. Para esse cenário, a Microsoft recomenda a utilização de ambientes do Dataverse for Teams. O ciclo de vida, a gestão de acesso e a etiquetagem de dados são controlados ao nível do grupo do Microsoft 365, eliminando a necessidade de gastar tempo a gerir estes utilizadores de uma perspetiva de governação do Power Platform. Este nível de utilização é o próximo passo no espectro de risco.

• Desenvolvimento empresarial/nível de produção usado por todos os colaboradores: para utilizadores que criam ferramentas ou soluções usadas de forma mais ampla em toda a empresa. Estes ambientes podem armazenar os dados mais confidenciais, utilizar conectores mais potentes e requerer mais governação. Este nível comporta o maior risco e, por conseguinte, são despendidos esforços significativos na governação. A ALM é necessária, com o trabalho de pré-produção a acontecer em ambientes de sandbox e apenas soluções geridas permitidas em ambientes de produção. Estes ambientes têm de ser 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 de ambientes e regras são utilizados para gerir e controlar estes ambientes.

A estratégia de governação da Microsoft não é estática. É fluido e muda para se adaptar a novos desafios e incorporar novas caraterísticas do Power Platform.

Evoluir a sua estratégia de ambiente de inquilinos

Neste artigo, descrevemos como estabelecer uma estratégia de ambiente de inquilinos de escala empresarial. A estratégia cresce com o seu negócio, independentemente de onde está a começar no percurso. Organizações de qualquer dimensão podem 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 de inquilinos não é uma atividade única. É um percurso. Evolua a sua estratégia ao longo do tempo à medida que as suas necessidades mudam. A sua estratégia também deve ser ajustada para adotar novos recursos da plataforma e enfrentar novos desafios.

Como todos os percursos, diferentes organizações aderem em diferentes pontos ao longo do caminho, mas todas têm o mesmo destino em mente. Seguem-se possíveis rampas que representam onde a sua organização está atualmente.

Iniciar

A sua organização está no início do percurso para a adoção do Power Platform. Esta fase denomina-se frequentemente como greenfield. Está a iniciar o seu percurso no melhor local porque não tem de se preocupar com os ambientes existentes nem com o impacto que as novas políticas podem ter na forma como as pessoas da sua organização estão a utilizar o Power Platform. Este é o melhor momento para implementar uma estratégia de ambiente de escala empresarial que esteja alinhada com as caraterísticas do produto e as melhores práticas.

Explore as principais caraterísticas e estratégias de ambiente descritas neste artigo. Reserve tempo para compreender os principais temas e as considerações e decisões que precisa de tomar para conceber e implementar uma estratégia de ambiente de inquilino que melhor satisfaça as suas necessidades.

Estabelecer uma base sólida agora é essencial para evitar ter de lidar com uma situação fora de controlo que pode ocorrer mais tarde se começar sem uma estratégia definida. Planeie a aceleração rápida da sua utilização do Power Platform, mas evite a tentação de projetar em excesso a sua estratégia de ambiente, adicionando complexidade que não é necessária. Lembre-se, este é um percurso e pode continuar a evoluir a sua estratégia à medida que as suas necessidades mudam.

Align

A sua organização tem e está a executar uma estratégia de ambiente que precisa de ser modificada para se alinhar com novas caraterísticas e melhores práticas do Power Platform. Esta fase denomina-se frequentemente como brownfield. Ao contrário das organizações que estão agora a começar, precisa de considerar o impacto na sua organização da mudança da sua estratégia de ambiente.

Explore as principais caraterísticas e estratégias do ambiente descritas neste artigo e avalie o que é necessário para evoluir a sua estratégia para que esteja mais alinhada. Normalmente, tudo o que é necessário são ajustes incrementais. Quando possível, planeie o lançamento de alterações para minimizar o impacto nos seus utilizadores.

As seguintes sugestões são alterações incrementais comuns que poderia implementar:

• Para iniciar o alinhamento sem afetar os ambientes existentes, crie um grupo de ambientes que contenha novos ambientes de programação e estabeleça regras para a forma como pretende governá-los. Ative o encaminhamento de ambientes para garantir que todos os novos ambientes de programação são criados no grupo designado.

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

• Identificar aplicações amplamente populares que são criadas e utilizadas no ambiente predefinido. Utilize pipelines para os publicar num ambiente de produção onde os utilizadores da sua organização possam executá-los. Em seguida, trabalhe na migração do desenvolvimento dessas aplicações para um ambiente de programação individual ou para um ambiente de programação dedicado.

• Crie um plano para identificar, colocar em quarentena e remover recursos no ambiente predefinido que não estejam a ser utilizados.

Melhorar

A estratégia de ambiente que está a executar já está alinhada com as caraterísticas e as melhores práticas mais recentes, mas a sua organização pretende adicionar mais controlos ou caraterísticas.

Comunicar a estratégia de ambiente à sua organização

Implementa a sua estratégia de ambiente de inquilinos com mais sucesso se os seus utilizadores do Power Platform compreenderem e estiverem alinhados com o que está a tentar alcançar. Se ativar simplesmente a sua estratégia sem qualquer comunicação, os utilizadores verão as alterações como restrições e procurarão maneiras de contorná-las.

Como parte do desenvolvimento ou evolução da sua estratégia, decida como informar os utilizadores sobre os elementos-chave da estratégia que afetam a utilização do Power Platform. Não precisam de todos os detalhes técnicos da sua estratégia, apenas dos elementos essenciais que os ajudam a permanecer produtivos. Por exemplo, comunique:

• O objetivo do ambiente predefinido
• Onde devem criar novos recursos de low-code
• Como devem utilizar o seu ambiente de programação pessoal
• Como pedir ambientes personalizados para unidades de negócio ou projetos específicos
• Políticas gerais de utilização de conectores e como pedir mais privilégios de conector para os respetivos ambientes
• Como partilhar o que criam com os outros
• As responsabilidades de um criador, por exemplo:
  • Manter o inquilino organizado. Eliminar os seus ambientes, aplicações e fluxos se já não forem necessários. Utilizar ambientes de teste se estiver a fazer experiências.
  • Partilhar com sensatez. Esteja atento à partilha excessiva dos seus ambientes, aplicações, fluxos e ligações partilhadas.
  • Proteger dados da organização. Evite mover dados de origens de dados confidenciais ou altamente confidenciais para armazenamento não protegido ou externo.
• Quando a sua estratégia mudar, partilhe como as alterações afetam os seus utilizadores, para que saibam o que fazer de forma diferente

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

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

Outra abordagem eficaz para comunicar com os utilizadores é estabelecer um hub do Power Platform interno. O hub pode ser um lugar para as pessoas colaboram em projeto, partilharem ideias e descobrirem novas formas de aplicar a tecnologia para conseguir mais. O hub é onde também pode partilhar informações detalhadas sobre a sua estratégia de ambiente que sejam relevantes para os seus utilizadores. Obtenha informações sobre como criar um hub do Power Platform interno.

Conclusão

Neste artigo, exploramos caraterísticas concebidas para ajudar a sua organização a gerir ambientes do Power Platform em escala empresarial e incorporá-los na sua estratégia de ambientes de inquilinos.

À medida que a sua organização adota o Power Platform e a utilização acelera, a necessidade de ambientes pode mudar rapidamente. Necessita de uma abordagem ágil que ajude a sua estratégia de ambiente a acompanhar as mudanças e a cumprir a evolução dos requisitos de governação da sua organização.

Um fator-chave para o sucesso de uma estratégia de ambiente de inquilinos é comunicar com os seus criadores e utilizadores e obter o respetivo suporte. Certifique-se de que as pessoas que criam aplicações e automatizações de low-code sabem como seguir a estratégia de ambiente da sua organização e onde devem criar os respetivos recursos de low-code.

O percurso de adoção do Power Platform de cada organização é exclusivo. Apresentámos algumas ideias para o ajudar a começar. A sua equipa da conta Microsoft ou parceiro do Power Platform podem ajudá-lo a criar uma estratégia de ambiente de inquilinos mais personalizada para a sua organização.

Informações relacionadas

• Grupos de ambientes
• Encaminhamento de ambientes
• Segurança empresarial com o Power Platform (documento técnico)
• Segurança e governação de low-code
• Conceitos da solução em ALM