Vue d’ensemble de l’intégration du Git Dataverse (version préliminaire)
[Cet article fait partie de la documentation préliminaire et peut faire l’objet de modifications.]
L’intégration du contrôle de code source permet aux équipes de développement de synchroniser des solutions et des objets de solution dans un ou plusieurs environnements Microsoft Dataverse à l’aide d’un référentiel Git Azure DevOps. La fonctionnalité d’intégration du contrôle de code source est disponible en mode natif dans les expériences de solutions, ce qui permet aux développeurs citoyens, aux développeurs axés sur le code et aux administrateurs de bénéficier du contrôle de version, du suivi des modifications et d’une collaboration d’équipe transparente entre différents outils et environnements. L’intégration Git est destinée à être utilisée avec des environnements de développement et non dans vos environnements de test ou de production où les déploiements peuvent être effectués à l’aide de builds pour créer des artefacts de solution et des pipelines à déployer.
Important
- Cette fonctionnalité est en version préliminaire.
- Les fonctionnalités en version préliminaire ne sont pas destinées à une utilisation en production et peuvent être restreintes. Ces fonctionnalités sont disponibles avant une publication officielle afin que les clients puissent y accéder de façon anticipée et fournir des commentaires.
- Cette fonctionnalité n’est actuellement disponible que pour les environnements qui ont été créés pour des cycles de lancement anticipés. Accédez à Environnements du cycle de lancement anticipé
Dans cet article, vous trouverez quelques-uns des concepts clés et des avantages de l’utilisation du contrôle de code source compatible Git avec vos environnements et solutions Dataverse. Pour plus d’informations sur Git dans Azure DevOps, accédez à Référentiel Git Azure DevOps.
ALM dans Power Platform et Dataverse
Power Platform fournit de nombreuses fonctionnalités prêtes à l’emploi qui permettent aux organisations de gérer la gestion du cycle de vie des applications (ALM) pour leurs solutions. Il est notamment possible d’empaqueter des solutions sous forme de conteneurs pour les différents types de composants de la plateforme, de gérer les environnements impliqués dans le cycle de vie des applications et de déployer des solutions à l’aide de pipelines dans Power Platform. Il existe également plusieurs façons d’intégrer les référentiels Git à Power Platform l’aide d’outils de développement. Avec l’intégration native de Git dans Dataverse, le processus est simplifié et rationalisé pour que les créateurs puissent travailler avec leurs solutions de manière familière et interagir avec le contrôle de code source via des interfaces simplifiées dans Power Apps (make.powerapps.com).
Avantages
- Contrôle de code source comme source de vérité : au sein de certaines organisations, la source de vérité pour les déploiements dans Dataverse est l’environnement de créateur dans lequel les solutions sont construites. Le principal moteur de ce comportement est que l’intégration Git non native utilise des techniques et des outils avancés, qui nécessitent une expertise informatique professionnelle pour démarrer. Avec l’intégration native de Git dans Dataverse, le contrôle de code source peut être activé en quelques étapes seulement et fournit une interface familière aux créateurs pour travailler avec leurs solutions.
- Sécurité, audit et conformité à l’aide des meilleures pratiques SDLC : les meilleures pratiques du cycle de vie du développement logiciel (SDLC) sont un ensemble de directives et de processus qui vous aident à gérer efficacement vos projets de développement logiciel. En utilisant l’intégration Git dans Dataverse, vous suivez les pratiques SDLC telles que le contrôle de version, les révisions de code et l’analyse statique du code source pour garantir la qualité, la fiabilité et la sécurité de vos solutions. L’intégration de Git dans Dataverse fournit également des fonctionnalités telles que l’audit, la conformité et la traçabilité qui vous aident à suivre les modifications apportées à vos solutions et à collaborer efficacement avec les autres membres de l’équipe.
- Environnements de développement de courte durée : en stockant une copie des personnalisations et des configurations de vos environnements dans le contrôle de code source, vous pouvez réhydrater rapidement et facilement les environnements de développement à partir du contrôle de code source dans Dataverse. Cela vous permet de créer des environnements de courte durée à des fins de développement et de test. Les environnements de courte durée vous permettent de libérer du stockage, d’expérimenter de nouvelles fonctionnalités, de tester et d’itérer vos solutions sans dépendre d’environnements permanents.
- Équipes de développement Fusion : les équipes de développement Fusion sont des équipes composées à la fois de développeurs et de créateurs qui travaillent ensemble pour créer des solutions. En utilisant l’intégration Git dans Dataverse, ces utilisateurs peuvent créer indépendamment dans des environnements séparés et collaborer avec d’autres en se synchronisant avec un référentiel de contrôle de code source commun. L’intégration du contrôle de code source vous permet d’utiliser les compétences et l’expertise des développeurs et des créateurs pour créer des solutions de haute qualité qui répondent aux besoins de votre organisation.
- Protection : l’utilisation du contrôle de code source comme source de vérité pour vos solutions vous permet de récupérer rapidement et facilement des modifications involontaires de vos solutions. En stockant vos solutions dans le contrôle de code source, vous pouvez restaurer un état ou une version antérieur.
Concepts clés
Solutions gérées versus solutions non gérées
Lorsque vous utilisez l’intégration Git avec Dataverse, les solutions stockées dans le contrôle de code source proviennent de solutions non gérées dans l’environnement d’un créateur. Les solutions non gérées permettent aux créateurs d’ajouter, de supprimer et de mettre à jour des composants synchronisés avec le contrôle de code source lorsque vous validez et appliquez des modifications. Les solutions gérées sont créées à partir du contrôle de code source et déployées dans des environnements en aval, tels que des tests ou des productions, et ne sont pas modifiables dans ces environnements. Les solutions gérées sont utilisées pour garantir que la source de vérité de vos solutions est toujours le contrôle de code source et que les modifications ne sont effectuées que dans l’environnement d’un créateur avant d’être ajoutées au contrôle de code source et déployées ailleurs.
Formatage de fichier pour les composants de solution
Avec l’introduction de l’intégration Git dans Dataverse, des changements ont été apportés à la façon dont les solutions et les composants de solution sont représentés dans le contrôle de version. Lorsque vous validez et envoyez des modifications au contrôle de code source, les composants de la solution sont stockés dans un format spécifique compatible avec Git. Ce format est utilisé pour représenter les composants de la solution d’une manière facile à lire et à comprendre et peut être utilisé pour suivre les modifications apportées aux composants de la solution au fil du temps. Le format de fichier des composants de solution est conçu pour être lisible par l’homme et peut être utilisé pour afficher les modifications apportées aux composants de solution dans le contrôle de code source. De plus, pour permettre à plusieurs solutions d’être stockées dans le même référentiel et dossier, les composants de solution dans le contrôle de code source ne sont plus dupliqués pour chaque solution. Au lieu de cela, les composants de solution sont stockés dans un emplacement unique et peuvent être partagés entre plusieurs solutions dans le même référentiel et dossier.
Développement code-first avec Git
Le développement code-first dans Power Platform est activé avec des outils de développement tels que la CLI Power Platform, Visual Studio et les extensions Visual Studio Code. Il est difficile d’impliquer les développeurs code-first dans le processus de développement de la solution sans l’intégration du contrôle de code source, car des composants tels que les contrôles Power Apps Component Framework (PCF) et les plug-ins Dataverse sont déployés dans les solutions en tant qu’actifs packagés construits à partir du code source et non directement modifiables dans Power Apps (make.powerapps.com). Sans contrôle de code source dans le cadre du processus de développement pour les composants low-code et code-first, il est difficile de gérer les modifications apportées à la solution et de s’assurer que les modifications sont suivies et déployées de manière contrôlée.
En activant l’intégration de Git dans Dataverse, vous pouvez rencontrer les développeurs code-first là où ils sont à l’aise et offrir une expérience transparente aux développeurs low-code et code-first. Cependant, il y a quelques considérations à garder à l’esprit lors de la gestion des composants code-first dans un environnement low-code.
Développement de la fusion avec intégration Git Dataverse
Power Platform fournit des fonctionnalités pour le développement low-code et code-first. Cet article aborde les processus de développement code-first associés à Dataverse et à l’intégration du Git et fournit des instructions sur la manière de gérer les composants code-first et low-code dans un environnement unique. Les composants tels que les contrôles Power Apps component framework, les plug-ins Dataverse et les activités de workflow personnalisées sont des exemples de composants code-first qui peuvent être gérés dans le contrôle de code source.
Composants code-first et low-code dans un environnement unique
Les composants code-first peuvent être inclus dans les solutions via un processus de construction qui génère une solution gérée ou non gérée qui peut être importée dans un environnement Dataverse. Cependant, les composants code-first peuvent également être déployés directement dans une solution non gérée dans un environnement de créateur une fois qu’ils sont créés sans utiliser le processus de construction de la solution pour les déployer. Il y a le processus de génération à prendre en compte en raison de cette flexibilité.
Si vous déployez des composants code-first directement dans une solution non gérée dans un environnement de créateur, lorsque ces composants sont validés dans le contrôle de code source, seule leur version compilée (construite) est stockée dans le contrôle de code source. Par exemple, la DLL binaire s’il s’agit d’un plug-in, ou le bundle JavaScript transpilé et optimisé pour un contrôle Power Apps component framework. Par conséquent, vous vous retrouvez avec deux copies du composant dans le contrôle de code source, l’une représentée par la version générée et l’autre représentée par le code source. Le stockage des fichiers binaires dans votre répertoire peut entraîner des confusions et des conflits potentiels si le code source et la version compilée ne sont pas synchronisés. Cette pratique n’est pas recommandée, car le code source doit être la seule source de vérité pour le composant et une seule copie doit être stockée.
L’approche recommandée consiste à créer des composants code-first dans le cadre d’un processus de génération de solution et à importer la solution non gérée générée dans l’environnement de création. Cette approche garantit que le code source et la version générée sont synchronisés et que le code source est la source unique de vérité pour le composant. Toutefois, cette approche nécessite la mise en place d’un processus de génération pour générer la solution gérée ou non gérée à utiliser dans le processus d’importation et le processus de déploiement. Vous pouvez créer des workflows Azure Pipelines ou GitHub, par exemple, qui créent des artefacts pour les pipelines dans Power Platform et pour les processus de synchronisation Git à consommer.