WEBVTT

00:00:00.620 --> 00:00:07.000
Preparado para 10 dias de Microsoft 305, Copilot, IA, Azure e as pessoas moldando o futuro do trabalho?

00:00:07.900 --> 00:00:11.980
Em janeiro, a M365 com está de volta, estamos crescendo ainda mais.

00:00:12.840 --> 00:00:18.480
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.

00:00:18.820 --> 00:00:21.160
Nada de slides genéricos, nada de jargões sem fim.

00:00:21.940 --> 00:00:23.540
Estamos enfrentando os desafios reais.

00:00:23.680 --> 00:00:28.740
Copilot Studio, agente de IA, fábrica, segurança, governança e automação, GAU.

00:00:28.740 --> 00:00:34.400
Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões projetadas para você.

00:00:35.560 --> 00:00:40.000
Com 10 dias inteiros, você pode explorar múltiplas tecnologias e se conectar com uma comunidade global.

00:00:40.980 --> 00:00:44.200
Assista ao vivo e leve insights práticos de volta para sua organização.

00:00:45.220 --> 00:00:48.800
Janeiro de 2027, 10 dias, uma comunidade Microsoft.

00:00:49.440 --> 00:00:50.520
As inscrições já estão abertas.

00:00:52.480 --> 00:00:54.500
Garanta sua vaga hoje!

00:00:54.500 --> 00:00:58.800
É mm3105com.net

00:00:58.800 --> 00:01:04.560
Participe agora em m3105com.net e nos vemos ao vivo em janeiro!

00:01:05.320 --> 00:01:08.020
Você sente que suas implantações no Power Platform são uma caixa preta?

00:01:08.480 --> 00:01:12.340
Você envia uma atualização, prende a respiração e torce para que funcione em dev, teste e produção?

00:01:12.340 --> 00:01:18.960
E se você pudesse controlar e ver cada estágio do seu processo de ELM usando o GitHub Action sem mais palpites,

00:01:19.400 --> 00:01:21.340
ou remendos manuais, ou...

00:01:21.960 --> 00:01:27.800
Vamos revelar como cada componente, controle de versão, automação e variáveis seguras realmente se conectam?

00:01:28.740 --> 00:01:29.900
Este não é apenas mais um passo a passo.

00:01:30.440 --> 00:01:34.460
Este é o porquê que a maioria dos guias ignora para que sua próxima implantação não deixe você na dúvida.

00:01:35.060 --> 00:01:37.640
Então por que o ELM do Power Platform parece um labirinto?

00:01:37.640 --> 00:01:41.720
Se você já tentou implantar um Power App e sentiu aquela incerteza constante,

00:01:41.840 --> 00:01:44.940
como se algo importante tivesse escapado, você não está sozinho.

00:01:46.660 --> 00:01:49.360
No papel, o Power Platform promete um desenvolvimento de apps fácil,

00:01:49.440 --> 00:01:52.260
mas por trás da fachada amigável, o ELM é tudo menos simples.

00:01:53.300 --> 00:01:55.860
Um aplicativo web é implantado a partir do controle de versão,

00:01:56.020 --> 00:01:59.100
compilado em um pipeline e chega à produção com comportamento previsível.

00:02:00.100 --> 00:02:04.140
O Power Platform, por outro lado, esconde metade da lógica em interfaces de arrastar e soltar,

00:02:04.140 --> 00:02:07.440
telas de conectores e fórmulas que você não vê em nenhum repositório Git.

00:02:08.640 --> 00:02:11.840
Então mesmo que você siga a cada passo daqueles guias administrativos,

00:02:11.940 --> 00:02:14.560
você ainda encontra falhas estranhas e difíceis de diagnosticar

00:02:14.560 --> 00:02:16.640
quando os apps críticos deixam o desenvolvimento.

00:02:17.460 --> 00:02:19.280
Vamos analisar os guias de ELM por aí?

00:02:19.900 --> 00:02:23.860
A maioria deles vai te mostrar como exportar um arquivo zip de solução e importá-lo em outro lugar.

00:02:24.600 --> 00:02:25.140
Simples o bastante.

00:02:25.640 --> 00:02:26.960
Mas o como é apenas uma camada.

00:02:27.420 --> 00:02:28.760
O que eles ignoram é o porquê.

00:02:29.700 --> 00:02:33.360
Por que a implantação do Power Platform quebra de maneiras que o código comum nunca quebra?

00:02:33.360 --> 00:02:35.300
É isso que causa uma confusão sem fim.

00:02:35.300 --> 00:02:41.280
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.

00:02:42.440 --> 00:02:45.080
Você não está apenas clonando um repositório e observando os testes unitários.

00:02:45.620 --> 00:02:48.780
Então, quando você tenta mover seu aplicativo, todas aquelas dependências ocultas,

00:02:48.880 --> 00:02:53.960
conexões com Outlook, SharePoint e APIs personalizadas nem sempre viajam perfeitamente dentro daquele arquivo zip.

00:02:54.680 --> 00:02:55.280
Eis o cenário.

00:02:55.680 --> 00:02:57.920
Você tem um aplicativo novo e incrível funcionando no ambiente de desenvolvimento.

00:02:57.920 --> 00:03:01.640
Você exporta uma solução e importa para teste e, de repente, o fluxo para de funcionar.

00:03:02.080 --> 00:03:03.380
Raramente é apenas um problema de arquivo.

00:03:03.700 --> 00:03:07.460
Em vez disso, as conexões estão apontando para o lugar errado, as permissões não coincidem

00:03:07.460 --> 00:03:11.300
e as políticas de dados bloqueiam conexões que pareciam estar bem há alguns minutos.

00:03:12.500 --> 00:03:16.700
Agora, imagine fazer isso em três ambientes, Dev, Test e Prod, com cada um usando conexões,

00:03:17.160 --> 00:03:20.860
políticas de proteção de dados, aprovadores e guardas administrativos diferentes.

