Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Pipelines Azure DevOps pour Power Platform : des déploiements fiables avec service principals, validation et rollback (Doublage IA)

Transcript

Pipelines Azure DevOps pour Power Platform : des déploiements fiables avec service principals, validation et rollback (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Prêt pour 10 jours de Microsoft 365, copilote, l'IA, Azure
0:04
Speaker 2: et les personnes qui façonnent l'avenir du travail? En janvier,
0:08
Speaker 2: la M365Con est de retour et elle va plus loin.
0:12
Speaker 2: Rejoignez-nous pour des sessions en direct, des démonstrations concrètes et
0:15
Speaker 2: des connaissances pratiques de MVP et d'experts du secteur du
0:17
Speaker 2: monde entier. Pas de diapositives génériques, pas de mots à
0:20
Speaker 2: la mode sans fin. Nous nous attaquons aux vrais défis.
0:23
Speaker 2: Copilot Studio, agent d'IA, fabrique, sécurité, gouvernance et automatisation? Que
0:30
Speaker 2: vous soyez un professionnel de l'informatique, un développeur ou un
0:32
Speaker 2: chef d'entreprise, il existe des sessions conçues pour vous. Pendant
0:35
Speaker 2: 10 jours complets, vous pouvez explorer de multiples technologies et
0:38
Speaker 2: vous connecter à une communauté mondiale. Regardez en direct et
0:42
Speaker 2: rapportez des informations pratiques à votre organisation. Janvier 2027, 10 jours,
0:47
Speaker 2: une communauté Microsoft. Les inscriptions sont ouvertes dès maintenant. Rendez-vous
0:52
Speaker 2: sur m365n. net et réservez votre place dès aujourd'hui. C'est m365n. net...
1:00
Speaker 2: Rejoignez-nous dès maintenant sur m365con. net et nous vous donnons. Rendez-vous
1:04
Speaker 2: en direct en janvier.
1:04
Speaker 3: J'ai eu l'impression que le déploiement de solutions Power Platform
1:07
Speaker 3: était un pas en avant et deux pas en arrière.
1:09
Speaker 3: Si vous en avez assez de voir vos modifications Dataverse
1:11
Speaker 3: échouer au niveau de l'assurance qualité ou de voir les
1:13
Speaker 3: dépendances faire échouer vos déploiements, cette vidéo est faite pour vous,
1:15
Speaker 3: cette vidéo est faite pour vous. Aujourd'hui, nous allons décomposer
1:17
Speaker 3: le pipeline Azure DevOps, composant par composant, afin que vos
1:20
Speaker 3: déploiements fonctionnent comme une machine bien huilée et non comme
1:23
Speaker 3: un pari. Vous êtes curieux de savoir comment fonctionne réellement
1:26
Speaker 3: la restauration lorsque l'automatisation en est accomplie? Dévoilons ce que
1:28
Speaker 3: la documentation ne vous dit jamais. Déploiement manuel ou pipeline automatisé,
1:32
Speaker 3: là où les choses commencent vraiment. Si vous travaillez avec
1:35
Speaker 3: Power Platform, vous avez probablement vécu ce moment. Des heures
1:39
Speaker 3: passées à peaufiner une application pilotée par modèle, à peaufiner
1:42
Speaker 3: un flux Power Automate, à ajuster soigneusement les rôles de sécurité,
1:45
Speaker 3: toute la liste de contrôle. Vous avez revérifié chaque champ,
1:48
Speaker 3: cliqué sur exporter la solution, téléchargé votre fichier zip et
1:50
Speaker 3: croisé les doigts pendant que l'assurance qualité reçoit une nouvelle version. Puis,
1:54
Speaker 3: alors que tout le monde se prépare pour une démonstration
1:55
Speaker 3: ou une mise en service, quelque chose ne va pas, mais...
1:59
Speaker 3: Une table ne s'affiche pas, un flux se déclenche dans
2:01
Speaker 3: le mauvais environnement ou, pire encore, l'importation échoue avec l'un
2:04
Speaker 3: de ses codes d'erreur cryptique qui signifie simplement que quelque
2:06
Speaker 3: chose ne correspond pas à quelque part. La pièce semble
2:10
Speaker 3: soudainement plus silencieuse. Ce creux familier dans votre estomac s'installe
2:13
Speaker 3: et vous devez recommencer à essayer de trouver ce qui
2:15
Speaker 3: a échoué, où et pourquoi. C'est la réalité quotidienne des
2:19
Speaker 3: équipes qui s'appuie sur des déploiements manuels d'emploi en plateforme.
2:22
Speaker 3: Vous jonglez avec les exportations de solutions vers votre bureau,
2:24
Speaker 3: déplacer des fichiers zip entre environnements, utiliser parfois une vieille
2:26
Speaker 3: feuille Excel ou un chat Teams pour consigner ce qui
2:28
Speaker 3: a été déplacé et quand. Taching. Si vous oubliez une personnalisation,
2:33
Speaker 3: qu'il s'agisse d'une nouvelle table ou d'une référence de connexion
2:35
Speaker 3: pour un flux, votre déploiement est à moitié terminé, mais
2:37
Speaker 3: complètement cassé. Le classique fonctionne en développement, mais l'assurance qualité
2:41
Speaker 3: n'a aucune idée de ce que vous venez d'envoyer. Maintenant,
2:43
Speaker 3: tout le monde est sur Slack ou Teams à essayer
2:45
Speaker 3: de comprendre ce qui manque ou qui a exporté la
2:47
Speaker 3: dernière version réelle de l'application. Les déploiements manuels sont plus
2:50
Speaker 3: sournois dans leur fragilité que ne le pensent les équipes.
2:52
Speaker 3: Il ne s'agit pas seulement d'étapes manquantes. Vous gérez des
2:55
Speaker 3: environnements qui se désalignent discrètement au fil des semaines de changement.
3:00
Speaker 3: Le développeur obtient un nouveau connecteur ou une nouvelle autorisation,
3:02
Speaker 3: mais personne ne les consigne pour le déploiement suivant. Quelqu'un
3:05
Speaker 3: modifie peut-être les détails du déclencheur d'un flux, mais uniquement
3:07
Speaker 3: dans le développement. Au moment où vous êtes en production,
3:09
Speaker 3: il existe un patchwork de dérive de configuration. Même si
3:12
Speaker 3: vous essayez de tout documenter, l'erreur humaine trouve toujours un
3:14
Speaker 3: moyen de s'y introduire... Un changement tardif après un stand-up,
3:17
Speaker 3: un rôle de sécurité négligé ou une variable d'environnement migré
3:20
Speaker 3: manuellement et vous vous retrouvez soudainement à la recherche d'un
3:23
Speaker 3: problème qui n'était pas évident il y a deux jours
3:24
Speaker 3: mais qui bloque désormais l'adoption par les utilisateurs ou corrompt
3:27
Speaker 3: les données dans une intégration critique. Voici une histoire qui
3:31
Speaker 3: vous semble probablement familière. Un flux Power Automate essentiel à
3:35
Speaker 3: l'entreprise fonctionnait en mode développement déplaçant des lignes entre les
3:37
Speaker 3: tables Dataverse à l'aide de nouvelles références de connexion. L'exportation
3:42
Speaker 3: vers l'assurance qualité et l'importation semblent correctes mais rien ne
3:44
Speaker 3: se déclenche. Après des heures passées à passer au peigne
3:46
Speaker 3: fin les journaux et à revérifier les autorisations, quelqu'un réalise
3:49
Speaker 3: que l'environnement d'assurance qualité n'a jamais eu la bonne référence
3:51
Speaker 3: de connexion. Il n'y a aucun avertissement dans l'interface utilisateur,
3:54
Speaker 3: rien n'est signalé à l'étape d'importation. Cela nécessitait une analyse
3:57
Speaker 3: approfondie des couches de la solution et des dépendances des composants,
3:59
Speaker 3: et pendant ce temps, l'entreprise a connu un processus défaillant
4:01
Speaker 3: pendant une bonne partie de la semaine. Microsoft signale ouvertement
4:06
Speaker 3: ce point sensible dans sa documentation, ce qui est presque rassurant.
4:09
Speaker 3: Même les administrateurs expérimentés, des personnes qui vivent et respirent Dataverse,
4:12
Speaker 3: perdent la trace des dépendances cachées ou des différences d'environnement nuancées, nuancées.
4:17
Speaker 3: Des éléments qui ne figurent à peine dans la documentation
4:19
Speaker 3: sont souvent précisément ce qui fait dérailler une mise en service,
4:21
Speaker 3: ce qui fait dérailler une mise en service. Ce ne
4:22
Speaker 3: sont pas des erreurs de débutants. Ce sont les conséquences
4:24
Speaker 3: d'une plateforme flexible, mais discrètement pleine de liens croisés et
4:27
Speaker 3: de dépendances. Lorsque vous comptez sur les gens pour se
4:30
Speaker 3: souvenir de chaque paramètre, ce n'est qu'une question de temps
4:32
Speaker 3: avant que quelque chose ne dérape, avant que quelque chose
4:34
Speaker 3: ne dérape. Le principal argument est donc l'automatisation. Azure DevOps
4:37
Speaker 3: se situe à la limite de ce problème, promettant de
4:39
Speaker 3: transformer ses étapes manuelles, sujettes aux erreurs, en pipelines reproductibles,
4:43
Speaker 3: traçables et, espérons-le, à toute épreuve. L'idée semble bonne sur
4:48
Speaker 3: le papier. Vous connectez un pipeline, vous l'alimentez avec Power
4:51
Speaker 3: Platform et vous le laissez faire le gros du travail.
4:54
Speaker 3: La solution est exportée, importée, les dépendances sont vérifiées et
4:57
Speaker 3: si quelque chose échoue, vous le détectez immédiatement. Vous obtenez
5:00
Speaker 3: de véritables journaux horodatés. Plus besoin de se demander si
5:03
Speaker 3: Alice ou Bob a la dernière copie. Bien fait, chaque
5:06
Speaker 3: déploiement est versionné et traçable jusqu'à la source. Plus de
5:09
Speaker 3: dépendance à la roulette, ni de surprises de dernière minute.
5:12
Speaker 3: Et voici le chiffre que tout le monde aime partager
5:13
Speaker 3: dans les présentations. Les équipes qui passent des processus manuels
5:16
Speaker 3: aux pipelines automatisés voient des boucles de rétroaction qui sont
5:19
Speaker 3: non seulement plus rapides, mais qui ferment la porte à
5:21
Speaker 3: la plupart des déploiements, qui ont échoué à... Bien sûr,
5:24
Speaker 3: des erreurs se produisent toujours, mais elles sont détectées rapidement,
5:27
Speaker 3: et vous ne passez pas des heures à démêler ce
5:28
Speaker 3: qui s'est mal passé. Plus important encore, vous bénéficiez d'une vérifiabilité.
5:31
Speaker 3: Vous pouvez retracer chaque déploiement, savoir exactement qui a livré quoi, et, oui,
5:35
Speaker 3: identifier où et comment quelque chose a échoué. Mais la
5:38
Speaker 3: réalité est qu'il s'agit de confiance, pas seulement de rapidité.
5:41
Speaker 3: Si votre équipe ne peut pas faire confiance au processus
5:42
Speaker 3: de déploiement, si chaque version ressemble à un coup de dé,
5:44
Speaker 3: alors chaque bonne fonctionnalité que vous créez est en danger.
5:47
Speaker 3: Les parties prenantes hésitent à lancer une version. Les utilisateurs
5:49
Speaker 3: sont frustrés par les pannes ou les fonctionnalités manquantes. La
5:51
Speaker 3: promesse d'une innovation low-code rapide tombe à plat lorsque le
5:54
Speaker 3: dernier kilomètre reste peu fiable. L'automatisation ne consiste pas seulement
5:59
Speaker 3: à gagner du temps ou à impressionner les dirigeants en
6:01
Speaker 3: adoptant DevOps. C'est le seul moyen réaliste de fournir des
6:05
Speaker 3: solutions Power Platform qui fonctionnent de la même manière à
6:07
Speaker 3: chaque fois dans chaque environnement. Ainsi, avec les pipelines automatisés,
6:11
Speaker 3: vous obtenez de la prévisibilité. Vous obtenez un enregistrement fiable
6:14
Speaker 3: de chaque dépendance de déploiement et de chaque étape effectuée.
6:17
Speaker 3: Une véritable CICD pour Power Platform devient possible et le
6:21
Speaker 3: dépannage devient une question de journaux et non de conjectures.
6:25
Speaker 3: Bien sûr, rien de tout cela n'arrive par magie. L'automatisation
6:27
Speaker 3: n'est aussi solide que les liens entre votre pipeline et
6:29
Speaker 3: vos environnements. C'est là que les choses peuvent encore mal tourner.
6:35
Speaker 3: Parlons maintenant de la manière de connecter Azure DevOps à
6:38
Speaker 3: votre Power Platform d'une manière stable, sécurisée et qui ne
6:41
Speaker 3: tombe pas en panne à 3h du matin. La colle,
6:44
Speaker 3: les connexions de services et les poules d'agents qui ne
6:47
Speaker 3: se cassent pas. Si vous avez essayé de connecter Azure
6:49
Speaker 3: DevOps à Power Platform et que vous avez vu le
6:50
Speaker 3: pipeline générer instantanément une erreur d'autorisation ou simplement se bloquer
6:54
Speaker 3: pendant ce qui semble être une éternité, vous êtes en
6:56
Speaker 3: bonne compagnie. Presque toutes les équipes rencontrent ce problème à
7:00
Speaker 3: un moment ou un autre. Le pipeline peut être magnifiquement conçu.
7:03
Speaker 3: Votre YAML peut être parfait, mais une seule connexion de
7:06
Speaker 3: service mal configurée ou un paramètre d'agent manquant et vous
7:09
Speaker 3: vous retrouvez face à des erreurs d'authentification où vous vous
7:11
Speaker 3: demandez pourquoi rien ne démarre jamais. La réalité est que
7:15
Speaker 3: les déploiements Power Platform vivent ou meurent en fonction de
7:17
Speaker 3: ce qui se passe en coulisses, ce que j'aime appeler
7:19
Speaker 3: la plomberie invisible. Nous parlons de connexion de service, de
7:23
Speaker 3: flux d'authentification, de poules d'agents et de ces petits paramètres
7:25
Speaker 3: qui maintiennent tout ensemble en silence ou qui vous gâchent
7:27
Speaker 3: la journée. Soyons honnêtes, le concept semble d'une simplicité trompeuse.
7:33
Speaker 3: Vous créez une connexion de service dans Azure DevOps, vous
7:35
Speaker 3: lui donnez des informations d'identification, vous la dirigez vers votre environnement,
7:38
Speaker 3: et vous vous remettez à créer vos flux. Mais en coulisses,
7:42
Speaker 3: c'est un réseau d'autorisation, de jetons et de poignées, de
7:44
Speaker 3: mains d'API. Si vous en manquez un, vous risquez de
7:47
Speaker 3: casser non seulement votre pipeline, mais aussi potentiellement l'intégration sous-jacente
7:50
Speaker 3: pour tous les autres utilisateurs du même principal de service.
7:53
Speaker 3: Ce n'est pas seulement théorique. J'ai vu des équipes fonctionner
7:56
Speaker 3: parfaitement pendant des mois pour finalement se retrouver face à
7:58
Speaker 3: un déploiement unique qui refusait de passer, Cela se résume
8:02
Speaker 3: toujours à un détail en coulisses, un secret expiré, un
8:04
Speaker 3: rôle manquant dans le compte de service ou une modification
8:07
Speaker 3: de l'étendue des autorisations dans Azure Active Directory. Dans le
8:11
Speaker 3: pire des cas, vous pouvez accidentellement vous exclure, vous ou
8:14
Speaker 3: votre équipe des environnements si vous êtes trop agressif dans
8:16
Speaker 3: les attributions de rôle. Imaginez la configuration. Vous obtenez enfin
8:19
Speaker 3: l'autorisation d'utiliser un principal de service pour votre pipeline en
8:22
Speaker 3: visant une véritable sécurité et une séparation des tâches. La
8:26
Speaker 3: théorie est logique. Vous avez une identité par environnement et
8:28
Speaker 3: tout devrait fonctionner, mais le jour du déploiement arrive. Vous
8:32
Speaker 3: exécutez votre pipeline et il échoue à la toute première
8:34
Speaker 3: étape d'authentification. Les messages d'erreur sont obscurs. Vous fouillez dans
8:37
Speaker 3: les journaux pour découvrir que vous avez oublié une minuscule
8:39
Speaker 3: attribution de rôle Dataverse, une case à cocher, et maintenant
8:43
Speaker 3: votre agent ne peut plus accéder à l'environnement. Bien sûr,
8:45
Speaker 3: les journaux ne le signalent pas. Ils renvoient juste un
8:48
Speaker 3: message générique de notre autorisation. Vous vous retrouvez donc à
8:50
Speaker 3: fouiller dans le portail Azure à 23h, à basculer les
8:53
Speaker 3: autorisations et à espérer ne rien casser d'autre au passage.
8:57
Speaker 3: C'est à la fois frustrant et totalement évitable. Il y
9:01
Speaker 3: a un schéma ici. Une autorisation manquée ou une configuration
9:04
Speaker 3: non standard peut bloquer tout le spectacle. C'est pourquoi la
9:07
Speaker 3: meilleure pratique consiste à utiliser un principal de service dédié.
9:10
Speaker 3: Et voilà, le hic. Ne lui attribuez pas des droits
9:13
Speaker 3: d'administrateur partout par commodité. Attribuez uniquement les rôles Dataverse minimaux
9:17
Speaker 3: nécessaires à son environnement et à sa tâche spécifique. Cela
9:21
Speaker 3: peut sembler excessif si vous débutez dans DevOps, mais dans
9:24
Speaker 3: le monde réel, cela vous évite que quelqu'un supprime ou
9:26
Speaker 3: corrompe accidentellement des données parce qu'un principal de service tout
9:28
Speaker 3: puissant avait accès à tout. Cela signifie également que le
9:31
Speaker 3: roulement de clé ou la modification de secret est plus propre.
9:34
Speaker 3: Si vous devez révoquer une connexion de l'assurance qualité, vous
9:36
Speaker 3: ne risquez pas de faire exploser la production. Les équipes
9:39
Speaker 3: qui respectent cette séparation voient rarement tous les environnements tomber
9:43
Speaker 3: en panne. Parlons maintenant des poules d'agents, car étrangement, ils
9:47
Speaker 3: sont généralement considérés comme une réflexion après coup. Vous avez
9:51
Speaker 3: deux options principales, les agents hébergés par Microsoft et les
9:53
Speaker 3: agents auto-hébergés. La plupart des gens choisissent ce qui est
9:57
Speaker 3: par défaut dans leur projet Azure DevOps et espèrent que
9:59
Speaker 3: cela fonctionne. Pour les tâches doigt net ou web de base,
10:04
Speaker 3: cela fonctionne généralement. Mais avec Power Platform, vous finirez par
10:07
Speaker 3: vous heurter à un mur. Les agents hébergés par Microsoft
10:10
Speaker 3: sont parfaits pour les tâches de build de base, mais
10:12
Speaker 3: comme ils sont provisionnés et partagés de manière dynamique, vous
10:14
Speaker 3: ne pouvez pas garantir que toutes les conditions préalables sont présentes.
10:17
Speaker 3: Comme des versions spécifiques des outils de build Power Platform,
10:20
Speaker 3: ou des modules PowerShell personnalisés dont vous avez besoin pour
10:24
Speaker 3: des tâches de solutions plus complexes. De plus, si vous
10:25
Speaker 3: avez besoin d'un logiciel personnalisé ou d'une intégration, tout ce
10:27
Speaker 3: qui ne figure pas dans l'image standard, vous êtes bloqué.
10:30
Speaker 3: Et bonne chance pour résoudre les problèmes isolés dans les
10:32
Speaker 3: environnements que vous ne possédez pas. Les agents auto-hébergés vous
10:35
Speaker 3: donnent un contrôle total sur l'environnement, ce qui est à
10:36
Speaker 3: la fois une bénédiction, une malédiction et une malédiction. D'une part,
10:40
Speaker 3: vous pouvez pré-installer des outils de build, des SDK, des scripts,
10:44
Speaker 3: tout ce dont votre projet a besoin. Si vous disposez
10:47
Speaker 3: de connecteurs uniques ou d'un ensemble stable des dépendances, cela
10:49
Speaker 3: peut vous faire gagner beaucoup de temps, cela peut vous
10:51
Speaker 3: faire de temps. D'un autre côté, vous êtes entièrement responsable
10:53
Speaker 3: des mises à jour de la machine, des correctifs et
10:55
Speaker 3: du maintien en état de marge de l'agent. Pourtant, de
10:58
Speaker 3: nombreuses équipes préfèrent cette voie, en particulier si leur travail
11:00
Speaker 3: sur Power Platform comprend de nombreuses étapes de construction personnalisées
11:03
Speaker 3: ou des intégrations qui ne fonctionnent pas bien avec les
11:05
Speaker 3: images Microsoft partagées. Un conseil qui est souvent négligé, effectuez-leur
11:09
Speaker 3: un essai à blanc. Testez votre connexion de service et
11:11
Speaker 3: effectuez une exportation d'essai avant de transmettre quoi que ce
11:13
Speaker 3: soit d'important à votre pipeline. Ce n'est pas parce que
11:15
Speaker 3: votre pipeline indique qu'il est connecté qu'il dispose du bon
11:17
Speaker 3: niveau d'accès pour chaque opération que vous souhaitez effectuer. Cette
11:21
Speaker 3: exportation de test est votre filet de sécurité. Vous détecterez
11:23
Speaker 3: les lacunes en matière d'autorisation, les problèmes de rôle et
11:25
Speaker 3: même les anomalies de base du réseau avant de vous
11:27
Speaker 3: lancer dans un déploiement en production. Il vaut mieux le
11:29
Speaker 3: savoir maintenant que lorsque vous êtes en train de courir
11:30
Speaker 3: après les fenêtres de mise en service, ce que vous
11:33
Speaker 3: voulez vraiment c'est une fiabilité sans surprise. Des connexions de
11:36
Speaker 3: service et des poules d'agents durables sont la base de
11:38
Speaker 3: tout ce qui vient après. Si vous vous trompez, peu
11:41
Speaker 3: importe à quel point votre YAML est soignée ou vos
11:43
Speaker 3: tâches de pipeline sophistiquées, elles échoueront, car les bases ne
11:46
Speaker 3: sont pas correctement câblées. Une fois que vous avez réussi
11:50
Speaker 3: cette plomberie invisible, le reste du processus de pipeline se
11:52
Speaker 3: met en place avec beaucoup moins de drame et beaucoup
11:54
Speaker 3: plus de prévisibilité. Les mots de tête passent de la
11:57
Speaker 3: question de savoir pourquoi mon pipeline n'a jamais démarré, à
11:59
Speaker 3: celle de savoir comment le rendre encore plus intelligent. Ce
12:01
Speaker 3: qui est un problème beaucoup plus amusant à résoudre. Avec
12:04
Speaker 3: ces connexions stables et vos agents fonctionnant de manière fiable,
12:06
Speaker 3: vous venez de franchir le premier véritable obstacle. Cependant, une
12:09
Speaker 3: plomberie solide ne garantit pas de détecter les problèmes de
12:11
Speaker 3: solution avant qu'il n'atteigne la production. Voyons maintenant comment les
12:15
Speaker 3: vérifications et validations automatisées protègent vos environnements des erreurs silencieuses
12:18
Speaker 3: avant qu'elles ne se propagent. Carte de fou automatisée, vérification
12:22
Speaker 3: des dépendances et validation préalable au déploiement. Si vous avez
12:26
Speaker 3: déjà vu un déploiement Power Platform passer en développement, suivre
12:29
Speaker 3: les étapes en contrôle qualité, puis déclencher des alarmes dès
12:32
Speaker 3: qu'il arrive en production, vous savez où cela vous mène.
12:35
Speaker 3: Les problèmes ne s'annoncent presque jamais à l'avance. Au lieu
12:38
Speaker 3: de cela, vous obtenez ces dépendances discrètement cachées, genre qui
12:41
Speaker 3: se trouvent à deux ou trois clics de profondeur dans
12:43
Speaker 3: une application Canvas ou enfouies dans les sous-flux d'une application
12:45
Speaker 3: pilotée par modèle. En ce qui concerne le développement, tout
12:48
Speaker 3: semble correct, mais la production, avec ses propres connecteurs, différents
12:51
Speaker 3: utilisateurs sous licence ou une différence subtile dans les rôles
12:54
Speaker 3: de sécurité Dataverse trouvent immédiatement le maillon faible. Maintenant, les
12:58
Speaker 3: gens se démêlent. Parfois, le seul avertissement que vous recevez
13:00
Speaker 3: est un utilisateur disant« Ah oui, ces données ne sont
13:01
Speaker 3: pas mises à jour» ou un ticket d'assistance avec une
13:03
Speaker 3: trace de pile qui n'offre rien d'utile. Le problème sous-jacent?
13:07
Speaker 3: Personne n'a vérifié si tous les éléments mobiles ont effectivement
13:09
Speaker 3: survécu au déplacement. C'est pourquoi les vérifications de dépendance et
13:12
Speaker 3: les validations préalables au déploiement ne sont pas seulement agréables
13:14
Speaker 3: à avoir. Elles constituent le système unitaire de votre pipeline.
13:17
Speaker 3: Considérez-les comme un moyen de devancer votre déploiement et de
13:19
Speaker 3: mettre en lumière tous les recoins où les problèmes aiment
13:21
Speaker 3: se cacher. Ces garde-fous automatisés détectent des éléments tels que
13:26
Speaker 3: les flux d'enfants manquants, les références de connexion absentes ou
13:28
Speaker 3: les composants non gélés qui n'ont jamais été ajoutés à
13:30
Speaker 3: votre exportation. Sans ces vérifications, chaque déploiement est un acte
13:34
Speaker 3: de foi. Vous espérez juste que la plomberie sous-jacente à
13:37
Speaker 3: votre application soit la même dans chaque environnement, et vous
13:39
Speaker 3: ne savez que ce n'est pas le cas une fois
13:40
Speaker 3: que le rapport d'incident arrive dans votre boîte de réception.
13:43
Speaker 3: J'ai vu cela se produire plus de fois que je
13:44
Speaker 3: ne veux bien l'admettre. Un projet a connu un cauchemar récurrent,
13:47
Speaker 3: un flux, Power Automate, qui fonctionnait parfaitement dans chaque test
13:49
Speaker 3: de développement pour disparaître complètement d'un déploiement en production. Euh...
13:54
Speaker 3: Que s'est-il passé? Il s'est avéré qu'une solution rapide avait
13:56
Speaker 3: un flux enfant comme dépendance, et le processus d'exportation n'a
13:58
Speaker 3: pas détecté que le flux enfant était en dehors de
14:00
Speaker 3: la solution gérée. lorsque ce flux enfant n'est pas apparu
14:04
Speaker 3: dans l'assurance qualité, la production ou la logique parente a
14:06
Speaker 3: simplement échoué en silence. Aucune erreur, aucun avertissement, juste un
14:10
Speaker 3: processus qui s'est arrêté en silence et les utilisateurs ne
14:12
Speaker 3: comprenaient pas pourquoi leur tâche était soudainement bloquée. Nous n'avons
14:15
Speaker 3: réalisé qu'après qu'un nombre suffisant d'utilisateurs ont signalé des mises
14:18
Speaker 3: à jour manquantes que quelqu'un a finalement trouvé le chaînon manquant.
14:21
Speaker 3: A ce moment-là, des heures avaient été passées à passer
14:22
Speaker 3: au peigne fin les fichiers XML d'exploitation et à exécuter
14:25
Speaker 3: des vérifications manuelles. Une dépendance négligée a provoqué un chaos
14:28
Speaker 3: qui aurait pu être signalé avec la bonne barrière de
14:30
Speaker 3: sécurité en place. Le véritable avantage est qu'il est désormais
14:33
Speaker 3: possible d'éviter ce problème. Des outils tels que SolutionShaker dans
14:36
Speaker 3: Power Platform vous permettent de configurer des analyses automatisées en
14:38
Speaker 3: tant qu'étapes du pipeline, ce qui vous donne des avertissements
14:40
Speaker 3: en amont sur les problèmes de superposition de solutions, les
14:42
Speaker 3: dépendances manquantes, les performances des applications et même des recommandations
14:47
Speaker 3: de sécurité. Les outils de création Power Platform pour Azure
14:51
Speaker 3: DevOps rapprochent encore plus cela de la réalité CICD. Avec
14:56
Speaker 3: la bonne étape du pipeline, vous faites bien plus qu'une
14:57
Speaker 3: simple importation slash exportation. Vous exécutez des contrôles de validation
15:01
Speaker 3: à la fois sur la solution et sur ses connexions
15:03
Speaker 3: à l'environnement cible. Si vous avez des exigences supplémentaires, les
15:06
Speaker 3: scripts PowerShell personnalisés vous permettent d'aller encore plus loin en
15:09
Speaker 3: analysant des éléments tels que les variables d'environnement requises, en
15:13
Speaker 3: validant les connexions pour les API premium ou en vérifiant
15:15
Speaker 3: les étendues d'autorisation sur les flux intégrés AAD. Ce qui
15:21
Speaker 3: est intéressant, c'est à quel point ces garde-fous automatisés détectent
15:23
Speaker 3: beaucoup de problèmes par rapport aux anciennes méthodes d'exportation et d'espoir.
15:27
Speaker 3: Des études communautaires indiquent que ces contrôles signalent jusqu'à 70%
15:29
Speaker 3: des problèmes avant la mise en service. Cela signifie moins
15:33
Speaker 3: d'appels en dehors des heures de bureau, moins de sprints
15:35
Speaker 3: de rattrapage pour corriger ce qui a mal tourné et
15:37
Speaker 3: beaucoup moins de réunions gênantes pour expliquer à la direction
15:40
Speaker 3: pourquoi une mise en service est devenue un échec. Les
15:44
Speaker 3: propres recherches et études de cas de Microsoft le confirment.
15:46
Speaker 3: Les équipes qui effectuent la validation avant le déploiement constatent
15:49
Speaker 3: généralement une baisse spectaculaire des peines de production et les
15:51
Speaker 3: problèmes sont détectés sitôt qu'ils sont à peine considérés comme
15:53
Speaker 3: des incidents. Une étape de pipeline solide pour cela est
15:56
Speaker 3: simple mais efficace. Exportez votre solution depuis la source, mais
16:00
Speaker 3: avant même d'envisager de l'importer dans l'environnement cible, lancez une
16:02
Speaker 3: séquence qui exécute le vérificateur de solution et tous les
16:05
Speaker 3: tests personnalisés que vous avez ajoutés à... Ne vous arrêtez
16:08
Speaker 3: pas à la construction. Exécutez des requêtes sur le dataverse
16:11
Speaker 3: de production pour vous assurer que les entités que vous
16:12
Speaker 3: êtes sur le point de remplacer ne présentent pas de
16:14
Speaker 3: différents schémas qui provoqueraient une erreur silencieuse. Validez les références
16:18
Speaker 3: de connexion. Ne partez pas du principe que toutes les
16:19
Speaker 3: personnes disposant d'autorisation en développement ou en assurance qualité auront
16:22
Speaker 3: le même rôle en production. Le fait d'avoir ces étapes
16:24
Speaker 3: dans le pipeline signifie que le script échoua rapidement s'il
16:26
Speaker 3: manque quelque chose et vous obtenez des journaux utiles vous
16:28
Speaker 3: indiquant exactement où se trouve l'écart. Ces vérifications automatisées font
16:32
Speaker 3: la différence entre passer votre journée à créer des fonctionnalités
16:35
Speaker 3: utiles et passer votre soirée à lutter contre les déploiements défectueux.
16:39
Speaker 3: Elles ne se contentent pas de maintenir la stabilité de l'environnement.
16:41
Speaker 3: Elles donnent à toute l'équipe l'assurance que les modifications en
16:44
Speaker 3: cours dans le pipeline n'ont pas sauté d'étape cruciale ou
16:46
Speaker 3: oublié une dépendance de dernière minute. Cela transforme le jour
16:50
Speaker 3: du déploiement d'un moment tendu en une routine. Lorsque quelqu'un demande,
16:54
Speaker 3: le déploiement est-il terminé? Car vous pouvez en fait répondre
16:57
Speaker 3: avec plus de précision que je ne le pense, car
16:58
Speaker 3: vous disposez des garde-fous pour le prouver. Il est facile
17:01
Speaker 3: de rejeter les vérifications préalables au déploiement comme une autre
17:03
Speaker 3: case à cocher, mais dans le monde de Power Platform,
17:05
Speaker 3: elles permettent de gagner plus de temps et de faire
17:07
Speaker 3: gagner du temps que presque toute autre automatisation. Au lieu
17:11
Speaker 3: de travailler à rebours à partir des pannes et des plaintes,
17:14
Speaker 3: vous obtenez des alertes sentinelles proactives, précoces, exploitables et directement
17:18
Speaker 3: liées aux composants. Considérez-les-moi comme un filet de sécurité que
17:22
Speaker 3: comme un système radar. Bien sûr, même avec les meilleurs
17:24
Speaker 3: garde-fous en place, les choses peuvent toujours mal tourner. Rien
17:27
Speaker 3: n'est infaillible et chaque équipe a besoin d'un moyen d'annuler
17:30
Speaker 3: les changements lorsque quelque chose passe à côté. Voyons donc
17:33
Speaker 3: à quoi ressemble un véritable plan de restauration et de
17:35
Speaker 3: sauvegarde pour Power Platform au-delà du simple fait d'espérer que
17:38
Speaker 3: le bouton annuleur fonctionne. Lorsque les choses se cassent, élaborons
17:42
Speaker 3: une véritable stratégie de restauration et de sauvegarde. Parlons de
17:45
Speaker 3: ce que signifie réellement la restauration pour Power Platform, car
17:48
Speaker 3: il est facile de supposer qu'il existe un gros bouton
17:50
Speaker 3: annuleur prêt à vous sauver lorsqu'un déploiement échoue, lorsqu'un déploiement échoue. Mais,
17:55
Speaker 3: contrairement au projet de code où une restauration n'est qu'une
17:58
Speaker 3: réinitialisation Git ou un redéploiement de package, le monde de
18:00
Speaker 3: Power Platform est beaucoup moins indulgent. Il n'existe pas d'option
18:03
Speaker 3: native de restauration du déploiement. Une fois l'importation effectuée, les
18:07
Speaker 3: modifications sont intégrées à l'environnement, les tables peuvent être mises
18:10
Speaker 3: à jour, les composants changent de version et les relations
18:12
Speaker 3: de données peuvent se remanier discrètement à Si quelque chose
18:16
Speaker 3: échoue au milieu de l'importation, le résultat peut être une
18:18
Speaker 3: solution à moitié déployée, des intégrations cassées ou des utilisateurs
18:21
Speaker 3: exclus des applications dont ils ont besoin. Les enjeux sont
18:25
Speaker 3: rarement évidents avant qu'ils ne surviennent et à ce moment-là,
18:27
Speaker 3: la correction nécessite de la finesse. La dure vérité est
18:30
Speaker 3: qu'une importation bâclée laisse votre environnement dans une sorte de
18:32
Speaker 3: vide juridique. Certains composants peuvent être mis à niveau, d'autres
18:36
Speaker 3: restent à leur ancienne version et les connexions ou les
18:38
Speaker 3: rôles peuvent être dans un état indéfini. Les configurations se
18:42
Speaker 3: désynchronisent rapidement et vous vous retrouvez avec un système qui
18:45
Speaker 3: ne correspond pas vraiment à ce que tout le monde
18:46
Speaker 3: avait prévu. Ce qui ressemble à une modification mineure dans
18:49
Speaker 3: une solution gérée peut mettre à mal des processus métiers anti-enaval.
18:53
Speaker 3: C'est là que la plupart des administrateurs se font piéger.
18:55
Speaker 3: On a l'impression qu'il suffit d'exécuter à nouveau, ou d'annuler
18:58
Speaker 3: une étape alors qu'en pratique il s'agit d'une application indirecte
19:00
Speaker 3: sur laquelle les utilisateurs comptent pour faire leur travail. Maintenant
19:04
Speaker 3: imaginez les enjeux avec un exemple réel. Une grande société
19:07
Speaker 3: financière avait une nouvelle fonctionnalité en attente pour son portail PowerApps,
19:12
Speaker 3: Quelques ajustements de flux de travail, quelques nouveaux tableaux de
19:15
Speaker 3: bord et une table de données reconfigurée. Le changement a
19:18
Speaker 3: été rapidement validé par le contrôle qualité, de sorte qu'ils
19:20
Speaker 3: ont donné le feu vert à l'importation en production tard
19:22
Speaker 3: un vendredi, espérant arranger les choses avant la date limite
19:24
Speaker 3: de reporting du lundi. L'importation a échoué à mi-chemin. Résultat,
19:28
Speaker 3: les utilisateurs qui se sont connectés lundi matin ont trouvé
19:30
Speaker 3: des tableaux de bord cassés, des automatisations défaillantes et une
19:33
Speaker 3: poignée d'applications Canva qui ne se chargeaient pas. Pour ne
19:36
Speaker 3: rien arranger, leur dernière sauvegarde complète de l'environnement datait de
19:38
Speaker 3: plusieurs semaines et ils n'avaient pas exporté la dernière version
19:41
Speaker 3: de la solution après des modifications de développement de dernière minute.
19:44
Speaker 3: Les options de restauration étaient limitées et l'entreprise a perdu
19:47
Speaker 3: une journée entière de travail pendant que les administrateurs reconstituaient l'environnement.
19:50
Speaker 3: Aucune étape n'a été à l'origine du désastre. C'est une
19:53
Speaker 3: fenêtre de sauvegarde manquée, une croyance dans les solutions rapides
19:55
Speaker 3: et un manque de planification flexible de la restauration qui
19:57
Speaker 3: les ont laissés exposer. Alors que pouvez-vous faire concrètement pour
20:01
Speaker 3: éviter de vous retrouver dans les limbes de la restauration?
20:04
Speaker 3: La première couche et la plus fiable consiste à automatiser
20:06
Speaker 3: les exportations de solutions à chaque étape. Au lieu de
20:10
Speaker 3: faire confiance à la dernière version dans un dossier de développement,
20:12
Speaker 3: votre pipeline doit exporter automatiquement la solution vers un emplacement sécurisé,
20:15
Speaker 3: idéalement dans le contrôle de source. De cette façon, chaque version,
20:19
Speaker 3: qu'elle ait réussi ou échoué, dispose d'une sauvegarde correspondante. Si
20:23
Speaker 3: le déploiement d'aujourd'hui tourne mal, vous n'êtes pas coincé avec
20:25
Speaker 3: ce qui se trouve sur votre bureau. Vous avez toujours
20:27
Speaker 3: accès au dernier paquet connu en bon état. Les sauvegardes
20:31
Speaker 3: nocturnes de l'environnement sont une autre mesure pratique, même si
20:33
Speaker 3: vous pensez ne jamais en avoir besoin. Microsoft propose des
20:36
Speaker 3: fonctionnalités de sauvegarde complète de l'environnement, en particulier pour les
20:38
Speaker 3: environnements Dataverse, mais vous serez surpris du nombre d'équipes qui
20:41
Speaker 3: n'automatisent pas réellement leur utilisation. Les directives officielles sont claires,
20:44
Speaker 3: effectuez toujours une sauvegarde complète de l'environnement avant de passer
20:46
Speaker 3: en production. Pourtant, sur le terrain, de nombreuses équipes se
20:50
Speaker 3: contentent de dire« nous le ferons si nous nous en souvenons, Akerber».
20:53
Speaker 3: Cela fonctionne aussi bien que prévu, jusqu'à ce que cela
20:55
Speaker 3: ne fonctionne plus. La configuration de sauvegarde nocturne ou de
20:57
Speaker 3: pré-déploiement signifie que vous disposez d'un instantané complet à partir
21:00
Speaker 3: duquel restaurer si les choses se gagnent. Lorsqu'elles sont associées
21:02
Speaker 3: à des exportations au niveau de la solution, vous pouvez
21:04
Speaker 3: décider de restaurer un environnement entier ou de simplement restaurer
21:07
Speaker 3: une seule solution en fonction de l'ampleur du problème. Les
21:11
Speaker 3: fichiers de solution de version dans le contrôle de source
21:13
Speaker 3: peuvent sembler basiques, mais sont de véritables bouées de sauvetage.
21:15
Speaker 3: Le suivi de chaque fichier zip exporté avec l'historique des validations,
21:18
Speaker 3: la dénomination des branches et les demandes d'extraction rapprochent les
21:20
Speaker 3: déploiements Power Platform des cycles de vie classiques des applications.
21:24
Speaker 3: Vous obtenez une piste d'audit complète de ce qui a changé,
21:26
Speaker 3: quand et par qui. Si une restauration devient nécessaire, vous
21:28
Speaker 3: n'avez pas besoin de vous démener. Il vous suffit de
21:30
Speaker 3: redéployer la version précédente réussie. Ce n'est pas seulement pratique,
21:33
Speaker 3: c'est l'un des moyens les plus fiables de restaurer les
21:35
Speaker 3: modifications critiques pour l'entreprise sans impact collatéral, sans impact même.
21:39
Speaker 3: Lorsqu'il est temps d'exécuter une véritable restauration, les fichiers de
21:41
Speaker 3: solutions exportés sont votre bouée de sauvetage. Commencez par restaurer
21:45
Speaker 3: la version précédente de la solution que vous avez déjà
21:47
Speaker 3: validée dans un environnement inférieur. Le retour à cet état
21:51
Speaker 3: connu et correct réinitialisera vos composants, flux et personnalisations associés.
21:55
Speaker 3: Vous n'obtiendrez pas une machine à remonter le temps parfaite.
21:57
Speaker 3: Les enregistrements ou les données transactionnelles modifiées depuis le dernier
22:00
Speaker 3: déploiement peuvent toujours être en danger, mais vous pouvez rétablir
22:02
Speaker 3: l'application dans une configuration fonctionnelle en moins d'une heure. Pour
22:06
Speaker 3: tout problème plus grave, comme une entité corrompue, des relations
22:09
Speaker 3: perdues ou des problèmes d'intégration de données, vous devrez peut-être
22:12
Speaker 3: utiliser cette sauvegarde au niveau de l'environnement ou des restaurations
22:14
Speaker 3: de tables individuelles en fonction de ce qui est disponible.
22:18
Speaker 3: Une leçon apprise à vos dépens, ne partez jamais du
22:20
Speaker 3: principe que votre plan de restauration est solide à moins
22:22
Speaker 3: de l'avoir testé dans un bac à sable. La différence
22:25
Speaker 3: entre un processus de restauration théorique et un processus de
22:27
Speaker 3: restauration réelle est énorme. Sans test, vous risquez de restaurer
22:30
Speaker 3: des dépendances incomplètes ou de rencontrer des conflits d'importation que
22:33
Speaker 3: vous n'aviez pas anticipés. La mise en pratique de votre
22:35
Speaker 3: restauration est essentielle.