Gerenciamento do ciclo de vida de aplicativos (ALM) para componentes de código

ALM é um termo usado para descrever o gerenciamento do ciclo de vida de aplicativos de software, que inclui desenvolvimento, manutenção e governança. Mais informações: ALM (gerenciamento do ciclo de vida do aplicativo) com Microsoft Power Platform.

Este artigo descreve considerações e estratégias para trabalhar com aspectos específicos do gerenciamento do ciclo de vida da perspectiva dos componentes de código no Microsoft Dataverse:

1. Considerações sobre desenvolvimento e depuração de ALM
2. Estratégias de solução de componente de código
3. Controle de versão e implantação de atualizações
4. Considerações sobre ALM de aplicativos de tela

Considerações sobre desenvolvimento e depuração de ALM

Ao desenvolver componentes de código, você seguiria as etapas abaixo:

1. Crie um projeto de componente de código (pcfproj) a partir de um modelo usando pac pcf init. Mais informações: Criar e compilar um componente de código.
2. Implementar a lógica do componente de código. Mais informações: implementação do componente.
3. Depure o componente de código usando o ambiente de teste local. Mais informações: Depurar componentes de código.
4. Crie um projeto de solução (cdsproj) e adicione o projeto de componente de código como referência. Mais informações: empacotar um componente de código.
5. Crie o componente de código no modo de versão para distribuição e implantação.

Quando o componente de código estiver pronto para teste dentro de um aplicativo baseado em modelo, aplicativo de tela ou portal, há duas maneiras de implantar um componente de código no Dataverse:

1. pac pcf push: isso implanta um único componente de código de cada vez em uma solução especificada pelo --solution-unique-name parâmetro ou uma solução temporária do PowerAppsTools quando nenhuma solução é especificada.

2. Usando o pac solution init e msbuild para criar um cdsproj projeto de solução que tenha referências a um ou mais componentes de código. Cada componente de código é adicionado ao usando cdsproj. Um projeto de solução pode conter referências a vários componentes de código, enquanto projetos de componente de código podem conter apenas um único componente de código.

   O diagrama a seguir mostra a relação de um para muitos entre os projetos cdsproj e pcfproj:

   

Mais informações: Empacote um componente de código.

Criando projetos de componente de código pcfproj

Ao compilar projetos pcfproj, o JavaScript gerado depende do comando usado na compilação e do PcfBuildMode no arquivo pcfproj.

Normalmente, não implante um componente de código em Microsoft Dataverse que você criou no modo de desenvolvimento. O componente geralmente é muito grande para importar e pode resultar em um desempenho de runtime mais lento. Para obter mais informações, consulte Depurar componentes de código após a implantação no Microsoft Dataverse.

Para que pac pcf push resulte em um build de release, o PcfBuildMode é definido dentro do pcfproj adicionando um novo elemento sob o elemento OutputPath, da seguinte maneira:

<PropertyGroup>
   <Name>my-control</Name>
   <ProjectGuid>6aaf0d27-ec8b-471e-9ed4-7b3bbc35bbab</ProjectGuid>
   <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
   <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

A tabela a seguir mostra quais comandos resultam em builds de desenvolvimento versus versão:

Mais informações: Empacotar um componente de código.

Criando projetos de solução .cdsproj

Ao criar um projeto de solução (.cdsproj), você tem a opção de gerar a saída como uma solução gerenciada ou não gerenciada. As soluções gerenciadas são usadas para implantação em qualquer ambiente que não seja um ambiente de desenvolvimento para essa solução. Isso inclui ambientes de teste, UAT, SIT e produção. Mais Informações: Soluções gerenciadas e não gerenciadas.

O SolutionPackagerType está incluído no arquivo .cdsproj criado por pac solution init, mas inicialmente comentado. Descomente a seção e defina como Gerenciado, Não gerenciado ou Ambos.

 <!-- Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both) -->
 <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
 </PropertyGroup>

A tabela a seguir mostra quais comandos e configurações resultam em compilações de desenvolvimento e de versão:

Mais informações: Empacotar um componente de código.

Controle do código-fonte com componentes de código

Ao desenvolver componentes de código, é recomendável que você use um provedor de controle de código-fonte, como Azure DevOps ou GitHub. Ao fazer commit das alterações usando o controle de código-fonte Git, o arquivo .gitignore fornecido pelo modelo pac pcf init garantirá que alguns arquivos não sejam adicionados ao controle de código-fonte porque são restaurados por npm ou gerados como parte do processo de compilação:

# dependencies
/node_modules

# generated directory
**/generated

# output directory
/out