00:03:21.760 --> 00:03:23.520
Você não consegue resolver isso apenas com copia e colar.

00:03:23.520 --> 00:03:27.020
As pesquisas confirmam que administradores e criadores vêm toda semana.

00:03:27.800 --> 00:03:31.800
A maioria das implantações falhas na Power Platform decorre de referências de conector ausentes

00:03:31.800 --> 00:03:33.540
ou variáveis de ambiente mal gerenciadas.

00:03:34.620 --> 00:03:37.780
Uma referência de conector ausente significa apenas que o fluxo não consegue encontrar

00:03:37.780 --> 00:03:39.720
sua conexão com Outlook ou Dataverse.

00:03:40.440 --> 00:03:44.320
Portanto, no minuto em que você tenta executar seu aplicativo ou fluxo em outro ambiente,

00:03:44.440 --> 00:03:46.220
você recebe erros de tempo de execução.

00:03:47.280 --> 00:03:50.240
E como as variáveis de ambiente funcionam de forma diferente na Power Platform

00:03:50.240 --> 00:03:52.560
em comparação com outros produtos do Microsoft 365,

00:03:52.560 --> 00:03:54.900
elas confundem até desenvolvedores experientes.

00:03:55.700 --> 00:03:59.300
As variáveis devem lidar com pontos de extremidade-chave ou configurações específicas do locatário.

00:04:00.140 --> 00:04:02.740
Mas, se alguém esquecer de atualizá-las após exportar uma solução,

00:04:02.840 --> 00:04:06.200
até mesmo uma mudança aparentemente inofensiva pode quebrar um aplicativo ativo.

00:04:06.820 --> 00:04:08.680
Muitos de nós caímos na mesma armadilha no início.

00:04:09.340 --> 00:04:12.240
Você pode pensar que exportar um zip de solução agrupa tudo o que é necessário,

00:04:12.300 --> 00:04:14.380
mas na verdade ele ignora a referência de conector dinâmicas.

00:04:14.960 --> 00:04:17.560
Por exemplo, digamos que você tenha um aplicativo que usa um conector HTTP

00:04:17.560 --> 00:04:19.020
para um serviço de terceiros em Dev.

00:04:19.020 --> 00:04:23.480
Ao importar para teste ou produção, essa instância específica do conector não existirá.

00:04:24.000 --> 00:04:27.220
A referência do conector dentro do seu aplicativo aponta para um objeto ausente,

00:04:27.480 --> 00:04:30.240
e os fluxos dentro da solução param de funcionar silenciosamente

00:04:30.240 --> 00:04:34.440
até que um usuário ou administrador recrie e remapee as conexões manualmente.

00:04:34.440 --> 00:04:39.420
Se você tiver mais de um criador ou administrador, é ainda mais fácil perder o controle

00:04:39.420 --> 00:04:42.700
de qual referência vai para onde, e ninguém quer aquele post-mortem de funcionar em Dev.

00:04:44.500 --> 00:04:46.440
Outra complicação, entidades e serviço.

00:04:47.740 --> 00:04:51.640
A maioria das pessoas começa usando contas de usuário para exportar e importar soluções

00:04:51.640 --> 00:04:52.700
porque é mais rápido começar.

00:04:53.780 --> 00:04:56.780
Mas quando você tenta automatizar com GitHub Actions ou qualquer sistema de CI

00:04:56.780 --> 00:04:59.160
usando os credenciais de uma pessoa, você rapidamente chega a um beco sem saída.

00:04:59.160 --> 00:05:03.580
Você encontrará barreiras de permissão, às vezes sem mensagens de erro claras,

00:05:03.660 --> 00:05:05.700
ou até mesmo acionará auditorias de conformidade

00:05:05.700 --> 00:05:08.280
porque está executando implantações críticas sobre uma conta pessoal

00:05:08.280 --> 00:05:09.660
em vez de algo destinado à automação.

00:05:10.860 --> 00:05:14.500
Service Principles, essencialmente identidades de aplicativo criadas no Azure AD,

00:05:14.660 --> 00:05:18.280
cuidam de todas as permissões, registros e auditorias que seu pipeline precisa.

00:05:19.280 --> 00:05:23.100
Sem eles, sua cadeia de automação vira uma colcha de retalhos de transferências manuais,

00:05:23.220 --> 00:05:24.880
e você nunca sabe quem alterou o quê.

00:05:25.260 --> 00:05:27.520
P. Controle de versão também se torna um incógnito.

00:05:27.520 --> 00:05:31.360
Com um código comum, você tem histórico de commits e ferramentas de rastreamento.

00:05:32.140 --> 00:05:34.800
Arquivos de solução da Power Platform representam apenas instantâneos,

00:05:34.840 --> 00:05:36.860
o que significa que falta um rastreamento granular de mudança.

00:05:37.700 --> 00:05:39.920
A lógica escondida em fórmulas de tela de um Canvas App,

00:05:40.000 --> 00:05:43.560
ou em fluxos pouco documentados, não fica visível até que você exporte novamente.

00:05:44.340 --> 00:05:46.380
Alguém ajusta uma configuração de fluxo na interface,

00:05:46.480 --> 00:05:49.580
boa sorte tentando descobrir por que ambientes posteriores começam a se comportar de forma diferente.

00:05:50.020 --> 00:05:52.420
O resultado final, gerenciar a LM para a Power Platform,

00:05:52.420 --> 00:05:55.060
parece resolver um quebra-cabeça com metade das peças faltando,

00:05:55.140 --> 00:05:56.880
ou pelo menos escondidas sob a caixa.

00:05:57.680 --> 00:06:00.540
Dependências invisíveis, conectores específicos de ambiente,

00:06:01.060 --> 00:06:02.680
e variáveis que você não vê no código,

00:06:02.900 --> 00:06:05.280
alteram o fluxo de trabalho comum do desenvolvedor.

00:06:06.280 --> 00:06:09.180
E isso é antes de lidar com o fato de que ambientes de produção

