Utilisation d'ALM sans la gestion unifiée des changements

Vous pouvez utiliser les types d'enregistrement ALMBaseline et BTBuild sans la gestion unifiée des changements.

La gestion unifiée des changements ClearCase permet aux enregistrements ALMBaseline et BTBuild de détecter automatiquement les activités incluses dans les sous-versions. Cependant, vous pouvez également utiliser les types d'enregistrement ALMBaseline et BTBuild pour gérer les changements et les activités avec les systèmes qui n'utilisent pas la gestion unifiée des changements. Le terme non UCM fait référence à tout système utilisant une configuration ou une solution de gestion de ressources autres que la gestion unifiée des changements.

Lorsque vous créez un enregistrement ALMBaseline, vous pouvez utiliser les requêtes pour identifier la liste des activités, puis ajouter manuellement les activités à l'enregistrement ALMBaseline.

Remarque : Lors de l'ajout d'un enregistrement ALMActivity à un enregistrement ALMBaseline, l'ID ALMActivity doit être valide, auquel cas l'enregistrement ALMBaseline n'est pas mis à jour avec l'activité ajoutée.

Création de versions de référence et de sous-versions

L'enregistrement ALMBaseline permet de conserver des données dans une version de référence. Dans un système n'utilisant pas la gestion unifiée des changements, il peut s'agir d'un libellé placé sur un référentiel. Ce libellé doit être statique pendant la durée du projet. Il ne doit être déplacé, ni réappliqué.

La clé unique de l'enregistrement ALMBaseline est une combinaison des zones BaselineName et PvobOrLocation. Dans la gestion unifiée des changements, le VOB du projet contient les informations de processus d'un projet de gestion unifiée des changements. Sans la gestion unifiée des changements, PvobOrLocation est l'emplacement (composant ou zone du projet) qui rend le libellé unique. Par exemple, si vous disposez de deux composants, Gui et Core, conçus séparément et que vos libellés de sous-version conçus de nuit sont génériques (par exemple NightlyBuild_2008Jan15), vous pouvez créer des enregistrements de version de référence avec les valeurs BaselineName et PvobOrLocation :
BaselineName=NightlyBuild_2008Jan15  Location=Gui 
BaselineName=NightlyBuild_2008Jan15  Location=Core

Selon l'enregistrement de version de référence, plusieurs sous-versions peuvent être créées à partir de celui-ci. Par exemple, si vous concevez trois plateformes, un enregistrement de version de référence nécessitera trois enregistrements de sous-version.

Exemple

Libraries Ltd. est un producteur de bibliothèques de logiciels. Elle crée des fichiers .jar et publie ces fichiers regroupés sous forme d'archives. Le système de gestion des changements de l'organisation se base sur les fichiers. Chaque fichier .jar peut être défini comme un composant. L'archive qui contient des fichiers .jar regroupés peut être définie comme une offre. Les fichiers .jar de l'équipe du composant sont stockés dans des répertoires (par exemple, Jar\Gui_01.jar, Jar\Gui_02.jar, ...) Les testeurs au niveau des composants testent chaque fichier .jar au niveau du composant. Les composants ne savent pas nécessairement dans quelle offre (de produit) ils sont inclus. Les offres sont créées par l'ingénieur d'édition (ou générateur) qui a créé les fichiers archive contenant les composants. Les offres sont stockées dans des répertoires (par exemple, Products\Sparkle_01 and Products\Dazzle_01). Les testeurs au niveau du produit testent les fichiers archive et tous les fichiers .jar s'y trouvant au niveau du produit.

Le processus global du travail comprend les étapes suivantes :
  • Créez un enregistrement ALMProject (par exemple, nonUCM_GuiJar).
  • Créez un enregistrement ALMRequest et un enregistrement ALMTask associé à la demande.
  • Créez un enregistrement ALMActivity pour le travail de développement (par exemple, Activity ID = ALM00000486).
  • Réalisez un enregistrement ALMActivity. Le développeur modifie le code et ferme l'activité.
  • Créez un enregistrement ALMBaseline. Le générateur crée le fichier jar GUI_Jar_02.jar et un enregistrement de version de référence (GUI_Jar_02), et les ajoute aux activités réalisées. Le générateur peut exécuter une requête (basée sur la catégorie et la version du développeur), cliquer sur une tâche dans la grille Result Set, puis visualiser la zone Activities. Une fois la version de référence créée, une ou plusieurs sous-versions peuvent être créées.
  • Créez un enregistrement BTBuild à partir de la version de référence. Le générateur crée une nouvelle version BTBuild, qui fait référence à l'enregistrement ALMProject et l'enregistrement ALMBaseline appropriés. L'onglet Activities de l'enregistrement BTBuild affiche toutes les activités contenues dans l'enregistrement ALMBaseline. L'onglet ALM de l'enregistrement BTBuild indique la connexion à la version de référence ALM.
  • Testez une sous-version. Le testeur peut visualiser une tâche ALMTask et savoir dans quelle sous-version la nouvelle fonctionnalité peut être trouvée.

La création d'une version de référence composée signifie prendre les versions de référence existantes et les ajouter à la zone Composed of Baselines d'un nouvel enregistrement de version de référence. Par exemple, une version de référence au niveau du produit peut inclure toutes les versions de référence au niveau du composant.

Dans notre exemple, Composed of Baselines inclut la version de référence GUI_Jar_02 de la version de référence du composant. Le générateur peut ensuite créer un nouvel enregistrement BTBuild à partir de la nouvelle version de référence Dazzle_01. Il s'agit du même processus que celui utilisé pour créer la sous-version à partir du composant de l'interface graphique. Le même enregistrement ALMTask indique au testeur au niveau du produit la sous-version dans laquelle la nouvelle fonctionnalité peut être trouvée.


Retour d'informations