Comment convaincre une entreprise de changer de contrôle de source [fermé]

Question

Mon lieu de travail actuel est actuellement en transition, un nouveau propriétaire a pris le relais, les choses sont enfin standardisées et des directives appropriées sont appliquées.

Mais nous utilisons toujours VSS, il n'y a vraiment aucune raison de l'utiliser autre que ce qui est initialement configuré.Nous n'utilisons pas Visual Studio, ni aucun outil qui le nécessite spécifiquement.

Quel serait le meilleur argument que je puisse avancer pour les convaincre que passer à quelque chose comme Subversion serait une bien meilleure solution, à long terme.

Answer 1

VSS s'appuie totalement sur les clients pour gérer la base de données.Si un client abandonne la connexion au milieu d'une écriture sur le réseau au mauvais moment, votre fichier est supprimé sur le serveur.Pas seulement le conseil, mais toute l’histoire.J'espère que vous avez une bonne sauvegarde.Je l'ai vécu.C'est une mauvaise nouvelle.

L'utilisation de VSS sur VPN ou d'autres connexions à distance est catastrophique.Il utilise SMB pour transférer les données, et vous devez récupérer le fichier et tous ses deltas juste pour obtenir le pourboire.Méchant.

J'ai vu VSS commencer à fonctionner avec 1 Go de données.Erreurs de base de données, etc.MS (quelque part dans une FAQ ou une Ko) indique que 2 Go est vraiment la limite maximale de sécurité.Il n'existe pas de bons outils de gestion (les clients gèrent l'asile), donc vous n'êtes pas vraiment averti à ce sujet.

Rien avec un processus serveur pour fournir un certain niveau de transactions et de contrôle d'intégrité est une solution supérieure.

Answer 2

Le meilleur argument devrait être la raison pour laquelle vous souhaitez qu’ils passent à la subversion.:)

Je ne connais absolument rien au VSS, mais l'expression "si ce n'est pas cassé, ne le répare pas" me vient à l'esprit.Vous devez montrer à vos managers que VSS est défectueux et doit être réparé.C’est encore mieux si vous pouvez montrer à la direction comment cela lui permettrait d’économiser de l’argent.

Answer 3

@Adam Davis:Euhhh en fait Adam, VSS est un horrible système de contrôle de source.Il a une longue histoire de corruption de l’historique et de perte de données.Il est mauvais en matière de fusion, ne gère pas bien plusieurs développeurs et est très lent.De plus, l'histoire est médiocre.Microsoft ne le supporte plus vraiment, vous remarquerez qu'ils ne l'ont jamais utilisé pour leur propre développement interne et maintenant ils ne le vendent même plus au profit d'une solution plus moderne (VSTS).En bref, si vous devez choisir entre VSS et tout autre type de contrôle de code source, optez pour l'alternative.

Answer 4

En passant simplement en revue les fonctionnalités qu'un bon contrôle de source apporte :

• possibilité de consulter facilement les journaux indiquant qui a fait quoi, quand et dans quel ordre, dans quels fichiers
• garder un historique des versions passées de tout
• revenir facilement en arrière et reproduire une version spécifique de vos fichiers à partir de n'importe quelle version antérieure, pour reproduire plus facilement les bugs signalés dans les anciennes versions
• possibilité de récupérer le code supprimé ou de supprimer les modifications indésirables, sans avoir à vous soucier de la perte de données au cours du processus

Answer 5

Tout document prouvant que le changement réduira les coûts.À défaut, des graphiques et des diagrammes multicolores.Peut-être une présentation PowerPoint.

Answer 6

Internet regorge d’articles bien écrits sur les failles de VSS.Je rassemblerais cela comme un ensemble de preuves pour m'éloigner du VSS.Recherchez une exigence clé que VSS ne peut pas prendre en charge (travail à distance, prise en charge sur d'autres systèmes d'exploitation, intégration d'outils) et utilisez-la pour résoudre votre problème.Vous devez ensuite trouver un système de contrôle de code source qui correspond bien aux exigences de votre organisation. Êtes-vous sûr que Subversion est ce système ?Organisez une démonstration du système que vous avez choisi et utilisez-la pour prouver sa valeur.

J'ai mis en œuvre ce changement chez un employeur précédent (d'abord vers CVS, puis vers SVN), et même si cela a réussi, nous avons dû créer de nombreux éléments à la périphérie et nous appuyer sur de nombreux projets open source (parfois peu fiables) pour obtenir tous les outils dont nous avions besoin.Avec le recul, j'aurais dû envisager d'essayer d'évaluer des outils professionnels tels que Perforce, Vault ou encore Team System.Après les avoir évalués, j'aurais pu porter un jugement de valeur approprié sur la question de savoir si CVS/SVN valait leur prix « gratuit ».

Answer 7

être capable de gérer les branchements et les forks est un début.

Essayez d'utiliser Subversion pendant un certain temps en parallèle avec vss, vous trouverez probablement de nombreux arguments pour convaincre votre patron.Si vous ne le faites pas, votre patron a raison, aucune raison de changer.

Answer 8

