Parce que j'ai du mal à apprendre IBM Rational ClearCase, j'aimerais connaître votre opinion professionnelle.
Je suis particulièrement intéressé par les avantages/inconvénients par rapport à d'autres systèmes de contrôle de version comme Subversion ou Git.
Vous pouvez trouver une bonne comparaison entre ClearCase et Git dans ma réponse SO:
" Quels sont les concepts de base de ClearCase que chaque développeur doit connaître? ", illustrant quelques différences majeures (et quelques lacunes de ClearCase)
L'inconvénient le plus important de ClearCase est son ancienne approche " centrée sur les fichiers " (par opposition à " référentiel - centrique "comme dans SVN ou Git ou Perforce ...)
Cela signifie que chaque extraction ou enregistrement s'effectue fichier par fichier. L'atomicité de l'opération est au niveau du fichier.
Combinez cela avec un protocole très détaillé et un réseau avec potentiellement plusieurs nœuds entre le poste de travail développeur et le VOB serveur, et vous pouvez vous retrouver avec un serveur de fichiers assez lent et inefficace (dont ClearCase est à la base).
Les opérations fichier par fichier signifient: opérations lentes récursives (comme extraction récursive ou récursif "ajouter à la source) control " , même par clearfsimport
).
Un réseau local rapide est obligatoire pour atténuer les effets secondaires de ce protocole de discussion.
L'autre aspect à prendre en compte est son aspect centralisé (même s'il peut être "distribué" avec son multi-site répliqué VOB fonctionnalité)
Si le réseau ne permet pas d'accéder aux VOB, les développeurs peuvent:
Vous pouvez avoir une fonctionnalité VCS distribuée en répliquant un Vob.
Mais:
Comme mentionné dans "Comment tirer parti des fonctionnalités de ClearCase", les vues dynamiques sont excellentes (un moyen de voir les données à travers le réseau sans avoir à les copier sur le disque), mais la caractéristique principale reste [~ # ~] ucm [~ # ~] : cela peut être un réel atout si vous avez un gros projet avec un workflow complexe.
Quelques lacunes à cet égard:
Utiliser ClearCase sans utiliser UCM signifie devoir définir une politique pour:
cleartool find
"demandes ...La gestion des droits ClearCase est entièrement basée sur les droits système.
Cela signifie que vous devez enregistrer votre utilisateur dans le bon groupe de systèmes, ce qui n'est pas toujours facile à faire lorsque vous devez saisir un ticket pour votre service informatique afin qu'ils puissent effectuer l'enregistrement approprié.
Ajoutez à cela un environnement hétérogène (utilisateurs sous Windows et serveur sous Unix), et vous devez enregistrer votre utilisateur sous Unix en tant que ainsi que Windows! (avec le même nom de connexion/groupe). Sauf si vous mettez une sorte de correspondance LDAP entre les deux mondes (comme Centrify )
cleartool
" est l'interface de ligne de commande ClearCase), ce qui signifie que tout script (en Perl ou dans un autre langage) consiste à analyser la sortie de ces commandes cleartool
)Les stockages de vues sont l'équivalent du ".svn" de Subversion, sauf qu'il n'y a qu'un "stockage de vues" par vue au lieu de plusieurs .svn dans tous les répertoires d'un espace de travail Subversion. Ça c'est bon.
Ce qui est mauvais, c'est que chaque opération dans une vue (un simple "ls
", extraction, vérification, ...) déclenchera un réseau demande au processus view_server qui gère votre serveur de vue.
2 options:
Le premier mode signifie: vous devez sauvegarder vous-même votre travail en cours (fichiers privés ou fichiers extraits)
Le deuxième mode signifie: votre poste de travail peut être indisponible, vous pouvez simplement vous connecter à un autre et récupérer vos vues (sauf pour les fichiers privés d'une vue instantanée)
Discussion parallèle sur les vues dynamiques :
Pour ajouter à l'aspect "vue dynamique", il a un avantage (c'est dynamique) et un défaut (c'est dynamique).
Les vues dynamiques sont idéales pour définir un environnement simple pour partager rapidement un développement petit entre une équipe petite: pour un petit effort de développement, un la vue dynamique peut aider 2 ou 3 développeurs à rester constamment en contact les uns avec les autres, en voyant instantanément quand son commit casse quelque chose dans les autres vues.
Pour un effort de développement plus complexe, l '"isolation" artificielle fournie par la vue d'instantané est préférable (vous ne voyez les changements que lorsque vous actualisez - ou "mettez à jour" - votre vue d'instantané)
Pour de réels efforts ou cours de développement divergents, une branche est toujours requise pour obtenir une véritable isolation du code (des fusions seront nécessaires à un moment donné, que ClearCase gère très bien, quoique lentement, fichier par fichier)
Le fait est que vous pouvez utiliser les deux pour les bonnes raisons.
Remarque: par petite équipe je ne veux pas dire "petit projet". ClearCase est mieux utilisé pour les grands projets , mais si vous souhaitez utiliser des vues dynamiques, vous devez configurer " branches de tâches afin d'isoler un petit effort de développement par branche: de cette façon une "petite équipe" (un sous-ensemble de votre grande équipe) peut travailler efficacement, en partageant rapidement son travail entre ses membres.
.
Ce serait alors une mauvaise utilisation des vues dynamiques, et cela oublierait ses autres utilisations:
Développer directement dans une vue dynamique n'est pas toujours la meilleure option car tous les fichiers (non récupérés) sont lus sur le réseau .
Cela signifie que la dll, le jar ou l'exe requis par votre IDE serait accessible via le réseau, ce qui peut ralentir considérablement le processus de compilation.
Solutions possibles:
Le coût est un inconvénient assez évident. Pas seulement le coût de la licence, mais aussi le coût du salaire d'un gourou ClearCase. Presque toutes les entreprises que je connais qui utilisent ClearCase semblent avoir au moins une personne dont le seul but est d'apprivoiser la bête indisciplinée.
Le fait même qu'il soit suffisamment compliqué pour exiger une nounou à temps plein est également inquiétant.
Un cauchemar absolu d'un système. Cela m'a fait souhaiter que nous puissions revenir à VSS ! (Peu importe tout système de contrôle de source moderne comme Subversion ou Git!)
Fondamentalement, c'est lent, compliqué et peu fiable comme l'enfer. Oh, et ai-je mentionné c'est ridiculement cher? La seule façon dont ils peuvent éventuellement le vendre est de parler à des décideurs qui n'ont jamais utilisé le produit et ne le feront jamais! Je suis sûr qu'aucun développeur au monde ne l'achèterait jamais.
Les validations et les changesets atomiques sont mes plus gros reproches contre ClearCase. Supposons que vous archiviez cinq fichiers dans le cadre d'une correction de bogue ou d'une refactorisation. Ensuite, on découvre que quelque chose a été gâché et que vous devez revenir en arrière. Bonne chance pour trouver quels sont les cinq fichiers et quelle version chacun un doit être activé. Mais prenons un peu de recul. Vous venez de terminer la modification de ces cinq fichiers et il est temps de valider. Les quatre premiers passent très bien. Ce dernier nécessite une fusion massive. Les quatre autres fichiers sont déjà archivés. Ils n'attendent pas que vous ayez terminé les modifications nécessaires dans le dernier fichier. J'espère que personne n'a mis à jour ou n'utilise une vue dynamique. Un serveur de build d'intégration continue va également échouer.
Parfois, nous créons un tout nouveau répertoire plein de fichiers qui doivent être archivés, mais nous ne voulons pas les archiver jusqu'à ce qu'ils soient terminés. Il est tôt et tout est encore volatil, alors pourquoi vérifier les choses que vous pourriez supprimer très bientôt? OK, très bien jusqu'à présent. Il est maintenant temps de vous enregistrer. Vous ajoutez le dossier nouvellement créé au contrôle de code source. Eh bien, ClearCase n'est pas récursif, donc seulement ce dossier single est archivé. Avec SVN, ce dossier et tout ce qui se trouve en dessous est ajouté, comme vous le souhaitez. Le développeur doit se rappeler d'ajouter tout, sinon, beaucoup de fichiers seront manquants.
ClearCase est propriétaire des fichiers et des dossiers, vous ne pouvez donc rien modifier à moins de les avoir préalablement extraits. Le plugin Eclipse enlève beaucoup de nuisance ici. Je ne peux pas vous dire combien de fois j'ai ouvert un fichier dans vi pour effectuer un changement rapide, seulement pour découvrir que j'avais oublié de le vérifier en premier. Le paiement n'est pas non plus récursif.
Les mises à jour peuvent être douloureusement lentes sans changements. Lorsque vous mettez à jour avec une vue instantanée, tous les mises à jour de fichiers, pas seulement les fichiers modifiés. J'ai travaillé sur un projet avec plus de 20 000 fichiers. Je voudrais me connecter à distance à ma machine de travail, démarrer la mise à jour, puis me rendre au travail; prendre du café; aller à mon bureau pendant qu'il finissait. Cela peut sembler exagéré, mais ce n'est malheureusement pas le cas.
Les vues dynamiques sont terribles, sauf si vous êtes dans une très petite équipe. Et si c'est le cas, pourquoi avez-vous même ClearCase? J'ai vu d'innombrables points de vue de personnes se faire arroser parce que quelqu'un a archivé des fichiers qui ont brisé les vues de tout le monde. Vous devez toujours mettre à jour et fusionner tout conflit sur votre propre vue. De cette façon, les changements ne vous concernent que. Avec une vue dynamique, vous ne pouvez pas fusionner avant de remonter; vous vous engagez et espérez.
Je sais que le coût n'est probablement pas une grande préoccupation, mais les développeurs qui font de l'argent pour l'entreprise aimeraient dépenser les 50 000 à 100 000 $ (selon la licence ClearQuest, qui est un ajout courant) pour des événements amusants ou de nouveaux équipements ( chaises, moniteurs, etc.). IBM recommande d'avoir du personnel pour faire fonctionner ClearCase. Pourquoi ne pas redéfinir ces personnes pour générer des revenus pour l'entreprise, au lieu de s'assurer que les choses ne tombent pas en panne et ne brûlent pas?
Certaines des raisons que j'ai entendues pour ne pas changer:
La seule chose que ClearCase fait mieux que les autres est de ramifier des fichiers individuels, tout en gardant les autres sur la même piste qu'une autre branche.
Tout ce que j'ai fait dans Clearcase semble toujours dur. Alors que je n'ai jamais eu cette impression avec d'autres systèmes (sauf peut-être CVS à l'occasion).
J'ai utilisé SVN, CVS, Clearcase et Mercurial.
Nous migrons simplement de CC vers Git pour la plupart des raisons données ici. Je voudrais ajouter une raison de rester loin de CC ou de tout autre système de contrôle de source commercial.
Vos données commerciales essentielles sont le code, son historique de version et toutes les métadonnées telles que les commentaires de validation, qui se sont enregistrés et quand.
Tous les logiciels auront une durée de vie limitée. Vous devriez toujours vous demander quand vous introduisez un nouveau système qui avale des données commerciales importantes, que ce soit du code, des bogues, des données client ou autre: comment puis-je récupérer mes données? Si vous ne pouvez pas répondre à cette question, vous ne devez pas introduire ce système.
Lorsque nous avons migré, nous avons perdu la majeure partie de notre histoire et toutes nos métadonnées. Essentiellement, nous n'avons que l'historique correspondant aux versions publiées, mais des informations sur les modifications apportées en réponse aux demandes des clients sont perdues (nous avons ces données dans le système de support client et de ticket de bogue, donc elles ne sont pas complètement perdues, mais le couplage avec le code source a disparu).
Ce sera quelque part entre une nuisance et un problème pour nous à court ou moyen terme. Dans quelques années, ce n'est plus important, mais peut-être que pendant 1 à 3 ans, cela importera.
(Il existe des outils commerciaux pour migrer CC vers d'autres SCM, mais ils n'ont pas été jugés adaptés à nos besoins, et je doute que cela aurait été faisable. L'exportation minimale que nous avons effectuée a pris assez de temps.)
La leçon apprise est la suivante: ne confiez jamais des données commerciales vitales à des systèmes propriétaires.
Tout J'ai connu que ClearCase est inefficace, moche, trop complexe, lent, déroutant, cher et peu pratique.
Il semble attirer les gestionnaires et les ingénieurs qui ont tout compris.
Merde, IBM et Rational doivent avoir des vendeurs incroyables pour vendre un produit aussi merdique.
Mon expérience avec ClearCase a été un désastre, et je vais appuyer la déclaration de Don selon laquelle cela nécessite un expert résident - malheureusement, nous en avions plus d'un. J'avais de l'expérience avec CVS et d'autres systèmes de contrôle de version, je connaissais les concepts, mais j'ai trouvé la documentation ClearCase incompréhensible et j'ai dû demander de l'aide plusieurs fois; différents experts m'ont donné des conseils contradictoires au point où nous avons en fait cassé le cd. Autrement dit, après avoir émis une commande ClearCase dans un shell UNIX, la commande "cd" a échoué avec un message d'erreur.
La tâche de base d'un système de contrôle de version est vraiment assez simple. Honnêtement, je pense qu'une demi-douzaine de commandes devraient suffire, en utilisant un schéma de fichiers qui joue bien avec les autres. Pour moi, ClearCase ressemble au résultat d'un responsable marketing compliquant délibérément l'enfer pour rendre le produit sophistiqué et puissant. J'ai entendu dire qu'il peut être configuré pour se comporter de manière simple, sûre et fiable, mais encore une fois, cela nécessite les services d'un expert - prêt à l'emploi, c'est comme un couteau suisse motorisé.
Aucun commit atomique
Une fois que vous avez archivé les fichiers, il est très difficile de revenir à un certain état, car les validations atomiques ne sont pas prises en charge. Lors de l'archivage de plusieurs fichiers, chaque fichier obtient une nouvelle révision (similaire à CVS) et non l'archivage lui-même. Je pense que c'est une fonctionnalité cruciale, car vous ne voulez guère revenir sur des fichiers uniques mais effectuer des actions de validation (qui devraient mapper les tâches). Avec ClearCase, vous ne pouvez revenir à certains états qu'en utilisant des étiquettes. En pratique, l'utilisation d'étiquettes ClearCase pour chaque enregistrement est exagérée et n'est donc pas effectuée.
Interface utilisateur merdique
L'interface graphique de ClearCase Explorer n'est qu'une grosse blague. Horrible dans la convivialité et laid. Des fonctions différentes et souvent nécessaires ne sont pas fournies (par exemple, archivage récursif des artefacts travaillés). L'outil de ligne de commande cleartool utilisé avec cygwin est bien meilleur, mais certaines choses ne sont toujours pas disponibles, comme l'ajout récursif de nouveaux fichiers/dossiers au contrôle de code source. Je dois rire la tête si je lis un script de 50 lignes de long pour contourner ce problème.
Efforts administratifs élevés
Administrer ClearCase beast est loin d'être évident ou léger (à la différence d'autres systèmes scm comme CVS, Subversion ou Git). Attendez-vous à mettre quelques experts ClearCase dédiés pour simplement le faire fonctionner.
Performances horribles
Rien de pire que de faire attendre vos développeurs lors de l'interfaçage avec l'outil SCM, c'est comme conduire avec les freins à main activés. Cela ralentit votre cerveau et votre travail. Obtenir de nouveaux fichiers dans votre vue d'instantané prend environ 30 minutes pour les artefacts 10K. Une mise à jour (aucun artefact n'a été modifié) pour le même montant prend environ 5 minutes. Lorsque vous expérimentez beaucoup et que vous sautez entre différentes vues à jour, cela signifie beaucoup d'attente. Cela devient encore pire lorsque vous travaillez sur des fichiers et que vous souhaitez vous enregistrer ou les mettre à jour. Le départ, l'enregistrement et l'ajout aux cycles de contrôle de la source prennent environ 10 à 15 secondes, ce qui est évidemment un cauchemar. Cela devient très ennuyeux lorsque vous refactorisez le changement de nom ou le déplacement de types ou de méthodes (de nombreux fichiers peuvent être affectés).
Manque de support du développement distribué
Aujourd'hui, le développement de logiciels est souvent une chose distribuée (les développeurs sont répartis dans le monde entier et travaillent sur le même produit/projet). ClearCase ne convient absolument pas à cela, car il est mal adapté au travail hors ligne. Pour effectuer une extraction (action avant de pouvoir modifier un fichier/dossier), vous devez être connecté au réseau. Ici, vous pouvez utiliser l'option Hijack mais c'est plutôt une solution de contournement en tant que fonctionnalité (vous déverrouillez simplement le fichier sur le système de fichiers). Si vos sites de développement sont éloignés de votre serveur ClearCase, la latence de check-in/check-out peut même augmenter si considérablement qu'elle n'est pas utilisable du tout. Il existe des solutions de contournement pour cela, comme l'utilisation de ClearCase Multisite (technologie de réplique scm DB), mais vous devez payer un supplément pour cela et n'est pas trivial à administrer.
Git comme alternative
Bien qu'étant un grand fan + partisan de l'Open Source, je suis toujours prêt à payer de l'argent pour un bon logiciel. Mais en regardant IBM-Monster ClearCase, je n'investirais pas mon argent ici, il a toutes ces lacunes discutées, et de plus IBM ne semble pas investir d'argent pour améliorer leur produit de manière significative. Récemment, j'ai jeté un œil à une scit Git qui a l'air très bien, en particulier pour ses fonctionnalités de branchement + fusion, où ClearCase a ses principaux atouts.
Ces informations proviennent de http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/
Peut-être le pire logiciel jamais créé. Je ne travaillerai pour aucune entreprise qui utilise quoi que ce soit de rationnel. Mis à part CC complètement planter et redémarrer fréquemment mon poste de travail sur les builds dynamiques. Que se passe-t-il lorsque vous poussez quelque chose vers le contrôle de code source et que CC fait ce qu'il fait le mieux, planter? Votre code est-il alors mis en perdu + trouvé, sauvegardé quelque part peut-être? Non, c'est parti pour toujours. Donc, si vous êtes dans une situation horrible d'utilisation de ce logiciel géant coûteux, conservez des doublons de tout. Bon travail Rational/IBM. Façon de capturer la partie la plus importante du contrôle de source, la fiabilité. Meurs lentement.
Inconvénients de ClearCase - un ajout au message le plus détaillé ici.
L'outil de fusion ne vaut pas la peine. Il vous aide à peine, ne se souvient d'aucune décision que vous avez prise, c'est juste un diff glorifié.
L'outil de fusion doit vérifier les répertoires pour même vérifier s'ils ont besoin d'une fusion. C'est un peu fou.
J'utilise BitKeeper au travail (supposons Git), et la fusion de deux référentiels même s'il y a des conflits est si triviale et conviviale même avec la ligne de commande, tandis que ClearCase ayant des tonnes d'outils GUI est un processus long et laborieux qui est également extrêmement sujet aux erreurs .
Tous les outils GUI nécessitent une tonne de latence. Même voir ce qui peut être fait sur un fichier nécessite une connexion haut débit. Ainsi, un clic droit dans l'outil ClearCase sur un fichier travaillant à domicile pourrait prendre une minute ou deux avec un accès Internet haut débit en raison de la quantité extrême de besoins en réseau.
Quelqu'un peut complètement gâcher le référentiel ou les enregistrements s'ils rendent leurs spécifications de vue différentes de celles de l'équipe. Ce qui est assez fou que personne ne puisse vérifier une branche; ils ont besoin de la spécification de vue appropriée qui leur donnera incidemment les bonnes choses. Le concept peut être agréable et flexible, mais dans 99% des cas, il provoque juste beaucoup de douleur. Ai-je mentionné que vous ne pouvez pas envoyer vos spécifications via Microsoft Outlook, car les outils CC n'acceptent pas UTF-8, vous ne pouvez donc pas le copier-coller?
J'ai absolument rien Ravi de dire à propos de CC. Je l'ai utilisé pendant 2 ans dans 2 entreprises et je l'ai laissé tomber en un clin d'œil heureux tout le temps. Il est également impossible de simplement expérimenter à la maison avec vos propres projets, vous apprendrez donc toujours SVN ou Git à la maison et serez obligé de passer par des difficultés ClearCase au travail. Personne que je connais n'a jamais utilisé CC volontairement. Ils ne l'utilisent que parce qu'un gestionnaire au travail a décidé que CC est le chemin du salut et a forcé tout le monde à y migrer. En fait, ma dernière entreprise a migré de CVS vers ClearCase, et après un an de ClearCase à SVN. C'était ça détesté.
ClearCase n'est pas seulement une chose qui vous fait dire non. C'est comme vivre dans une maison infestée de fourmis. Chaque fourmi n'est au mieux qu'un inconvénient mineur, mais l'infestation vous rendra fou.
J'essaie de consolider quelques commentaires dans un véritable post ici. Je ne suis pas vraiment là pour vous convaincre que l'un est meilleur que l'autre, sauf en faisant quelques remarques:
ClearCase est un bon outil, mais c'est un outil compliqué. Il n'y a pas moyen de contourner cela - il n'a pas de mode "installation facile". :-) D'un point de vue technique, il n'y a rien que git ou SVN puisse faire que ClearCase ne puisse pas (bien que souvent la terminologie soit différente, car les projets Open Source ont tendance à simplement inventer une nouvelle taxonomie là où il en existait déjà une), mais certaines choses sont certainement plus faciles/plus difficile pour un système donné, selon leur conception. Les vues "instantanées" ClearCase sont fondamentalement la même chose que si vous extrayiez un référentiel de SVN ou CVS - il s'agit d'une copie locale du code source sur votre machine, avec des pointeurs vers le serveur central pour des outils permettant d'interroger l'historique des versions, etc. Vous pouvez travailler avec ces vues sans aucune connexion réseau au serveur ClearCase une fois qu'elles ont été créées, et vous pouvez les "recycler" pour éviter de télécharger à nouveau l'intégralité de votre référentiel lorsque vous souhaitez passer à une autre branche, par exemple Exemple. Les "vues dynamiques" sont fondamentalement une invention ClearCase et le mode de fonctionnement standard pour un LAN. Ils ressemblent à l'extraction d'un référentiel SVN, mais ils ne copient aucun fichier tant que vous n'avez pas apporté de modifications. De cette façon, la vue est disponible immédiatement, mais elle ne peut évidemment pas être utilisée si le serveur Clearcase principal n'est pas disponible et est désagréable à utiliser avec une connexion à latence élevée. Ils ont également l'avantage de pouvoir être montés en tant que lecteur réseau sur n'importe quelle machine ayant accès au serveur sur lequel ils ont été créés, donc si votre poste de travail Windows meurt, vous pouvez simplement vous connecter à un autre, monter votre vue et obtenir retour au travail, car tous les fichiers sont stockés soit sur le serveur VOB (pour les fichiers que vous n'avez pas modifiés sur cette branche), soit sur le serveur view_server (pour les fichiers que vous avez créés ou modifiés uniquement dans cette vue).
En outre, et cela mérite son propre paragraphe .... clearmerge vaut presque le prix de l'admission à lui seul. C'est de loin le meilleur outil de fusion que j'ai jamais utilisé dans ma vie. Je crois fermement que de nombreuses mauvaises pratiques dans SCM se sont développées en raison d'un manque d'outils de fusion de haute qualité, de sorte que les utilisateurs de CVS n'ont jamais appris à utiliser correctement les branches et cette peur de la branche s'est propagée à nos jours sans raison particulièrement bonne.
Ok, tout cela étant dit, si vous cherchez des raisons de ne pas utiliser ClearCase, ils ne sont pas difficiles à trouver, même si je pense que ce n'est pas la bonne façon de procéder. Vraiment, vous devriez avoir à trouver de bonnes raisons pour utiliser ClearCase, pas des raisons de NE PAS utiliser ClearCase. Vous devez entrer dans n'importe quelle situation SCM en supposant que ClearCase est trop d'outil ou un outil trop compliqué pour le travail, puis voyez si vous avez une situation qui vous encourage à l'utiliser de toute façon. Avoir des logos IBM ou Rational n'est pas une bonne raison .. :-)
Je ne considérerais même pas ClearCase à moins que vous ne puissiez dire oui à toutes les déclarations suivantes:
Mon expérience est principalement limitée par CC, CVS et SVN. En principe, CC est technologiquement capable, prêt pour l'entreprise et comparable par ses fonctionnalités à tout VCS moderne. Mais il a plusieurs défauts qui le rendent inutilisable dans tout environnement orienté vers les personnes. Pour les environnements orientés processus, il est probablement plus approprié, bien que je doute que ces environnements soient appropriés en eux-mêmes. Peut-être, dans les logiciels militaires, cosmiques ou médicaux, je ne sais pas. Quoi qu'il en soit, je pense que même pour ces domaines, il existe des outils appropriés et toujours plus conviviaux.
En plus d'être un VCS techniquement compétent, CC présente plusieurs avantages distinctifs:
À mon avis, leur utilisation est limitée sauf la dernière; et ils ne compensent pas les défauts. Vue dynamique Nice en théorie, mais pas toujours disponible en pratique. L'arbre des versions est beaucoup moins utilisé dans d'autres VCS, bien que nécessaire dans CC en raison de la prolifération des branches (voir 6). Les déclencheurs, comme je le sais, sont très détaillés et capables, mais je pense que pour la plupart des tâches pratiques, les crochets SVN sont assez bons. Et maintenant sur les inconvénients qui concernent principalement la convivialité:
cleartool
(avant la version 7.1), laissant seul des vues dynamiques.ClearCase semble extrêmement puissant, de l'extérieur. Mais vraiment, c'est juste que le nombre de commandes et d'options que vous devez utiliser pour le flux de travail de base est si élevé que celles-ci se cachent derrière quelques alias ou scripts, et vous vous retrouvez avec quelque chose de moins puissant que CVS, avec l'utilisabilité de Visual Source Sûr. Et chaque fois que vous voulez faire quelque chose d'un peu plus compliqué que vos scripts ne le permettent, vous ressentez une sensation de malaise à l'estomac.
Comparez cela avec Git, qui semble compliqué de l'extérieur, mais après une semaine de travail avec lui, vous vous sentez complètement en contrôle. Le modèle de référentiel est simple à comprendre et incroyablement puissant. Parce qu'il est facile d'accéder aux écrous et boulons, il est en fait agréable de creuser sous la surface de votre flux de travail quotidien.
Par exemple, trouver une tâche triviale comme comment simplement afficher une version non HEAD d'un fichier dans une vue instantanée m'a pris quelques heures et ce que j'ai fini par être n hack complet . Pas le genre de hack agréable non plus.
Mais dans Git, trouver une tâche apparemment compliquée, comme comment engager interactivement seulement quelques changements, (et laisser le reste pour plus tard) était très amusant, et tout le temps j'ai le sentiment que le VCS me permet d'organiser le code et l'histoire d'une manière qui me convient, plutôt que l'histoire soit un accident de la façon dont nous avons utilisé le VCS. "Git signifie ne jamais avoir à dire 'tu devrais avoir'" .
Dans mon travail, j'utilise Git pour toutes sortes de tâches légères, même dans ClearCase. Par exemple, je fais TDD, et je m'engage à Git chaque fois qu'un tas de tests réussit et que je suis sur le point de refactoriser. Une fois la tâche terminée, je m'enregistre dans ClearCase et Git m'aide à revoir exactement ce que je change. Essayez simplement d'obtenir ClearCase pour produire un diff sur quelques fichiers - ce n'est pas possible! Utilisez Google pour découvrir les différents hacks que les gens ont essayé de contourner. C'est quelque chose que le contrôle de version devrait faire dès le départ, et cela devrait être facile! CVS a cela depuis des décennies!
À mon avis? Seule raison de l'avoir? Si vous suivez religieusement RUP.
Le soutien est terrible. Nous avons des billets ouverts depuis des années. Notre gourou Eclipse a en fait corrigé un bogue dans son plugin Eclipse localement en environ 30 minutes en désassemblant le fichier Java. Mais le ticket n'a toujours pas reçu le support de niveau un. De temps en temps, ils essaient pour le fermer sournoisement ou nous le renvoyer "pour essayer la dernière version" (même si nous leur avons envoyé une recette de reproduction qu'ils pourraient essayer par eux-mêmes.).
Ne touchez pas avec un mât de barge.
Performance.
ClearCase est puissant, stable (SI correctement entretenu et supervisé) mais il est lent. Géologique parfois.
Les vues de vues dynamiques entraînent des temps de construction horribles, les vues instantanées peuvent prendre un certain temps à mettre à jour (pause déjeuner pour les grands projets) ou à la caisse (rentrer à la maison pour la journée).
Clearcase est tellement ennuyeux qu'il pousse les gens à écrire de la poésie à ce sujet:
http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control.html
http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it/
Les développeurs passeront la moitié de leur temps à trouver clearcase avant de faire n'importe quel travail et une fois qu'ils auront compris, ils installeront git localement et ne pousseront que vers le dépôt clearcase si nécessaire.
Vous devrez employer un administrateur Clearcase dédié.
Je suggérerais SVN pour le jeu d'outils et Git pour la mise à l'échelle/le flux de travail. Je suggère également d'éviter CC si possible. (Sans compter l'argent, le fait qu'il soit si pénible à utiliser qu'il nécessite un administrateur à temps plein est une blague totale)
J'ai récemment dû me débattre avec une situation similaire. Vous pouvez peut-être apprendre de mon histoire.
L'équipe à laquelle je venais d'être affecté utilisait un outil lourd de manière compliquée et sujette aux erreurs. J'ai d'abord tenté de les vendre sur mes outils et processus de choix. Cette tentative a lamentablement échoué. J'ai été sidéré qu'ils choisiraient un environnement aussi lourd que celui qui était à la fois plus facile et plus efficace. Il s'avère qu'ils voulaient être disciplinés, et utiliser un processus douloureux leur semblait discipliné. Cela semble bizarre, mais c'est vrai. Ils avaient aussi beaucoup d'autres idées fausses. Après avoir compris ce qu'ils recherchaient, nous sommes restés avec la même suite d'outils (Serena), mais avons massivement changé la configuration.
Mon conseil est de comprendre ce qui compte pour votre équipe. Extraire ClearCase ne vous mènera nulle part à moins que vous ne parliez de leurs intérêts. Découvrez également pourquoi ils ne veulent pas utiliser d'alternatives. Fondamentalement, faites un peu de collecte des exigences et adaptez vos choix d'outils à vos besoins. Selon vos options, qui sait, Clear Case peut finalement être la meilleure option.
Je ne suis pas totalement contre ClearCase (il a ses avantages), mais pour énumérer les inconvénients:
À partir de la nouvelle version de la version 7.1 CC, le check-in atomique est une fonctionnalité SI vous le souhaitez. Personnellement, je n'en voudrais vraiment pas, mais apparemment, certaines personnes y voient "une caractéristique essentielle". Je ne voudrais JAMAIS un gros volume en une seule fois comme une sorte de version massive. Là encore ... si vous le voulez, allumez-le.
donc ... plus un argument.
Nous utilisons UCM ClearCase intégré à ClearQuest (système de suivi/modification de DR) depuis 4 ans avec plus de 50 développeurs. Nous avons plus de 50 projets UCM sur des milliers de flux qui ont traité plus de 35 000 DR et demandes de changement. Au cours de cette période, nous avons officiellement effectué plus de 600 livraisons d'intégration et tout en ayant jusqu'à 6 efforts de développement et de publication simultanés.
Je suis le gars principal de CM/ClearCase avec une sauvegarde qui est capable d'effectuer les builds de livraison/fusion et d'intégration réguliers. Le réseau et les serveurs sont pris en charge par l'équipe informatique. Tout ce que je peux dire, c'est que nous n'avons eu pratiquement aucun problème venant du côté CM de cet énorme effort de développement et que nous n'avons jamais été un frein au spectacle. Nos développeurs ont été formés uniquement avec les éléments de base et des étapes simples leur ont été données à chaque fois qu'un nouveau projet (branche) était créé à la demande de la direction du projet.
Trop de développeurs se sont plaints de ClearCase car ils ne disposent pas du support CM/IT/ClearCase/Process/Management approprié. Les développeurs doivent se concentrer sur le développement et non SCM ou être un spécialiste des outils. Pour un développement logiciel de grande envergure, au moins 5 à 7% du budget doit être consacré au support CM et aux outils.
ClearCase est parfaitement utilisable si vous êtes prêt à utiliser également un autre système de contrôle de version! personnellement, je trouve que l'utilisation de Mercurial ontop of CC fonctionne assez bien.
Le plus gros inconvénient pour moi est à la fois les performances (surtout si votre VOB est multisite ou hors site), et les temps d'arrêt potentiellement longs.
Si vous êtes comme moi et travaillez dans un bureau relativement petit au sein d'une grande entreprise (sans informatique sur site), les serveurs Clearcase en panne peuvent vous coûter la meilleure partie d'une journée de travail en non-productivité et trouver les bonnes personnes pour le réparer.
En fin de compte, utilisez-le uniquement si vous en avez vraiment besoin pour ce que vous faites et assurez-vous d'avoir un budget informatique costaud pour le maintenir.
Exécuter un JDK à partir d'un VOB sous Linux.
Essayez-le, vous devez jouer avec la variable LD_PRELOAD (je sais!)
le point "il faut une personne dédiée" et "c'est compliqué" etc ....
Le problème principal ici pour trouver ce problème est que vous devez définir si vous voulez que la gestion de la configuration soit effectuée dans votre organisation (ce qui n'est PAS la gestion des versions). La gestion de la configuration est comme la gestion de projet: même sans outil, vous pouvez toujours gérer le projet et sans outil, vous pouvez faire la gestion de la configuration. Beaucoup de gens ont du mal à comprendre cela et beaucoup de gens pensent que la gestion de la configuration est égale à un outil qui versionne des sources de logiciels ou quelque chose ...... (donc des comparaisons avec des sous-versions ou d'autres systèmes de gestion de VERSION)
ClearCase est une solution conçue pour être utilisée dans un environnement de gestion de configuration ERGO: il y a un gestionnaire de configuration (tout comme "il y a un gestionnaire de projet").
Donc ... si, selon vous, cette personne dévouée est là pour gérer un outil, je pense qu'il y a quelque chose de très mal. À mon avis, il y a une personne dédiée qui gère la configuration qui, du point de vue de l'utilisateur final, ne se présente qu'en cas de problème avec l'outil, mais considère cela comme seulement 1% de son travail.
Donc, ce que vous devez faire (comme dans tout autre projet logiciel), revenez à vos exigences et compilez une liste d'exigences sur ce que votre organisation veut avec la gestion de la configuration. ET OUI, comme dans tout autre projet logiciel, vous aurez des utilisateurs (comme par exemple des développeurs) qui ne sont pas du tout d'accord avec d'autres utilisateurs (comme par exemple la gestion) sur certaines exigences. Là réside l'imho clé sur certaines réactions que j'ai lues ici.
Et à mon humble avis si vous avez la liste des exigences de l'organisation ET un gestionnaire de configuration dans le mélange .... le choix est assez clair (voir aussi le forum sur www.cmcrossroads.com)
ClearCase n'est pas un outil uniquement pour les utilisateurs finaux entrant leurs sources sous contrôle de version comme Subversion ou git. C'est seulement 1% de la raison pour laquelle un gestionnaire de configuration veut vraiment un outil de gestion de configuration mature.
Et ... Je pense que le choix d'un système CM ne devrait jamais incomber aux développeurs comme choisir le bon outil de gestion de projet ou le bon système CRM. Les développeurs sont des utilisateurs finaux d'une certaine partie des fonctionnalités de l'outil.