Pipelines Power Platform da origem à produção

O que este tutorial resolve

Ao final deste guia você terá um pipeline funcional de pipelines Power Platform levando uma solução do repositório de origem até o ambiente de produção da cooperativa, passando por homologação, com aprovação registrada e sem depender de alguém exportar solução manualmente numa sexta-feira à tarde. Isso importa porque cooperativa de crédito não é startup: mudança em produção que toca esteira de crédito, PLD ou app de atendimento em agência passa por auditoria, e "eu importei a solução na hora do almoço" não é uma resposta que sobrevive a uma auditoria do Bacen ou a uma revisão de controles internos.

O ângulo aqui é prático: vamos configurar primeiro o pipeline manual dentro do Power Platform, entender exatamente onde ele para de escalar, e então evoluir para um pipeline automatizado no Azure DevOps usando Power Platform Build Tools, disparado por commit no repositório. As duas abordagens coexistem em produção real, a diferença entre elas é o que este post existe para deixar claro.

Pré-requisitos

Ambientes Dataverse para Desenvolvimento, Homologação e Produção. Pipelines nativos do Power Platform só funcionam entre ambientes com Dataverse habilitado, ambiente trial ou Dataverse for Teams não servem como origem nem destino.
Um ambiente adicional para hospedar a configuração de pipelines, chamado de host environment. Não use o ambiente de produção nem o de desenvolvimento para isso, a Microsoft recomenda um ambiente dedicado e enxuto, e a mistura gera problemas de permissão que você só descobre no primeiro deploy real.
Papel de System Administrator no host environment para configurar os estágios.
Papel de segurança Deployment Pipeline Administrator atribuído a quem vai configurar pipelines, e Deployment Pipeline User para quem só vai disparar deploys no dia a dia (o time de sustentação da cooperativa, por exemplo, sem precisar de acesso de admin ao Dataverse).
Licenciamento Microsoft 365 ou Power Apps por usuário/aplicativo que já contemple Dataverse. Power Platform Pipelines em si não tem SKU própria, mas consome a capacidade de Dataverse do host environment.
Para a parte automatizada: uma organização no Azure DevOps, o Power Platform CLI (pac) instalado localmente, e um Service Principal registrado no Microsoft Entra ID com um Application User criado em cada ambiente Dataverse envolvido.
Extensão Power Platform Build Tools instalada na organização do Azure DevOps (via marketplace).

Passo 1: desenhe o modelo de ambientes antes de tocar em pipelines

A tentação em cooperativa pequena é ter dois ambientes: um "de teste" que na prática já é produção disfarçada, e o de produção mesmo. Isso quebra qualquer tentativa séria de ALM. O modelo mínimo defensável para uma cooperativa é:

Desenvolvimento: onde o analista de negócio ou desenvolvedor cidadão constrói o app ou o fluxo, com solução unmanaged.
Homologação: espelha produção em segurança e conectores, é onde o comitê de risco ou o dono do processo de crédito valida antes do go-live.
Produção: só recebe solução managed, nunca é editada diretamente.

O racional técnico: solução managed em produção impede edição direta na interface, o que é exatamente o controle que um auditor de cooperativa vai perguntar se existe. Se hoje a resposta é "qualquer analista pode editar o formulário direto em produção", o pipeline resolve isso estruturalmente, não por acordo verbal.

Passo 2: configure o ambiente host de pipelines

No Power Platform admin center, vá em Pipelines > Overview e clique em Set up pipelines. O assistente pede para você escolher ou criar o ambiente host. Escolha um ambiente Dataverse novo, dedicado, sem outras soluções nele.

Depois de criado, dentro do host environment abra o app Pipelines (aparece na lista de aplicativos do ambiente) e cadastre os ambientes que participarão do fluxo: o de Desenvolvimento como origem, Homologação e Produção como destinos. Cada ambiente precisa ser registrado explicitamente, o pipeline não enxerga ambientes que não foram cadastrados aqui.

Passo 3: registre os estágios de deployment (deployment stages)

Ainda no app Pipelines, crie um registro de Pipeline e dentro dele os Stages, na ordem em que a solução deve andar: Homologação primeiro, Produção depois. Para cada estágio, associe o ambiente de destino correspondente e defina se aquele estágio exige aprovação antes de liberar o próximo.

É aqui que vale marcar a exigência de aprovação para o estágio de Produção. Em cooperativa, isso normalmente mapeia para o responsável técnico ou o gestor de TI que assina a liberação, o registro dessa aprovação fica no histórico do pipeline e serve como evidência de controle.

