Partager via

Gestion du cycle de vie des applications des composants de code (ALM)

  • Article

ALM est un terme utilisé pour décrire la gestion du cycle de vie des applications logicielles, il inclut le développement, la maintenance et la gouvernance. Plus d’informations : Gestion du cycle de vie des applications (ALM) avec Microsoft Power Platform.

Cet article présente les éléments à prendre en compte et les stratégies pour utiliser certains aspects de la gestion du cycle de vie du point de vue des composants de code dans Microsoft Dataverse :

  1. Considérations relatives au développement et au débogage d’ALM

  2. Stratégies de solution des composants de code

  3. Contrôle des versions et déploiement des mises à jour

  4. Considérations relatives à l’ALM des applications canevas

Considérations relatives au développement et au débogage d’ALM

Lors du développement des composants de code, suivez les étapes ci-dessous :

  1. Créer un projet de composant de code (pcfproj) à partir d’un modèle en utilisant pac pcf init. Plus d’informations : Créer et générer un composant de code.
  2. Implémenter la logique du composant de code. Plus d’informations : Implémentation de composant.
  3. Déboguer le composant de code à l’aide du faisceau de test local. Plus d’informations : Déboguer les composants de code.
  4. Créer un projet de solution (cdsproj) et ajouter le projet de composant de code en référence. Pour plus d’informations, voir : Créer un package de composant de code.
  5. Générer le composant de code en mode Mise en production pour la distribution et le déploiement.

Dès que le composant de code est prêt à être testé dans une application pilotée par modèle, une application canevas ou un portail, il existe deux manières de déployer un composant de code sur Dataverse :

  1. pac pcf push : cela déploie un seul composant de code à la fois sur une solution spécifiée par le --solution-unique-name paramètre ou un PowerAppsTools temporaire solution lorsqu’aucune solution n’est spécifiée.

  2. En utilisant pac solution init et msbuild pour générer cdsproj un projet de solution qui fait référence à un ou plusieurs composants de code. Chaque composant de code est ajouté à cdsproj en utilisant pac solution add-reference. Un projet de solution peut contenir des références à plusieurs composants de code tandis que les projets de composants de code ne peuvent contenir qu’un seul composant de code.

    Le diagramme suivant montre la relation un-à-plusieurs entre les projets cdsproj et pcfproj :

    Relation un-à-plusieurs entre les projets cdsproj et pcfproj.

Pour plus d’informations, voir : Créer un package de composant de code.

Génération des projets de composants de code pcfproj

Lors de la génération des projets pcfproj, le code JavaScript généré dépend de la commande utilisée et du PcfBuildMode dans le projet pcfproj.

Vous ne déployez normalement pas de composant de code dans Microsoft Dataverse généré en mode développement car il est souvent trop volumineux pour une importation et peut provoquer un ralentissement des performances d′exécution. Plus d’informations : Débogage après le déploiement dans Microsoft Dataverse.

Pour que pac pcf push renvoie une version de mise en production, PcfBuildMode est placé à l’intérieur de pcfproj en ajoutant un nouvel élément sous l’élément OutputPath comme suit :

<PropertyGroup>
   <Name>my-control</Name>
   <ProjectGuid>6aaf0d27-ec8b-471e-9ed4-7b3bbc35bbab</ProjectGuid>
   <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
   <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

Le tableau suivant montre les commandes qui renvoient des versions de développement ou des versions de mise en production :

Commande de version utilisée sur pcfproj Version de développement
(à des fins de débogage uniquement)		 Version de mise en production
npm start watch Toujours
pac pcf push Comportement par défaut ou si PcfBuildMode est défini sur développement dans le fichier pcfproj PcfBuildMode est défini sur production dans le fichier pcfproj
npm run build Comportement par défaut npm run build -- --buildMode production

Pour plus d’informations, voir : Créer un package de composant de code.

Génération de projets de solution .cdsproj

Lors de la génération d′un projet de solution (.cdsproj), vous avez la possibilité de générer la sortie en tant que solution gérée ou solution non gérée. Les solutions gérées permettent un déploiement dans tout environnement autre qu’un environnement de développement pour la solution concernée. Cela inclut les environnements d’évaluation, UAT, SIT et de production. Plus d’information : Solutions gérées et non gérées.

