Question

Votre environnement de travail utilise-t-il Harvest SCM ?Je l'ai utilisé maintenant à deux endroits différents et je trouve cela épouvantable.Dans une situation, j'ai écrit un script de conversion pour pouvoir utiliser CVS localement, puis importer quotidiennement les modifications dans le système Harvest pendant que je dormais.La société était fanatique de l'utilisation de Harvest, malgré le fait que 80 % des programmeurs réclamaient quelque chose de différent.C'était inutilement compliqué, lent et lourd.C'est désormais une exigence de mon travail que Harvest ne soit pas utilisé là où je travaille.

Quelqu'un d'autre a-t-il déjà utilisé Harvest ?Quelle est votre expérience ?Aussi mauvais que le mien ?Avez-vous utilisé d'autres solutions de contournement différentes ?Pourquoi ce produit est-il encore acheté aujourd’hui ?

Était-ce utile?

La solution

Il y a de fortes chances que votre entreprise ait une sorte de contrat avec CA : utilisez-vous de nombreux autres logiciels CA en interne ?

Modifier: J'imagine!

Autres conseils

J'ai eu l'avantage d'utiliser Harvest dans une banque et vous ne trouverez jamais une ruche plus misérable de racaille et de méchanceté, des gants d'enregistrement non documentés à triple fourche arrière qui nécessitent 15 étapes pour effectuer un simple changement.Peu importe qu'ils n'utilisaient même pas de branchement.C'est un outil maléfique, ne le laissez pas vous prendre dans ses griffes.

OK, je vais répondre à cette question dans quelques épisodes car il est tard ici et Harvest est un gros sujet.

Tout d'abord, CA Harvest (c'est ainsi que s'appelle la version 7 du produit, la version 5 est CCC dont je ne me souviens pas de l'extension, la version 12 s'appelle CA SCM) est bien plus qu'un simple outil SCM - de la même manière que ClearCase est un bien plus qu'un outil SCM.SVN, CVS, git, hg sont tous des SCM standard de base et un peu plus.

Ce que vous obtenez avec Harvest est une politique SCM +.Il vous donne un endroit pour stocker et versionner votre code et le tout envelopper dans une politique sur la façon dont ce code évolue au sein de votre organisation, du développement à la production.Avez-vous une politique dans votre organisation selon laquelle un développeur principal doit signer le code avant sa publication au contrôle qualité ?Harvest vous permet de définir l'approbation en tant que politique et de l'appliquer - vous ne pouvez pas migrer le code de l'état "Dev" vers l'état "QA" jusqu'à ce qu'une des personnes du projet désignées comme Lead Dev fasse exactement cela.Avez-vous une politique selon laquelle tout code SQL doit être approuvé par un administrateur de base de données avant de progresser ?Harvest vous permet de définir cette politique et de l'appliquer. Vous pourriez donc avoir besoin de l'approbation de Lead Dev et de DBA avant la migration du code.

Harvest n'est en aucun cas un outil pour la plupart des éditeurs de logiciels : il est généralement utilisé dans le secteur financier ou dans le monde des affaires, où un cadre réglementaire très strict régit ce qu'ils peuvent faire.Les banques doivent se conformer à la loi Sarbannes-Oxley, qui impose des exigences d'audit très strictes.Harvest offre la possibilité de définir toutes sortes de contrôles et de processus concernant la manière dont les modifications apportées aux actifs de la banque évoluent tout au long de leur cycle de vie.Je connais de grandes organisations de transports publics qui sont responsables de la sécurité et de la ponctualité de millions de personnes chaque jour, qui ont besoin des mécanismes de contrôle étroitement définis qu'offre un outil comme Harvest.J'ai également vu Harvest utilisé dans des environnements où des milliers de développeurs l'utilisent quotidiennement - oui, je n'exagère pas, littéralement des milliers de développeurs dans une organisation, écrivant du code pour un détaillant mondial, proposant des solutions informatiques chaque jour dans les magasins des environs. le monde.

La récolte n'est pas parfaite, je pense que la version 12 est bien meilleure.Il a trop de moments "c'est juste stupide", il effectue une gestion des versions par fichier à la manière de CVS, et une gestion des versions de branchement et de répertoire de type CVS (ou son absence), avec tout le plaisir que nous connaissons et craignons.Une fois que vous le savez et l’acceptez, ce n’est pas intrinsèquement plus lent que n’importe quel autre SCM que j’ai utilisé.Il y a simplement un travail plus important à faire que de simplement versionner votre code.

Un autre grand avantage, et encore plus grand avec la version 12, est son intégration avec d'autres outils CA (et sa capacité à s'intégrer avec des outils non-CA, mais pas beaucoup pour le moment) - suivi des défauts avec Quality Centre, gestion des tickets d'incident avec Unicentre Service Desk. , déploiement de logiciels sur le bureau avec SDM.Vous pouvez définir des ponts entre ces applications qui aboutissent à une intégration beaucoup plus étroite de ces préoccupations, avec des effets généralement positifs sur la précision et l'actualité.

