ALM no Copilot Studio: a fundação para agentes em produção

Por que ALM importa desde o primeiro agente

O Copilot Studio tira um agente da ideia para o ar em horas. Essa velocidade é a maior qualidade da plataforma, mas também é o motivo pelo qual times acabam com um agente em produção antes de qualquer decisão sobre como alterá-lo com segurança. No momento em que alguém precisa construir a versão 2 sem quebrar a versão 1 que usuários reais já estão usando, falta um lugar para editar que não seja a produção, e falta um caminho confiável para levar essas mudanças até lá.

Isso é Application Lifecycle Management, ALM. Não é burocracia de TI, é a diferença entre um agente que evolui de forma previsível e um agente que se transforma em dívida técnica na primeira correção urgente. Este artigo cobre a base: as decisões que qualquer organização precisa ter resolvidas antes de um agente importar para alguém além de quem o construiu. Não é o conjunto completo de práticas avançadas, é o piso de segurança.

Comece pelos ambientes

Toda estratégia de ALM na Power Platform começa com isolamento de ambientes. O padrão mais testado é o de três camadas: Desenvolvimento, Teste e Produção. Dev é onde makers constroem e editam livremente. Test é onde se valida antes de expor usuários reais. Produção é onde o agente conversa com quem depende dele no dia a dia.

As mudanças fluem em uma única direção, de Dev para Test e depois para Produção. Essa unidirecionalidade é o que mantém a produção estável e previsível. Os ambientes são criados no Power Platform Admin Center, e essa parte é simples. O que exige decisão é a disciplina de nunca editar direto em Test ou Produção.

Esse modelo de três ambientes não é uma exigência técnica da plataforma. Para uma prova de conceito descartável, um único ambiente resolve. Mas a separação se paga no instante em que alguém precisa construir a próxima versão de um agente enquanto a versão atual continua atendendo usuários. Sem essa separação, toda edição é uma edição em produção, e não existe forma segura de testar antes de impactar quem já usa o agente.

Times mais maduros costumam acrescentar depois um ambiente de preview em anel de lançamento antecipado, para capturar regressões de plataforma antes que cheguem à produção, e um ambiente alinhado à produção, reservado para hotfixes de emergência sem interferir no trabalho em andamento nos outros ambientes. São padrões de resiliência, não fundação. Comece com os três ambientes básicos e só adicione mais quando um problema real justificar.

Solutions: a unidade de implantação do seu agente

Se os ambientes são onde o agente vive, as solutions são como ele viaja entre eles. Uma solution é um contêiner que reúne todos os componentes de que o agente depende e transforma esse conjunto em um artefato portável. Para quem vem de desenvolvimento de software, a analogia é a de um projeto ou pacote: agrupa ativos relacionados para que possam ser versionados, exportados e importados como uma unidade coerente.

Crie um publisher antes de qualquer coisa

Antes de criar a solution, crie um publisher customizado com um prefixo próprio, algo como contoso_. Isso não é formalidade, é prática que evita retrabalho. O prefixo do publisher é gravado no nome de esquema de tudo que você cria dentro da solution, o que mantém os componentes claramente identificáveis e evita o publisher genérico padrão da plataforma. O prefixo é definido uma única vez e acompanha os componentes para sempre, então vale a pena fazer isso de forma deliberada, antes de qualquer agente ser criado.

O que precisa estar dentro da solution

Tudo que o agente depende para funcionar precisa viver dentro de uma solution. Na prática, isso inclui o agente e seus componentes visíveis no Copilot Studio:

• Tópicos, a lógica conversacional
• Ferramentas, as ações que o agente pode chamar
• Fontes de conhecimento, o conteúdo em que o agente se baseia para responder

Junto disso, viajam componentes de Power Platform que sustentam o agente por trás dos panos:

• Conectores customizados, definições de API próprias que o agente ou seus fluxos chamam
• Referências de conexão, um apontador consciente de solution para uma conexão, de forma que a credencial real seja vinculada por ambiente, e não fixada no código
• Variáveis de ambiente, valores de configuração que mudam de ambiente para ambiente
• Workflows, fluxos de Power Automate que executam lógica em nome do agente

Qualquer componente criado fora de uma solution é invisível para o pipeline de implantação e não pode ser promovido de forma limpa. Esse é o erro mais comum em times que estão começando: construir dentro da solution default e só descobrir depois que não é possível movê-la. A prevenção é simples: crie sua solution primeiro e construa tudo dentro dela desde o início.