# msbuild output directories
/bin
/obj

Como a /out pasta é excluída, o arquivo resultante bundle.js (e recursos relacionados) compilado não será adicionado ao controle do código-fonte. Quando seus componentes de código são compilados manualmente ou como parte de um pipeline automatizado de compilação, o bundle.js seria compilado usando o código mais recente para garantir que todas as alterações fossem incorporadas.

Além disso, quando uma solução é compilada, quaisquer arquivos ZIP de solução de associação não seriam incluídos no controle de versão. Em vez disso, o resultado seria publicado como artefatos binários de lançamento.

Usando SolutionPackager com componentes de código

Além de colocar cdsproj e pcfproj no controle de versão, o SolutionPackager pode ser usado para desempacotar incrementalmente uma solução em suas respectivas partes, como uma série de arquivos XML que podem ser confirmados no controle de versão. Isso tem a vantagem de criar uma imagem completa dos metadados no formato legível para que você possa controlar as alterações usando solicitações de pull ou semelhantes . Sempre que uma alteração é feita nos metadados da solução do ambiente, o Solution Packager é usado para desempacotar e as alterações podem ser exibidas como um conjunto de alterações.

Se você estiver combinando componentes de código com outros elementos da solução, como tabelas, aplicativos baseados em modelo e aplicativos de tela, normalmente não precisará do build do projeto cdsproj. Em vez disso, você moveria os artefatos gerados de pcfproj para a pasta do pacote de solução antes de reempacotá-lo para importação.

Depois que uma solução que contém um componente de código for descompactada usando SolutionPackager /action: Extract, ela será semelhante a:

.
├── Controls
│   └── prefix_namespace.ControlName
│       ├── bundle.js *
│       └── css
│          └── ControlName.css *
│       ├── ControlManifest.xml *
│       └── ControlManifest.xml.data.xml
├── Entities
│   └── Contact
│       ├── FormXml
│       │   └── main
│       │       └── {3d60f361-84c5-eb11-bacc-000d3a9d0f1d}.xml
│       ├── Entity.xml
│       └── RibbonDiff.xml
└── Other
    ├── Customizations.xml
    └── Solution.xml

Na pasta Controls, você pode ver que existem subpastas para cada componente de código incluído na solução. As outras pastas contêm componentes de solução adicionais adicionados à solução.

Ao confirmar essa estrutura de pastas para o controle do código-fonte, você excluiria os arquivos marcados com um asterisco (*) acima, pois eles serão gerados quando o pcfproj projeto for criado para o componente correspondente.

Os únicos arquivos necessários são os *.data.xml arquivos, pois contêm metadados que descrevem os recursos exigidos pelo processo de empacotamento. Depois que cada componente de código é criado, os arquivos na out pasta são copiados para a respectiva pasta de controle nas pastas SolutionPackager. Depois que as saídas de build tiverem sido adicionadas, as pastas de pacote contêm todos os dados necessários para reempacotar em uma solução do Dataverse usando SolutionPackager /action: Pack.

Mais informações: argumentos da linha de comando do SolutionPackager.

Estratégias de solução de componente de código

Os componentes de código são implantados em ambientes downstream usando soluções do Dataverse. Depois de implantados em seu ambiente de desenvolvimento, eles podem ser implantados da mesma forma que outros componentes da solução. Mais informações: Conceitos de solução – Power Platform.

Há duas estratégias para implantar componentes de código dentro de soluções:

1. Soluções segmentadas – um projeto de solução é criado usando pac solution init e, em seguida, pac solution add-reference para adicionar um ou mais componentes de código. Essa solução pode então ser exportada e importada para ambientes downstream e outras soluções segmentadas assumirão uma dependência da solução de componente de código, de modo que ela deve ser implantada primeiro nesse ambiente. Isso é conhecido como segmentação de solução porque a funcionalidade geral é dividida entre diferentes segmentos e camadas de solução, com interdependências sendo controladas pela estrutura de solução. Se estiver usando essa abordagem, você provavelmente precisará de vários ambientes de desenvolvimento, um para cada solução segmentada. Mais informações: use soluções segmentadas em Power Apps.

2. Solução única – uma única solução é criada dentro de um ambiente do Dataverse e, em seguida, os componentes de código são adicionados juntamente com outros componentes de solução (como tabelas, aplicativos controlados por modelos ou aplicativos de tela) que, por sua vez, fazem referência a esses componentes de código. Essa solução pode ser exportada e importada para ambientes downstream sem nenhuma dependência entre soluções. Com essa abordagem, o branching de código e ambiente torna-se importante para que você possa implantar uma atualização em uma parte da solução sem fazer alterações que estão sendo feitas em outra área. Mais informações: Estratégia de ramificação e mesclagem com Microsoft Power Platform.

