Principais considerações para ALM

8 minutos

Os arquitetos de soluções precisam definir a estratégia de gerenciamento do ALM (ciclo de vida do aplicativo) no projeto. Essa tarefa faz parte do processo de ajudar a organização a estabelecer a governança adequada à solução.

Estratégia do ambiente

Um ambiente é um contêiner que armazena, gerencia e compartilha seus dados de negócios, aplicativos, fluxos, conexões e outros ativos, juntamente com permissões, para permitir que os membros da organização usem os recursos.

Um ambiente serve como um contêiner para separar aplicativos que podem ter diferentes funções, requisitos de segurança ou públicos-alvo. A maneira como você opta por usar os ambientes depende de sua organização e dos aplicativos que você está tentando criar; por exemplo:

Você pode optar por criar seus aplicativos apenas em um único ambiente.
Você pode criar ambientes separados que agrupam as versões de teste e produção de seus aplicativos.
Você pode criar ambientes separados que correspondem a equipes ou departamentos específicos na empresa, cada um contendo os dados e aplicativos relevantes para cada público-alvo.
Você pode criar ambientes separados para diferentes filiais globais de sua empresa.

O desenvolvimento de uma estratégia de ambiente significa configurar ambientes e outras camadas de segurança de dados de uma forma que dê suporte ao desenvolvimento produtivo em sua organização e, ao mesmo tempo, proteja e organize os recursos. Uma estratégia para gerenciar o provisionamento e o acesso do ambiente e controlar os recursos neles é importante para:

Proteger os dados e o acesso.
Entender como usar o ambiente padrão corretamente.
Gerenciar o número correto de ambientes para evitar a proliferação e conservar a capacidade.
Facilitar o gerenciamento do ALM (ciclo de vida do aplicativo).
Organizar recursos em partições lógicas.
Dar suporte às operações (e à assistência técnica) na identificação de aplicativos que estão em produção, mantendo-os em ambientes dedicados.
Garantir que os dados sejam armazenados e transmitidos em regiões geográficas aceitáveis (por motivos de desempenho e conformidade).
Garantir o isolamento dos aplicativos que estão sendo desenvolvidos.

Os seguintes tipos de ambientes estão disponíveis no Microsoft Power Platform:

Área restrita – um ambiente de área restrita é qualquer ambiente do Dataverse que não seja de produção. Isolado da produção, um ambiente de área restrita é o lugar certo para desenvolver e testar alterações de aplicativos com segurança e baixo risco.
Produção – o ambiente em que os aplicativos e outros softwares são colocados em operação para o uso pretendido.
Comunidade (desenvolvedor) – o Plano da Comunidade do Power Apps dá ao usuário acesso à funcionalidade premium do Power Apps, do Dataverse e do Microsoft Power Automate apenas para uso individual. Esse ambiente se destina principalmente a fins de aprendizagem. Um ambiente de desenvolvedor é um ambiente de usuário único e não pode ser usado para executar ou compartilhar aplicativos. Um ambiente de Plano da Comunidade pode participar do pipeline do Azure DevOps.
Padrão – um único ambiente padrão é criado automaticamente para cada locatário e compartilhado por todos os usuários nesse locatário. O ambiente padrão é usado pelos serviços do Microsoft 365.
Avaliação – os ambientes de avaliação são para testar novos recursos ou realizar provas de conceito. Os ambientes de avaliação são excluídos automaticamente após 30 dias.

Importante

O arquiteto de soluções precisa definir quantos ambientes são necessários, seus propósitos e as dependências entre os ambientes. No mínimo, uma prática saudável de ALM deve incluir o uso de um ambiente de avaliação antes de implantar qualquer item no ambiente de produção. Essa prática garante que você tenha um lugar para testar o aplicativo, mas também garante que a implantação possa ser testada.

Para obter mais informações, consulte ambientes e estratégia de ambiente.

Lidar com soluções e outros códigos e componentes sem reconhecimento de solução

Os projetos do Microsoft Power Platform consistem em componentes que podem ser reunidos em soluções em ambientes e componentes que não podem ser adicionados a soluções, como aqueles implantados no Azure, dados de configuração e relatórios do Power BI. O plano de ALM deve considerar como lidar com os componentes sem reconhecimento de solução.

O arquiteto de soluções precisa decidir se o gerenciamento do ciclo de vida do aplicativo será gerenciado pelo uso de soluções ou controle do código-fonte. Tradicionalmente, os projetos do Microsoft Power Platform têm sido mais centrados no ambiente, mas muitos agora estão mudando para o controle do código-fonte.

Se você usar uma abordagem centrada no ambiente, então:

O ambiente de desenvolvimento será a cópia mestra de todas as alterações.
As alterações serão promovidas diretamente de desenvolvimento > teste > produção.

Se você usar uma abordagem centrada no controle do código-fonte, então:

O controle do código-fonte será o mestre.
O ambiente de desenvolvimento é recriado com base no controle do código-fonte (esse processo pode ser automatizado e repetível).
As alterações do ambiente de desenvolvimento são verificadas no controle do código-fonte.

Uma abordagem centrada no controle do código-fonte o incentiva a ter um mestre definitivo e a capacidade de recriar ambientes de desenvolvimento para qualquer versão rastreada. Atualmente, a Microsoft está incentivando e criando ferramentas para dar suporte ao ALM centrado no controle do código-fonte.

