Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA em português / ALM do Power Platform com GitHub Actions: fonte, build, teste e implantação sem adivinhação (Dublagem IA)

Transcript

ALM do Power Platform com GitHub Actions: fonte, build, teste e implantação sem adivinhação (Dublagem IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA em português

0:00
Preparado para 10 dias de Microsoft 305, Copilot, IA, Azure e as pessoas moldando o futuro do trabalho?
0:07
Em janeiro, a M365 com está de volta, estamos crescendo ainda mais.
0:12
Junte-se a nós para sessões ao vivo, demonstrações reais e conhecimento prático de MVPs e especialistas do setor em todo mundo.
0:18
Nada de slides genéricos, nada de jargões sem fim.
0:21
Estamos enfrentando os desafios reais.
0:23
Copilot Studio, agente de IA, fábrica, segurança, governança e automação, GAU.
0:28
Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões projetadas para você.
0:35
Com 10 dias inteiros, você pode explorar múltiplas tecnologias e se conectar com uma comunidade global.
0:40
Assista ao vivo e leve insights práticos de volta para sua organização.
0:45
Janeiro de 2027, 10 dias, uma comunidade Microsoft.
0:49
As inscrições já estão abertas.
0:52
Garanta sua vaga hoje!
0:54
É mm3105com.net
0:58
Participe agora em m3105com.net e nos vemos ao vivo em janeiro!
1:05
Você sente que suas implantações no Power Platform são uma caixa preta?
1:08
Você envia uma atualização, prende a respiração e torce para que funcione em dev, teste e produção?
1:12
E se você pudesse controlar e ver cada estágio do seu processo de ELM usando o GitHub Action sem mais palpites,
1:19
ou remendos manuais, ou...
1:21
Vamos revelar como cada componente, controle de versão, automação e variáveis seguras realmente se conectam?
1:28
Este não é apenas mais um passo a passo.
1:30
Este é o porquê que a maioria dos guias ignora para que sua próxima implantação não deixe você na dúvida.
1:35
Então por que o ELM do Power Platform parece um labirinto?
1:37
Se você já tentou implantar um Power App e sentiu aquela incerteza constante,
1:41
como se algo importante tivesse escapado, você não está sozinho.
1:46
No papel, o Power Platform promete um desenvolvimento de apps fácil,
1:49
mas por trás da fachada amigável, o ELM é tudo menos simples.
1:53
Um aplicativo web é implantado a partir do controle de versão,
1:56
compilado em um pipeline e chega à produção com comportamento previsível.
2:00
O Power Platform, por outro lado, esconde metade da lógica em interfaces de arrastar e soltar,
2:04
telas de conectores e fórmulas que você não vê em nenhum repositório Git.
2:08
Então mesmo que você siga a cada passo daqueles guias administrativos,
2:11
você ainda encontra falhas estranhas e difíceis de diagnosticar
2:14
quando os apps críticos deixam o desenvolvimento.
2:17
Vamos analisar os guias de ELM por aí?
2:19
A maioria deles vai te mostrar como exportar um arquivo zip de solução e importá-lo em outro lugar.
2:24
Simples o bastante.
2:25
Mas o como é apenas uma camada.
2:27
O que eles ignoram é o porquê.
2:29
Por que a implantação do Power Platform quebra de maneiras que o código comum nunca quebra?
2:33
É isso que causa uma confusão sem fim.
2:35
A raiz do problema é que a lógica, as conexões e a configuração no Power Apps não são armazenadas como código clássico.
2:42
Você não está apenas clonando um repositório e observando os testes unitários.
2:45
Então, quando você tenta mover seu aplicativo, todas aquelas dependências ocultas,
2:48
conexões com Outlook, SharePoint e APIs personalizadas nem sempre viajam perfeitamente dentro daquele arquivo zip.
2:54
Eis o cenário.
2:55
Você tem um aplicativo novo e incrível funcionando no ambiente de desenvolvimento.
2:57
Você exporta uma solução e importa para teste e, de repente, o fluxo para de funcionar.
3:02
Raramente é apenas um problema de arquivo.
3:03
Em vez disso, as conexões estão apontando para o lugar errado, as permissões não coincidem
3:07
e as políticas de dados bloqueiam conexões que pareciam estar bem há alguns minutos.
3:12
Agora, imagine fazer isso em três ambientes, Dev, Test e Prod, com cada um usando conexões,
3:17
políticas de proteção de dados, aprovadores e guardas administrativos diferentes.
3:21
Você não consegue resolver isso apenas com copia e colar.
3:23
As pesquisas confirmam que administradores e criadores vêm toda semana.
3:27
A maioria das implantações falhas na Power Platform decorre de referências de conector ausentes
3:31
ou variáveis de ambiente mal gerenciadas.
3:34
Uma referência de conector ausente significa apenas que o fluxo não consegue encontrar
3:37
sua conexão com Outlook ou Dataverse.
3:40
Portanto, no minuto em que você tenta executar seu aplicativo ou fluxo em outro ambiente,
3:44
você recebe erros de tempo de execução.
3:47
E como as variáveis de ambiente funcionam de forma diferente na Power Platform
3:50
em comparação com outros produtos do Microsoft 365,
3:52
elas confundem até desenvolvedores experientes.
3:55
As variáveis devem lidar com pontos de extremidade-chave ou configurações específicas do locatário.
4:00
Mas, se alguém esquecer de atualizá-las após exportar uma solução,
4:02
até mesmo uma mudança aparentemente inofensiva pode quebrar um aplicativo ativo.
4:06
Muitos de nós caímos na mesma armadilha no início.
4:09
Você pode pensar que exportar um zip de solução agrupa tudo o que é necessário,
4:12
mas na verdade ele ignora a referência de conector dinâmicas.
4:14
Por exemplo, digamos que você tenha um aplicativo que usa um conector HTTP
4:17
para um serviço de terceiros em Dev.
4:19
Ao importar para teste ou produção, essa instância específica do conector não existirá.
4:24
A referência do conector dentro do seu aplicativo aponta para um objeto ausente,
4:27
e os fluxos dentro da solução param de funcionar silenciosamente
4:30
até que um usuário ou administrador recrie e remapee as conexões manualmente.
4:34
Se você tiver mais de um criador ou administrador, é ainda mais fácil perder o controle
4:39
de qual referência vai para onde, e ninguém quer aquele post-mortem de funcionar em Dev.
4:44
Outra complicação, entidades e serviço.
4:47
A maioria das pessoas começa usando contas de usuário para exportar e importar soluções
4:51
porque é mais rápido começar.
4:53
Mas quando você tenta automatizar com GitHub Actions ou qualquer sistema de CI
4:56
usando os credenciais de uma pessoa, você rapidamente chega a um beco sem saída.
4:59
Você encontrará barreiras de permissão, às vezes sem mensagens de erro claras,
5:03
ou até mesmo acionará auditorias de conformidade
5:05
porque está executando implantações críticas sobre uma conta pessoal
5:08
em vez de algo destinado à automação.
5:10
Service Principles, essencialmente identidades de aplicativo criadas no Azure AD,
5:14
cuidam de todas as permissões, registros e auditorias que seu pipeline precisa.
5:19
Sem eles, sua cadeia de automação vira uma colcha de retalhos de transferências manuais,
5:23
e você nunca sabe quem alterou o quê.
5:25
P. Controle de versão também se torna um incógnito.
5:27
Com um código comum, você tem histórico de commits e ferramentas de rastreamento.
5:32
Arquivos de solução da Power Platform representam apenas instantâneos,
5:34
o que significa que falta um rastreamento granular de mudança.
5:37
A lógica escondida em fórmulas de tela de um Canvas App,
5:40
ou em fluxos pouco documentados, não fica visível até que você exporte novamente.
5:44
Alguém ajusta uma configuração de fluxo na interface,
5:46
boa sorte tentando descobrir por que ambientes posteriores começam a se comportar de forma diferente.
5:50
O resultado final, gerenciar a LM para a Power Platform,
5:52
parece resolver um quebra-cabeça com metade das peças faltando,
5:55
ou pelo menos escondidas sob a caixa.
5:57
Dependências invisíveis, conectores específicos de ambiente,
6:01
e variáveis que você não vê no código,
6:02
alteram o fluxo de trabalho comum do desenvolvedor.
6:06
E isso é antes de lidar com o fato de que ambientes de produção
6:09
quase sempre têm permissões mais rígidas,
6:11
políticas de dados diferentes e requisitos de auditoria
6:13
que não são óbvios em dev ou teste.
6:17
Mas aqui está o lado positivo.
6:18
Essa complexidade não é aleatória.
6:20
Existe uma razão prática para a Power Platform lidar com fonte,
6:24
variáveis e conectores de uma forma tão única,
6:27
ela tenta permitir que usuários de negócio criem aplicativos poderosos,
6:30
sem se preocupar com o código.
6:32
O efeito colateral é que você, como uma pessoa configurando automação,
6:35
precisa monitorar o que está escondido sob o capô.
6:38
Se você souber onde esses fios invisíveis passam,
6:40
pode corrigir ou evitar a maioria das armadilhas que descarrilam o ILM da Power Platform.
6:45
Agora, se tudo isso parece muita coisa para lidar, você não está errado.
6:50
Mas existem quatro pilares de ILM que realmente ajudam antes a embaraçar essa bagunça.
6:54
Fonte, build, teste e implantação.
6:56
Cada um tem suas peculiaridades na Power Platform,
6:58
mas juntos eles devolvem estrutura ao que, de outra forma, parece um caos.
7:02
O sistema central de ILM, fonte, build, teste e implantação.
7:05
Toda vez que alguém pede um pipeline da Power Platform que simplesmente funcione,
7:09
a primeira coisa que vem à mente são aqueles quatro pilares de ILM, fonte, build, teste e implantação.
7:16
No mundo de desenvolvimento tradicional, você quase poderia executar isso dormindo.
7:19
A Power Platform não te deixa escapar tão fácil.
7:21
De repente, fonte não significa código.
7:24
Significa lidar com arquivos e solução,
7:26
exportando pacotes compactados repletos de aplicativos, fluxos e, às vezes,
7:30
conectores fingindo ser parte da fonte.
7:33
Vamos começar pelo básico,
7:35
depois analisar o que torna cada pilar um pouco estranho neste mundo.
7:37
Você tem seu arquivo zip-solução.
7:40
Não é código no sentido convencional.
7:42
Abre e você será recebido por arquivos explicativos em XML e JSON,
7:45
e não pela lógica que você veria em TypeScript ou C-Shack.
7:48
Mas essa é a fonte da Power Platform.
7:50
As equipes costumam tropeçar aqui.
7:52
Parece portátil até que você percebe que a maioria das alterações,
7:55
como atualizar uma fórmula em uma tela ou ajustar a lógica de um fluxo,
7:58
não são óbvias até você exportar um novo arquivo zip da solução.
8:01
Então sim, você pode versionar esses arquivos de solução no Git,
8:04
mas a menos que seja disciplinado ou exportar após cada edição relevante,
8:07
seu histórico terá lacunas gritantes,
8:09
seu histórico terá lacunas gritantes.
8:10
Agora vem a configuração.
8:12
Para aplicativos comuns, você pode armazenar streams de conexão
8:14
em um arquivo de configuração e dar o assunto para encerrado.
8:17
Power Platform introduz dados específicos do ambiente dentro dessas soluções.
8:21
Não se trata apenas de variáveis de ambiente,
8:23
mas de referências de conectores, endpoints, dinâmicos, funções
8:26
e permissões agrupadas junto com a lógica de negócios.
8:28
Se você esquecer de atualizá-los antes de exportar do Devil o teste,
8:33
estará travando ponteiros para o lugar errado.
8:36
Já vi equipes confirmarem religiosamente seus arquivos zip de solução,
8:40
apenas para implantar e perceber que metade do aplicativo
8:42
ainda está se comunicando com o Dataverse de desenvolvimento
8:44
em vez de produção porque ninguém remapeou as referências dos conectores.
8:48
Então temos o Build Compilação.
8:50
A palavra Build geralmente traz imagens de compilar código
8:52
e vê marcações verdes em um trabalho de CI.
8:54
Com a Power Platform, o processo de Build consiste em armazenar esses pacotes zip,
8:59
verificar o esquema e validar dependências.
9:02
Em um pipeline do GitHub Actions, um trabalho de Build pega o arquivo de solução
9:05
que você confirmou e usa a CLI da Power Platform da Microsoft
9:09
para descompactar, validar e recompactar a solução.
9:12
A etapa de validação é de a mágica ou o caos acontece.
9:14
Pode detectar referências quebradas ou ações não suportadas.
9:18
Pior ainda, se uma alteração no seu fluxo depender de um conector personalizado
9:21
que nunca entrou no controle de origem, seu Build,
9:23
empacota silenciosamente algo incompleto.
9:26
E onde as coisas ficam complicadas.
9:28
Esses trabalhos de Build são menos sobre compilar
9:30
e mais sobre orquestrar uma exportação confiável
9:32
e garantir que o conteúdo seja passível de entrega.
9:36
Equipes que pulam isso ou fazem compressa rapidamente
9:38
e acabam em situações onde o Build tecnicamente tem sucesso.
9:41
Mas o que chega ao AT ou produção está faltando metade dos recursos pretendidos.
9:45
A Microsoft continua promovendo a mensagem de que arquivos de solução
9:47
tornam o LM portátil, mas sempre há uma nota de rodapé.
9:50
A portabilidade depende de conectores estarem mapeados corretamente
9:53
e funções configuradas em todos os ambientes.
9:55
Teste o próximo botão de fonte.
9:56
Em um pipeline aplicativo web, testes automatizados
9:59
podem executar testes unitários ou verificações de interface.
10:02
Para a Power Platform, o que conta como teste está aberto a debate?
10:06
Às vezes é a validação da solução.
10:08
Em outras palavras, a solução abre e as dependências principais são resolvidas.
10:11
Outras vezes, executar fluxos de teste ou verificar se os conectores respondem
10:16
em um ambiente de teste a este.
10:18
Muitas vezes, os testes são manuais porque a validação da lógica de negócios
10:21
dentro de um aplicativo de tela ainda não está integrada a pipelines automatizados.
10:25
Mas você pode automatizar verificações para detectar conectores ausentes,
10:28
validar fluxos críticos ou até mesmo realizar um ping em um ambiente de teste
10:31
apenas para provar que as credenciais estão funcionando.
10:34
Implantação em um dia 12 e turno em VD.
10:35
Ao implantar um aplicativo padrão, você pode apenas enviar um artefato da web para o Azure.
10:39
Com o Power Platform, você precisa mapear conexões, atribuir permissões,
10:43
atualizar segredos, trocar variáveis de ambiente
10:44
e finalmente acionar uma importação usando uma entidade de serviço,
10:48
nunca uma conta comum.
10:49
Caso contrário, você ficará preso a auditorias e negações de permissão.
10:53
GitHub Actions pode unir esse processo,
10:55
mas apenas se cada trabalho souber qual ambiente direcionar e quais segredos usar.
11:00
Já vi equipes tentarem atalhos usando o único conjunto de credenciais
11:03
entre desenvolvimento e produção, o que é uma receita para o caos,
11:05
vazamentos de dados, erros de permissão e recursos quebrados
11:08
que aparecem apenas em um ambiente.
11:11
Vejo uma equipe real com a qual trabalhei alguns meses.
11:13
Eles faziam a maioria das coisas corretamente,
11:15
repositórios de Git padrão, arquivos ZipSol são versionados e ramificações casas.
11:18
Mas o pipeline deles sempre quebrava na implantação.
11:21
Eles nunca se preocupavam em trocar variáveis de ambiente
11:23
ou atualizar referências de conectores antes de importar para a produção.
11:26
Isso deixava fluxos importantes apontando para os pontos de extremidade errados,
11:29
com dados sendo enviados para os sistemas incorretos.
11:31
Solução.
11:32
Etapas roteirizadas no pipeline do GitHub que trocavam variáveis e remapeavam cada conector durante a importação.
11:38
A própria orientação da Microsoft é direta sobre isso.
11:41
Use arquivos de solução para mover itens entre ambientes,
11:43
mas sempre trate as referências de conectores e mapeamento de funções como parte do seu pipeline.
11:48
Eles destacam que pular essas etapas é a maneira número um de quebrar aplicativos,
11:51
especialmente à medida que os ambientes se tornam mais restritos.
11:53
Quando você trata origem, compilação, teste e implantação como peças móveis conectadas,
11:58
e não apenas etapas isoladas, fica mais fácil entender porque tantas tentativas GLM falham,
12:02
e como você pode solucionar problemas de fato em vez de apenas cruzar os dedos.
12:07
A seguir, vamos entrar em como o GitHub Actions coordena essa dança,
12:10
gatilhos, ramificações e a separação de trabalhos
12:13
que mantém sua automação no Power Platform flexível e segura.
12:17
GitHub Actions. Conectando os pontos com gatilhos e trabalho.
12:20
Se você já esperou um pipeline do GitHub Actions terminar após atualizar seu Power App,
12:24
já sabe que automação não significa instantâneo, e definitivamente não significa mágica.
12:29
A maioria das equipes bate nessa parede logo após a empolgação de ver seu primeiro fluxo de trabalho rodar.
12:34
Você configura um script, conecta ao seu repositório,
12:37
e espera que cada novo commit seja implantado perfeitamente em todos os ambientes.
12:41
Então a realidade aparece.
12:43
Em vez de apenas iniciar um script, o GitHub Actions usa uma cadeia lógica
12:46
construída em torno de gatilhos, tarefas e transferências entre ambientes.
12:51
Essa ordem e estrutura é o que impede que as implantações se tornem um emaranhado de etapas,
12:55
falhas e erros estranhos.
12:56
O ponto de partida nesse sistema é o gatilho?
12:59
A maioria dos iniciantes cria um fluxo de trabalho,
13:02
que é acionado a cada push, ou sempre que um pull request chega na branch principal,
13:07
a descer e descerá.
13:08
À primeira vista, isso parece uma boa prática.
13:10
Por que não executar seu pipeline sempre que o trabalho muda?
13:12
Aqui está o problema.
13:13
Quando você define um gatilho apenas na branch principal,
13:15
tudo é canalizado através de um único caminho.
13:17
E se as alterações precisarem para o ambiente de desenvolvimento,
13:19
menor produto e teste ou produção?
13:20
E se você estiver pronto para enviar para a produção, mas o teste ainda estiver em validação?
13:25
Equipes que usam gatilhos genéricos tendem a ter problemas
13:27
em que recursos destinados ao desenvolvimento acabam em produção ou implantações de teste,
13:32
substituem configurações de produção.
13:35
Você pode ramificar fluxos de trabalho para cada ambiente, dev, teste e prod,
13:39
e definir gatilhos muito específicos para cada um.
13:42
Por exemplo, configure um fluxo que só roda em pushes para branch dev,
13:45
ou dispare um fluxo diferente,
13:47
quando alguém fizer merge na branch de release de produção.
13:50
Essa abordagem oferece mais controle,
13:52
cria uma divisão clara entre trabalho em andamento e alterações reais,
13:55
mas muitas equipes nunca revisam seus gatilhos após criá-los.
13:58
É assim que segredos de um ambiente podem escapar para outro
14:01
e configurações de desenvolvimento acabam em produção por acidente.
14:05
Uma equipe com a qual trabalhei tentou executar todo o seu processo de LM
14:08
a partir de um único fluxo de trabalho.
14:10
Por um tempo, pareceu bem,
14:12
até que alguém notou que a string de conexão do banco de dados de produção
14:15
apareceu no ambiente de desenvolvimento.
14:18
Eles não perceberam que seus segredos estavam sendo compartilhados entre as tarefas.
14:21
E é assim que o código se movia entre os ambientes
14:23
e os segredos vazavam junto com ele.
14:25
Não foi uma falha ou erro óbvio.
14:26
Foi silencioso?
14:28
Esse tipo de vazamento de dados é mais comum do que se pensa,
14:30
especialmente se você não configurar seus fluxos
14:32
para separar segredos e variáveis de ambiente.
14:35
Cada tarefa em um fluxo do GitHub Actions
14:37
lida com uma parte clara do processo.
14:39
Uma tarefa pode lidar com a exportação da solução de um ambiente de origem.
14:44
Outra tarefa cuida da validação,
14:46
descompactação, verificação de metadados,
14:48
dependências e referências de conectores.
14:50
Em seguida vem a tarefa que prepara as variáveis específicas do ambiente,
14:55
adaptando a solução para que ela se encaixe no ambiente de destino.
14:59
A última tarefa aciona o processo de importação usando o Service Principles
15:02
para gravar as alterações no ambiente correto.
15:05
Você pode pensar em variáveis de ambiente e segredos como espaços reservados básicos,
15:08
mas na prática eles são a cola que mantém tudo unido, unido.
15:11
Strings de conexão, chave de API, senhas compartilhadas,
15:15
tudo precisa alternado entre tarefas, mas nunca pode vazar entre limites.
15:20
No ILM do Power Platform você pode ter uma conexão dataverse diferente para cada ambiente,
15:25
ou precisar alternar endpoints dependendo do fluxo ou powerapp que está usando.
15:30
Se você reutilizar variáveis ou codificar segredos,
15:32
acabará com um pipeline frágil ou pior, com riscos de segurança significativos.
15:35
O processo de importação depende de extrair segredos apenas do cofre correto
15:40
para que a produção não seja exposta por erros de teste ou desenvolvimento.
15:44
Um bom modelo mental para segredos no GitHub Actions
15:46
é imaginar cada ambiente como tendo seu próprio cofre digital,
15:49
uma caixa trancada que só as tarefas certas podem ver.
15:53
O GitHub oferece controles precisos.
15:55
Você pode limitar segredos a ambientes para que uma tarefa sendo executada em dev
15:59
não acesse credenciais de produção e vice-versa.
16:02
Configure esses cofres, e mesmo que alguém ajustando o pipeline
16:05
tente algo arriscado,
16:07
as regras de proteção de ambiente impedem que um erro se espalhe.
16:10
A documentação da Microsoft e do próprio GitHub enfatizam muito esse ponto.
16:13
Eles recomendam regras de proteção de ambiente e definição rigorosa de escopo de segredos
16:17
para impedir vazamentos entre ambientes antes mesmo de começarem.
16:20
Sem esse tipo de proteção, até os fluxos de trabalho de LM mais bem projetados falham.
16:25
Imagine um fluxo implantando em produção
16:26
enquanto ainda mantém uma stringa de conexão de desenvolvimento
16:29
ou um ambiente de teste acessando dados de produção.
16:32
Nem sempre isso quebra as coisas de forma visível.
16:34
Às vezes significa apenas que alertas de conformidade são disparados
16:37
ou os logs se enchem de erros sutis que lentamente se acumulam em problemas maiores.
16:41
É por isso que ramificar fluxo de trabalho e definir escopo de segredos
16:43
não são apenas tópicos avançados.
16:45
Eles são a rede de segurança que impede que sua automação se desfaça silenciosamente.
16:48
Também há valor em dividir fluxos de trabalho.
16:51
Não apenas por ambiente, mas por responsabilidade.
16:52
O código exporta e valida soluções não deveria nem saber como implantar ou trocar segredos.
16:59
Se cada tarefa cuida de uma peça do quebra-cabeça,
17:02
fica muito mais fácil identificar onde as coisas quebram,
17:04
reverter e auditar alterações posteriormente.
17:08
Segredos permanecem em seus cofres, tarefas seguem permissões claramente definidas
17:12
e falhos no pipeline apontam diretamente para a peça que precisa de correção.
17:15
Entender como o GitHub Actions transfere o trabalho de uma tarefa para outra,
17:20
mantendo os segredos com escopo restrito e gatilhos bem definidos,
17:23
é o que transforma o ALM de um experimento otimista em uma prática confiável, segura e previsível.
17:29
Essa segmentação de fluxo de trabalho não é apenas para seguir as melhores práticas.
17:32
É o que bloqueia vazamentos de seguranças silenciosos e substituições acidentais,
17:37
eliminando toda uma classe de erros invisíveis antes que comecem a assombrar seus ambientes.
17:41
Agora, com as peças trabalhando juntas por meio de automação devidamente dimensionada,
17:46
é hora de abordarmos outro ponto de atrito.
17:49
Conectores, service principles e as pequenas, porém críticas e armadilhas
17:52
que podem paralisar suas implantações justamente quando você ganha confiança.
17:57
Segredos de service principles e os problemas com conectores.
17:59
Se você já tentou mover um power app ou flow do desenvolvimento para a produção, conhece a história.
18:05
As coisas funcionam perfeitamente em um ambiente, mas assim que você alterna tudo para
18:09
ou apresenta aqueles erros de conexão misteriosos.
18:13
Isso não é exclusivo de uma equipe específica.
18:15
Todo administrador da Power Platform eventualmente esbarra nessa parede.
18:19
A raiz do problema está em como os conectores e segredos se comportam nos bastidores.
18:24
Você não pode simplesmente exportar um zip de solução do desenvolvimento e esperar que
18:28
funcione em outro lugar, porque as conexões dependem do ambiente.
18:33
Comecemos pelas referências de conector.
18:34
Na Power Platform, um conector nunca é apenas uma informação estática incluída no seu
18:39
aplicativo.
18:40
Ele é dinâmico, mutável e muitas vezes exclusivo de cada ambiente.
18:44
Ao exportar sua solução, as referências de conector funcionam quase como favoritos.
18:48
Elas apontam para objetos de conexão que só existem no ambiente em que foram criados.
18:52
Portanto, ao importar para teste ou produção, seu endpoint HTTP ou link do Dataverse não
18:57
é necessariamente recriado da mesma forma ou nem chega a ser recriado.
19:01
É aqui que as equipes são pegas de surpresa.
19:02
Se o ambiente de desenvolvimento usa um conector para testar dados e essa configuração não
19:08
é espelhada na produção, seu fluxo ou app falha silenciosamente ou trava na primeira
19:13
tentativa de conexão.
19:16
Muitas pessoas tentam contornar isso compartilhando credenciais de usuário entre ambientes.
19:21
Elas pensam que se usarem a mesma conta ou senha que criou a conexão no desenvolvimento,
19:25
talvez funcione na produção.
19:27
A realidade é que isso traz uma série de problemas, desde negações de permissão até
19:30
gatilhos de auditoria de conformidade.
19:32
A própria orientação da Microsoft é clara dos agredenciais de usuário individuais
19:36
para implantações automatizadas não é viável nem seguro.
19:39
Isso deixa sua automação à mercê de redefinições de senha e pode deixar um rastro confuso nos
19:43
logs de auditoria.
19:44
Não há responsabilidade clara e, eventualmente, as permissões bloqueiam o pipeline quando o
19:49
usuário original é sinalizado, removido ou perde o acesso.
19:53
Apresentamos o Service Principle.
19:54
Se você nunca trabalhou com eles, imagine um service principal como um par de mãos
19:58
digital extra criado especificamente para automação.
20:01
Diferente de um usuário comum, um service principal está vinculado a um registro de
20:05
aplicativo no Azure AD, não a uma pessoa real, não a uma pessoa real.
20:09
Você concede a ele as permissões mínimas necessárias para executar suas tarefas de
20:11
implantação.
20:12
Isso parece simples, mas o benefício é enorme.
20:15
Em vez de depender de um usuário que pode sair da organização ou mudar de cargo, as
20:18
implantações permanecem consistentes, auditáveis e rastreáveis.
20:20
Cada ambiente obtém acesso apenas às conexões e recursos corretos, e quaisquer alterações
20:26
são registradas sob esta conta de robô.
20:28
Quando algo falha, você tem uma trilha de auditoria clara, e não acaba com fluxos órfãos
20:32
que ninguém consegue corrigir.
20:35
Sobre o problema de mapear conectores.
20:37
Considere o que acontece quando os ambientes se distanciam.
20:40
Talvez a equipe de desenvolvimento tenha omitido aprovação para um novo conector personalizado.
20:43
Digamos que ele acesse uma API de sandbox.
20:46
Quando chega a hora de mover para a produção, esse conector não apenas está faltando como pode
20:49
nem ser permitido pelas políticas de dados da organização.
20:52
Se você esquecer de remapear, o aplicativo chamará o endpoint errado ou quebrará completamente.
20:58
Eu vi isso causar sérios problemas em um grupo de saúde recentemente.
21:01
Um mapeamento de conector esquecido disparou o uso de dados de teste na produção e quase
21:05
criou um incidente de conformidade.
21:07
O pipeline automatizado deles exportou tudo como planejado, mas a referência do conector
21:11
dentro da solução ainda apontava para um antigo banco de dados de teste que não foi
21:15
sinalizado pela Power Platform até que dados reais começassem a fluir pelos caminhos
21:18
errados.
21:20
Variáveis de ambiente entram em cena para aliviar parte desse transtorno.
21:23
Diferente de codificar endpoints ou chaves de API, as variáveis de ambiente permitem separar
21:27
o que muda entre os ambientes do que permanece igual.
21:31
Você pode trocar endpoint, chaves de API ou outros segredos a cada implantação sem precisar
21:35
reescrever seu aplicativo ou fluxo.
21:38
Por exemplo, um fluxo que funciona com uma tabela Dataverse de desenvolvimento pode ser reconfigurado
21:42
na importação para usar a tabela de produção, simplesmente alterando a variável de ambiente
21:45
dentro do seu processo de implantação.
21:48
Os pipelines do GitHub Actions tornam-se... cada tarefa pode injetar o valor correto no
21:52
momento certo.
21:53
Mas mesmo aqui a disciplina é fundamental.
21:56
Esqueça de atualizar uma variável ou deixe segredos vazarem entre ambientes e, de repente,
22:00
seu fluxo de trabalho estará exposto.
22:03
A Microsoft enfatiza a necessidade de definir o escopo de segredos com cuidado e mapear referências
22:07
de conectores intencionalmente.
22:08
Suas políticas de DLP, prevenção contra a perda de dados, existem por um motivo para
22:13
evitar que informações confidenciais transitem entre ambientes ou apareçam no lugar errado.
22:18
Se você tentar contorná-las compartilhando variáveis ou conexões, acabará tropeçando
22:23
nos controles de segurança ou conformidade corporativos.
22:26
Mais importante, você perde a previsibilidade porque não há mais uma linha separando o
22:30
que é para desenvolvimento, teste ou produção.
22:33
O benefício quando você faz tudo isso corretamente é difícil de mensurar.
22:36
Service Principles combinados com variáveis de ambiente bem gerenciadas e conectores mapeados
22:40
adequadamente transformam seu pipeline.
22:43
Suas implantações tornam-se previsíveis.
22:45
Quando as coisas quebram, você tem uma cadeia de custódia clara e sabe exatamente onde
22:48
procurar.
22:49
Foi um mapeamento de conector uma variável ou uma permissão esquecida?
22:52
Auditores podem acompanhar as mudanças e não há suspense quando alguém deixa a organização
22:56
ou altera as senhas.
22:57
Tudo se resume a tratar segredos, conectores e Service Principles como se eles fossem importantes.