Pourquoi mon équipe devrait-elle adopter le contrôle de source ?

Question

J'ai la possibilité de faire une présentation formelle à mon patron sur tout ce qui est bénéfique pour l'entreprise. Mon idée est d'adopter le contrôle de la source sur mon lieu de travail. J'ai utilisé Mercurial pour gérer mon propre projet au travail, mais le reste de l'équipe n'a pas de système de contrôle de source formel en place. Malheureusement, je ne suis pas très doué pour présenter des idées.

Alors, pouvez-vous me dire pourquoi les développeurs DOIVENT utiliser le contrôle de source ? De plus, pourquoi choisir n'importe quel outil sauf Visual SourceSafe ? Je n'ai pas d'expérience dans l'utilisation de VSS, mais il est probable qu'il demande pourquoi nous n'utiliserions pas simplement les outils de Microsoft.

Je veux entendre l'avis des nombreux programmeurs intelligents qui sont ici ! Mes options préférées sont SVN ou mercurial. Les deux semblent avoir un bon support pour leurs versions Windows, et les deux sont moins archaïques que CVS. De plus, en tant que disciple autoproclamé de l'open source, je préfère suggérer un outil open source :)

Gracias.

Modifier : Pour faire court, généralement, la pratique actuelle pour les autres développeurs est de copier le dossier, de marquer avec la date et peut-être d'enregistrer sur leur propre. Vous voyez le tableau. Et si mon patron dit "si ça marche, pourquoi le réparer ?"

Answer 1

Comparons deux exemples, un environnement de développement qui utilise le contrôle de la source, et un autre qui ne le fait pas.

• R : Utilise
• B : Est-ce que pas Utilisez

Scénario 1 : un projet est demandé, réalisé et mis en œuvre.

A + B) Les programmeurs développent le projet en interne, lorsqu'il est terminé, ils le soumettent à des tests, puis le livrent au client (quel qu'il soit).

Pas de grande différence, dans l'ensemble

Scénario 2 : après la mise en œuvre d'un projet, le client décide qu'il ne veut pas de la fonction X.

A + B) Les développeurs suppriment le code que le client ne veut pas, le testent et le livrent.

Là encore, pas de grande différence.

Scénario 3 : Deux semaines plus tard, le client décide qu'il veut vraiment la fonction X.

A) Les développeurs réintègrent le code qu'ils ont retiré en 2 dans l'arbre de développement normal, le testent et le livrent.

B) Les développeurs recherchent l'ancien code sur leurs machines personnelles, le serveur de fichiers et les sauvegardes. S'ils trouvent le code, ils doivent réinsérer manuellement chaque fichier. S'ils ne le trouvent pas, ils doivent probablement recoder toute la fonctionnalité.

C'est facile de récupérer un vieux code que vous avez retiré pour une raison ou une autre.

Scénario 4 : il y a un bogue étrange dans le système où une fonction est censée renvoyer un résultat booléen, mais renvoie toujours faux. Ce n'était pas le cas il y a deux semaines.

A) Les développeurs examinent toutes les anciennes versions du logiciel et se rendent compte qu'une directive return false n'est pas dans la bonne portée - elle s'exécute à l'intérieur d'une boucle au lieu de l'extérieur.

B) Les développeurs passent des semaines à essayer de comprendre quel est le problème. Ils finissent par remarquer que la déclaration se trouve sur la mauvaise ligne, et la corrigent. Ne pas avoir le contrôle de la source signifie qu'ils ont dû examiner chaque fichier exécuté, plutôt que de trouver les différences entre le moment où cela fonctionnait et maintenant.

Scénario 5 : quelqu'un casse la construction. Il passe les tests et n'est remarqué que des semaines plus tard.

A) L'équipe examine l'historique des livraisons, découvre qui a cassé la construction, oblige cette personne à la réparer et invite l'équipe à dîner.

B) L'équipe doit revenir sur l'ensemble du projet pour trouver l'erreur, mais ne parvient pas à savoir qui a inséré ce code. Les développeurs se rejettent la faute et la dynamique de l'équipe s'effondre.

Il est facile de voir qui a commis quoi, quand et pourquoi.

Answer 2

Utilisez le contrôle des sources parce que ni vous ni votre équipe n'êtes parfaits. La fonction première du contrôle des sources est de garantir que vous disposez d'un historique complet de votre processus de développement. Grâce à cet historique, vous pouvez vous lancer en toute confiance dans des versions "expérimentales", en sachant que si l'expérience échoue, vous pouvez revenir à une version antérieure.

En outre, un bon système de contrôle de source comme svn permettra à plusieurs développeurs de travailler sur le même fichier et fournira des outils puissants pour concilier les différences que chacun introduit.

Answer 3

Simplement - pour avoir un véritable historique du code - pour étudier les changements (raisons des bogues), revenir à des versions antérieures, auditer, etc. La sauvegarde n'est pas suffisante - vous avez simplement une copie de la actuel photo. Vous avez déjà modifié un fichier et souhaité vous souvenir de ce que vous avez fait ?

Answer 4

Vous devez utiliser le contrôle de source pour les raisons suivantes

1) Vous pouvez revenir à n'importe quelle version

2) Différents développeurs peuvent travailler sur les mêmes fichiers.

3) Tous les développeurs auront accès à la même base de code.

4) Vous pouvez suivre les changements

5) Vous pouvez annuler les changements qui ne fonctionnent pas.

6) Le contrôle des sources est la base de l'intégration continue et aide massivement à la TDD.

7) Si vous n'utilisez pas le contrôle de la source, vous deviendrez lentement fou à mesure que des fichiers seront perdus/écrasés et que rien ne fonctionnera comme il se doit.

VSS n'est pas la pire des applications SCC, je l'ai utilisé pendant des années et j'ai fini par le détester, mais il fonctionne, il est simple et beaucoup de gens le connaissent.

Answer 5

Microsoft (MSDN) propose un bon article sur les avantages du contrôle de la source.
http://msdn.microsoft.com/en-us/library/ms173539.aspx

Il y a aussi beaucoup de bonnes questions ici sur SO quant aux avantages et aux inconvénients.
Quels sont vos avantages et inconvénients de git après l'avoir utilisé ?

Subversion est très populaire, mais Git va devenir la "prochaine grande chose" dans le monde du contrôle de source.