Os motivos para adotar uma abordagem de solução segmentada em uma abordagem de solução única mista podem ser:

1. Ciclo de vida de versionamento - você deseja desenvolver, implantar e fazer o controle de versão dos componentes de código em um ciclo de vida separado das outras partes da sua solução. Esse é um cenário comum no qual você tem uma "equipe de fusão", em que componentes de código criados por desenvolvedores estão sendo consumidos por criadores de aplicativos. Normalmente, isso também significaria que os componentes de código existiriam em um repositório de código diferente para outros componentes da solução.

2. Uso compartilhado – Você deseja compartilhar seus componentes de código entre vários ambientes e, portanto, não deseja associar seus componentes de código com nenhum outro componente de solução. Isso pode ser se você for um ISV ou estiver desenvolvendo um componente de código para uso por diferentes partes da sua organização que cada um tem seu próprio ambiente.

O diagrama a seguir mostra uma visão geral do ciclo de vida da solução para essas duas abordagens:

O diagrama descreve os seguintes pontos:

1. Push usando a CLI do PAC - Quando o componente de código está pronto para testes no Dataverse, o pac pcf push é usado para implantar o componente em um ambiente de desenvolvimento. Isso cria uma solução não gerenciada chamada PowerAppsTools_namespace, em que o namespace é o prefixo de namespace do provedor de solução no qual você deseja implantar seu componente de código. O provedor de solução já deve existir no ambiente de destino e deve ter o mesmo prefixo de namespace que você deseja usar para ambientes downstream. Após a implantação, você pode adicionar seu componente de código a aplicativos baseados em modelos ou de tela para teste.

   Note

   Conforme descrito acima, é importante configurar o componente cdsproj de código para o build de produção para que você implante o código otimizado para produção em vez de desenvolvimento.

2. Adicionar componentes de código existentes (após a implantação da CLI do PAC) – se você estiver usando a abordagem de solução única, uma vez implantada, o componente de código poderá ser adicionado a outra solução. (Essa solução deve compartilhar o mesmo editor de soluções usado pela solução PowerAppsTools .)

   

3. Criar um projeto de solução não gerenciado – se você estiver usando projetos de solução cdsproj , uma solução não gerenciada poderá ser criada usando msbuilde, em seguida, importada para seu ambiente de desenvolvimento.

4. Adicionar componentes de código existentes (após a implantação do projeto de solução) - Assim como após pac pcf push, os componentes de código importados de uma compilação de projeto de solução podem ser adicionados a uma solução mista, desde que tenha sido usado o mesmo prefixo do publicador da solução.

5. Exportar uma única solução como gerenciada – a solução de componente misto único pode ser exportada como gerenciada e importada para os ambientes downstream. Como os componentes de código e outros componentes da solução são implantados na mesma solução, todos eles compartilham a mesma solução e estratégia de controle de versão.

6. Exportar a solução segmentada do componente de código como gerenciada - Se você estiver usando a abordagem de solução segmentada, poderá exportar o projeto de solução do componente de código como gerenciado para ambientes subsequentes.

7. Criar uma solução segmentada de componente de código como gerenciada – se você estiver usando soluções segmentadas e não tiver necessidade de uma solução não gerenciada, poderá criar o projeto de solução diretamente como uma solução gerenciada usando msbuild /p:configuration=Release . Em seguida, isso pode ser importado para ambientes que precisam assumir uma dependência em seus componentes de código.

8. Consumir solução de componente de código segmentado – Depois que os componentes de código são implantados por meio de uma solução segmentada gerenciada, outras soluções podem ser criadas, usando uma dependência da solução de componente de código. As dependências dos componentes de código serão listadas na seção MissingDependencies da solução do tipo 66. Mais informações: Acompanhamento de dependência para componentes da solução.

9. Implante a solução segmentada de componente de código antes das soluções que a utilizam - Ao importar soluções que dependem de uma solução segmentada de componente de código, a solução de componente de código deve ser instalada no ambiente de destino antes que possam ser importadas.

Mais informações: empacotar e distribuir extensões usando soluções.

Componentes de código e pipelines de compilação automatizados

Além de criar e implantar manualmente suas soluções de componente de código, você também pode criar e empacotar seus componentes de código usando pipelines de build automatizados.

• Se você estiver usando Azure DevOps, poderá usar a Ferramenta de Compilação Microsoft Power Platform para Azure DevOps.
• Se você estiver usando GitHub, poderá usar o GitHub Actions do Power Platform.