Observação

O ideal é que todos os ambientes, exceto os de produção, sejam descartados; em outras palavras, os ambientes de desenvolvimento e teste podem ser excluídos e recriados sem sofrer perdas.

Usar uma abordagem centrada no controle do código-fonte permitirá uma abordagem do Azure DevOps com pipelines de compilação e liberação. Usar uma abordagem centrada no ambiente significa que você precisa definir o fluxo de trabalho para criadores e desenvolvedores de aplicativos. O arquiteto de soluções precisará definir como e quem promoverá o aplicativo nos ambientes, desde o desenvolvimento até a produção.

O arquiteto de soluções também precisará definir como configurar cada ambiente e procurar maneiras de facilitá-lo.

Trabalho em equipe

Em comparação com o desenvolvimento de aplicativos tradicionais, os projetos do Microsoft Power Apps diferem em duas áreas principais:

Como vários membros da equipe do projeto trabalham juntos para criar a solução
Metodologia de desenvolvimento

O Power Apps é uma plataforma que beneficia desenvolvedores profissionais e desenvolvedores cidadãos. Em um ambiente de desenvolvimento tradicional, apenas desenvolvedores profissionais podem estar envolvidos na criação real de um aplicativo. Com o Power Apps, todos têm o poder de criar os aplicativos de que precisam, usando funcionalidades avançadas que antes estavam disponíveis apenas para desenvolvedores profissionais. O Power Apps democratiza a experiência de criação de aplicativos de negócios personalizados, permitindo que os usuários criem aplicativos de negócios personalizados e repletos de recursos sem escrever código.

Diagrama que mostra o ecossistema em desenvolvimento.

Com o Power Apps, você pode criar rapidamente uma versão utilizável do aplicativo, pois o Power Apps fornece uma experiência de desenvolvimento WYSIWYG. Você pode experimentar o aplicativo de trabalho real no início do processo de desenvolvimento e, se surgirem novos requisitos, poderá adicionar novos recursos à próxima versão.

Os problemas de personalização e desenvolvimento de componentes no Microsoft Power Platform incluem:

O Microsoft Power Platform não dá suporte ao controle de versão de componentes (exceto para aplicativos de tela).
Os usuários não podem trabalhar no mesmo componente do Microsoft Power Platform simultaneamente.
Os aplicativos baseados em modelos têm vários componentes, cada um com seus próprios editores, permitindo que o trabalho seja dividido entre os criadores. Por outro lado, os aplicativos de tela têm apenas um editor, e apenas uma pessoa pode trabalhar em um aplicativo por vez. Usando componentes de tela, você pode permitir que vários criadores trabalhem no mesmo aplicativo simultaneamente.

Os arquitetos de soluções devem estabelecer o fluxo de trabalho para como os criadores de aplicativos farão as mudanças e as promoverão. A comunicação e as atribuições de trabalho proativas devem ser gerenciadas para minimizar os conflitos entre os criadores.

Você pode minimizar conflitos entre criadores criando um ambiente individual para cada um deles. Ambientes de criadores individuais oferecem isolamento e rastreamento, mas exigem esforço extra para mesclar o trabalho e resolver conflitos. Um ambiente de criador compartilhado pode ser menos complexo, mas não oferece isolamento entre os criadores de aplicativos e carece de detalhes no rastreamento de alterações.

Controle do código-fonte

Embora você esteja usando uma abordagem centrada no ambiente, ainda precisará decidir onde ficará a cópia mestra das soluções e do código.

Ativos de código de desenvolvedor com reconhecimento de solução (como plug-ins, componentes de código PCF e scripts de formulário (transcompilados do TypeScript)) devem ser "criados" em um ambiente de criação e não na área de trabalho do desenvolvedor. Depois de criados, os ativos devem ser implantados em um ambiente do qual a solução mestra será exportada ou incorporada em uma solução que será instalada.

Ferramentas

A Microsoft fornece várias ferramentas e aplicativos que você pode usar com o ALM no Microsoft Power Platform:

Centro de administração do Microsoft Power Platform – fornece um portal unificado para que os administradores criem e gerenciem ambientes.
Power Apps Build Tools – automatize tarefas comuns de compilação e implantação relacionadas ao Power Apps usando o Azure DevOps.
GitHub – exemplo popular de um sistema de controle de versão.
Ferramenta de Migração de Configuração – permite migrar dados de configuração e/ou de referência entre ambientes.
Package Deployer – permite implantar pacotes de ativos em instâncias do Dataverse. Os pacotes podem consistir em arquivos de solução e arquivos simples, código personalizado, arquivos HTML e dados.
Pacote de Soluções – uma ferramenta que pode descompactar um arquivo de solução compactado em vários arquivos XML e outros arquivos para que possam ser facilmente gerenciados por um sistema de controle do código-fonte.
Microsoft Power Apps CLI – uma interface de linha de comando simples que capacita os desenvolvedores a criar componentes de código.
Módulo do PowerShell de implantação de pacotes – usado para implantar pacotes no ambiente do Dataverse.
Módulo do PowerShell do verificador do Power Apps – interage com o serviço verificador do Power Apps para que você possa executar trabalhos de análise estática e baixar os resultados.