Contrôle des fichiers lors de la distribution sur le serveur et la promotion entre flux

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. Vous pouvez ainsi sélectionner des contrôles sous forme de préconditions.

Pourquoi et quand exécuter cette tâche

Les préconditions effectuent des contrôles de deux types :
  • Contrôle de fichiers lors de la distribution sur le serveur. Ces préconditions sont des préconditions clientes car elles concernent les remontées depuis l'espace de travail de l'utilisateur.
    • RPP - Contrôle de création des Rubriques.

      Cette précondition vérifie que des Rubriques ne sont pas créées en dehors du périmètre des composants sélectionnés.

    • RPP - Contrôle de redéfinition des Rubriques, RPP - Contrôle de redéfinition des Méta Entités et RPP - Contrôle de redéfinition des artefacts de design.

      Ces préconditions vérifient 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. Vous pouvez sélectionner des composants dans lesquels les redéfinitions restent possibles.

      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.

    • RPP - 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 ou promus sont résolues.

      Les références ne sont pas résolues dans les cas suivants :
      • Des modifications locales sont distribuées ou promues 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é ou promu.
      • 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 ou promue.
      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.
    • RPP - Contrôle de distribution de multiples fichiers design.

      Cette précondition vérifie que chaque ensemble d'artefacts modifiés sur le point d'être distribué ne contient qu'une seule instance de design.

    • RPP - Contrôle de distribution de multiples fichiers générés.

      Cette précondition vérifie que chaque ensemble d'artefacts modifiés sur le point d'être distribué ne contient qu'un seul fichier généré.

    • RPP - Contrôles d'intégrité des fichiers générés.
      Cette précondition vérifie l'intégrité des fichiers générés sur le point d'être distribués en effectuant les contrôles suivants :
      • Les fichiers générés et les fichiers pdp correspondants doivent être distribués simultanément. Par exemple, un fichier cbl doit être distribué avec son fichier cblpdp.
      • Les fichiers générés doivent être synchronisés avec les fichiers design ayant participé à leur génération en local.
      • Les fichiers générés ne peuvent pas être modifiés si le pattern l'interdit. Pour le pattern Pacbase, seuls les fichiers d'extension cbl des Programmes, Ecrans ou Serveurs peuvent être modifiés pour insérer du code spécifique. Les autres fichiers générés (bms, cpy ou ddl par exemple) sont en lecture seule.
      Remarque : Cette précondition se base sur le contenu de la vue Modifications en attente. Ainsi, si des fichiers design impliqués dans une génération ont été chargés dans l'espace de travail avec le choix Charger les artefacts requis et s'ils n'ont pas été partagés, ils ne sont pas pris en compte dans la précondition.
    • RPP - Interdire la distribution de fichiers générés si des fichiers design contributeurs sont manquants.
      Cette précondition vérifie que tous les fichiers design ayant participé à la génération d'un fichier sur le point d'être distribué ou promu ont déjà été distribués (ou promus) ou sont distribués (ou promus) en même temps que le fichier généré.
      Remarque : Cette précondition se base sur le contenu de la vue Modifications en attente. Ainsi, si des fichiers design impliqués dans une génération ont été chargés dans l'espace de travail avec le choix Charger les artefacts requis et s'ils n'ont pas été partagés, ils ne sont pas pris en compte dans la précondition.
    • RPP - Interdire la distribution de fichiers générés si des modifications entrantes contiennent des fichiers design contributeurs.
      Cette précondition vérifie que les ensembles d'artefacts modifiés entrants ne contiennent pas de fichiers pouvant impacter les fichiers générés sur le point d'être distribués.
      Remarque : Cette précondition se base sur le contenu de la vue Modifications en attente. Ainsi, si des fichiers design impliqués dans une génération ont été chargés dans l'espace de travail avec le choix Charger les artefacts requis et s'ils n'ont pas été partagés, ils ne sont pas pris en compte dans la précondition.
    • RPP - Interdire la mise à jour du diagramme de projets.

      Cette précondition vérifie que la structure du diagramme des projets du chemin de compilation design n'a pas été mise à jour. Le diagramme de projets est consultable ou modifiable, en fonction des droits d'accès, en faisant un clic droit sur un référentiel ouvert dans la vue Explorateur de designs et en sélectionnant Propriétés.

    • RPP - Contrôle des préconditions client du 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.

      Le contrôle qualité est implémenté avec Rational Software Analyzer. Pour savoir comment le mettre en œuvre, référez-vous à Règles de contrôle qualité.

    • RPP - Le fichier généré et le fichier design utilisé pour le produire, doivent être distribués dans le même ensemble de modifications.

      Cette précondition vérifie que chaque ensemble d'artefacts modifiés sur le point d'être distribué contient à la fois le fichier généré et le fichier design utilisé pour le produire, si ce fichier design a été modifié.

    Les contrôles s'appliquent au contenu des ensembles d'artefacts modifiés sur le point d'être distribués, et au contenu indexé du serveur. Ce contenu peut être déphasé par rapport au contenu réel du serveur. Avant de distribuer vos modifications, vous devez donc synchroniser le contenu indexé du serveur avec son contenu réel. Vous devez aussi 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. Ainsi, par exemple, si vous distribuez la suppression d'un appel de Rubrique dans un Segment, le contenu du serveur doit être réindexé pour que la distribution de la suppression de la Rubrique soit autorisée.

    La réindexation du contenu du serveur peut être demandée de plusieurs façons :
    • Pour une réindexation automatique après chaque distribution de fichiers design, sélectionnez l'action de suivi RPP - Forcer l'indexation des fichiers design distribués, si nécessaire dans le même onglet que la sélection des préconditions. Cette action de suivi ne fonctionne qu'avec Rational Team Concert version 6.0.2 ou supérieure.
      L'indexation est forcée après les distributions suivantes :
      • Distribution de la création d'une instance de design. L'instance créée apparaîtra alors dans les résultats des requêtes serveur.
      • Distribution de la suppression d'une instance de design. L'instance supprimée disparaîtra alors des résultats des requêtes serveur.
      • Distribution d'une modification des sous-références d'une instance de design. Ceci est le cas, par exemple, quand un appel de Rubrique est ajouté ou supprimé dans les Lignes -CE d'un Segment.

    • Pour le lancement manuel d'une réindexation, ouvrez la perspective Eléments de travail puis la vue Artefacts de l'équipe. Développez la zone de projet contenant les modifications à distribuer puis la ligne Enterprise Extensions. Faites un clic droit sur Données de code source et sélectionnez Mettre à jour les données de code source.

  • Contrôle de fichiers lors de la promotion d'éléments de travail. Ces préconditions sont des préconditions serveur car elles s'appliquent lorsqu'un flux est mis à jour par un autre flux. Pour des explications sur la promotion entre flux, reportez-vous à l'aide Rational Team Concert. Ces préconditions ne fonctionnent qu'avec Rational Team Concert version 6.0.2 ou supérieure.
    • RPP - 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 ou promus sont résolues.

      Les références ne sont pas résolues dans les cas suivants :
      • Des modifications locales sont distribuées ou promues 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é ou promu.
      • 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 ou promue.
      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.
    • RPP - Interdire la distribution de fichiers générés si des fichiers design contributeurs sont manquants.
      Cette précondition vérifie que tous les fichiers design ayant participé à la génération d'un fichier sur le point d'être distribué ou promu ont déjà été distribués (ou promus) ou sont distribués (ou promus) en même temps que le fichier généré.
      Remarque : Cette précondition se base sur le contenu de la vue Modifications en attente. Ainsi, si des fichiers design impliqués dans une génération ont été chargés dans l'espace de travail avec le choix Charger les artefacts requis et s'ils n'ont pas été partagés, ils ne sont pas pris en compte dans la précondition.