00:06:09.180 --> 00:06:11.100
quase sempre têm permissões mais rígidas,

00:06:11.240 --> 00:06:13.420
políticas de dados diferentes e requisitos de auditoria

00:06:13.420 --> 00:06:15.840
que não são óbvios em dev ou teste.

00:06:17.020 --> 00:06:17.960
Mas aqui está o lado positivo.

00:06:18.480 --> 00:06:19.860
Essa complexidade não é aleatória.

00:06:20.220 --> 00:06:23.620
Existe uma razão prática para a Power Platform lidar com fonte,

00:06:24.080 --> 00:06:26.900
variáveis e conectores de uma forma tão única,

00:06:27.520 --> 00:06:30.380
ela tenta permitir que usuários de negócio criem aplicativos poderosos,

00:06:30.480 --> 00:06:31.500
sem se preocupar com o código.

00:06:32.460 --> 00:06:35.200
O efeito colateral é que você, como uma pessoa configurando automação,

00:06:35.340 --> 00:06:37.840
precisa monitorar o que está escondido sob o capô.

00:06:38.680 --> 00:06:40.720
Se você souber onde esses fios invisíveis passam,

00:06:40.960 --> 00:06:45.400
pode corrigir ou evitar a maioria das armadilhas que descarrilam o ILM da Power Platform.

00:06:45.400 --> 00:06:49.760
Agora, se tudo isso parece muita coisa para lidar, você não está errado.

00:06:50.400 --> 00:06:53.400
Mas existem quatro pilares de ILM que realmente ajudam antes a embaraçar essa bagunça.

00:06:54.060 --> 00:06:55.520
Fonte, build, teste e implantação.

00:06:56.140 --> 00:06:57.860
Cada um tem suas peculiaridades na Power Platform,

00:06:58.100 --> 00:07:01.000
mas juntos eles devolvem estrutura ao que, de outra forma, parece um caos.

00:07:02.540 --> 00:07:05.080
O sistema central de ILM, fonte, build, teste e implantação.

00:07:05.700 --> 00:07:09.100
Toda vez que alguém pede um pipeline da Power Platform que simplesmente funcione,

00:07:09.100 --> 00:07:14.880
a primeira coisa que vem à mente são aqueles quatro pilares de ILM, fonte, build, teste e implantação.

00:07:16.020 --> 00:07:18.600
No mundo de desenvolvimento tradicional, você quase poderia executar isso dormindo.

00:07:19.060 --> 00:07:20.860
A Power Platform não te deixa escapar tão fácil.

00:07:21.640 --> 00:07:23.320
De repente, fonte não significa código.

00:07:24.180 --> 00:07:25.960
Significa lidar com arquivos e solução,

00:07:26.260 --> 00:07:29.960
exportando pacotes compactados repletos de aplicativos, fluxos e, às vezes,

00:07:30.140 --> 00:07:32.200
conectores fingindo ser parte da fonte.

00:07:33.860 --> 00:07:34.960
Vamos começar pelo básico,

00:07:35.220 --> 00:07:37.840
depois analisar o que torna cada pilar um pouco estranho neste mundo.

00:07:37.840 --> 00:07:39.880
Você tem seu arquivo zip-solução.

00:07:40.280 --> 00:07:41.420
Não é código no sentido convencional.

00:07:42.020 --> 00:07:45.160
Abre e você será recebido por arquivos explicativos em XML e JSON,

00:07:45.380 --> 00:07:47.780
e não pela lógica que você veria em TypeScript ou C-Shack.

00:07:48.880 --> 00:07:50.400
Mas essa é a fonte da Power Platform.

00:07:50.920 --> 00:07:52.280
As equipes costumam tropeçar aqui.

00:07:52.820 --> 00:07:55.440
Parece portátil até que você percebe que a maioria das alterações,

00:07:55.820 --> 00:07:58.640
como atualizar uma fórmula em uma tela ou ajustar a lógica de um fluxo,

00:07:58.680 --> 00:08:01.360
não são óbvias até você exportar um novo arquivo zip da solução.

00:08:01.980 --> 00:08:04.900
Então sim, você pode versionar esses arquivos de solução no Git,

00:08:04.900 --> 00:08:07.580
mas a menos que seja disciplinado ou exportar após cada edição relevante,

00:08:07.580 --> 00:08:09.140
seu histórico terá lacunas gritantes,

00:08:09.260 --> 00:08:10.600
seu histórico terá lacunas gritantes.

00:08:10.780 --> 00:08:11.780
Agora vem a configuração.

00:08:12.460 --> 00:08:14.960
Para aplicativos comuns, você pode armazenar streams de conexão

00:08:14.960 --> 00:08:16.840
em um arquivo de configuração e dar o assunto para encerrado.

00:08:17.340 --> 00:08:20.500
Power Platform introduz dados específicos do ambiente dentro dessas soluções.

00:08:21.700 --> 00:08:23.300
Não se trata apenas de variáveis de ambiente,

00:08:23.460 --> 00:08:26.340
mas de referências de conectores, endpoints, dinâmicos, funções

00:08:26.340 --> 00:08:28.780
e permissões agrupadas junto com a lógica de negócios.

00:08:28.780 --> 00:08:33.400
Se você esquecer de atualizá-los antes de exportar do Devil o teste,

00:08:33.540 --> 00:08:35.420
estará travando ponteiros para o lugar errado.

00:08:36.540 --> 00:08:39.600
Já vi equipes confirmarem religiosamente seus arquivos zip de solução,

00:08:40.200 --> 00:08:42.440
apenas para implantar e perceber que metade do aplicativo

00:08:42.440 --> 00:08:44.460
ainda está se comunicando com o Dataverse de desenvolvimento

00:08:44.460 --> 00:08:47.220
em vez de produção porque ninguém remapeou as referências dos conectores.

00:08:48.300 --> 00:08:49.320
Então temos o Build Compilação.

00:08:50.120 --> 00:08:52.660
A palavra Build geralmente traz imagens de compilar código