SolutionPackagerType est inclus dans le fichier .cdsproj créé par pac solution init, mais initialement commenté. Annulez les commentaires de la section et définissez la solution sur Gérée, Non gérée ou Les deux.

 <!-- Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both) -->
 <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
 </PropertyGroup>

Le tableau suivant montre les résultats de configuration et de commande dans les versions de développement et les versions de mise en production :

Commande de version utilisée sur cdsproj SolutionPackageType Sortie
msbuild Géré Version Développement dans la solution Gérée
msbuild /p:configuration=Release Géré Version Mise en production dans la solution Gérée
msbuild Non managé Version Développement dans la solution Non gérée
msbuild /p:configuration=Release Non managé Version Mise en production dans la solution Non gérée

Pour plus d’informations, voir : Créer un package de composant de code.

Contrôle du code source avec les composants de code

Lors du développement des composants de code, il est conseillé d′utiliser un fournisseur de contrôle de code source tel que Azure DevOps ou GitHub. Lors de la validation des modifications à l′aide du contrôle de code source Git, le fichier .gitignore fourni par le modèle pac pcf init garantit que certains fichiers ne sont pas ajoutés au contrôle de code source, car ils sont soit restaurés par npm, soit générés dans le cadre du processus de génération :

# <a name="dependencies"></a>dependencies
/node_modules

# <a name="generated-directory"></a>generated directory
**/generated

# <a name="output-directory"></a>output directory
/out

# <a name="msbuild-output-directories"></a>msbuild output directories
/bin
/obj

Le dossier /out étant exclu, le fichier bundle.js obtenu (et les ressources associées) n′est pas ajouté au contrôle de code source. Si les composants de code étaient générés manuellement ou dans le cadre d’un pipeline de build automatisé, le fichier bundle.js serait généré en utilisant le code le plus récent pour s’assurer que toutes les modifications soient prises en compte.

De plus, lorsqu′une solution est générée, les fichiers zip de la solution d′association ne sont pas validés dans le contrôle de source. Au lieu de cela, la sortie serait publiée sous forme d′artefacts de version binaire.

Utilisation de SolutionPackager avec les composants de code

Outre le contrôle de code source au niveau de pcfproj et de cdsproj, SolutionPackager peut permettre de décompresser progressivement une solution en une série de fichiers XML pouvant être validés dans le contrôle de code source. Vous créez ainsi une image complète de vos métadonnées dans un format lisible par l′utilisateur afin de suivre les modifications en utilisant les demandes d′extraction ou autre. À chaque fois qu′une modification est apportée aux métadonnées de la solution de l′environnement, SolutionPackager sert à décompresser et les modifications peuvent être affichées dans un ensemble de modifications.

Notes

Pour le moment, SolutionPackager diffère de l’utilisation de pac solution clone, car il peut être utilisé de manière incrémentielle pour exporter les modifications d’une solution Dataverse.

Si vous associez des composants de code à d′autres éléments de solution, comme des tables, des applications pilotées par modèle et des applications canevas, vous n′auriez normalement pas besoin de la version de projet cdsproj. Par contre, vous déplaceriez les artefacts de version de pcfproj vers le dossier du package de solution avant de le recompresser pour l′importation.

Dès qu’une solution contenant un composant de code est décompressée en utilisant SolutionPackager /action: Extract, elle ressemble à ce qui suit :

.
├── Controls
│   └── prefix_namespace.ControlName
│       ├── bundle.js *
│       └── css
│          └── ControlName.css *
│       ├── ControlManifest.xml *
│       └── ControlManifest.xml.data.xml
├── Entities
│   └── Contact
│       ├── FormXml
│       │   └── main
│       │       └── {3d60f361-84c5-eb11-bacc-000d3a9d0f1d}.xml
│       ├── Entity.xml
│       └── RibbonDiff.xml
└── Other
    ├── Customizations.xml
    └── Solution.xml

Dans le dossier Controls, vous affichez des sous-dossiers pour chaque composant de code inclus dans la solution. Les autres dossiers contiennent des composants de solution supplémentaires ajoutés à la solution.

Lors de la validation de cette structure de dossiers dans le contrôle de code source, vous excluez les fichiers marqués d′un astérisque (*) ci-dessus car ils sont générés lorsque le projet pcfproj est généré pour le composant correspondant.

