Si vous êtes un administrateur, vous pouvez utiliser les
capacités de contrôle de Rational Team Concert pour
vous assurer que les fichiers remontés sur le serveur ne sont pas
sources d'erreurs.
Pourquoi et quand exécuter cette tâche
Les contrôles suivants, correspondant à des préconditions,
peuvent être sélectionnés :
- Contrôles de redéfinition des Rubriques, des Méta Entités ou de
tous les artefacts de design (sauf les Structures de Données).
Ces
préconditions vérifient, selon la précondition sélectionnée, que les
Rubriques, les Méta Entités ou tous les artefacts de design (sauf
les Structures de Données) sur le point d'être distribués, et qui
ont été créés, ne sont pas des redéfinitions d'artefacts appartenant
à une même hiérarchie de projets. Ces contrôles ne s'appliquent pas
aux artefacts redéfinis et modifiés. Lors de la migration Pacbase, ces contrôles ne
sont pas actifs et ne s'appliquent pas aux instances redéfinies dans Pacbase et migrées.
- Contrôle de synchronisation du code source.
Cette précondition
vérifie que les fichiers COBOL sur le point d'être distribués sont
synchronisés avec tous les fichiers design ayant participé à leur
génération en local. Cette précondition s'applique uniquement aux
fichiers COBOL qui font partie de la distribution. De plus, si un
développeur ne distribue que des fichiers COBOL sans distribuer les
fichiers design associés, il provoque des erreurs dans le flux Rational Team Concert.
- Contrôle de références de design non résolues.
Cette précondition
vérifie que toutes les références des fichiers design sur le point
d'être distribués sont résolues.
Les références ne sont pas
résolues dans les cas suivants :
- Des modifications locales sont distributées partiellement. Les
références ne sont pas résolues, par exemple, si une nouvelle Rubrique
est appelée dans un nouveau Segment mais si seul le Segment est distribué.
- Une instance utilisée par d'autres instances est supprimée. Les
références ne sont pas résolues, par exemple, si une Rubrique appelée
dans un Segment est supprimée mais si seule cette suppression est
distribuée.
Cette précondition s'applique au contenu des ensembles
d'artefacts modifiés sur le point d'être distribués, et au contenu
indexé du serveur. Vous devez donc distribuer toutes les modifications
liées simultanément ou, à défaut, vous devez vous assurer que le contenu
du serveur ait été réindexé avant de distribuer la suite de vos modifications.
Remarque : Cette
précondition est un premier moyen de contrôler la résolution des références
entre les fichiers design. Cependant, pour détecter automatiquement
et globalement les références non résolues dans les ensembles d'artefacts
modifiés distribués, il est conseillé de mettre en place des générations
nocturnes sur le serveur Rational Team Concert. Vous
bénéficiez alors de tout l'outillage requis pour remonter dans l'historique
des modifications et corriger la cause d'une erreur.
- Contrôle qualité.
Cette précondition vérifie que les fichiers
COBOL et design sur le point d'être distribués ne contiennent pas
d'erreurs graves de contrôle qualité Rational Programming Patterns.
Procédure
- Depuis la vue Artefacts de l'équipe de
la perspective Eléments de travail de Rational Team Concert,
faites un clic droit sur la zone de projet. Sélectionnez Ouvrir.
- Ouvrez l'onglet Configuration du processus.
- Dans la partie Configuration, développez
la ligne Configuration d'équipe et sélectionnez Comportement
de l'opération.
- Dans la table Opérations, localisez
la ligne Distribuer (client) sous Contrôle
des sources. Cliquez, sur cette ligne, dans la colonne Tout
le monde. Cette colonne contient une icône pour indiquer
que des préconditions sont disponibles sur cette opération.
Remarque : Il
est possible d'appliquer les préconditions selon les rôles définis
dans Rational Team
Concert. Pour plus d'informations, veuillez vous reporter à la
documentation Rational
Team Concert.
La ligne Des
préconditions et des actions de suivi sont configurées pour cette
opération devient disponible et est sélectionnée.
- Cliquez sur le bouton Ajouter associé
à la table Préconditions.
- Dans la boîte de sélection qui s'affiche, sélectionnez
une ou plusieurs préconditions, selon les contrôles que vous voulez
implémenter :
- RPP - Contrôle de redéfinition des artefects de design
- RPP - Contrôle de redéfinition des Meta Entites
- RPP - Contrôle de redéfinition des Rubriques
- RPP - Contrôle de références de design non résolues
- RPP - Contrôle des préconditions client de synchronisation
du code source
- RPP - Contrôle des préconditions client du contrôle
qualité
- Cliquez sur OK.
Le
nom de la précondition s'affiche dans la zone Nom et
une brève description apparaît dans la zone Description.
- Si vous cochez la case Echec si non installé,
seuls les développeurs ayant installé le plug-in contenant la précondition
pourront distribuer des fichiers sur le serveur. Ce plug-in s'installe
automatiquement lors d'une installation standard de la partie cliente
de Rational Programming
Patterns.
- Si vous cochez la case L'utilisateur peut ignorer,
les développeurs pourront choisir d'ignorer une erreur liée au non-respect
d'une précondition. Ils pourront donc distribuer leurs fichiers, même
si ces fichiers ne respectent pas la précondition.
- Vous pouvez limiter les préconditions RPP -
Contrôle des préconditions client de synchronisation du code source et RPP
- Contrôle des préconditions client du contrôle qualité à
un ou plusieurs composants. Pour ce faire, cliquez sur le bouton Ajouter associé
à la table Portée. Sélectionnez des composants
et cliquez sur OK.
- Sauvegardez.
Résultats
Si les développeurs tentent de distribuer un fichier ne respectant
pas les préconditions sélectionnées, la distribution ne s'effectue
pas et une erreur s'affiche dans la vue
Assistant de l'équipe.
L'erreur indique la précondition non respectée et inclut un lien actif
vers le fichier en erreur.
Si vous avez coché la case L'utilisateur
peut ignorer, le développeur peut faire un clic droit
sur l'erreur affichée dans la vue Assistant de l'équipe et
ignorer cette erreur. Il pourra alors distribuer ses mises à jour.
Si
vous n'avez pas coché la case
L'utilisateur peut ignorer,
le développeur doit corriger l'erreur avant de distribuer.
- S'il s'agit d'une erreur de synchronisation avec le design, il
doit regénérer le code COBOL.
- S'il s'agit d'une erreur de contrôle qualité, il peut, par exemple,
restaurer le code généré depuis la vue Structure du code
généré.