00:08:52.660 --> 00:08:54.620
e vê marcações verdes em um trabalho de CI.

00:08:54.620 --> 00:08:59.640
Com a Power Platform, o processo de Build consiste em armazenar esses pacotes zip,

00:08:59.740 --> 00:09:01.520
verificar o esquema e validar dependências.

00:09:02.620 --> 00:09:05.940
Em um pipeline do GitHub Actions, um trabalho de Build pega o arquivo de solução

00:09:05.940 --> 00:09:09.080
que você confirmou e usa a CLI da Power Platform da Microsoft

00:09:09.080 --> 00:09:11.560
para descompactar, validar e recompactar a solução.

00:09:12.140 --> 00:09:14.320
A etapa de validação é de a mágica ou o caos acontece.

00:09:14.880 --> 00:09:17.140
Pode detectar referências quebradas ou ações não suportadas.

00:09:18.140 --> 00:09:21.420
Pior ainda, se uma alteração no seu fluxo depender de um conector personalizado

00:09:21.420 --> 00:09:23.360
que nunca entrou no controle de origem, seu Build,

00:09:23.360 --> 00:09:25.760
empacota silenciosamente algo incompleto.

00:09:26.580 --> 00:09:27.780
E onde as coisas ficam complicadas.

00:09:28.460 --> 00:09:30.460
Esses trabalhos de Build são menos sobre compilar

00:09:30.460 --> 00:09:32.560
e mais sobre orquestrar uma exportação confiável

00:09:32.560 --> 00:09:35.200
e garantir que o conteúdo seja passível de entrega.

00:09:36.340 --> 00:09:38.500
Equipes que pulam isso ou fazem compressa rapidamente

00:09:38.500 --> 00:09:40.760
e acabam em situações onde o Build tecnicamente tem sucesso.

00:09:41.100 --> 00:09:44.180
Mas o que chega ao AT ou produção está faltando metade dos recursos pretendidos.

00:09:45.060 --> 00:09:47.820
A Microsoft continua promovendo a mensagem de que arquivos de solução

00:09:47.820 --> 00:09:50.000
tornam o LM portátil, mas sempre há uma nota de rodapé.

00:09:50.000 --> 00:09:53.120
A portabilidade depende de conectores estarem mapeados corretamente

00:09:53.120 --> 00:09:54.860
e funções configuradas em todos os ambientes.

00:09:55.340 --> 00:09:56.400
Teste o próximo botão de fonte.

00:09:56.880 --> 00:09:59.160
Em um pipeline aplicativo web, testes automatizados

00:09:59.160 --> 00:10:01.620
podem executar testes unitários ou verificações de interface.

00:10:02.480 --> 00:10:05.280
Para a Power Platform, o que conta como teste está aberto a debate?

00:10:06.280 --> 00:10:07.960
Às vezes é a validação da solução.

00:10:08.220 --> 00:10:11.980
Em outras palavras, a solução abre e as dependências principais são resolvidas.

00:10:11.980 --> 00:10:16.120
Outras vezes, executar fluxos de teste ou verificar se os conectores respondem

00:10:16.120 --> 00:10:17.840
em um ambiente de teste a este.

00:10:18.560 --> 00:10:21.720
Muitas vezes, os testes são manuais porque a validação da lógica de negócios

00:10:21.720 --> 00:10:24.780
dentro de um aplicativo de tela ainda não está integrada a pipelines automatizados.

00:10:25.520 --> 00:10:28.520
Mas você pode automatizar verificações para detectar conectores ausentes,

00:10:28.660 --> 00:10:31.400
validar fluxos críticos ou até mesmo realizar um ping em um ambiente de teste

00:10:31.400 --> 00:10:33.320
apenas para provar que as credenciais estão funcionando.

00:10:34.320 --> 00:10:35.440
Implantação em um dia 12 e turno em VD.

00:10:35.880 --> 00:10:39.300
Ao implantar um aplicativo padrão, você pode apenas enviar um artefato da web para o Azure.

00:10:39.300 --> 00:10:43.020
Com o Power Platform, você precisa mapear conexões, atribuir permissões,

00:10:43.140 --> 00:10:44.980
atualizar segredos, trocar variáveis de ambiente

00:10:44.980 --> 00:10:47.980
e finalmente acionar uma importação usando uma entidade de serviço,

00:10:48.200 --> 00:10:49.020
nunca uma conta comum.

00:10:49.860 --> 00:10:52.520
Caso contrário, você ficará preso a auditorias e negações de permissão.

00:10:53.120 --> 00:10:54.960
GitHub Actions pode unir esse processo,

00:10:55.480 --> 00:10:59.040
mas apenas se cada trabalho souber qual ambiente direcionar e quais segredos usar.

00:11:00.300 --> 00:11:03.440
Já vi equipes tentarem atalhos usando o único conjunto de credenciais

00:11:03.440 --> 00:11:05.960
entre desenvolvimento e produção, o que é uma receita para o caos,

00:11:05.960 --> 00:11:08.700
vazamentos de dados, erros de permissão e recursos quebrados

00:11:08.700 --> 00:11:10.080
que aparecem apenas em um ambiente.

00:11:11.180 --> 00:11:13.040
Vejo uma equipe real com a qual trabalhei alguns meses.

00:11:13.940 --> 00:11:15.320
Eles faziam a maioria das coisas corretamente,

00:11:15.420 --> 00:11:18.220
repositórios de Git padrão, arquivos ZipSol são versionados e ramificações casas.

00:11:18.760 --> 00:11:20.540
Mas o pipeline deles sempre quebrava na implantação.

00:11:21.540 --> 00:11:23.500
Eles nunca se preocupavam em trocar variáveis de ambiente

00:11:23.500 --> 00:11:26.100
ou atualizar referências de conectores antes de importar para a produção.

00:11:26.900 --> 00:11:29.600
Isso deixava fluxos importantes apontando para os pontos de extremidade errados,