Passo 4: rode o primeiro deploy manual e entenda onde ele para de escalar

No ambiente de Desenvolvimento, abra Solutions, selecione a solução e clique em Pipelines > Deploy. O sistema mostra os estágios configurados no passo anterior. Escolha Homologação, revise as connection references e environment variables exibidas na tela de revisão, e confirme.

Isso é o pipeline manual: alguém com o papel certo entra na interface, clica, revisa, confirma. Funciona bem para uma cooperativa com poucas soluções e cadência baixa de mudança. O problema aparece quando você tem múltiplas soluções, múltiplos times (crédito, cobrança, atendimento) e precisa de rastreabilidade de código-fonte, não só de histórico de cliques. O pipeline manual não versiona o conteúdo da solução em um repositório Git, não roda testes automatizados, e não tem gatilho por commit. Ele resolve o "levar a solução de A para B com aprovação", não resolve "saber exatamente o que mudou entre a versão 3 e a versão 4 da solução".

Passo 5: monte o pipeline automatizado no Azure DevOps

Aqui entra a diferença real entre pipeline manual e pipeline automatizado: o segundo trata a solução como código, versionado em Git, com build e deploy disparados por evento, não por clique.

Primeiro, exporte a solução como unmanaged do ambiente de Desenvolvimento e desempacote ela no repositório usando o pac CLI:

powershell

pac auth create --url https://cooperativa-dev.crm2.dynamics.com

pac solution export --path .\out\SolucaoCredito.zip --name SolucaoCredito --managed false

pac solution unpack --zipfile .\out\SolucaoCredito.zip --folder .\src\SolucaoCredito --packagetype Unmanaged

O comando pac solution unpack transforma o .zip binário em arquivos XML e JSON legíveis, que agora podem ser versionados e revisados em pull request como qualquer outro código. Faça commit dessa pasta no repositório.

No Azure DevOps, crie um pipeline YAML que builda e importa a solução usando as tasks do Power Platform Build Tools:

yaml