Algumas vantagens do uso de pipelines de build automatizados são:

• Eles são eficientes em tempo – a remoção das tarefas manuais torna as tarefas de compilar e empacotar seu componente mais rapidamente para que ele possa ser feito com mais regularidade, como sempre que uma alteração é verificada.
• Eles são repetíveis – depois que o processo de build for automatizado, ele será executado da mesma forma todas as vezes e, portanto, não dependerá do membro da equipe que executa o build.
• Eles oferecem consistência no versionamento - quando o pipeline de compilação define automaticamente a versão do componente de código e da solução, você pode ter confiança de que, quando um novo build é criado, ele recebe um versionamento consistente em relação às versões anteriores. Isso facilita o acompanhamento de recursos, correções de bugs e implantações.
• Eles são mantenedíveis – como tudo o que é necessário para criar sua solução está contido dentro do controle do código-fonte, você sempre pode criar novos branches e ambientes de desenvolvimento verificando o código. Quando você estiver pronto para implementar uma atualização, os pull requests poderão ser mesclados nas ramificações posteriores. Mais informações: Estratégia de ramificação e mesclagem com o Microsoft Power Platform.

Conforme descrito acima, há duas abordagens para o gerenciamento de soluções de componentes de código: um projeto de solução segmentado ou uma única solução mista contendo outros artefatos, como aplicativos controlados por modelo, aplicativos de tela e tabelas às quais os componentes de código são adicionados.

Se você estiver usando o projeto de solução com componentes de código segmentados, poderá compilar o projeto em um Azure DevOps Pipeline (usando Microsoft Power Platform Build Tools) ou em um pipeline do GitHub (usando GitHub Actions for Microsoft Power Platform). Cada pasta pcfproj de componente de código é adicionada ao controle de código-fonte (excluindo as pastas generated, out e node_modules), um projeto cdsproj é criado, e cada componente de código é referenciado usando pac solution add-reference antes de também ser adicionado ao controle de código-fonte. Em seguida, o pipeline executaria o seguinte:

1. Atualize, no arquivo Solution.xml, a versão da solução para que corresponda à versão da sua compilação. A versão da solução é mantida no ImportExportXml/Version atributo. Veja abaixo detalhes sobre estratégias de controle de versão.
2. Atualize a versão do componente de código no ControlManifest.Input.xml arquivo. A versão é armazenada no manifest//controlversion atributo. Isso deve ser feito para todos os pcfproj projetos criados.
3. Execute uma MSBuild tarefa com o argumento/restore /p:configuration=Release usando um caractere curinga *.cdsproj. Isso compilará todos os projetos cdsproj e seus projetos pcfproj referenciados.
4. Inclua o arquivo zip da solução compilada nos artefatos de release do pipeline. Essa solução conterá todos os componentes de código incluídos como referências no cdsproj.

Se você estiver usando uma solução mista que contenha outros componentes além de componentes de código, isso será extraído no controle do código-fonte usando SolutionPackager , conforme descrito acima. Em seguida, o pipeline executará o seguinte:

1. Atualize as versões da solução e do componente de código da mesma forma que descrito nas etapas 1 e 2 acima.
2. Instale as Ferramentas de Build do Microsoft Power Platform no pipeline de compilação usando a tarefa PowerPlatformToolInstaller.
3. Restaurar node_modules usando uma tarefa Npm com o comando ci.
4. Compile componentes de código no modo de lançamento de produção usando a tarefa Npm com o parâmetro customCommand definido comorun build -- --buildMode release.
5. Copie a saída da compilação para a pasta do Empacotador de Soluções do controle correspondente.
6. Empacote a solução usando a tarefa PowerPlatformPackSolution Power Platform Build Tools.
7. Inclua o zip da solução compilada nos artefatos de release do pipeline.

É recomendável que você confirme os metadados da solução descompactada no controle do código-fonte em sua forma não gerenciada para permitir a criação de um ambiente de desenvolvimento em qualquer estágio posterior. (Se apenas os metadados da solução gerenciada forem confirmados, isso dificultará a criação de novos ambientes de desenvolvimento.) Você tem duas opções para fazer isso:

1. Faça commit das versões gerenciada e não gerenciada usando a opção /packagetype:Both do Solution Packager. Isso permite empacotar no modo gerenciado ou não gerenciado, mas tem a desvantagem da duplicação dentro do código-fonte, de modo que as alterações geralmente aparecerão em vários arquivos xml – a versão gerenciada e não gerenciada.
2. Apenas confirme não gerenciado no controle do código-fonte (resultando em conjuntos de alterações mais limpos) e, em seguida, dentro do pipeline de build, importe a solução empacotada para um ambiente de build para que ela possa ser exportada como gerenciada para convertê-la em um artefato de implantação gerenciada.

