2009-12-03 23 views
1

Mes collègues et moi sommes relativement besoin de l'idée de flux avec Clearcase UCM. Actuellement, la direction a créé des flux pour chaque progiciel fonctionnel, chacun d'entre eux ayant des interfaces définies et vivant dans une architecture en couches. Les développeurs créent des flux enfants en fonction du package dans lequel ils travaillent, et essaient de développer leur code indépendamment, mais ils ont normalement des dépendances sur d'autres paquets lors du développement initial. Cela a amené notre groupe d'intégration à créer des constructions système que les développeurs utilisent ensuite pour créer un environnement adéquat pour développer leur logiciel et extraire manuellement les dépendances (fichiers zip, correctifs, etc.).Clearcase UCM - Travailler avec les flux et les composants, comment?

Mon argument est que cela est faux et pas comment UCM était destiné à être utilisé, mais je besoin de quelqu'un plus familier avec UCM pour confirmer mes croyances.

Je crois que les flux devraient être créés à partir d'un point de vue fonctionnel (alors que chaque paquet une fonction, paquets architecturaux multiples contribuent à la réalisation une fonction client, appelez-le « ABC »). Ensuite, le composant pour chaque composant architectural qui exécute le développement initial pour la fonction "ABC" est ajouté au flux. Tous les développeurs de la fonction "ABC" travaillent maintenant dans le flux (ou dans un ensemble de flux enfants) pour compléter cette fonction. Une fois terminé, vous avez une référence pour chaque composant UCM, et aucune "liaison" entre les composants n'existe du point de vue d'UCM (quelqu'un a affirmé que cela pourrait se produire dans UCM en raison des enregistrements d'activité). REMARQUE: Je suis d'accord pour dire que vous ne travaillez peut-être JAMAIS, mais lors du développement initial où les interfaces changent fréquemment, vous n'avez pas implémenté toutes les interfaces pour toutes les fonctions, et donc avoir plusieurs composants fonctionnant ensemble dans un flux fait le plus de sens. Plus tard, vous pouvez passer à un mode de travail «architectural centré sur le paquet» où chaque paquet est indépendant des changements dans un autre.

Pensées? Désolé pour le long post, j'ai senti que le détail était nécessaire.

Répondre

0
  • flux créés pour chaque logiciel fonctionnel
  • Tous les développeurs pour la fonction « ABC » fonctionne maintenant dans le flux (ou dans un ensemble de flux d'enfants) pour compléter cette fonction

Oui, c'est à peu près les deux UCM usages normaux du flux
(le seul très mauvais usage est celui qui implique un flux par développeur, juste pour les besoins d'isolement, et ce serait de la folie, comme specified before)

Ces deux modes sont approche et approche par composants système , détaillé dans this answer.
Fondamentalement, vous voulez éviter trop de fusions ou de rebasculer pendant la phase initiale de développement et garder un système cohérent (avec tous les composants inscriptibles) au début.
Ensuite, lorsque l'API est stabilisée, vous pouvez passer un flux par composant inscriptible. Remarque: cela ne vous empêche pas d'établir des flux "d'intégration système", lorsque vous avez un ensemble de lignes de base bien définies référençant un état stable pour tous vos composants (en lecture seule), et où vous pouvez déployer et tester votre système.
Ces flux sont gérés sur un ou plusieurs projets UCM "d'intégration" distincts.

0

Je suis d'accord avec VonC. Je préférerais l'approche fonctionnelle.

Il existe un plug-in ClearCase qui peut vous aider à établir des environnements pour vos utilisateurs (flux, vues, stratégie de projet) quelle que soit l'approche que vous utilisez. Il suffit de google à propos de "clearEnv"