Les seuls fichiers obligatoires sont les fichiers *.data.xml car ils contiennent des métadonnées qui décrivent les ressources requises par le processus de compression. Après la génération de chaque composant de code, les fichiers du dossier out sont copiés dans le dossier de contrôle respectif dans les dossiers de Solution Packager. Dès que les sorties de version sont ajoutées, les dossiers de package contiennent toutes les données requises pour la recompression en une solution Dataverse en utilisant SolutionPackager /action: Pack.

Plus d’informations : Arguments de ligne de commande SolutionPackager.

Stratégies de solution des composants de code

Les composants de code sont déployés dans des environnements en aval à l’aide des solutions Dataverse. Une fois déployés dans votre environnement de développement, ils se déploient de la même manière que les autres composants de solution. Plus d’informations : Concepts de solution – Power Platform.

Il existe deux stratégies pour déployer des composants de code dans les solutions :

  1. Solutions segmentées : un projet de solution est créé en utilisant pac solution init, puis en utilisant pac solution add-reference pour ajouter un ou plusieurs composants de code. Cette solution est ensuite exportable et importable dans les environnements en aval et les autres solutions segmentées dépendront de la solution de composant de code de sorte qu’elle doit d’abord être déployée dans cet environnement. Il s′agit d′une segmentation de solution car la fonctionnalité globale est fractionnée entre différents segments et couches de solution, les interdépendances étant suivies par l′infrastructure de la solution. Pour cette approche, vous aurez probablement besoin de plusieurs environnements de développement - un par solution segmentée. Plus d’informations : Utiliser des solutions segmentées dans Power Apps.

  2. Solution unique : une solution unique est créée dans un environnement Dataverse, les composants de code sont ensuite ajoutés avec d’autres composants de solution (comme des tables, des applications pilotées par modèle ou des applications canevas) qui à leur tour référencent ces composants de code. Cette solution est exportable et importable dans les environnements en aval sans aucune dépendance entre les solutions. Pour cette approche, le branchement du code et de l’environnement devient important pour déployer une mise à jour dans une partie de la solution sans prendre en compte les modifications apportées dans une autre zone. Plus d’informations : Stratégie de branches et de fusion avec Microsoft Power Platform.

Raisons pour adopter une approche à solution segmentée plutôt qu’à solution unique mixte :

  1. Cycle de vie du contrôle de version : pour développer, déployer et contrôler les versions des composants de code sur un cycle de vie à part des autres parties de la solution. Un scénario courant avec une « équipe de fusion » où les composants de code générés par les développeurs sont consommés par les créateurs d′applications. En général, cela signifie également que vos composants de code existent dans un référentiel de code différent des autres composants de la solution.

  2. Utilisation partagée : pour partager les composants de code entre plusieurs environnements et donc ne pas les associer aux autres composants de code de la solution. Cela peut être le cas si vous êtes éditeur de logiciels indépendant ou si vous développez un composant de code utilisé par différentes parties de l′organisation dans son propre environnement.

Le diagramme suivant présente une vue d’ensemble du cycle de vie de la solution pour ces deux approches :

Stratégies de solution.

