|
|
|
|
|
|
|
|
|
|
- Présentation
- Comment le faire ?
- Définir une politique de réintégration
- Fonctionnement de la politique de réintégration
- Stockage et manipulations de la politique de réintégration
- Les différentes règles en détail
- Onglet "Général"
- Onglet "Tests automatiques"
- Onglet "Métrique de code"
- Onglet "Plan d'action"
GDS : Politique de réintégration
Le GDS offre la possibilité de définir une politique de réintégration. Il suffit de définir les critères à remplir pour qu'un élément du projet puisse être réintégré dans la base de sources du GDS. Parmi les critères possibles : - Pas d'erreur de compilation,
- Lancement au moins d'un test de l'élément, etc.
Ces règles peuvent être obligatoires ou non. En cas de non respect, le développeur peut être tenu de fournir une explication. Définir une politique de réintégration Pour définir une politique de réintégration : - Sous le volet "GDS", dans le groupe "Base GDS", déroulez "Gérer" et sélectionnez "Politique de réintégration".
- Sélectionnez les règles à respecter par les éléments réintégrés. Ces règles sont regroupées par thème sur plusieurs onglets : "Général", "Tests automatiques", "Métrique de code" et "Plan d'action".
- Indiquez les options générales de la politique de réintégration (ces options sont affichées quel que soit l'onglet sélectionné) :
- Toujours ignorer les règles sur le projet (wdp) : Permet de ne pas prendre en compte les règles lors de la manipulation du fichier du projet (fichier wdp).
- Possibilité d'ignorer les règles.
- Saisie obligatoire d'un commentaire en cas de règle non respectée.
- Validez. La politique de réintégration est automatiquement prise en compte pour le projet en cours.
Remarque : Il est également possible de définir la politique de réintégration depuis l'administrateur du GDS (option "Politique de réintégration" du menu contextuel d'un projet). Fonctionnement de la politique de réintégration Si l'élément réintégré ne respecte pas la politique de réintégration définie pour le projet : - en cas d'obligation de saisie d'un commentaire, un toast est affiché.
- en cas de non respect d'une des autres règles, la fenêtre suivante apparaît : Cette fenêtre présente les différentes règles non respectées.
Si l'utilisateur a la possibilité d'ignorer les règles, il peut cocher l'option "Réintégrer quand même". Si un commentaire explicatif doit être saisi pour ignorer les règles, le bouton de validation de cette fenêtre sera dégrisé uniquement lorsque le commentaire sera saisi dans la zone correspondante. Le bouton "Editer la politique..." permet d'éditer et de modifier si nécessaire les règles de la politique de réintégration. Stockage et manipulations de la politique de réintégration La politique de réintégration est stockée dans un fichier "PolitiqueDeReintegration.gds" à la racine du répertoire du projet. Ce fichier est présent dans le GDS comme tous les fichiers du projet. Ce fichier est partageable entre plusieurs projets. Il est possible d'attribuer des droits spécifiques au fichier correspondant à la politique de réintégration (par exemple pour que seul le chef de projet puisse modifier ce fichier). Si le fichier "PolitiqueDeReintegration.gds" est présent dans le répertoire parent, tous les nouveaux projets créés utiliseront cette politique de réintégration. Astuce : Dans le cas d'une branche, il est possible de définir une politique de réintégration plus restrictive. Les différentes règles en détail Onglet "Général" Les différentes règles de réintégration proposées par l'onglet "Général" sont les suivantes : - Aucune erreur de compilation : Pour être réintégré, l'élément ne doit comporter aucune erreur de compilation.
- Aucun warning de compilation : Pour être réintégré, l'élément ne doit comporter aucun warning de compilation.
- Aucune information de compilation : Pour être réintégré, l'élément ne doit comporter aucune information de compilation.
- Aucune erreur de norme de programmation : Pour être réintégré, l'élément ne doit comporter aucune erreur de norme de programmation. Cette norme de programmation est définie dans l'onglet "Compilation" de la fenêtre de description du projet. Pour plus de détails, consultez Description du projet : Onglet Compilation.
- L'élément réintégré doit être associé à une tâche ou un incident : Cette option permet de lier l'élément réintégré à une tâche ou un incident présent dans le Centre de Gestion de Projets.
- Un commentaire doit être saisi lors de la réintégration.
- Le projet doit avoir été testé (GO) au moins une fois après une modification : Permet d'obliger le développeur à tester sa modification.
- Toujours ignorer les règles sur le projet (wdp) : Permet de ne pas prendre en compte les règles lors de la manipulation du fichier du projet (fichier wdp).
- Ces règles peuvent être ignorées : Permet à l'utilisateur d'ignorer les règles de réintégration (par exemple dans certains cas spécifiques). Dans ce cas, l'option "Un commentaire doit être saisi pour ignorer les règles" permet de rendre obligatoire la saisie d'un commentaire en cas de règle non respectée.
Onglet "Tests automatiques" Les différentes règles de réintégration proposées par l'onglet "Tests automatiques" sont les suivantes : - Chaque élément doit avoir au moins 1 test automatique.
Attention : si cette règle est sélectionnée, elle s'applique à tous les éléments, même au fichier projet (".WDP"), qui contient notamment le code d'initialisation du projet. - Aucun test automatique en erreur.
Onglet "Métrique de code" L'onglet "Métrique de code" permet de saisir le taux de pourcentage de commentaires de code minimal à respecter. Onglet "Plan d'action" L'onglet "Plan d'action" permet de définir le plan d'action à exécuter lors de la réintégration du projet. Si un plan d'action doit être exécuté, il est nécessaire d'indiquer : - le coordinateur de la fabrique logicielle utilisée,
- le port du coordinateur,
- l'utilisateur et le mot de passe associé.
Le plan peut être choisi parmi les plans existants sur le coordinateur.
Documentation également disponible pour…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|