00:11:29.680 --> 00:11:31.180
com dados sendo enviados para os sistemas incorretos.

00:11:31.180 --> 00:11:32.300
Solução.

00:11:32.560 --> 00:11:37.380
Etapas roteirizadas no pipeline do GitHub que trocavam variáveis e remapeavam cada conector durante a importação.

00:11:38.420 --> 00:11:40.400
A própria orientação da Microsoft é direta sobre isso.

00:11:41.080 --> 00:11:43.300
Use arquivos de solução para mover itens entre ambientes,

00:11:43.440 --> 00:11:47.380
mas sempre trate as referências de conectores e mapeamento de funções como parte do seu pipeline.

00:11:48.520 --> 00:11:51.360
Eles destacam que pular essas etapas é a maneira número um de quebrar aplicativos,

00:11:51.480 --> 00:11:53.620
especialmente à medida que os ambientes se tornam mais restritos.

00:11:53.620 --> 00:11:58.580
Quando você trata origem, compilação, teste e implantação como peças móveis conectadas,

00:11:58.700 --> 00:12:02.660
e não apenas etapas isoladas, fica mais fácil entender porque tantas tentativas GLM falham,

00:12:02.740 --> 00:12:05.800
e como você pode solucionar problemas de fato em vez de apenas cruzar os dedos.

00:12:07.160 --> 00:12:10.320
A seguir, vamos entrar em como o GitHub Actions coordena essa dança,

00:12:10.520 --> 00:12:13.040
gatilhos, ramificações e a separação de trabalhos

00:12:13.040 --> 00:12:16.440
que mantém sua automação no Power Platform flexível e segura.

00:12:17.660 --> 00:12:20.240
GitHub Actions. Conectando os pontos com gatilhos e trabalho.

00:12:20.240 --> 00:12:24.620
Se você já esperou um pipeline do GitHub Actions terminar após atualizar seu Power App,

00:12:24.680 --> 00:12:28.060
já sabe que automação não significa instantâneo, e definitivamente não significa mágica.

00:12:29.320 --> 00:12:33.360
A maioria das equipes bate nessa parede logo após a empolgação de ver seu primeiro fluxo de trabalho rodar.

00:12:34.280 --> 00:12:37.100
Você configura um script, conecta ao seu repositório,

00:12:37.320 --> 00:12:40.680
e espera que cada novo commit seja implantado perfeitamente em todos os ambientes.

00:12:41.760 --> 00:12:42.640
Então a realidade aparece.

00:12:43.440 --> 00:12:46.700
Em vez de apenas iniciar um script, o GitHub Actions usa uma cadeia lógica

00:12:46.700 --> 00:12:50.060
construída em torno de gatilhos, tarefas e transferências entre ambientes.

00:12:51.120 --> 00:12:54.880
Essa ordem e estrutura é o que impede que as implantações se tornem um emaranhado de etapas,

00:12:55.000 --> 00:12:56.180
falhas e erros estranhos.

00:12:56.900 --> 00:12:58.600
O ponto de partida nesse sistema é o gatilho?

00:12:59.400 --> 00:13:02.220
A maioria dos iniciantes cria um fluxo de trabalho,

00:13:02.480 --> 00:13:06.680
que é acionado a cada push, ou sempre que um pull request chega na branch principal,

00:13:07.460 --> 00:13:08.320
a descer e descerá.

00:13:08.680 --> 00:13:10.140
À primeira vista, isso parece uma boa prática.

00:13:10.540 --> 00:13:12.340
Por que não executar seu pipeline sempre que o trabalho muda?

00:13:12.720 --> 00:13:13.300
Aqui está o problema.

00:13:13.300 --> 00:13:15.740
Quando você define um gatilho apenas na branch principal,

00:13:15.840 --> 00:13:17.240
tudo é canalizado através de um único caminho.

00:13:17.520 --> 00:13:19.440
E se as alterações precisarem para o ambiente de desenvolvimento,

00:13:19.520 --> 00:13:20.360
menor produto e teste ou produção?

00:13:20.640 --> 00:13:23.740
E se você estiver pronto para enviar para a produção, mas o teste ainda estiver em validação?

00:13:25.180 --> 00:13:27.720
Equipes que usam gatilhos genéricos tendem a ter problemas

00:13:27.720 --> 00:13:31.960
em que recursos destinados ao desenvolvimento acabam em produção ou implantações de teste,

00:13:32.080 --> 00:13:33.940
substituem configurações de produção.

00:13:35.260 --> 00:13:38.980
Você pode ramificar fluxos de trabalho para cada ambiente, dev, teste e prod,

00:13:39.240 --> 00:13:41.280
e definir gatilhos muito específicos para cada um.

00:13:42.220 --> 00:13:45.260
Por exemplo, configure um fluxo que só roda em pushes para branch dev,

00:13:45.520 --> 00:13:46.780
ou dispare um fluxo diferente,

00:13:47.120 --> 00:13:49.560
quando alguém fizer merge na branch de release de produção.

00:13:50.720 --> 00:13:52.280
Essa abordagem oferece mais controle,

00:13:52.420 --> 00:13:55.000
cria uma divisão clara entre trabalho em andamento e alterações reais,

00:13:55.000 --> 00:13:57.960
mas muitas equipes nunca revisam seus gatilhos após criá-los.

00:13:58.920 --> 00:14:01.500
É assim que segredos de um ambiente podem escapar para outro

00:14:01.500 --> 00:14:05.020
e configurações de desenvolvimento acabam em produção por acidente.

00:14:05.960 --> 00:14:08.760
Uma equipe com a qual trabalhei tentou executar todo o seu processo de LM

00:14:08.760 --> 00:14:10.040
a partir de um único fluxo de trabalho.

00:14:10.760 --> 00:14:11.800
Por um tempo, pareceu bem,

00:14:12.000 --> 00:14:15.420
até que alguém notou que a string de conexão do banco de dados de produção

00:14:15.420 --> 00:14:17.620
apareceu no ambiente de desenvolvimento.