Demandez-leur de rechercher sur Google « problème vss », « corruption sécurisée de la source » ou consultez simplement la page Wiki pour cela.Cela devrait les convaincre que ce n’est probablement pas une chose viable à long terme pour vous de parier sur une partie aussi vitale de votre entreprise.

Quelle est la taille de votre équipe ?(c'est-à-dire, je veux dire combien de membres, pas si vous êtes ou non des réfractaires à la salade) Une fois que vous commencerez à avoir plus d'une demi-douzaine d'utilisateurs assez actifs, VSS va vous donner des maux de tête.

Je doute sérieusement que Microsoft l'utilise (en fait, n'utilisent-ils pas une variante Subversion ou CVS personnalisée ?) et vous devez vous demander : si l'entreprise ne mange pas sa propre nourriture pour chiens, pourquoi la mangeriez-vous ?

Answer 9

La réponse fondamentale est que vous devez démontrer que le changement répond aux besoins de l’entreprise.Par exemple:

1. moindre coût de développement
2. horaire plus court (une autre nuance de #1)
3. plus apte à répondre aux exigences du processus (comme la traçabilité des exigences logicielles ou la reproductibilité de la construction, etc.).

Faire valoir ces arguments nécessite également quelque chose de quantitatif, et pas seulement « nous réduirons les coûts parce que c'est l'objectif ». droite façon de le faire!".

Une chose à surveiller est qu'il est trop facile pour un développeur de se convaincre qu'il serait bénéfique d'effectuer le changement sans passer au préalable par les filtres métier de base.Une fois que cela se produit, vous vous retrouvez avec des développeurs mécontents de leurs outils et doublement frustrés car ils pensent que la direction ne les écoutera pas.Si vous ne pouvez pas cocher l'une des choses ci-dessus, vous n'aurez aucune chance de convaincre la direction de quoi que ce soit (sauf si la direction est incompétente, mais c'est pour une autre question).

Answer 10

Pourquoi Subversion plutôt que VSS ?

• Logiciel gratuit
• Plus facile à gérer
• les « enregistrements » sont atomique!
• Facile à créer des branches et à fusionner
• Développement continu (c.-à-d.VSS est une impasse)
• De meilleurs outils pour suivre les modifications et afficher les journaux
• Indépendant des outils et des plates-formes, mais s'intègre également à de nombreux outils

J'ai fait la proposition à mon manager, et la vente a été assez facile.Je l'ai trouvé beaucoup plus facile à utiliser, en particulier pour le branchement (notre projet a pris 5 heures pour "partager et épingler" dans VSS, puis chaque opération a pris plus de temps pour être terminée !).

Answer 11

j'ai écrit précédemment pourquoi VSS n'est pas une bonne idée.Vous pourrez peut-être en tirer des informations.Aussi Cet article et celui-ci contiennent des informations complémentaires.

VSS 2005 a masqué certaines fissures de la version 6.0, mais pas de manière particulièrement convaincante.Le même fondement en état de mort cérébrale demeure.

Answer 12

Même si ce n’est pas un problème, la migration de VSS présente un avantage potentiel.Tout d’abord et surtout, vous n’aurez pas à acheter de nouvelles licences VSS.Deuxièmement, il existe de nombreux exemples de lacunes dans le produit VSS (certaines sont également reconnues par les États membres).La courbe d'apprentissage pour SVN est au moins aussi faible que pour VSS, et si vos développeurs sont plus satisfaits de leur système de contrôle de code source, ils sont plus susceptibles de l'utiliser tôt et souvent.Cela se traduira par beaucoup moins de risques pour votre entreprise, et c'est un avantage appréciable.

Answer 13

@Jason :VSS est cassé.

Je pense que la méthode la plus puissante pour motiver un changement par rapport à VSS est de souligner à quel point votre code source est un atout essentiel.Prendre des risques avec son intégrité n’est pas un choix commercial judicieux.

Ajoutez que vos programmeurs sont les créateurs de cet actif et que faciliter leur productivité signifie plus de valeur dans votre actif de code source.Joel sur Software explique souvent à quel point investir dans ses programmeurs est une grande victoire pour son entreprise.

Les autres réponses ici décrivent toutes des raisons spécifiques que vous pouvez invoquer pour défendre votre cause.

Answer 14

En plus des points techniques donnés dans d'autres réponses, il peut y avoir des raisons non techniques auxquelles vous devriez être prêt à répondre :

Vous devez vérifier si votre entreprise a une politique contre (ou une peur erronée) des logiciels open source.Si l'entreprise ou ses avocats ne comprennent pas les tenants et les aboutissants des licences « infectant » le code propriétaire et celles qui ne l'infectent pas, ainsi que ce que vous pouvez faire avec du code open source qui n'affecte pas votre code propriétaire, vous avoir du mal à les faire passer d'un outil propriétaire à un outil open source.(Et vous pourriez avoir un travail éducatif plus important à accomplir.)

En plaidant pour le passage du système propriétaire (par ex.VSS) vers l'open source (par ex.subversion), vous devrez également être prêt à défendre la qualité du code et l’absence de besoin de garantie ou d’autres droits contractuels concernant le code.