Uma boa prática complementar é definir sua solution como preferred solution em Dev logo depois de criá-la. Assim, novos componentes caem automaticamente nela em vez de ficarem soltos na solution default, onde acabam esquecidos.

Managed vs. unmanaged: onde as coisas dão errado

Solutions existem em duas formas, e confundir os dois papéis é a origem da maior parte dos problemas de ALM em Power Platform.

Em Dev, agentes, workflows e variáveis vivem dentro de uma solution não gerenciada, onde makers editam livremente. Na hora de promover, essa solution é exportada como um pacote gerenciado versionado e implantada em Test e, depois, em Produção, onde chega como solution gerenciada. As mudanças fluem em uma direção só: de Dev, através do pacote, para os ambientes seguintes. Se algo precisa mudar, a mudança acontece em Dev, é reexportada e reimplantada, nunca editada diretamente no destino.

Um detalhe que pega muitos times de surpresa: uma solution gerenciada não é totalmente selada. É possível criar, no ambiente de destino, uma camada não gerenciada sobre componentes gerenciados e sobrescrevê-los localmente. É possível, e é a origem das piores confusões de ALM, porque essas edições locais são silenciosamente apagadas na próxima implantação, sem aviso e sem log claro do que se perdeu.

Duas medidas fecham essa brecha: ativar a configuração de ambiente que bloqueia customizações não gerenciadas em Test e Produção, e remover o acesso de maker e admin desses ambientes para que ninguém tenha a possibilidade de editar ali. Vale registrar que esse bloqueio ainda permite algumas operações pontuais, como ativar ou desativar um flow, então a higiene de acesso continua sendo necessária mesmo com o bloqueio ativo.

Pipelines: movendo a solution com segurança

Com ambientes definidos e a solution concentrando todos os ativos do agente, resta a pergunta prática: como a solution se move de Dev para Test e para Produção sem depender de processo manual? É possível exportar um .zip de Dev e importar em Test, repetindo o processo em Produção. Funciona, mas é sujeito a erro humano e não deixa registro confiável de o que foi implantado, quando e por quem.

Power Platform Pipelines resolvem esse problema. Um pipeline é um caminho de promoção pré-configurado que conecta os ambientes em sequência. Promover passa a ser uma ação única: selecionar a solution, selecionar o próximo estágio, implantar. Um ponto importante de arquitetura: a mesma versão da solution implantada em Test é a que é promovida para Produção, o pipeline carrega esse artefato exato adiante, em vez de reexportar de Dev a cada estágio. Isso garante que o que foi validado em Test é exatamente o que chega em Produção.

A implantação via pipeline também é o momento em que a configuração se vincula ao ambiente de destino. Durante o deploy é possível fornecer:

• Conexões para ferramentas, conectores customizados, servidores MCP e workflows, mapeadas através de referências de conexão, de forma que cada ambiente use sua própria credencial
• Valores de variáveis de ambiente específicos do ambiente de destino

O que um pipeline entrega, na prática:

• Repetibilidade, o mesmo processo em toda implantação, sem passos manuais para esquecer
• Trilha de auditoria, quem implantou o quê, quando e em qual ambiente
• Visibilidade de versão, o histórico de deploy mostra exatamente qual versão está em cada ambiente
• Guardrails, é possível exigir aprovação antes de a implantação avançar para o próximo estágio

Um ponto que precisa ser tratado com realismo: o histórico de deploy dá visibilidade, mas não é rollback de um clique. Desinstalar uma solution gerenciada remove seus componentes, incluindo o próprio agente. Voltar atrás geralmente significa implantar uma versão gerenciada anterior ou restaurar um backup de ambiente. Isso precisa estar no plano de contingência antes do incidente, não ser descoberto durante ele.

Configuração: variáveis de ambiente e segredos

O princípio é direto: nada específico de ambiente fica fixado no código ou no componente. Endpoints de API, URLs de SharePoint, limiares de negócio, feature flags, tudo isso vai para variáveis de ambiente.

Uma variável de ambiente tem duas partes distintas:

• Definição, o esquema: nome, tipo de dado, descrição. Isso sempre viaja com a solution.
• Valor, o conteúdo real para um ambiente específico.

Por padrão, os valores ficam fora da solution, e cada ambiente fornece o seu. Essa é a escolha certa para qualquer coisa genuinamente específica de ambiente, um endpoint de Test não deve chegar à Produção. Mas isso não é obrigatório: é possível incluir um valor junto com a solution para que ele viaje também, quando o valor é igual em todos os lugares e faz sentido tratá-lo como padrão.