00:14:18.300 --> 00:14:21.020
Eles não perceberam que seus segredos estavam sendo compartilhados entre as tarefas.

00:14:21.720 --> 00:14:23.360
E é assim que o código se movia entre os ambientes

00:14:23.360 --> 00:14:24.760
e os segredos vazavam junto com ele.

00:14:25.000 --> 00:14:26.460
Não foi uma falha ou erro óbvio.

00:14:26.840 --> 00:14:27.460
Foi silencioso?

00:14:28.580 --> 00:14:30.660
Esse tipo de vazamento de dados é mais comum do que se pensa,

00:14:30.760 --> 00:14:32.260
especialmente se você não configurar seus fluxos

00:14:32.260 --> 00:14:33.920
para separar segredos e variáveis de ambiente.

00:14:35.220 --> 00:14:37.260
Cada tarefa em um fluxo do GitHub Actions

00:14:37.260 --> 00:14:38.860
lida com uma parte clara do processo.

00:14:39.960 --> 00:14:43.660
Uma tarefa pode lidar com a exportação da solução de um ambiente de origem.

00:14:44.660 --> 00:14:46.440
Outra tarefa cuida da validação,

00:14:46.540 --> 00:14:48.540
descompactação, verificação de metadados,

00:14:48.660 --> 00:14:50.780
dependências e referências de conectores.

00:14:50.780 --> 00:14:55.600
Em seguida vem a tarefa que prepara as variáveis específicas do ambiente,

00:14:55.760 --> 00:14:58.380
adaptando a solução para que ela se encaixe no ambiente de destino.

00:14:59.240 --> 00:15:02.420
A última tarefa aciona o processo de importação usando o Service Principles

00:15:02.420 --> 00:15:04.360
para gravar as alterações no ambiente correto.

00:15:05.040 --> 00:15:08.560
Você pode pensar em variáveis de ambiente e segredos como espaços reservados básicos,

00:15:08.780 --> 00:15:11.380
mas na prática eles são a cola que mantém tudo unido, unido.

00:15:11.380 --> 00:15:15.500
Strings de conexão, chave de API, senhas compartilhadas,

00:15:15.580 --> 00:15:19.240
tudo precisa alternado entre tarefas, mas nunca pode vazar entre limites.

00:15:20.860 --> 00:15:24.600
No ILM do Power Platform você pode ter uma conexão dataverse diferente para cada ambiente,

00:15:25.160 --> 00:15:28.080
ou precisar alternar endpoints dependendo do fluxo ou powerapp que está usando.

00:15:30.220 --> 00:15:32.380
Se você reutilizar variáveis ou codificar segredos,

00:15:32.720 --> 00:15:35.900
acabará com um pipeline frágil ou pior, com riscos de segurança significativos.

00:15:35.900 --> 00:15:40.300
O processo de importação depende de extrair segredos apenas do cofre correto

00:15:40.300 --> 00:15:43.480
para que a produção não seja exposta por erros de teste ou desenvolvimento.

00:15:44.380 --> 00:15:46.960
Um bom modelo mental para segredos no GitHub Actions

00:15:46.960 --> 00:15:49.540
é imaginar cada ambiente como tendo seu próprio cofre digital,

00:15:49.780 --> 00:15:52.320
uma caixa trancada que só as tarefas certas podem ver.

00:15:53.380 --> 00:15:55.080
O GitHub oferece controles precisos.

00:15:55.760 --> 00:15:59.160
Você pode limitar segredos a ambientes para que uma tarefa sendo executada em dev

00:15:59.160 --> 00:16:01.860
não acesse credenciais de produção e vice-versa.

00:16:02.700 --> 00:16:05.380
Configure esses cofres, e mesmo que alguém ajustando o pipeline

00:16:05.380 --> 00:16:06.380
tente algo arriscado,

00:16:07.040 --> 00:16:09.520
as regras de proteção de ambiente impedem que um erro se espalhe.

00:16:10.260 --> 00:16:13.220
A documentação da Microsoft e do próprio GitHub enfatizam muito esse ponto.

00:16:13.700 --> 00:16:17.100
Eles recomendam regras de proteção de ambiente e definição rigorosa de escopo de segredos

00:16:17.100 --> 00:16:19.640
para impedir vazamentos entre ambientes antes mesmo de começarem.

00:16:20.640 --> 00:16:24.420
Sem esse tipo de proteção, até os fluxos de trabalho de LM mais bem projetados falham.

00:16:25.260 --> 00:16:26.880
Imagine um fluxo implantando em produção

00:16:26.880 --> 00:16:29.520
enquanto ainda mantém uma stringa de conexão de desenvolvimento

00:16:29.520 --> 00:16:31.900
ou um ambiente de teste acessando dados de produção.

00:16:32.900 --> 00:16:34.600
Nem sempre isso quebra as coisas de forma visível.

00:16:34.600 --> 00:16:37.780
Às vezes significa apenas que alertas de conformidade são disparados

00:16:37.780 --> 00:16:40.880
ou os logs se enchem de erros sutis que lentamente se acumulam em problemas maiores.

00:16:41.200 --> 00:16:43.540
É por isso que ramificar fluxo de trabalho e definir escopo de segredos

00:16:43.540 --> 00:16:44.760
não são apenas tópicos avançados.

00:16:45.160 --> 00:16:48.240
Eles são a rede de segurança que impede que sua automação se desfaça silenciosamente.

00:16:48.920 --> 00:16:50.720
Também há valor em dividir fluxos de trabalho.

00:16:51.120 --> 00:16:52.940
Não apenas por ambiente, mas por responsabilidade.

00:16:52.940 --> 00:16:59.220
O código exporta e valida soluções não deveria nem saber como implantar ou trocar segredos.

00:16:59.820 --> 00:17:02.380
Se cada tarefa cuida de uma peça do quebra-cabeça,

00:17:02.500 --> 00:17:04.780
fica muito mais fácil identificar onde as coisas quebram,