trigger:
  branches:
    include:
      - main
  paths:
    include:
      - src/SolucaoCredito/*

pool:
  vmImage: 'windows-latest'

variables:
  solutionName: 'SolucaoCredito'

stages:
- stage: Build
  jobs:
  - job: PackSolution
    steps:
    - task: PowerPlatformToolInstaller@2
      inputs:
        DefaultVersion: true

    - task: PowerPlatformPackSolution@2
      inputs:
        SolutionSourceFolder: '$(Build.SourcesDirectory)/src/$(solutionName)'
        SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/$(solutionName).zip'
        SolutionType: 'Managed'

    - publish: '$(Build.ArtifactStagingDirectory)'
      artifact: solucaoManaged

- stage: DeployHomologacao
  dependsOn: Build
  jobs:
  - deployment: ImportHomolog
    environment: 'homologacao-cooperativa'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: PowerPlatformToolInstaller@2

          - task: PowerPlatformImportSolution@2
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: 'conexao-spn-homologacao'
              SolutionInputFile: '$(Pipeline.Workspace)/solucaoManaged/$(solutionName).zip'
              AsyncOperation: true
              MaxAsyncWaitTime: '60'

- stage: DeployProducao
  dependsOn: DeployHomologacao
  jobs:
  - deployment: ImportProducao
    environment: 'producao-cooperativa'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: PowerPlatformToolInstaller@2

          - task: PowerPlatformImportSolution@2
            inputs:
              authenticationType: 'PowerPlatformSPN'
              PowerPlatformSPN: 'conexao-spn-producao'
              SolutionInputFile: '$(Pipeline.Workspace)/solucaoManaged/$(solutionName).zip'
              DeploymentSettingsFile: '$(Build.SourcesDirectory)/config/deploymentSettingsProd.json'
              AsyncOperation: true
              MaxAsyncWaitTime: '60'

O detalhe que faz esse YAML funcionar como controle de verdade, e não só como automação, é o environment do Azure DevOps (homologacao-cooperativa, producao-cooperativa). Configure em Pipelines > Environments uma regra de approval no ambiente de produção: sem aprovação manual de alguém autorizado, o estágio DeployProducao fica pendente. Você ganha automação de execução sem perder controle de decisão, o que é exatamente o meio-termo que uma cooperativa precisa: menos clique manual repetitivo, mesma governança sobre quem autoriza ir para produção.

[[FIG:1]]

Passo 6: resolva connection references e environment variables antes de tocar produção

Esta é a armadilha mais comum e a mais cara de destravar depois que já aconteceu. Uma solução do Power Platform não carrega valores fixos de conexão: ela carrega connection references (a que conector aquela ação se conecta) e environment variables (URLs, IDs, chaves de configuração). Quando você importa a mesma solução managed em Homologação e depois em Produção, se não houver um arquivo de configuração de deployment, o Power Platform tenta reaproveitar valores default definidos no ambiente de origem.

Na prática isso significa: um fluxo que deveria gravar aprovação de crédito na API do core bancário de produção pode continuar apontando para o endpoint de homologação, silenciosamente, porque ninguém sobrescreveu a environment variable no import. O fluxo roda sem erro nenhum, os dados de produção vão parar num ambiente de teste, e ninguém percebe até a conciliação não bater.

A correção é gerar um arquivo de deployment settings por ambiente de destino e referenciá-lo na task de import:

json

{
  "EnvironmentVariables": [
    {
      "SchemaName": "coop_UrlApiCoreBancario",
      "Value": "https://api-producao.coopcredito.com.br/credito/v2"
    },
    {
      "SchemaName": "coop_AmbienteExecucao",
      "Value": "Producao"
    }
  ],
  "ConnectionReferences": [
    {
      "LogicalName": "coop_sharedapproval_producao",
      "ConnectionId": "d3f1a2b0-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_approvals"
    }
  ]
}

Gere esse JSON com pac solution create-settings a partir de uma exportação existente do ambiente correto, ajuste os valores manualmente e mantenha um arquivo por ambiente no repositório, nunca um único arquivo genérico reaproveitado entre estágios. Essa é a diferença entre um deploy que parece funcionar e um deploy que de fato aponta para onde deveria.

Como validar que o pipeline funcionou

Depois de rodar o fluxo completo, confira três coisas:

No host environment, abra o app Pipelines e veja o Deployment History do estágio de Produção: deve mostrar a versão da solução, o horário e quem aprovou, se você usou o pipeline nativo.
No Azure DevOps, confira o log da stage DeployProducao: a task PowerPlatformImportSolution@2 deve terminar com status succeeded e o log deve citar o nome da solução e a versão importada.
Dentro do ambiente de Produção, em Solutions, verifique que a solução aparece como Managed e que a versão bate com a que você acabou de publicar. Depois, abra a environment variable crítica (a URL do core bancário, por exemplo) e confirme visualmente que o valor é o de produção, não o herdado de homologação.

Erros comuns e o que eles realmente significam

"The pipeline host environment cannot be the same as a stage environment": você tentou usar o ambiente de produção ou desenvolvimento também como host. Crie um ambiente dedicado só para hospedar a configuração de pipelines.
"Principal user is missing prvCreatePipeline privilege": o usuário que está tentando configurar estágios não tem o papel de segurança Deployment Pipeline Administrator atribuído no host environment. Atribua o papel antes de repetir a operação.
"SolutionImportException: Import failed for connection reference": a connection reference referenciada na solução não existe no ambiente de destino ou não foi mapeada no deployment settings file. Gere ou atualize o JSON de deployment settings com o ID de conexão correto daquele ambiente.
Deploy termina com sucesso mas o app se comporta como se estivesse em ambiente de teste: não é um erro que aparece em log, é a armadilha do passo 6. A environment variable manteve o valor default de origem porque o deployment settings file não foi aplicado ou estava incompleto.
"Service principal does not have privileges on this environment" no pipeline do Azure DevOps: o Application User do Service Principal não foi criado no ambiente de destino específico. Um Service Principal precisa de Application User separado em cada ambiente Dataverse em que ele vai operar, não é herdado automaticamente entre Homologação e Produção.

Fechamento

O pipeline manual do Power Platform já resolve o problema de "não editar direto em produção" e cobre bem cooperativas com poucas soluções ativas. Ele deixa de ser suficiente quando o número de apps, fluxos e times cresce e a rastreabilidade de código passa a ser tão importante quanto o controle de acesso. Nesse ponto, o pipeline automatizado com repositório Git e Azure DevOps é o próximo degrau natural, sem descartar as aprovações que a governança da cooperativa já exige.

Se sua cooperativa está decidindo entre manter deploys manuais ou estruturar um pipeline de alm power platform completo, vale mapear primeiro quantas soluções e quantos times dependem desse fluxo hoje, é esse número que define se o investimento em automação já se paga.