Procédure

  1. 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.
  2. Ouvrez l'onglet Configuration du processus.
  3. Dans la partie Configuration, développez la ligne Configuration d'équipe et sélectionnez Comportement de l'opération.
  4. Dans la table Opérations, localisez la ligne Distribuer (client) ou Distribuer (serveur) 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.

  5. Cliquez sur le bouton Ajouter associé à la table Préconditions.
  6. 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.
  7. 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.

  8. Si vous cochez 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.
  9. Si vous cochez 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.
  10. Pour la précondition RPP - Contrôle de création des Rubriques, vous devez sélectionner les composants dans lesquels la création de Rubriques est possible.

    Pour les préconditions RPP - Contrôle de redéfinition des Rubriques, RPP - Contrôle de redéfinition des Meta Entites et RPP - Contrôle de redéfinition des artefacts de design, vous pouvez sélectionner des composants dans lesquels les redéfinitions sont possibles.

    Pour les préconditions RPP - Contrôles d'intégrité des fichiers générés, RPP - Contrôle des préconditions client de synchronisation du code source et RPP - Contrôle des préconditions client du contrôle qualité, vous pouvez sélectionner des composants qui limitent leur portée.

    Pour sélectionner des composants, cliquez sur le bouton Ajouter associé à la table Composants dans Portée. Sélectionnez ensuite les composants appropriés et cliquez sur OK.

  11. Si vous avez sélectionné Distribuer (client) dans la table Opérations, vous pouvez sélectionner une action de suivi pour que le contenu du serveur soit réindexé automatiquement après chaque distribution de fichiers design. Pour cela, cliquez sur le bouton Ajouter associé à la table Actions de suivi. Dans la boîte de sélection qui s'affiche, sélectionnez RPP - Forcer l'indexation des fichiers design distribués, si nécessaire et cliquez OK. Cette action de suivi ne fonctionne qu'avec Rational Team Concert version 6.0.2 ou supérieure.
  12. Sauvegardez.

Résultats

Si les développeurs tentent de distribuer ou promouvoir un fichier ne respectant pas les préconditions sélectionnées, la distribution ou la promotion de ce fichier 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 ou promouvoir les fichiers.

Si vous n'avez pas coché la case L'utilisateur peut ignorer, le développeur doit corriger l'erreur avant de distribuer ou promouvoir.

Pour corriger une erreur lors d'une distribution, le développeur doit, par exemple, regénérer le code COBOL s'il s'agit d'une erreur de synchronisation avec le design. 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é.

Pour corriger une erreur lors d'une promotion, le développeur doit promouvoir les éléments de travail contenant les fichiers de designs manquants pour les références ou les fichiers de design contributeurs d'un fichier généré.


Vos commentaires