00:17:04.880 --> 00:17:07.400
reverter e auditar alterações posteriormente.

00:17:08.580 --> 00:17:12.060
Segredos permanecem em seus cofres, tarefas seguem permissões claramente definidas

00:17:12.060 --> 00:17:15.320
e falhos no pipeline apontam diretamente para a peça que precisa de correção.

00:17:15.320 --> 00:17:20.140
Entender como o GitHub Actions transfere o trabalho de uma tarefa para outra,

00:17:20.240 --> 00:17:23.400
mantendo os segredos com escopo restrito e gatilhos bem definidos,

00:17:23.480 --> 00:17:27.940
é o que transforma o ALM de um experimento otimista em uma prática confiável, segura e previsível.

00:17:29.480 --> 00:17:32.880
Essa segmentação de fluxo de trabalho não é apenas para seguir as melhores práticas.

00:17:32.880 --> 00:17:37.460
É o que bloqueia vazamentos de seguranças silenciosos e substituições acidentais,

00:17:37.540 --> 00:17:41.500
eliminando toda uma classe de erros invisíveis antes que comecem a assombrar seus ambientes.

00:17:41.500 --> 00:17:46.580
Agora, com as peças trabalhando juntas por meio de automação devidamente dimensionada,

00:17:46.840 --> 00:17:48.540
é hora de abordarmos outro ponto de atrito.

00:17:49.200 --> 00:17:52.340
Conectores, service principles e as pequenas, porém críticas e armadilhas

00:17:52.340 --> 00:17:55.660
que podem paralisar suas implantações justamente quando você ganha confiança.

00:17:57.160 --> 00:17:59.600
Segredos de service principles e os problemas com conectores.

00:17:59.980 --> 00:18:04.300
Se você já tentou mover um power app ou flow do desenvolvimento para a produção, conhece a história.

00:18:05.500 --> 00:18:09.560
As coisas funcionam perfeitamente em um ambiente, mas assim que você alterna tudo para

00:18:09.560 --> 00:18:12.620
ou apresenta aqueles erros de conexão misteriosos.

00:18:13.540 --> 00:18:15.200
Isso não é exclusivo de uma equipe específica.

00:18:15.820 --> 00:18:18.700
Todo administrador da Power Platform eventualmente esbarra nessa parede.

00:18:19.940 --> 00:18:23.680
A raiz do problema está em como os conectores e segredos se comportam nos bastidores.

00:18:24.860 --> 00:18:28.640
Você não pode simplesmente exportar um zip de solução do desenvolvimento e esperar que

00:18:28.640 --> 00:18:32.460
funcione em outro lugar, porque as conexões dependem do ambiente.

00:18:33.300 --> 00:18:34.700
Comecemos pelas referências de conector.

00:18:34.700 --> 00:18:39.400
Na Power Platform, um conector nunca é apenas uma informação estática incluída no seu

00:18:39.400 --> 00:18:40.000
aplicativo.

00:18:40.800 --> 00:18:43.400
Ele é dinâmico, mutável e muitas vezes exclusivo de cada ambiente.

00:18:44.120 --> 00:18:47.480
Ao exportar sua solução, as referências de conector funcionam quase como favoritos.

00:18:48.160 --> 00:18:51.720
Elas apontam para objetos de conexão que só existem no ambiente em que foram criados.

00:18:52.680 --> 00:18:57.240
Portanto, ao importar para teste ou produção, seu endpoint HTTP ou link do Dataverse não

00:18:57.240 --> 00:19:00.460
é necessariamente recriado da mesma forma ou nem chega a ser recriado.

00:19:01.020 --> 00:19:02.220
É aqui que as equipes são pegas de surpresa.

00:19:02.220 --> 00:19:08.300
Se o ambiente de desenvolvimento usa um conector para testar dados e essa configuração não

00:19:08.300 --> 00:19:13.420
é espelhada na produção, seu fluxo ou app falha silenciosamente ou trava na primeira

00:19:13.420 --> 00:19:14.740
tentativa de conexão.

00:19:16.380 --> 00:19:20.420
Muitas pessoas tentam contornar isso compartilhando credenciais de usuário entre ambientes.

00:19:21.180 --> 00:19:24.900
Elas pensam que se usarem a mesma conta ou senha que criou a conexão no desenvolvimento,

00:19:25.020 --> 00:19:26.660
talvez funcione na produção.

00:19:27.800 --> 00:19:30.680
A realidade é que isso traz uma série de problemas, desde negações de permissão até

00:19:30.680 --> 00:19:32.100
gatilhos de auditoria de conformidade.

00:19:32.880 --> 00:19:36.240
A própria orientação da Microsoft é clara dos agredenciais de usuário individuais

00:19:36.240 --> 00:19:38.420
para implantações automatizadas não é viável nem seguro.

00:19:39.320 --> 00:19:43.200
Isso deixa sua automação à mercê de redefinições de senha e pode deixar um rastro confuso nos

00:19:43.200 --> 00:19:43.960
logs de auditoria.

00:19:44.800 --> 00:19:49.640
Não há responsabilidade clara e, eventualmente, as permissões bloqueiam o pipeline quando o

00:19:49.640 --> 00:19:52.760
usuário original é sinalizado, removido ou perde o acesso.

00:19:53.760 --> 00:19:54.880
Apresentamos o Service Principle.

00:19:54.880 --> 00:19:58.560
Se você nunca trabalhou com eles, imagine um service principal como um par de mãos

00:19:58.560 --> 00:20:00.680
digital extra criado especificamente para automação.

00:20:01.900 --> 00:20:05.360
Diferente de um usuário comum, um service principal está vinculado a um registro de

00:20:05.360 --> 00:20:08.680
aplicativo no Azure AD, não a uma pessoa real, não a uma pessoa real.

00:20:09.040 --> 00:20:11.900
Você concede a ele as permissões mínimas necessárias para executar suas tarefas de