Le diagramme décrit les points suivants :

  1. Transmettre à l’aide de PAC CLI  : si le composant de code est prêt à être testé dans Dataverse, pac pcf push sert à déployer dans un environnement de développement. Une solution non gérée nommée PowerAppsTools_espace de noms est ainsi créée dans laquelle espace de noms correspond au préfixe de l′espace de noms du fournisseur de solutions que vous voulez utiliser pour déployer le composant de code. Le fournisseur de solutions doit déjà exister dans l′environnement cible et doit avoir le même préfixe d′espace de noms que celui que vous souhaitez utiliser pour les environnements en aval. Après le déploiement, vous pouvez ajouter votre composant de code aux applications pilotées par modèle ou canevas pour les tests.

    Notes

    Comme expliqué ci-dessus, il est important de configurer le composant de code cdsproj pour la version de production afin que vous déployiez le code optimisé pour la production plutôt que pour le développement.

  2. Ajouter des composants de code existants (après le déploiement de PAC CLI)  : si vous utilisez l′approche par solution unique, après le déploiement, le composant de code peut être ajouté à une autre solution. (Cette solution doit partager le même éditeur de solutions que celui utilisé par la solution PowerAppsOutils.)

    Ajouter.

  3. Générer un projet de solution non gérée : si vous utilisez les projets cdsproj de solution, une solution non gérée peut être générée en utilisant msbuild, puis importée dans votre environnement de développement.

  4. Ajouter les composants de code existants (après le déploiement du projet de solution)  : tout comme pour pac pcf push, les composants de code importés à partir d′une version de projet de solution peuvent être ajoutés à une solution mixte, à condition d′avoir utilisé le même préfixe d′éditeur de solutions.

  5. Exporter une solution unique en tant que solution gérée : la solution mixte unique peut ensuite être exportée comme gérée et importée dans les environnements en aval. Les composants de code et les autres composants de solution étant déployés dans la même solution, ils partagent tous la même solution et la même stratégie de contrôle de version.

  6. Exporter la solution segmentée de composants de code comme gérée : si vous utilisez l’approche à solution segmentée, vous pouvez exporter votre projet de solution de composants de code comme géré dans les environnements en aval.

  7. Générer une solution segmentée de composants de code comme gérée : si vous utilisez des solutions segmentées et n’avez pas besoin d’une solution non gérée, vous pouvez créer le projet de solution directement en tant que solution gérée en utilisant msbuild /p:configuration=Release. Il peut ensuite être importé dans les environnements qui doivent créer une dépendance sur ses composants de code.

  8. Utiliser la solution de composants de code segmentée : après le déploiement des composants de code par une solution segmentée gérée, d’autres solutions peuvent être générées, en créant une dépendance sur la solution de composants de code. Les dépendances sur les composants du code sont répertoriées dans la section MissingDependencies de type 66. Pour plus d’informations, voir : Suivi de dépendance pour les composants de solution.

  9. Déployer la solution segmentée de composants de code avant les solutions qui l’utilisent : lors de l’importation des solutions qui créent des dépendances sur une solution de composants de code segmentée, la solution de composante de code doit être installée sur l’environnement cible avant son importation.

Plus d’informations : Conditionner et distribuer des extensions à l’aide de solutions.

Composants de code et pipelines de build automatisés

Outre la génération et le déploiement manuels des solutions de composants de code, vous pouvez également générer et mettre en package les composants de code en utilisant des pipelines de build automatisés.

Voici quelques avantages liés à l′utilisation des pipelines de build automatisés :

  • Rapidité : la suppression des tâches manuelles accélère les tâches de génération et de compression du composant pour une exécution plus fréquent, par exemple à chaque fois qu’un changement est enregistré.
  • Répétabilité : dès que la génération est automatisée, elle est exécutée de la même manière à chaque fois et ne dépend donc pas du membre de l’équipe qui la réalise.
  • Cohérence du contrôle des versions : si le pipeline de build définit automatiquement la version du composant de code et de la solution, vous pouvez être certain que lorsqu’une version est créée, elle prend en compte les versions antérieures de façon cohérente. Le suivi des fonctionnalités, des corrections de bogues et des déploiements s’en trouve facilité.
  • Gestion : tous les éléments nécessaires à la génération de la solution étant contenus dans le code source, vous pouvez toujours créer de nouvelles branches et environnements de développement en extrayant le code. Lorsque vous êtes prêt à déployer une mise à jour, les demandes d′extraction peuvent être fusionnées dans les branches en aval. Plus d’informations : Stratégie de branches et de fusion avec Microsoft Power Platform.

Comme expliqué ci-dessus, il existe deux approches en matière de gestion des solutions de composants de code : des projets de solution segmentée ou une solution mixte unique contenant d’autres artefacts comme les applications pilotées par modèle, les applications de canevas et les tables auxquelles les composants de code sont ajoutés.