Si vous avez affaire à la distribution de logiciels à une entreprise mondiale, avec des milliers de postes de travail et de serveurs, des systèmes mainfame/milieu de gamme/middleware, des processus de contrôle des modifications à toute épreuve, de la complexité, des réglementations, des contrats, des auditeurs, tout un tas de complexité, Harvest est juste un outil parmi toute une suite d’outils dont vous aurez besoin.Si vous souhaitez simplement un simple SCM pour une équipe de 10 développeurs prenant en charge quelques centaines de clients, ce n'est pas une bonne solution.

J'essaierai d'ajouter quelque chose sur la façon dont Harvest fonctionne réellement la prochaine fois : référentiels, projets, vues, packages, formulaires, processus, etc.Cela pourrait aider à expliquer pourquoi certaines organisations l’utilisent et pourquoi ce n’est pas pour tout le monde.

J'ai utilisé Harvest lors d'un court concert dans le secteur bancaire il y a quelques années.Je suis d'accord, c'était pratiquement inutilisable, mais les responsables de l'assurance qualité semblaient l'adorer.

J'ai travaillé pour une entreprise qui avait deux choix :ClearCase ou Récolte.Subversion n'avait jamais été envisagée, et la raison en était que ClearCase (IBM) et Harvest (CA) avaient déjà tous deux des contrats mainframe de longue date.

Nous utilisons Harvest depuis une dizaine d'années (2000-2010) et même si nous envisageons maintenant de le remplacer, je pense qu'il nous a très bien servi.Harvest (gardons ce nom même si ce n'est plus son nom officiel), a été le premier outil majeur que nous avons implémenté pour nous soutenir en R&D et à l'époque, personne d'entre nous ne savait grand-chose sur les nombreux aspects du cycle de vie des applications (versioning du code, branchement, tests automatisés, tests de régression, assurance qualité, déploiement dans de nombreux environnements d'exécution et de production, restauration, correctifs d'urgence, mises à jour de maintenance, etc.) ;aujourd’hui, nous en savons beaucoup plus et nos processus de développement nous servent très bien (même s’il n’y a pas beaucoup de place pour de nombreuses améliorations).Nous n'avons pas une organisation très hiérarchique (nous n'avons pas beaucoup d'inspecteurs qui doivent approuver les modifications), mais il est très utile de prendre en charge les « points de contrôle » - des points du processus de développement où quelque chose doit se produire (par ex.tests fonctionnels ou tests d'intégration).

L'inconvénient (pour nous) de Harvest en termes de convivialité a été "ce qu'un programmeur doit faire pour modifier x lignes de code".Aujourd'hui (là-bas), il existe de nombreux moyens plus simples et plus efficaces que Harvest pour obtenir un accès en écriture aux fichiers de code source, effectuer vos mises à jour, puis renvoyer à nouveau les fichiers/les déplacer vers un autre aspect du processus de développement (tests, déploiement, etc. .).Un autre inconvénient est le prix ;c'est cher.

Gain que nous avons eu avec Harvest :Il prend en charge le flux de travail et nous avons donc pu disposer d'un système unique pour gérer la gestion des versions du code, le flux de travail et l'automatisation des processus.Si possible, il est plus facile de maintenir et d’améliorer un seul système que plusieurs.En plus de fournir un accès en ligne cmd aux processus internes (permettant de créer des scripts de solutions spéciales lorsque vos processus l'exigent), Harvest est également facilement configuré par une interface graphique.Il a le concept de "Package" qui permet d'attacher facilement de nombreuses métadonnées aux modifications de code et de gérer les modifications indépendamment des autres modifications (version au niveau du fichier plutôt que des ensembles de modifications contenant la masse complète du code).Ceci est utile pour gérer les modifications indépendantes d’urgence et de maintenance.

Si un développeur n'est qu'un programmeur et ne pense qu'à l'aspect codage du développement logiciel, j'imagine qu'il pourrait être très frustré par Harvest.Si un développeur est un développeur et comprend que le développement de logiciels est bien plus que du codage et que le codage n'est que le tout début du cycle de vie d'un logiciel, je pense qu'il verrait de nombreux avantages avec Harvest.

J'utilise HARVEST depuis 4 ans et je l'adore.Le type de support qu'il vous offre pour contrôler le mouvement du code est vraiment fantastique.Nous utilisons HARVEST pour déployer des applications sur Websphere.Il fait également un travail incroyable en déployant les plugins sur le serveur Web avec l'application.Lorsque vous souhaitez mettre en place un processus pour déplacer le code dans un environnement de grande entreprise, je ne pense pas qu'un autre outil puisse se rapprocher de HARVEST.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top