L'enregistrement ALMActivity contient un onglet Unified Change Management. Il s'agit d'un paramètre facultatif pour les équipes qui utilisent la gestion unifiée des changements.
La gestion unifiée des changements (UCM) est une fonction de Rational ClearCase qui :
- fournit un modèle de gestion des codes source flexible et prêt à l'emploi pour gérer les changements entre les activités et les ressources associées ;
- fournit un niveau d'abstraction pratique pour les ressources de codes ;
- ne nécessite pas de recourir au développement et à la gestion de scripts dans un environnement ClearCase ;
- automatise la configuration de l'espace de travail du projet et du développeur ;
- s'intègre à d'autres outils Rational, permettant ainsi d'obtenir une suite d'outils de développements qui améliorent le processus de développement.
Lorsque l'intégration de ClearCase/ClearQuest UCM est utilisée avec ClearQuest ALM, les enregistrements ALMActivity se chargent du suivi du travail effectué pendant que les développeurs extraient et restituent les fichiers. L'enregistrement
ALMActivity est lié à une tâche ALMTask désignant un projet ALMProject particulier. L'enregistrement ALMActivity est identique à une activité UCM. Tous les types d'activité sont compatibles avec la gestion unifiée des changements.
Une activité ALMActivity est mappée à une activité UCM, une version ALMBaseline est mappée à une version de référence
UCM et une version BTBuild est mappée à une sous-version réelle. Une fois les activités terminées, vous créez une version de référence ALMBaseline, qui crée également une version de référence UCM. Si vous créez une sous-version à l'aide de la dernière version de référence UCM, l'enregistrement
BTBuild correspondant est créé. L'enregistrement BTBuild contient une référence à la version de référence ALMBaseline à partir de laquelle la sous-version a été créée.
Pour les projets utilisant l'intégration UCM, définissez . Lorsque l'intégration UCM est activée dans un projet de gestion unifiée des changements, toutes les activités UCM sont suivies par les enregistrements
ALMActivity. Lorsqu'une activité UCM est distribuée au flux d'intégration du projet UCM, l'activité ALMActivity correspondante est terminée.
L'utilisation du type d'enregistrement ALMBaseline pour mapper les versions de référence lors de la création d'une version de référence dans la gestion unifiée des changements permet de disposer des nouvelles activités dans la version de référence. La liste des activités de gestion unifiée des services peut être fournie dans l'enregistrement ALMBaseline. Si vous n'utilisez pas la gestion unifiée des changements, vous pouvez utiliser les requêtes pour identifier la liste des activités, puis ajouter manuellement les activités à l'enregistrement de version de référence.
L'enregistrement ALMBaseline répertorie les activités ALMActivities distribuées au flux d'intégration depuis la création de la dernière version de référence. L'ingénieur d'édition crée ensuite une sous-version à partir de la dernière version de référence. Un enregistrement BTBuild correspondant est également créé. L'enregistrement BTBuild répertorie la version de référence utilisée pour créer cette sous-version. L'enregistrement répertorie également les activités ALMActivities incluses depuis la dernière sous-version.
Remarque : Dans la gestion unifiée des changements, un flux est identique à une branche dans les autres systèmes de gestion de configuration de ressources ou de logiciels.
Les enregistrements de version de référence sont conçus avec des unités d'exécution sur le flux à des fins d'organisation.
Lors de la distribution d'une activité vers un flux avec une règle d'administration de transition possédant l'état Complete après distribution, l'action passe à l'état Complete, même si un développeur doit encore travailler sur l'activité.
Cette transition d'état empêche toute extraction supplémentaire. Le développeur peut :
- effectuer une autre distribution afin de ne partager les changements qu'avec un autre développeur, puis continuer d'apporter des changements à l'aide de la même activité ;
- effectuer la distribution vers un flux de dispositif pour partager les changements avec l'équipe travaillant sur les mêmes fonctions.
Par exemple, un développeur utilisant des journaux UCM se connecte et trouve des activités UCM, spécifie une activité par défaut ou ajoute un fichier à un flux de développement, puis l'ajoute au contrôle des sources. Le développeur peut également visualiser l'activité dans ClearQuest sous la forme d'une activité ALMActivity (State
= Activated).
- Le développeur peut utiliser un client ClearCase pour distribuer les changements, puis terminer la distribution. Une fois l'activité terminée, l'ingénieur de la version (ou générateur) crée une version de référence du code.
- Le générateur se connecte à ClearQuest, puis crée une version de référence ALMBaseline. Le générateur spécifie un VOB de projet, un projet, des valeurs de version et des ID d'activité pour la nouvelle version de référence.
- Selon la version de référence UCM, plusieurs sous-versions peuvent être créées à partir de celle-ci.
Pour chaque sous-version, le générateur crée un enregistrement BTBuild.
- Le testeur termine les activités de type Test. L'activité de test inclut une référence à la version BTBuild contenant le correctif Développeur (si une sous-version a été créée). Le testeur installe la sous-version, puis termine l'activité de test.
Création de versions de référence et d'enregistrements ALMBaseline
Pour les jalons ou les sous-versions de nuit, vous créez une version de référence UCM, puis créez un enregistrement ALMBaseline. La création de l'enregistrement ALMBaseline vérifie le dernier enregistrement de version de référence créé. S'il s'agit de la deuxième version de référence sur le VOB de projet et le flux, le premier enregistrement est la version de référence initiale. Etant donné la version de référence actuelle et la dernière version de référence trouvée,
une comparaison UCM ClearCase (opération diffbl)
est utilisée pour comparer les versions de référence. Les activités ALMActivities distribuées depuis le dernier enregistrement de version de référence sont ajoutées au nouvel enregistrement de version de référence.
Selon le projet UCM, créez une version de référence initiale, puis créez un enregistrement ALMBaseline initial pour ancrer le flux UCM et le VOB de projet à une série d'enregistrements ALMBaseline.
Définissez une convention de dénomination claire pour les versions de référence. Vous voudrez peut-être inclure toutes ou une partie des informations suivantes dans un nom de version de référence:
- Nom du projet
- Nom du composant
- Jalon ou phase du planning de développement
- Date de création
Pour plus d'informations sur la définition d'un modèle de dénomination de version de référence, voir http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_u_pln_bl_nm_cnvntn.htm.
Projets UCM existants
D'anciens projets qui n'étaient pas créés comme projets ALM peuvent posséder de nombreuses activités et versions de référence existantes. Vous voudrez peut-être importer toutes ou une partie de ces informations. Vous devez importer les versions de référence dans l'ordre de leur flux.
Notez que chaque version de référence doit être importée. Toutefois, elles ne sont pas obligatoirement importées dans leur ordre de création. Le script create_baseline_record.pl recherche les nouvelles activités présentes dans la version de référence. Pour ce faire, il compare la version de référence avec l'enregistrement de version de référence précédent dans ALM sur le même flux.
Si vous souhaitez disposer uniquement du suivi des nouvelles activités, vous pouvez créer un enregistrement ALMBaseline sur le même flux et cette nouvelle version de référence remplacera la version de référence originale de l'ancien projet dans le cadre d'une nouvelle comparaison. Seules les activités créées depuis cette nouvelle version de référence initiale s'afficheront dans le nouvel enregistrement de version de référence. Vous pouvez créer cet enregistrement de version de référence initial de l'une des manières suivantes :
- Vous pouvez le créer manuellement dans ALM en renseignant les zones PVOB or Location et Stream afin que le script create_baseline_record.pl puisse le retrouver.
- Vous pouvez utiliser create_baseline_record.pl pour créer la version de référence initiale.
create_baseline_record.pl peut créer une version de référence de départ initiale en transmettant les options appropriées. L'option -nodiffbl spécifie la création de la version de référence transmise. En outre, cette option demande de ne pas rechercher/exécuter une comparaison avec une version de référence précédente. Cette option n'examinant pas la version de référence, vous devez également inclure les informations de l'argument -ucmstream nom_flux.
Par exemple :
ratlperl create_baseline_record.pl -user RE -pw secret -dbname ALM -dbset CQ.ALM.HOST -projectid ALM00000123 -nodiffbl -pvob "\pvob01" -ucmstream "proj_01_int" -baseline "proj_01_02_24_2008"
Cette commande crée un enregistrement ALMBaseline avec les valeurs suivantes : Project id: ALM00000123
Name: proj_01_02_24_2008
ucm_stream: proj_01_int
PVOB or Loc:\pvob01
Une fois l'enregistrement ALMBaseline initial créé, vous pouvez créer des enregistrements de version de référence plus récents dans leur ordre de création sur le flux. Pour ce faire, appelez create_baseline_record.pl avec les options requises et le nom de la nouvelle version de référence. Une version de référence est comparée à l'enregistrement de version de référence précédemment trouvé et les nouvelles activités sont ajoutées au nouvel enregistrement de version de référence.