00:20:11.900 --> 00:20:12.280
implantação.

00:20:12.860 --> 00:20:14.560
Isso parece simples, mas o benefício é enorme.

00:20:15.120 --> 00:20:18.160
Em vez de depender de um usuário que pode sair da organização ou mudar de cargo, as

00:20:18.160 --> 00:20:20.920
implantações permanecem consistentes, auditáveis e rastreáveis.

00:20:20.920 --> 00:20:26.280
Cada ambiente obtém acesso apenas às conexões e recursos corretos, e quaisquer alterações

00:20:26.280 --> 00:20:27.940
são registradas sob esta conta de robô.

00:20:28.900 --> 00:20:32.600
Quando algo falha, você tem uma trilha de auditoria clara, e não acaba com fluxos órfãos

00:20:32.600 --> 00:20:33.740
que ninguém consegue corrigir.

00:20:35.220 --> 00:20:36.700
Sobre o problema de mapear conectores.

00:20:37.300 --> 00:20:39.720
Considere o que acontece quando os ambientes se distanciam.

00:20:40.700 --> 00:20:43.560
Talvez a equipe de desenvolvimento tenha omitido aprovação para um novo conector personalizado.

00:20:43.920 --> 00:20:45.400
Digamos que ele acesse uma API de sandbox.

00:20:46.340 --> 00:20:49.980
Quando chega a hora de mover para a produção, esse conector não apenas está faltando como pode

00:20:49.980 --> 00:20:52.400
nem ser permitido pelas políticas de dados da organização.

00:20:52.900 --> 00:20:57.840
Se você esquecer de remapear, o aplicativo chamará o endpoint errado ou quebrará completamente.

00:20:58.800 --> 00:21:00.900
Eu vi isso causar sérios problemas em um grupo de saúde recentemente.

00:21:01.620 --> 00:21:05.060
Um mapeamento de conector esquecido disparou o uso de dados de teste na produção e quase

00:21:05.060 --> 00:21:06.440
criou um incidente de conformidade.

00:21:07.380 --> 00:21:11.720
O pipeline automatizado deles exportou tudo como planejado, mas a referência do conector

00:21:11.720 --> 00:21:15.080
dentro da solução ainda apontava para um antigo banco de dados de teste que não foi

00:21:15.080 --> 00:21:18.620
sinalizado pela Power Platform até que dados reais começassem a fluir pelos caminhos

00:21:18.620 --> 00:21:20.240
errados.

00:21:20.240 --> 00:21:22.780
Variáveis de ambiente entram em cena para aliviar parte desse transtorno.

00:21:23.420 --> 00:21:27.820
Diferente de codificar endpoints ou chaves de API, as variáveis de ambiente permitem separar

00:21:27.820 --> 00:21:30.240
o que muda entre os ambientes do que permanece igual.

00:21:31.000 --> 00:21:35.220
Você pode trocar endpoint, chaves de API ou outros segredos a cada implantação sem precisar

00:21:35.220 --> 00:21:36.900
reescrever seu aplicativo ou fluxo.

00:21:38.040 --> 00:21:42.100
Por exemplo, um fluxo que funciona com uma tabela Dataverse de desenvolvimento pode ser reconfigurado

00:21:42.100 --> 00:21:45.500
na importação para usar a tabela de produção, simplesmente alterando a variável de ambiente

00:21:45.500 --> 00:21:47.060
dentro do seu processo de implantação.

00:21:48.120 --> 00:21:52.360
Os pipelines do GitHub Actions tornam-se... cada tarefa pode injetar o valor correto no

00:21:52.360 --> 00:21:52.940
momento certo.

00:21:53.860 --> 00:21:55.320
Mas mesmo aqui a disciplina é fundamental.

00:21:56.200 --> 00:22:00.440
Esqueça de atualizar uma variável ou deixe segredos vazarem entre ambientes e, de repente,

00:22:00.600 --> 00:22:02.440
seu fluxo de trabalho estará exposto.

00:22:03.340 --> 00:22:07.260
A Microsoft enfatiza a necessidade de definir o escopo de segredos com cuidado e mapear referências

00:22:07.260 --> 00:22:08.460
de conectores intencionalmente.

00:22:08.460 --> 00:22:13.620
Suas políticas de DLP, prevenção contra a perda de dados, existem por um motivo para

00:22:13.620 --> 00:22:17.340
evitar que informações confidenciais transitem entre ambientes ou apareçam no lugar errado.

00:22:18.680 --> 00:22:23.400
Se você tentar contorná-las compartilhando variáveis ou conexões, acabará tropeçando

00:22:23.400 --> 00:22:26.100
nos controles de segurança ou conformidade corporativos.

00:22:26.880 --> 00:22:30.500
Mais importante, você perde a previsibilidade porque não há mais uma linha separando o

00:22:30.500 --> 00:22:32.700
que é para desenvolvimento, teste ou produção.

00:22:33.700 --> 00:22:36.240
O benefício quando você faz tudo isso corretamente é difícil de mensurar.

00:22:36.240 --> 00:22:40.980
Service Principles combinados com variáveis de ambiente bem gerenciadas e conectores mapeados

00:22:40.980 --> 00:22:42.500
adequadamente transformam seu pipeline.

00:22:43.000 --> 00:22:44.500
Suas implantações tornam-se previsíveis.

00:22:45.020 --> 00:22:48.200
Quando as coisas quebram, você tem uma cadeia de custódia clara e sabe exatamente onde

00:22:48.200 --> 00:22:48.560
procurar.

00:22:49.220 --> 00:22:51.900
Foi um mapeamento de conector uma variável ou uma permissão esquecida?

00:22:52.900 --> 00:22:56.460
Auditores podem acompanhar as mudanças e não há suspense quando alguém deixa a organização

00:22:56.460 --> 00:22:57.260
ou altera as senhas.

00:22:57.960 --> 00:23:01.660
Tudo se resume a tratar segredos, conectores e Service Principles como se eles fossem importantes.