Os valores são fornecidos no momento do deploy, não antes. Essa ordem importa: não é possível configurar um valor para uma variável cuja definição ainda não existe no ambiente, e a definição só chega quando a solution é importada. Por isso, um pipeline pergunta os valores durante a implantação, ou, em cenários não assistidos, lê-los de um arquivo de configurações de implantação. Na primeira implantação a definição chega junto com a solution; em atualizações seguintes, a definição já existe no destino, então os valores podem ser pré-configurados com antecedência.

Para gerar esse arquivo de configurações via linha de comando, usa-se o pac solution do CLI for Microsoft 365 ou do Power Platform CLI. Um exemplo de estrutura desse arquivo de deployment settings:

{
  "EnvironmentVariables": [
    {
      "SchemaName": "contoso_ApiEndpoint",
      "Value": "https://api.producao.contoso.com/v1"
    },
    {
      "SchemaName": "contoso_LimiteAprovacao",
      "Value": "50000"
    }
  ],
  "ConnectionReferences": [
    {
      "LogicalName": "contoso_sharedsharepointonline",
      "ConnectionId": "guid-da-conexao-em-producao"
    }
  ]
}

Esse arquivo é gerado a partir de um template do Power Platform CLI, preenchido por ambiente e usado pelo pipeline em implantações não assistidas de CI/CD. Segredos, chaves de API, tokens, credenciais, não devem entrar nesse arquivo em texto puro. O lugar certo para eles é o Azure Key Vault, referenciado através de uma variável de ambiente do tipo segredo. O agente referencia o segredo pelo nome e a plataforma resolve o valor em tempo de execução, o que significa que rotacionar uma chave é só atualizar o Key Vault, sem precisar de nova implantação. O pipeline mapeia a referência por ambiente, mas nunca armazena o valor do segredo em si.

Avaliações: saber que o agente funciona, não só que foi implantado

Implantar corretamente não garante comportamento correto. Uma avaliação é um conjunto definido de entradas de teste e saídas esperadas que mede se o agente está selecionando as ferramentas certas e produzindo respostas aceitáveis. Trate isso como um portão de qualidade, não como um extra opcional.

A prática recomendada é rodar as avaliações em Dev antes de exportar a solution, e novamente no ambiente de destino depois da importação, para confirmar que a implantação chegou intacta e que o comportamento do agente se manteve consistente entre ambientes. Um agente pode ser implantado sem erro técnico e ainda assim se comportar diferente em produção, por causa de uma variável de ambiente com valor errado ou uma fonte de conhecimento que não replicou corretamente.

Isso pode ser automatizado como parte do pipeline de CI/CD, transformando as avaliações em um gate que bloqueia a promoção quando a qualidade cai abaixo de um limiar definido. Essa integração entre avaliações e pipeline de implantação é um tema denso o suficiente para merecer tratamento próprio, mas a base descrita aqui, ambientes, solutions e pipelines, é o que torna esse gate possível de existir.

Checklist antes de promover para produção

• Publisher customizado e prefixo próprio estão configurados
• Todos os ativos do agente vivem dentro de uma única solution
• Essa solution está definida como preferred solution em Dev
• Nenhum valor específico de ambiente está fixado no código, tudo está em variáveis de ambiente
• Segredos estão no Key Vault, referenciados via variáveis de ambiente do tipo segredo
• Test e Produção bloqueiam customizações não gerenciadas, com acesso de maker e admin removido
• Um pipeline está configurado com a sequência correta de estágios
• A solution é exportada como gerenciada para Test e Produção
• As avaliações passam em Dev antes da exportação, e novamente no destino após a importação

O retorno de ter a fundação pronta

Com essa base sólida, avançar um agente se torna uma única ação de pipeline. A produção fica estável porque ninguém edita nela diretamente. A configuração se vincula automaticamente ao ambiente certo. Segredos rotacionam sem precisar de nova implantação. E a qualquer momento é possível saber exatamente qual versão está rodando em cada ambiente.

Essa é a fundação, não o ponto de chegada. Ambientes de preview, ambientes de hotfix alinhados à produção, controle de versão e gates automatizados de qualidade são passos naturais depois que essa base está estável, e cada um desses temas merece profundidade própria em vez de ser tratado como item de lista.

Times que colocam agentes do Copilot Studio em produção sem essa disciplina de ALM costumam descobrir o custo tarde, quando uma correção simples exige recriar o que já funcionava. Vale revisar essa fundação antes que o próximo agente vire dependência crítica de alguém.