Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Améliorez votre plug-in en utilisant des preuves de suivi et des évaluations pour trouver ce qui doit changer. Appliquez le correctif ou l’amélioration, publiez le package exact que vous avez testé et confirmez que le plug-in mis à jour continue de fonctionner pour les utilisateurs prévus.
Les constructeurs entretiennent et testent l’ensemble. Les administrateurs Microsoft 365 exécutent des actions de déploiement organisationnel si nécessaire. Les propriétaires de services gèrent les connecteurs, les serveurs MCP distants, les identités et les services externes utilisés par le plug-in.
Avant de commencer
Avoir :
- L’identité actuelle du plug-in et la version du package.
- Comment la version actuelle parvient aux utilisateurs : partage direct, téléchargement administrateur ou Microsoft Marketplace.
- Preuves de suivi, commentaires des utilisateurs, cas de support ou amélioration prévue.
- Tâches représentatives et critères d’acceptation.
- Les utilisateurs affectés et les expériences Microsoft 365.
- Accès à la source du plug-in et fonctionnalités affectées.
- Propriétaires pour les connexions et services externes requis.
Si vous ne savez pas encore ce qui doit changer, commencez par surveiller votre plug-in.
Établir un planning de référence
- Indiquez le problème ou l’amélioration que vous souhaitez résoudre.
- Identifiez la version du package, les utilisateurs, les expériences, les fonctionnalités et les dépendances affectés.
- Définir des tâches représentatives et des critères d’acceptation mesurables.
- Exécutez les tâches sur le package actuel et enregistrez les résultats.
- Si votre organisation administre le plug-in, enregistrez son état actuel, sa disponibilité utilisateur et son état d’installation dansles plug-insoutils>> agents.
- Préservez les preuves dont vous avez besoin pour comparer le comportement actuel et le comportement mis à jour.
Pour un plug-in qui inclut un agent, utilisez la vue d’ensemble de l’évaluation de l’agent pour concevoir une évaluation lorsque la qualité de la réponse, les instructions, les connaissances ou l’utilisation de l’outil fait partie de la modification. L’évaluation peut fournir des preuves avant la publication et aider à examiner les problèmes de qualité après le déploiement, y compris ceux soulevés par les signaux d’utilisation, les commentaires des utilisateurs ou les modifications d’agent et de dépendance.
L’évaluation de l’agent n’est pas requise pour chaque plug-in. Il ne remplace pas les tests de capacité, la validation de package ou le test de l’expérience utilisateur complète.
Pour les agents déclaratifs déployés, utilisez le workflow guidéwiqd agent eval. Pour un contrôle direct de ligne de commande ou de pipeline, consultez la vue d’ensemble de CLI des évaluations d’agent.
Appliquer et tester la modification
- Mettez à jour la source du plug-in ou la fonctionnalité affectée.
- Mettre à jour les services ou la configuration gérés séparément lorsque le changement l’exige.
- Testez chaque capacité modifiée et dépendance affectée.
- Réexécutez les tâches de référence et les évaluations.
- Comparez les résultats avec les critères d’acceptation.
- Recherchez les régressions avant de créer le package de publication.
Lorsque la modification affecte un connecteur, un serveur MCP distant, une identité, une autorisation ou un service externe, impliquez le propriétaire de cette dépendance. Ne présumez pas que le changement de package met à jour un service géré séparément.
Créer et valider le package
- Affectez une nouvelle version de package et case activée les exigences d’identité pour votre méthode de publication.
- Créez le package de plug-in.
- Validez et testez le package exact que vous avez l’intention de publier.
- Testez la connexion, le consentement, les connexions et les services externes requis.
- Testez le package pour chaque expérience Microsoft 365 que vous souhaitez prendre en charge.
- Enregistrez les limitations connues, la configuration requise et l’option de restauration ou de remplacement disponible.
Ne publiez pas un package qui diffère du package que vous avez validé.
Publier et déployer la mise à jour
Choisissez une méthode de publication ou de partage prise en charge pour le package mis à jour et le public prévu. Vérifiez ses instructions sur la façon de mettre à jour un plugin existant ; Ne présumez pas que le partage ou le chargement d’une nouvelle version remplace son entrée de Registre ou conserve les paramètres de disponibilité.
| Comment la version actuelle a atteint les utilisateurs | Par où commencer avec la mise à jour | Qui agit |
|---|---|---|
| Partage direct | Suivez les instructions de partage du même outil pour le package testé et le public prévu. | Propriétaire du plug-in |
| Chargement administrateur | Donnez le package testé à l’administrateur, qui suit Télécharger les plug-ins ou les compétences et vérifie l’entrée de registre résultante et la portée de l’utilisateur. | Propriétaire et administrateur du plug-in |
| Place de marché Microsoft | Vérifiez le type d’offre pris en charge et suivez la procédure de l’Espace partenaires applicable liée à Publier votre plug-in via la Place de marché Microsoft. Attendez la révision et la publication nécessaires avant de diriger les clients vers la mise à jour. | Éditeur et administrateur client, le cas échéant |
Avant la publication, vérifiez si la méthode réutilise l’identité du package ou crée une entrée distincte, si les paramètres de disponibilité et d’installation de l’utilisateur précédent sont conservés et comment remplacer ou restaurer une version si nécessaire. Si une deuxième entrée apparaît, vérifiez que les utilisateurs prévus sont passés à la nouvelle version avant de restreindre l’ancienne. Ne supprimez pas une entrée encore utilisée.
Ensuite :
- Publiez, téléchargez ou partagez le package testé exact par la méthode sélectionnée et enregistrez s’il a été envoyé, publié, partagé, rejeté ou bloqué.
- Indiquez à l’administrateur ou au propriétaire du déploiement la version exacte du package, les utilisateurs prévus, la configuration requise, les limitations connues et le contact de support technique.
- Effectuez uniquement les étapes applicables pour rendre disponible le plug-in mis à jour. Les exigences d’approbation, d’affectation et d’installation dépendent de la méthode et des paramètres de l’organisation.
- Mettez à jour les agents, les connexions, les identités, les serveurs MCP distants ou les services externes contrôlés séparément, si nécessaire.
- Confirmez quelle version du package a atteint chaque audience.
Pour un plug-in alpha Work IQ Dev Tools, wiqd plugin share est publié dans le registre de plug-ins pour le public sélectionné. La soumission au magasin public se produit séparément dans l’Espace partenaires. Suivez le guide du plug-in Work IQ Dev Tools pour sa configuration, son package, sa validation et sa séquence de partage lors de la préparation d’une autre version.
Avant le lancement, confirmez si la méthode prend en charge la restauration d’une version précédente. Le remplacement du package ne restaure pas automatiquement un changement de service, de connexion, d’identité, de données ou d’autorisation externe.
Vérification de la mise à jour
- Testez les tâches représentatives avec un utilisateur prévu dans chaque expérience prise en charge.
- Vérifiez que l’utilisateur a reçu la version attendue du package.
- Vérifiez que la connexion, le consentement, les connexions, les appels d’outils et les services externes fonctionnent.
- L’emplacement où le plug-in est administré dans votre organization, case activée que son status, sa disponibilité utilisateur et son état d’installation correspondent à l’audience prévue dansles plug-insoutils>> agents. Vérifiez si une version remplacée est encore utilisée.
- Répéter les évaluations utilisées pour approuver la modification.
- Examinez les signaux d’utilisation, les commentaires, les erreurs et les cas de support après le déploiement.
- Si la mise à jour ne répond pas à ses critères d’acceptation, suivez la procédure de restauration ou de remplacement prise en charge et restaurez les dépendances affectées si nécessaire.
La mise à jour est terminée lorsque le public concerné dispose de la bonne version de package, que ses paramètres d’accès correspondent au déploiement prévu, que les tâches représentatives répondent aux critères d’acceptation et que chaque problème non résolu a un propriétaire et une action suivante.
Enregistrer la mise à jour
Enregistrement :
- Versions de package précédentes et mises à jour.
- Changement, raison, fonctionnalités affectées et dépendances.
- Résultats de référence, d’évaluation, de validation et de test utilisateur.
- Méthode de publication, audience, status de déploiement et état du Registre applicable.
- Modifications de configuration ou de service.
- Limitations connues, option de restauration et propriétaire du support.