Controle de versão e implantação de atualizações

Ao implantar e atualizar seus componentes de código, é importante ter uma estratégia de controle de versão consistente para que você possa:

• Acompanhe qual versão é implantada em relação aos recursos/correções que ela contém.
• Verifique se os aplicativos de tela conseguem detectar que precisam ser atualizados para a versão mais recente.
• Verifique se os aplicativos controlados por modelo invalidarão o cache e carregarão a nova versão.

Uma estratégia de controle de versão comum é o controle de versão semântico, que tem o formato: MAJOR.MINOR.PATCH.

Incrementando a versão do PATCH

O ControlManifest.Input.xml armazena a versão do componente de código no elemento de controle:

<control namespace="..." constructor="..." version="1.0.0" display-name-key="..." description-key="..." control-type="...">

Ao implantar uma atualização em um componente de código, a versão em ControlManifest.Input.xml deve ter, no mínimo, seu PATCH (a última parte da versão) incrementado para que a alteração seja detectada. Isso pode ser feito manualmente editando o atributo de versão diretamente ou usando o seguinte comando para avançar a versão patch por um:

pac pcf version --strategy manifest

Como alternativa, para especificar um valor exato para a parte PATCH (por exemplo, como parte de um pipeline de compilação automatizado), use:

pac pcf version --patchversion <PATCH VERSION>

Mais informações: pac pcf version.

Quando incrementar a versão MAJOR e a versão MINOR

É recomendável que as versões principal e secundária da versão do componente de código sejam mantidas em sincronia com a solução do Dataverse que é distribuída. Por exemplo:

1. A versão do componente de código implantado é 1.0.0 e a versão da solução é 1.0.0.0.
2. Você faz uma pequena atualização no componente de código e incrementa a versão PATCH do componente de código para 1.0.1 usando pac pcf version --strategy manifest.
3. Ao empacotar o componente de código para implantação, a versão Solution.xml da solução é atualizada para 1.0.0.1 ou a versão é incrementada automaticamente exportando manualmente a solução.
4. Você faz alterações significativas em sua solução de modo que deseja incrementar a versão MAJOR e MINOR para 1.1.0.0.
5. Nesse caso, a versão do componente de código também pode ser atualizada para ser 1.1.0.

Uma solução do Dataverse tem quatro partes e pode ser pensada na seguinte estrutura: MAJOR.MINOR.BUILD.REVISION.

Se você estiver usando AzureDevOps, poderá definir o controle de versão do seu pipeline de build usando as variáveis de ambiente e Rev (Build) e usar um script do PowerShell semelhante à abordagem descrita no artigo Usar scripts do PowerShell para personalizar pipelines.

Considerações sobre ALM de aplicativos de tela

Consumir componentes de código em aplicativos de tela é diferente de fazer isso em aplicativos controlados por modelos. Os componentes de código devem ser adicionados explicitamente ao aplicativo selecionando Obter mais componentes no painel Inserir . Depois que o componente de código é adicionado ao aplicativo de tela, ele é incluído como conteúdo na definição do aplicativo. Para atualizar para uma nova versão do componente de código depois que ele for implantado (e a versão de controle incrementada), o fabricante do aplicativo deve primeiro abrir o aplicativo no Power Apps Studio e selecionar Atualizar quando solicitado na caixa de diálogo Atualizar componentes de código. Em seguida, o aplicativo deve ser salvo e publicado para que a nova versão seja usada quando os usuários executarem o aplicativo.

Se o aplicativo não for atualizado ou Skip for usado, o aplicativo continuará a usar a versão mais antiga do componente de código, mesmo que ele não exista no ambiente, pois ele foi substituído pela versão mais recente.

Como o aplicativo contém uma cópia do componente de código, é, portanto, possível ter diferentes versões dos componentes de código sendo executadas lado a lado em um único ambiente, em diferentes aplicativos de tela. No entanto, você não pode ter versões diferentes de um componente de código em execução lado a lado no mesmo aplicativo. Os criadores de aplicativos são incentivados a atualizar seus aplicativos para a versão mais recente dos componentes de código quando uma nova versão é implantada.

Artigos relacionados

Gerenciamento do ciclo de vida do aplicativo (ALM) com a Microsoft Power Platform
Referência da API da estrutura de componentes do Power Apps
Criar seu primeiro componente
Depurar componentes de código