Si vous utilisez le projet de solution de composants de code segmentée, vous pouvez générer le projet dans un pipeline Azure DevOps (en utilisant Microsoft Power Platform Build Tools) ou un Pipeline GitHub (en utilisant Actions GitHub pour Microsoft Power Platform). Chaque dossier de composant de code pcfproj est ajouté au contrôle de code source (à l’exclusion des dossiers generated, out et node_modules), un projet cdsproj est créé et chaque composant de code est référencé en utilisant pac solution add-reference avant l’ajout au contrôle de code source. Le pipeline effectue ensuite les opérations suivantes :

  1. Mettre à jour la version de la solution dans le fichier Solution.xml pour correspondre avec la version de votre build. La version de la solution est conservée dans l’attribut ImportExportXml/Version. Voir ci-dessous pour plus de détails sur les stratégies de contrôle de version.
  2. Mettre à jour la version du composant de code dans le fichier ControlManifest.Input.xml. La version est stockée dans l’attribut manifest/control/version. Cette opération doit être faite pour tous les projets pcfproj générés.
  3. Exécuter une tâche MSBuild avec l’argument /restore /p:configuration=Release en utilisant un caractère générique *.cdsproj. Cette opération permet de générer tous les projets cdsproj et leurs projets pcfproj référencés.
  4. Collecter le zip de la solution de version dans les artefacts de mise en production du pipeline. Cette solution contient tous les composants de code inclus comme références dans le projet cdsproj.

Si vous utilisez une solution mixte qui contient d′autres composants en plus des composants de code, elle doit être extraite dans le contrôle de code source en utilisant SolutionPackager, comme expliqué ci-dessus. Votre pipeline effectue ensuite les opérations suivantes :

  1. Mettre à jour les versions des composants de code et de solution, comme expliqué aux étapes 1 et 2 ci-dessus.
  2. Installer Microsoft Power Platform Build Tools dans le pipeline de build en utilisant la tâche PowerPlatformToolInstaller.
  3. Restaurer node_modules en utilisant une tâche Npm avec la commande ci.
  4. Générer des composants de code en mode mise en production en utilisant une tâche Npm avec un paramètre customCommand de run build -- --buildMode release.
  5. Copier la sortie de la version dans le dossier du packager de solution pour le contrôle correspondant.
  6. Compresser la solution en utilisant la tâche PowerPlatformPackSolution de Power Platform Build Tools.
  7. Collecter le zip de la solution de version dans les artefacts de mise en production du pipeline.

Il est conseiller de valider les métadonnées de la solution décompressée dans le contrôle de code source sous sa forme non gérée pour permettre plus tard la création d′un environnement de développement. (Si seules les métadonnées de la solution gérée sont validées, il est difficile de créer des environnements de développement.) Deux options s′offrent à vous :

  1. Valider à la fois la solution gérée et non gérée à l’aide de l’option /packagetype:Both du packager de solution. Cela permet de compresser en mode géré ou non géré, mais présente l′inconvénient d′une duplication dans le code source, de sorte que les modifications apparaissent souvent dans plusieurs fichiers XML : à la fois dans la version gérée et non gérée.
  2. Validez uniquement le contrôle de code source non géré (ce qui entraîne des ensembles de modifications plus propres), puis, dans le pipeline de build, importez la solution compressée dans un environnement de version pour pouvoir l’exporter comme gérée et la convertir en un artefact de déploiement géré.

Contrôle des versions et déploiement des mises à jour

Lors du déploiement et de la mise à jour des composants de code, il est important d′avoir une stratégie de contrôle de version cohérente pour vous permettre de :

  • Suivre la version déployée par rapport aux fonctionnalités/correctifs qu’elle contient.
  • Garantir que les applications de canevas soient mises à jour vers la dernière version.
  • Garantir que les applications pilotées par modèle invalident leur cache et chargent la nouvelle version.

Une stratégie de contrôle des versions courante est la version sémantique dont le format est le suivant : MAJOR.MINOR.PATCH.

Incrémentation de la version PATCH

ControlManifest.Input.xml stocke la version du composant de code dans l’élément de contrôle :

<control namespace="..." constructor="..." version="1.0.0" display-name-key="..." description-key="..." control-type="...">

Lors du déploiement d′une mise à jour sur un composant de code, la version présente dans ControlManifest.Input.xml doit au minimum avoir sa version PATCH (la dernière partie de la version) incrémentée pour que le changement soit détecté. Cela peut se faire manuellement en modifiant directement l’attribut de version ou en utilisant la commande suivante pour avancer la version PATCH d’une unité :

pac pcf version --strategy manifest

Sinon, pour spécifier une valeur exacte pour la partie PATCH (par exemple, dans le cadre d’un pipeline de build automatisé), utilisez :

