Configuration de Modern Requirements4DevOps à l’aide de l’onglet Agent/Services MR
Dans cet article, nous expliquons comment configurer l’onglet Agent / Services MR dans MR4DevOps. L’onglet Services offre actuellement aux utilisateurs 3 fonctionnalités supplémentaires à tout projet utilisant Azure DevOps Service (anciennement VSTS).
Utilisation de l’onglet Services pour configurer
Exigences modernes4DevOps
MR Services (anciennement appelé MR Agent) est l’un des composants de Modern Requirements4DevOps qui est automatiquement installé avec l’application principale. C’est un cadre qui offre de l’extensibilité à Azure DevOps en utilisant des déclencheurs.
IMPORTANT :
Veuillez noter que les services MR ne sont accessibles qu’avec les services AZURE DEVOPS utilisant une IP LIVE/publique pour communiquer avec VSTS (Azure DevOps services). Si une machine n’a pas d’accès public, les services VSTS Azure DevOps ne pourraient pas être utilisés (car ils nécessitent un accès public pour communiquer avec la machine). Il est conseillé aux utilisateurs de contacter leurs administrateurs réseau pour modifier la valeur de l’adresse IP active de leurs machines, y compris le port concerné.
Actuellement, les Services MR (Agent MR) comportent les trois sous-composantes suivantes :
- ID personnalisé
- Drapeau Sale
- Moniteur de courriels
Une authentification utilisateur appropriée est requise avant la configuration de ces composants. Les fichiers de configuration de n’importe quel composant ne fonctionneront que si l’organisation pertinente (dans Azure DevOps) ou la collection (dans TFS) est enregistrée via authentification.
Authentification des utilisateurs des services MR
- Lance la version intégrée de l’application et sélectionne le Exigences modernes4DevOps option sous la onglet Paramètres.
Le panneau d’administration s’affiche.
- Cliquez sur le Onglet Services.
Les options pour l’onglet Services sont affichées.
L’onglet Paramètres propose deux options :
- Définir un intervalle de temps pour scanner l’organisation Azure DevOps (ou la collection TFS) pour les nouveaux projets
- Enregistrement de l’organisation actuelle (des identifiants administrateur sont requis pour cette option)
Note : Entrez les valeurs pour ces deux réglages en une seule fois. Les utilisateurs ne peuvent pas choisir de configurer un paramètre tout en laissant l’autre en attente.
Entrez l’intervalle de temps pour le balayage automatique (devrait être entre 1 et 60).
Cette valeur détermine l’intervalle en minutes après lequel l’organisation Azure DevOps enregistrée sera analysée pour les nouveaux projets.
- Fournissez des identifiants de connexion autorisés. (avec les droits d’administrateur TFS).
Après l’authentification réussie, l’organisation actuelle est enregistrée et un message de confirmation s’affiche.
Identifier manuellement un nouveau projet dans votre organisation Azure DevOps
La section ci-dessus expliquait le processus pour personnaliser le temps de balayage automatique pour l’organisation Azure DevOps. La valeur montrée dans l’image ci-dessus signifie que l’organisation serait scannée toutes les 30 minutes pour le nouveau projet.
Cependant, si l’utilisateur vient de créer un nouveau projet et veut travailler dessus immédiatement, il doit l’identifier manuellement (le projet) dans l’organisation Azure DevOps. Les étapes suivantes sont requises pour y parvenir :
- Voici la commande suivante sur CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin
- Une fois dans le répertoire bin, entrez la commande suivante : MONSIEUR
Le menu des options s’affiche.
- Type 4 et cliquez sur Entrée.
- Voici la valeur d’organisation Azure DevOps à analyser pour de nouveaux projets.
Si aucun message d’erreur n’est affiché, le processus a été réalisé avec succès pour analyser les nouveaux projets créés après l’enregistrement d’une organisation Azure DevOps ou l’application de sa configuration.
Configurez la fonction ID personnalisé
L’ID personnalisé est un composant des services MR (agent MR) utilisé pour fournir des identifiants personnalisés aux éléments de travail en plus de leurs identifiants de travail par défaut. Les identifiants personnalisés ne remplacent pas les identifiants d’origine, ils les complètent plutôt. Les identifiants personnalisés peuvent être utilisés pour suivre l’origine de l’élément de travail (c’est-à-dire quelle équipe a créé un élément de travail particulier).
Pour que l’ID personnalisé fonctionne correctement, les utilisateurs doivent créer manuellement les deux éléments suivants :
- Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel l’ID personnalisé est requis).
- Un autre dossier porte le nom d’une organisation Azure DevOps ou de la collection TFS (sur laquelle l’ID personnalisé est requis) sous le nom du dossier Azure DevOps (TFS).
Le dossier d’organisation pertinent devrait aussi inclure le config.xml contenant toutes les configurations. La hiérarchie des fichiers et des dossiers devrait apparaître telle qu’affichée ci-dessous, en utilisant le motif de texte et l’image pertinente :
Comme décrit dans l’image ci-dessus, un échantillon Config.xml le fichier est placé dans le CustomId Dossier.
- Créez un dossier nommé d’après le nom du serveur Azure DevOps (sur quel composant doit s’appliquer) à cet endroit.
- Entrez dans le dossier nouvellement créé et créez à nouveau un autre dossier ici avec le nom de l’organisation Azure DevOps (sur quel composant doit s’appliquer).
- Copiez le XML (mentionné plus tôt) dans le nouveau dossier créé, c’est-à-dire Dossier avec le nom d’organisation Azure DevOps.
Ce fichier contient le plan pour la configuration désirée.
Configuration du fichier XML Custom ID
- Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
- Définir la valeur de la IDScope Étiquette selon les exigences, par exemple :
– Collection -> appliquer un champ de contre-champ au niveau de la collection.
– Projet -> appliquer la portée contraire au niveau du projet.
– Équipe -> appliquer un contre-scope au niveau équipe. - La balise « FieldReferenceName » avec la valeur « Overrie » « Oui » signifie que le champ défini par l’utilisateur (entre les étiquettes) sera considéré pour l’ID personnalisé. La valeur « Overrie » « Non » signifie que le champ par défaut « MR. CID » sera pris en compte et demandé pour l’ID personnalisé. Cela signifie que les utilisateurs doivent définir ce champ dans leur modèle TFS avec le même nom de référence, c’est-à-dire MR. CID.
- La balise « CollectionUrl » nécessite l’URL de la collection TFS sur laquelle l’ID personnalisé doit s’appliquer. (Note : Veuillez vous assurer que l’URL ne doit pas se terminer par '\')
- “Projects DefaultNoOfChar” tag denotes the number of characters to pick up from the project name, if the project name is not defined in the tag<Project Name= “ ”>. By default its value is 5. Update the value if desired.
- Fournir le nom du projet TFS (par exemple Nom du projet = = GITNew ») et son nom personnalisé (par exemple préfixe = « GTN ») pour être utilisés dans des identifiants personnalisés.
- “Séquence ID="1 »« La valeur de l’ID de l’étiquette indique le nombre de groupes différents d’ID personnalisés créés dans le fichier de configuration et sert à identifier et différencier de l’ID. Ce sera toujours un champ uniquement numérique et devrait rester unique. La balise Séquence consiste en une combinaison du type d’Élément de travail, de la mise en forme requise sur le champ ID et du compteur pour commencer.
- La valeur « WIType » nécessite le type d’élément de travail sur lequel l’ID personnalisé est requis pour s’appliquer. De plus, si nécessaire, plusieurs éléments de travail pourraient être définis pour que la même configuration s’applique en groupe.
- L’étiquette « FieldFormat » est utilisée pour définir la mise en forme de l’ID requise sur l’ID personnalisé.
Exemple : [PN] Req #####[PN] est utilisé comme substitut pour le préfixe défini ci-dessus du nom du projet.
Pour une référence au format numérique, veuillez consulter le lien suivant :
https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings - L’étiquette « FieldCounter » est requise pour définir le numéro ou la série d’où le compteur d’ID personnalisé doit commencer. Une fois la valeur du compteur appliquée (le fichier de configuration est appliqué), elle ne peut en aucun cas être modifiée.
- Après avoir complété avec succès le fichier de configuration, sauvegardez et fermez le fichier.
Application d’un identifiant personnalisé sur des éléments de travail existants
- Entrez la commande suivante sur CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin
- Une fois dans le répertoire bin, entrez la commande suivante : MONSIEUR
Le menu des options s’affiche.
- Type 1 et cliquez sur Entrée.
- Entrez la valeur URL d’organisation Azure DevOps (ou TFS Collection).
Si aucun message d’erreur n’est affiché, l’ID personnalisé a été appliqué avec succès sur les éléments de collection existants.
Configurez la fonction Dirty Flag
Dirty Flag est un composant des services MR (agent MR) utilisé pour marquer certains éléments de travail comme inactifs (en raison d’exigences modifiées) afin que les parties prenantes concernées puissent examiner ces éléments une seule fois au lieu de poursuivre avec les exigences obsolètes.
Pour que le Dirty Flag fonctionne correctement, les utilisateurs doivent créer manuellement les deux éléments suivants :
- Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le Dirty Flag doit s’appliquer).
- Un autre dossier nommé d’après l’organisation Azure DevOps ou la collection TFS (sur laquelle le drapeau Dirty est requis) sous le nom du dossier Azure DevOps (TFS).
Le dossier pertinent de la collection devrait également inclure le config.xml contenant toutes les configurations. La hiérarchie des fichiers et des dossiers devrait apparaître telle qu’affichée ci-dessous, en utilisant le motif de texte et l’image pertinente :
Comme décrit dans l’image ci-dessus, un échantillon Config.xml le fichier est placé dans le Drapeau Sale Dossier.
- Créez un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit s’appliquer) à cet endroit.
- Entrez dans le dossier nouvellement créé et créez à nouveau un autre dossier ici avec le nom de l’organisation Azure DevOps (ou de la collection TFS) (sur quel composant doit s’appliquer).
- Copiez le XML (mentionné plus tôt) dans le nouveau dossier créé, c’est-à-dire Dossier avec le nom d’organisation Azure DevOps (ou collection TFS).
Ce fichier contient le plan pour la configuration désirée.
Configuration du fichier XML Dirty Flag
- Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
- Définir la valeur de l’URL de la collection à l’aide de la CollectionURL
Chaque balise Action possède une Source partie et a Cible partie. La partie Source indique aux Services MR (Agent MR) quoi surveiller pour déclencher le Signal Rouge; la partie Cible indique aux Services MR (Agent MR) quels types d’éléments seront étiquetés comme sales en cas de déclenchement.
- Dans la section Source, l’étiquette « WIType » indique le type d’éléments de travail avec lesquels le Dirty Flag fonctionnera. Plusieurs types d’éléments de travail pouvaient être utilisés avec une virgule « , » comme séparateur.
- La balise « FieldReferenceName » indique le(s) champ(s) de l’élément de travail (la liste est fournie dans l’étiquette WIType ) qui seront cochés.
- Le "FieldValue" indique la valeur exacte de la FieldReferenceName ça déclenchera le Dirty Flag.
Si plusieurs champs sont cochés, le Dirty Flag ne sera déclenché que lorsque toutes les valeurs de champ sont correspondantes, c’est-à-dire en utilisant la logique AND.
- Le « WIType » de la section cible indique le type d’éléments de travail qui seront marqués comme sales si la condition de la section source est remplie.
- Sauvegardez et fermez le fichier de configuration après son achèvement réussi.
Mise en place de la fonction Surveillance des courriels
Email Monitor est un composant des services MR (MR Agent) utilisé pour créer automatiquement des éléments de travail à partir des courriels. Une adresse courriel particulière est configurée à cette fin et, une fois le processus de configuration complété avec succès, tous les courriels envoyés à cette adresse courriel entraînent la création ou la mise à jour des éléments de travail. Le processus comprend les étapes suivantes* :
- Configuration du fichier de configuration du moniteur courriel (placé à un endroit précis)
- Saisie et vérification des paramètres de courriel
Chacune de ces étapes est détaillée ci-dessous.
*Pour les serveurs Azure DevOps (TFS) locaux, MR Services (MR Agent) ajoute automatiquement l’emplacement pertinent dans le fichier de paramètres d’application (AppSettings.config). Cependant, si des services Azure DevOps sont impliqués, la machine de l’utilisateur devrait avoir une adresse IP active que les services Azure DevOps peuvent utiliser pour accéder ou communiquer. Cette adresse IP devrait être ajoutée dans le fichier de configuration AppSettings. Le processus pour le réaliser est expliqué en étapes suivantes :
- Allez dans le dossier d’installation de MR Services (MR Agent) (surligné dans l’image) et ouvrez le Paramètres de l’application fichier de configuration dans un éditeur de texte.
Le ApplicationURL est automatiquement réglé vers la machine locale.
Changez la valeur (pour les services Azure DevOps seulement) pour l’adresse IP active de votre machine, y compris le port concerné.
*Contactez votre administrateur réseau pour obtenir l’adresse IP en temps réel et les informations sur les ports- Sauvegardez et fermez le fichier de configuration.
Configurations de synchronisation dans le fichier APPSETTING
Au bas du fichier de configuration AppSettings, trois configurations de timing sont disponibles pour les utilisateurs.
AbonnementCalendrier
- Fonctionne pour toutes les composantes des services MR
- Utilisé pour vérifier les nouveaux projets/collections
- La valeur par défaut « 30 »* représente le nombre de minutes, après quoi les services MR (agent MR) scannent les nouveaux projets. Les utilisateurs peuvent configurer la valeur (en minutes) selon leurs besoins.
*Cette valeur peut aussi être configurée à l’aide du Panneau d’administration.
ApplyAllSchedule
- Fonctionne seulement pour l’ID personnalisé
- Utilisé pour appliquer un identifiant personnalisé sur les éléments de travail nouvellement créés
- La valeur par défaut « 30 » représente le nombre de minutes, après quoi les services MR (agent MR) scannent les nouveaux éléments de travail et y appliquent des identifiants personnalisés. Les utilisateurs peuvent configurer la valeur (en minutes) selon leurs besoins.
EmailCheckSchedule
- Fonctionne seulement pour Email Monitor
- Ça servait à vérifier si un nouveau courriel était arrivé d’où les éléments de travail pouvaient être créés ou mis à jour
- La valeur par défaut « 15 » représente le nombre de minutes, après quoi les services MR (agent MR) scannent les courriels. Les utilisateurs peuvent configurer la valeur (en minutes) selon leurs besoins.
Configuration du moniteur de courriel
Pour que l’Email Monitor fonctionne correctement, les utilisateurs doivent créer manuellement les éléments suivants :
- Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (auquel le moniteur de courriel doit s’appliquer).
Le dossier serveur concerné devrait aussi inclure le fichier config.xml contenant toutes les configurations. La hiérarchie des fichiers et des dossiers devrait apparaître comme indiqué ci-dessous à l’aide du motif de texte et de l’image pertinente :
* Note : pour les versions actuelles d’Email Monitor, la hiérarchie s’arrête au dossier serveur, et place le fichier dans ce dossier serveur. Cependant, pour les versions futures, la hiérarchie remonterait jusqu’au dossier de l’organisation (comme pour d’autres composants des services MR (MR Agent)). Veuillez consulter votre administrateur ou contacter les Exigences modernes si toute incertitude persiste à ce sujet.
Comme décrit dans l’image ci-dessus, un fichier Config.xml exemple est placé dans le dossier EmailMonitor .
- Créez un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit s’appliquer) à cet endroit.
- Entrez dans le dossier nouvellement créé et copiez le XML (mentionné plus tôt) dans ce dossier, c’est-à-dire Dossier avec le nom du serveur Azure DevOps (TFS).
- Ce fichier contient le plan pour la configuration désirée.
Configuration du fichier XML du moniteur de courriel
- Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
- Définir la valeur de la ServerURL Étiquette selon les exigences, par exemple :
- De même, on définit la valeur pour Collection Url (y compris le DefaultProject)
IMPORTANT
– Les valeurs pour les deux ServerURL et Collection Url doit correspondre à la structure de dossiers décrite précédemment.
– S’assurer que l’URL ne se termine pas par une barre oblique « / »
– L’utilisateur peut définir plusieurs URL de collection dans le fichier de configuration. - Fournir la valeur pour AdminEmail. Cette adresse courriel est utilisée comme atténuation, au cas où la fonctionnalité désirée ne pourrait pas être atteinte avec l’adresse définie dans Courriel tag (expliqué à l’étape suivante).
Note : Un seul courriel administrateur peut exister dans le fichier de configuration.
- “Courriel" est l’étiquette principale dans ce fichier qui définit où le courriel sera envoyé. Les courriels envoyés à cette adresse serviraient à créer les types de travaux désirés. Configurez la Courriel Étiquette au besoin
- Courriel: Fournir l’adresse courriel cible où le courriel doit être livré pour la création ou la mise à jour des éléments de travail. Si certains critères ne correspondent pas aux valeurs souhaitées, le courriel d’avertissement sera envoyé à la Courriel administratif défini ci-dessus.
Note : Plusieurs adresses courriel peuvent être définies dans le fichier de configuration.
- Type d’article de travail : Définissez le type d’élément de travail souhaité à créer. Dans l’exemple suivant CatégorieRéférence représente le type de catégorie interne des éléments de travail. Plusieurs valeurs dans cette étiquette signifient que le type de travail pertinent sera créé selon le modèle de projet d’équipe. Par exemple, si le projet d’équipe utilise le modèle CMMI, alors le courriel créerait un élément de travail d’exigence. De même, pour un projet axé sur Agile, une histoire utilisateur serait créée et pour un projet basé sur Scrum, un élément de backlog de projet serait créé.
- FieldReference="System.Title » : Indique quel serait le titre de l’objet à créer. L’exemple suivant montre que l’objet du courriel deviendrait le titre de l’élément de travail.
- OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
- OnUpdate=”false” signifie que pour les éléments de travail existants, le champ Titre ne serait pas mis à jour.
- FieldReference="System.Description »: Indiquer où placer l’information provenant des courriels entrants (c’est-à-dire dans quelle propriété/champ se trouve l’article). L’exemple suivant utilise le Description champ pour cette fin.
- OnCreate= ”true” means that for new Work Items, the content of the email (described next) would be used to populate the Description field of the work item.
- OnUpdate=”false” means that for existing Work Items, the Description field would not be overwritten. Instead the update would go to the comments/history section of the work item.
La partie ultérieure de ce champ indique la composition du champ de description. Les informations suivantes composeraient le champ Description :
- Sender Name shown inside <> e.g.
- Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
- Corps du courriel ajouté dans une nouvelle ligne
- La finale FieldReference="System.History » est utilisé pour les courriels de discussion qui arrivent après la création d’un élément de travail. Au lieu d’écraser le Description les informations courriel suivantes sont stockées dans le Commentaires Champ (appelé en interne Histoire). La composition de la Histoire Le champ est plus ou moins le même à partir de Description Domaine mentionné plus haut. Il est conseillé aux utilisateurs de conserver les paramètres originaux de cette balise.
- Après avoir complété avec succès le fichier de configuration, sauvegardez et fermez le fichier.
- Courriel: Fournir l’adresse courriel cible où le courriel doit être livré pour la création ou la mise à jour des éléments de travail. Si certains critères ne correspondent pas aux valeurs souhaitées, le courriel d’avertissement sera envoyé à la Courriel administratif défini ci-dessus.
Déploiement du moniteur de courriel
Le moniteur de courriel peut être déployé en configurant les paramètres pertinents sous le panneau d’administration. Ces paramètres peuvent être consultés via l’onglet Services.
La section Services du panneau d’administration comporte actuellement deux onglets : Décors & Moniteur de courriels
L’onglet Paramètres traite de 1) Authentification utilisateur/Enregistrement d’organisation 2) Numérisation de nouveaux projets.
Email Monitor gère toutes les options liées aux courriels discutées plus tôt dans la section ligne de commande.
Configuration des options du moniteur de courriel
- L’onglet Surveillance des courriels, dans la section Services, est utilisé pour configurer les paramètres du courriel.
- Les options sont accessibles en cliquant sur l’onglet Surveillance des courriels, comme illustré dans l’image suivante.
- Si l’utilisateur n’a pas enregistré son organisation (en fournissant les détails requis dans le sous-onglet Paramètres), alors en cliquant sur le sous-onglet Surveillance des courriels, l’utilisateur est renvoyé dans le sous-onglet Paramètres, à moins que l’information souhaitée ne soit saisie.
- Les paramètres du moniteur de courriel sont divisés en sections, chaque section servant à configurer un réglage particulier.
- Tous les réglages nécessaires sont configurés une seule fois. Les utilisateurs ne peuvent pas configurer certains paramètres et en laisser d’autres en attente.
- La première section sert à configurer le projet par défaut et l’adresse courriel d’administration.
- La deuxième section sert à configurer l’adresse courriel qui sera utilisée pour la surveillance des courriels.
Cliquer sur Adresse courriel d’inscription ouvrirait une fenêtre contextuelle où les paramètres réseau du courriel (par exemple SSL, POP3, IMAP, etc.) peuvent être configurés.
- La troisième section sert aux paramètres (qui serviront à) d’extraire le contenu de l’élément de travail à partir des courriels envoyés à l’adresse courriel enregistrée.
Cliquer sur le bouton Enregistrer les modifications après avoir configuré tous les réglages, le moniteur des courriels s’ouvrait.