pac pcf version --patchversion <PATCH VERSION>

Plus d’informations : version pac pcf.

Quand incrémenter la version MAJEURE et MINEURE ?

Il est conseiller de synchroniser les versions MAJEURE et MINEURE de la version du composant de code avec la solution Dataverse de distribution. Par exemple :

  1. La version du composant de code déployé est 1.0.0 et la version de votre solution est 1.0.0.0.
  2. Faites une petite mise à jour du composant de code et incrémentez la version PATCH du composant de code sur 1.0.1 en utilisant pac pcf version --strategy manifest.
  3. Lors de la compression du composant de code pour le déploiement, la version de la solution dans Solution.xml est mise à jour vers la version 1.0.0.1, ou la version est incrémentée automatiquement en exportant manuellement la solution.
  4. Vous apportez des modifications importantes à votre solution et souhaitez incrémenter les versions MAJEURE et MINEURE sur 1.1.0.0.
  5. Dans ce cas, la version du composant de code peut également être mise à jour vers la version 1.1.0.

Une solution Dataverse a 4 parties et on peut imaginer la structure suivante : MAJOR.MINOR.BUILD.REVISION.

Si vous utilisez AzureDevOps, vous pouvez définir le contrôle de version du pipeline de build à l’aide des variables d’environnement Build et Rev (numéro d’exécution (version) – Azure Pipelines), et utiliser un script PowerShell similaire à l’approche décrite dans l’article Utiliser des scripts PowerShell pour personnaliser les pipelines.

Partie de la version sémantique Partie de la version ControlManifest.Input.xml
MAJOR.MINOR.PATCH		 Partie de la version Solution.xml
MAJOR.MINOR.BUILD.REVISION		 Version de build AzureDevOps
MAJEUR MAJEUR MAJEUR Définir en utilisant la variable de pipeline $(majorVersion) ou utiliser la dernière valeur validée pour le contrôle de code source.
MINEUR MINEUR MINEUR Définir en utilisant la variable de pipeline $(minorVersion) ou utiliser la dernière valeur validée pour le contrôle de code source.
--- --- BUILD $(Build.BuildId)
PATCH PATCH RÉVISION $(Rev:r)

Considérations relatives à l’ALM des applications canevas

Les composants de code sont utilisés différemment dans les applications canevas que dans les applications pilotées par modèle. Les composants de code doivent être explicitement ajoutés à l’application en sélectionnant Obtenir plus de composants dans le volet Insérer. Une fois le composant de code ajouté à l′application canevas, il est inclus en tant que contenu dans la définition de l′application. Pour mettre à jour vers une nouvelle version du composant de code après son déploiement (et la version de contrôle incrémentée), le créateur d′applications doit d′abord ouvrir l′application dans Power Apps Studio et sélectionner Mettre à jour lorsqu′il y est invité dans la boîte de dialogue Mettre à jour des composants du code. L′application doit ensuite être enregistrée et publiée pour que la nouvelle version soit utilisée lorsque l′application est utilisée.

Mettre à jour des composants de code.

Si l′application n′est pas mise à jour ou si l′option Ignorer est sélectionnée, l′application continue d′utiliser l′ancienne version du composant de code même si elle n′existe pas dans l′environnement car elle a été écrasée par la nouvelle version.

Étant donné que l′application contient une copie du composant de code, il est donc possible d′avoir différentes versions des composants de code s′exécutant côte à côte dans un environnement unique à partir de différentes applications canevas. Cependant, vous ne pouvez pas avoir différentes versions d′un composant de code qui s′exécutent côte à côte dans la même application. On encourage les créateurs d′applications à mettre à jour leurs applications vers la dernière version des composants de code lorsqu′une nouvelle version est déployée.

Notes

Même si, à ce stade, vous pouvez importer une application canevas sans déployer le composant de code correspondant dans cet environnement, il est conseillé de toujours vérifier que les applications sont mises à jour vers la dernière version des composants de code et que la même version soit déployée sur cet environnement en premier ou dans le cadre de la même solution.

Gestion du cycle de vie des applications (ALM) avec Microsoft Power Platform
Référence d’API Power Apps component framework
Création de votre premier composant
Déboguer des composants de code

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).