Pourquoi mon équipe devrait-elle adopter le contrôle des sources?

J’ai l’occasion de faire une présentation formelle à mon patron sur tout ce qui profite à l’entreprise. Mon idée est d’adopter le contrôle des sources sur mon lieu de travail. J’ai utilisé Mercurial pour gérer mon propre projet au travail, mais le rest de l’équipe ne dispose pas d’un système de contrôle de source formel. 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 choisiriez-vous un outil autre que Visual SourceSafe? Je n’ai pas d’expérience dans l’utilisation de VSS, mais il est probable qu’il se demande pourquoi nous n’utiliserions pas uniquement les outils de Microsoft.

Je veux entendre les opinions des nombreux programmeurs intelligents 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 open source auto-déclaré, je préférerais suggérer un outil open-source. 🙂

Je vous remercie!

Edit : Pour faire court, en général, la pratique actuelle pour les autres développeurs consiste à copier un dossier, à marquer avec une date et peut-être à enregistrer seul. Vous obtenez la photo. Et si mon patron dit “si ça marche, pourquoi le réparer?”

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

    • Un: utilise
    • B: ne pas utiliser

    Scénario 1: un projet est demandé, complété et déployé

    A + B) Les programmeurs développent le projet en interne, une fois terminé, le soumettent à des tests, puis le livrent au client (quel qu’il soit)

    Pas beaucoup de différence, dans la grande image

    Scénario 2: après la publication d’un projet, le client décide qu’il ne souhaite pas la fonctionnalité X

    A + B) Les développeurs suppriment le code que le client ne veut pas tester, délivrer.

    Encore une fois, pas beaucoup de différence.

    Scénario 3: Deux semaines plus tard, le client décide qu’il veut en fait la fonctionnalité X

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

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

    Il est facile d’obtenir un ancien code que vous avez sorti pour une raison ou une autre

    Scénario 4: Il y a un bug étrange dans le système où une fonction est supposée renvoyer un résultat booléen, mais retourne toujours faux. Ce n’était pas comme ça il y a deux semaines.

    A) Les développeurs examinent toutes les anciennes versions du logiciel et réalisent qu’une directive de retour de faux n’est pas dans la scope appropriée – elle s’exécute dans une boucle plutôt qu’en dehors.

    B) Les développeurs passent des semaines à essayer de comprendre le problème. Finalement, ils remarquent le retour sur la mauvaise ligne et le résolvent. Ne pas avoir de contrôle de code source signifie qu’ils devaient examiner chaque fichier exécuté, plutôt que de trouver les différences par rapport au moment où il fonctionnait et maintenant.

    Scénario 5: Quelqu’un rompt la construction. Il est passé des tests et n’est remarqué que des semaines plus tard.

    A) L’équipe examine l’historique des validations, découvre qui a cassé la construction, fait en sorte que cette personne le répare et achète le dîner de l’équipe.

    B) L’équipe doit parcourir l’ensemble du projet pour trouver l’erreur, mais ne peut pas déterminer qui a mis ce code. Les développeurs se blâment mutuellement et la dynamic de l’équipe échoue.

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

    Utilisez le contrôle de la source car ni vous ni votre équipe ne sont parfaits. La fonction principale du contrôle de source est de vous assurer que vous avez un historique complet de votre processus de développement. Ayant cet enregistrement, vous avez la possibilité de créer des versions “expérimentales” en toute confiance, sachant que si l’expérience échoue, vous pouvez sauvegarder sur une version antérieure.

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

    Simplement – pour que vous ayez une véritable histoire du code – pour enquêter sur les modifications (raisons des bogues), pour revenir aux versions, à l’audit, etc. La sauvegarde ne suffit pas – vous avez simplement une copie de la photo actuelle . Vous avez déjà changé un fichier et vous souhaitez vous souvenir de ce que vous avez fait?

    Vous devez utiliser le contrôle de code source pour ces raisons

    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 access à la même base de code

    4) Vous pouvez suivre les changements

    5) Vous pouvez annuler les modifications qui ne fonctionnent pas

    6) Le contrôle de la source est la base de l’continuous integration et aide massivement avec TDD

    7) Si vous n’utilisez pas le contrôle de source, vous allez devenir fou à mesure que les fichiers sont perdus / écrasés et que rien ne fonctionne comme il se doit

    VSS n’est pas la pire application SCC, je l’ai utilisée pendant des années et je l’ai détestée, mais ça marche, c’est simple et beaucoup de gens le savent.

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

    Il y a aussi beaucoup de bonnes questions ici sur le pour et le contre.
    Quels sont vos avantages et inconvénients de git après l’avoir utilisé?

    Subversion est très populaire, mais Git va être la “prochaine grande chose” dans le monde du contrôle de code source.

    Voici un exemple simple et réel.

    Il y a quelques années, mon patron m’a dit: “Feature XYZ fonctionnait, et maintenant, ça ne marche pas. Personne ne sait ce qui s’est passé. Pouvez-vous le réparer?”

    Maintenant, je n’ai jamais travaillé avec la fonctionnalité XYZ auparavant. Donc, le réparer impliquerait beaucoup d’essayer de comprendre ce qu’il fait.

    Mais nous avons le contrôle des sources! Donc je fais ça:

    • Créez un script de test pour tester la fonctionnalité XYZ: “Cliquez ici, tapez ceci, cliquez ici, etc.”
    • Obtenir la version actuelle Construire. Tester. La caractéristique XYZ est cassée.
    • Obtenez la version d’il y a une semaine. Construire. Tester. Fonctionnalité XYZ fonctionne.
    • Obtenez la version à mi-chemin entre les deux. Construire. Tester. Fonctionnalité XYZ fonctionne.
    • Obtenez la version à mi-chemin entre la précédente et la précédente. Construire. Tester. La caractéristique XYZ est cassée.

    J’ai continué à faire cette recherche binary jusqu’à ce que j’atteigne le sharepoint changement: la version 145 (nous allons dire) avait la fonctionnalité qui fonctionnait, mais la version 146 l’avait brisée. Ensuite, je viens de faire une comparaison entre ces deux versions pour voir ce qui a changé. Notre chef technique ( soupir ) a vérifié le code qui a changé la fonctionnalité, mais a également introduit un effet secondaire qui a cassé la fonctionnalité XYZ.

    J’ai donc supprimé l’effet secondaire, testé … et voilà, la fonctionnalité XYZ a encore fonctionné.

    Sans contrôle de source, vous ne pouvez jamais faire cela. Vous devrez flâner, changer une chose ou une autre, en espérant pouvoir utiliser comme par magie la chose qui fait fonctionner le dispositif XYZ.

    Avec le contrôle de code source, il vous suffit de tester votre chemin à travers les versions, d’identifier le code exact à l’origine du problème et de le résoudre.

    Il me semble que la plupart des personnes ont couvert la principale caractéristique du contrôle de code source, mais l’un des plus gros atouts est ignoré. Ceux-ci sont:

    Branches

    Sans un référentiel de code source, il est impossible de créer des twigs (ou des copies / stream / etc.) De votre code à des fins particulières. Ne pas être capable de créer et de fusionner des twigs est l’une des choses les plus importantes qui empêchent VSS d’être un véritable système de contrôle de code source. Certains des objectives d’une succursale comprennent:

    Correction d’un bug

    Parfois, vous devez résoudre un bogue et le placer loin de la version principale ou de la version principale de votre code. Cela peut être pour résoudre un problème dans l’environnement de test ou pour un certain nombre de raisons. Si vous avez un outil de contrôle de version, vous devriez être capable de créer facilement une nouvelle twig (quelque chose que VSS craint) pour corriger le bogue et pouvoir le fusionner si nécessaire

    Version de maintenance

    Cela pourrait être très similaire à un correctif, mais une fois que le code a été publié en production. Des exemples pourraient être des groupes de correctifs, des versions de service, etc. Encore une fois, vous souhaitez pouvoir fusionner les modifications dans le coffre si nécessaire.

    Nouvelle fonctionnalité

    Parfois, vous devez commencer le développement d’une nouvelle version tout en conservant votre code actuel. Par exemple, vous lancez et maintenez la version 1.0, mais vous devez commencer à travailler sur la version 2.0 tout en maintenant la version 1.0. Les twigs aident à résoudre cette situation

    Étiquetage / étiquetage

    Une autre chose que font les systèmes de contrôle de code source est de créer des instantanés du code source à un moment donné. Celles-ci sont appelées étiquettes dans VSS, tags dans subversion, etc. En les créant régulièrement et en les reliant à une étape importante de votre projet, il devient alors possible de déterminer exactement ce qui a changé dans votre code entre les versions. Cela peut être important pour les auditeurs, mais aussi pour identifier la source / la scope d’un problème. VSS obtient également un échec ici parce que VSS uniquement les versions des fichiers, pas des répertoires. Cela signifie qu’il est impossible de recréer une version précédente du système si vous renommez / déplacez / supprimez des fichiers ou des répertoires dans le référentiel (ce qui arrive souvent si vous refactorez). C’est ce que font de bons systèmes de contrôle de code source comme Subversion.

    Je suggère d’utiliser SVN, car:

    1. Le contrôle de la source vous donne un excellent historique. Vous pouvez voir où les modifications ont été apscopes, fournissant ainsi un excellent moyen de voir ce qui a changé au fil du temps (encore mieux si vous remplissez le résumé de soumission à chaque fois)
    2. Pour le développeur, cela fournit un excellent retour en arrière si quelque chose tourne mal. Vous pouvez rétablir les modifications apscopes à un fichier à n’importe quel moment de son historique. Vous pouvez donc essayer le mod que vous souhaitez créer et, si cela ne fonctionne pas, le réactiver facilement.
    3. Il fournit un référentiel central beaucoup plus facile à sauvegarder que celui des ordinateurs des différents développeurs.
    4. Il vous permet de twigr un projet dans une direction différente – utile pour les spécialisations et les personnalisations.
    5. Il permet à plusieurs développeurs de travailler ensemble sur le même projet et la même source, en vous permettant de fusionner et de manipuler les modifications sur une seule copie centrale.

    Je suggère de ne pas utiliser VSS – voir cette page pour des raisons: http://www.highprogrammer.com/alan/windev/sourcesafe.html pour plus de raisons.

    Avoir un système de contrôle de version aide dans de nombreux cas:

    Développeur unique, twig unique

    • La tâche la plus élémentaire que chaque système de contrôle de version doit effectuer correctement s’il veut s’appeler le contrôle de version est de pouvoir revenir à la version spécifiée d’un projet. Si vous faites des dégâts, vous pouvez accéder à la version précédente. Vous pouvez examiner certaines versions précédentes pour vérifier comment cela a été fait (par exemple, comment c’était avant le refactoring ou avant de supprimer du code / fichier).

      Les systèmes de contrôle de version prennent beaucoup moins d’espace disque que l’enregistrement de copies de sauvegarde avec une date spécifiée, car ils utilisent la deltaification (ne stockant que les différences avec la version précédente) et la compression. Généralement, les systèmes de sauvegarde permettent de stocker les dernières versions N d’un projet, parfois avec N = 1 (uniquement la version précédente), tandis que les systèmes de contrôle de version (VCS) stockent tout l’historique d’un projet. Connaître Murphy quelques instants après avoir supprimé la dernière version de N, vous vous rendrez compte que c’est la version que vous souhaitez examiner.

      De plus, il est facile et automatisé de revenir à la dernière version. Vous pouvez également examiner à quoi ressemblait un fichier unique dans une version antérieure et obtenir des différences (au format diff) entre l’état actuel et une version antérieure. Vous pouvez également étiqueter (ou “étiqueter”) les versions, vous pouvez donc vous référer à la version antérieure non seulement par date, mais aussi par version symbolique, par exemple v1.2 ou v1.2-rc0 .

    • Avec le système de contrôle de version, vous pouvez examiner l’historique pour vous rappeler pourquoi (et comment) un morceau de code (une partie d’un fichier donné) est arrivé à l’état actuel. La plupart des VCS permettent d’examiner l’historique des lignes d’un fichier, c’est-à-dire d’annoter chaque ligne d’un fichier lorsqu’il a été modifié, dans quelle validation et par qui (la commande est nommée annotate , blame ou praise selon VCS). Dans certains VCS, vous pouvez rechercher l’historique d’une version (révision) qui a introduit un fragment de code donné (par exemple, appelé «pickaxe search» dans Git, l’un des VCS).

      Pour que cette fonctionnalité soit vraiment utile, vous devez maintenir une certaine discipline: vous devez décrire chaque nouvelle version (chaque nouvelle révision / chaque nouvelle validation) en écrivant pourquoi cette modification a été apscope. Une telle description (message de validation) est très utile, mais elle n’a pas de place naturelle dans le système de sauvegarde.

      Cette fonctionnalité est bien sûr encore plus utile si vous n’êtes pas le seul développeur …

    • L’utilisation du système de contrôle de version permet de trouver des bogues dans le code, notamment en recherchant l’historique pour trouver la version qui a introduit le bogue: histoire de la bissectiong . Lorsque vous trouvez une révision qui introduit un bogue, vous devriez avoir une zone limitée (dans le meilleur des cas: très limitée) pour rechercher un bogue, car le bogue doit être dans la différence entre la dernière version de travail et la première version avec un bogue. Vous auriez également une description d’un changement (un message de validation) pour vous rappeler ce que vous vouliez faire. Cette fonctionnalité est également appelée parfois diff débogage . Les systèmes modernes de contrôle de version (VCS) prennent en charge la recherche automatisée (ou semi-automatique) de l’historique en la divisant en deux parties (recherche de la partie contenant le bogue, répétition jusqu’à la découverte d’une seule version responsable). ou similaire) commande.

      Pour que cette fonctionnalité soit vraiment utile, vous devez maintenir une certaine discipline: vous devez valider (sauvegarder les modifications / mettre l’état donné dans le système de contrôle de version) une seule modification, traiter une seule fonctionnalité, avec une petite différence avec la version précédente; c’est à dire commettre souvent.

    • La plupart des systèmes de contrôle de version proposent différents crochets qui permettent, par exemple, de tester automatiquement ou de construire automatiquement un produit … ou simplement de vous rappeler que vous ne respectez pas les normes de codification (directives de codage).

    Développeur unique, plusieurs twigs

    • Les systèmes de contrôle de version permettent de créer plusieurs lignes de développement parallèles, appelées twigs (ou stream, ou vues). Le cas courant est d’avoir des twigs de développement , c.-à-d. Avoir une twig séparée pour le développement instable (pour tester les nouvelles fonctionnalités), une twig séparée pour la version stable (principale, principale) ) twigs.

      Avoir des twigs de maintenance vous permet de faire des corrections de bogues et de générer des service packs / version mineure avec des corrections à certaines versions, sans avoir à vous soucier des interférences du nouveau développement. Plus tard, vous pouvez fusionner la twig maintenance dans stable, ou choisir bigfix depuis la twig maintenance dans les twigs stable et de développement (si d’autres développements / autres n’ont pas permis de corriger les bogues indépendamment).

    • Le VCS moderne (ici moderne signifie que les twigs de twigment et de fusion sont faciles) permet d’aller un peu plus loin, c’est-à-dire de générer une twig séparée pour travailler sur une entité distincte (les twigs de rubrique ). Cela vous permet de basculer entre une fonctionnalité unique et le fait de travailler sur une autre fonctionnalité (et non seulement de passer d’une nouvelle fonctionnalité à un correctif à une demande urgente).

    • Si vous développez votre produit en fonction de la source d’un autre produit (généralement tiers), vous devez vraiment utiliser les twigs des fournisseurs pour pouvoir intégrer facilement la nouvelle version d’un produit aux modifications apscopes. Certes, ce n’est plus un cas purement “développeur unique”.

    Plusieurs développeurs

    • L’utilisation de systèmes de contrôle de version apporte des avantages supplémentaires si plusieurs développeurs travaillent sur le même projet. Le VCS permet un développement concurent (parallèle) sans craindre que quelqu’un écrase vos modifications ou ne prenne en compte vos modifications. Bien sûr, l’utilisation du système de contrôle de version ne remplace pas la communication.

    • Toutes les fonctionnalités ci-dessus sont encore plus importantes dans le cas des développeurs multiples: examiner qui a généré un changement donné, qui a changé le dernier code (aka. Qui a cassé la version), trouver un bogue dans le code que vous n’avez pas écrit.

    Simple: si le code n’est pas en sécurité source, il n’existe pas

    Subversion est gratuit et meilleur que VSS mais VSS est définitivement meilleur que rien.

    Avant de dire quoi que ce soit, découvrez pourquoi votre entreprise n’utilise pas le contrôle de source.

    Une fois que vous savez pourquoi, il est facile de trouver des scénarios où le contrôle des sources peut vous aider.

    Longue discussion sur les raisons pour lesquelles vous devriez absolument avoir le contrôle des sources:

    Le contrôle de version est-il nécessaire pour un petit groupe de développement (1-2 programmeurs)?

    Mes commentaires de ce fil:

    Vous voulez toujours, toujours, avoir une sorte de contrôle de source même si vous travaillez sur un projet par vous-même.

    Un historique des changements est essentiel pour pouvoir voir l’état d’un code à tout moment. Il y a une variété de raisons de revenir dans un historique de projet allant de la simple possibilité de restaurer un mauvais changement à la prise en charge d’une ancienne version lorsque le client veut simplement réparer un bogue plutôt que de mettre à jour une version plus récente. les logiciels.

    Ne pas avoir de contrôle de source est une pure folie.

    En ce qui concerne VSS, c’est certainement mieux que rien. Ce n’est certainement pas le meilleur contrôle des sources et c’est très daté, mais le fait qu’il continue à faire le travail pour un grand nombre d’entresockets.

    Si votre patron est déterminé à utiliser les outils Microsoft, optez pour Team Foundation Server au lieu de VSS. C’est un système bien meilleur que VSS et il a de belles fonctionnalités comme le suivi des bogues intégrés.

    Si le processus en cours copie un dossier et lui donne une date, n’est-ce pas pour que vous ayez un historique du développement, n’est-ce pas une forme simple de contrôle de code source?

    Donc, pour répondre aux critiques concernant le contrôle de la source, vous le faites déjà. Il ne vous rest plus qu’à signaler les faiblesses du système actuel et à en proposer une meilleure. Pourquoi avez-vous besoin de réinventer la roue lorsque les gens ont vraiment pensé à beaucoup de scénarios complexes qui peuvent se produire pendant le développement et développé les outils qui leur permettent de les gérer.

    Ce que vous êtes en train de faire est très fragile et tombera si un scénario complexe se présente, à quel point vous devrez dépenser beaucoup d’énergie pour travailler sur ce que les outils font déjà. VSS est meilleur que ce que vous faites, mais n’a pas les conventions très utiles que SVN, git ou mercurial ont, qui permettent à plusieurs projets de vivre ensemble de manière bien organisée – je parle de twigs, de balises et de fusions, à la fois dont sont fragiles et fondamentalement un cauchemar sous vss.

    SVN a des plugins pour Visual Studio. Certains sont gratuits. Mais je trouve que tortue-svn éclipse tout autre chose. Le seul avantage que je trouve avec un plugin est que les nouveaux fichiers sont ajoutés automatiquement à svn.

    Donc, les faiblesses de votre système actuel:

    • Si vous devez modifier un fichier, vous risquez d’écraser ou d’être remplacé par les modifications apscopes par les autres développeurs. Vous ne le remarquerez peut-être même pas.
    • Si vous devez vous souvenir des fichiers que vous avez modifiés pour les copier sur une copie «maître», vous risquez d’en manquer un à un moment donné.
    • Bonne chance de trouver une documentation sur le moment où vous avez fait un changement et pourquoi.
    • Comment pourriez-vous jamais construire un système de construction automatisé stable sur votre système actuel? Le régulateur de vitesse et le hudson fonctionnent très bien, vous hobez
    • VSS ne regroupe pas très bien les modifications apscopes à plusieurs fichiers. Tout ce que le moderne fait extrêmement bien et avec une consistance atomique.
    • La prise en charge de la twig et de la fusion VSS est terrible. Lorsque nous l’avons utilisé, nous avons fini par encadrer chaque modification avec des commentaires dans le code source et copier manuellement le code plutôt que de nous fier à la fusion VSS.
    • Il sera très difficile, presque impossible dans votre système actuel, d’avoir une version du code dans la maintenance en direct et une autre version plus récente dans un développement intensif. Pensez à ce qui est nécessaire pour maintenir la synchronisation de deux projets, vous aurez besoin d’un bon outil. SVN peut le faire, git peut très bien le faire.

    Cela pourrait suffire pour continuer, peut faire plus.

    Prends-le moi, souffle VSS . C’est le stockage de fichiers de base avec l’historique. Tout est mieux que VSS et VSS vaut mieux que rien 🙂

    Alors, pouvez-vous me dire pourquoi les développeurs DOIVENT utiliser le contrôle de source?

    • Il fournit une méthode à utiliser par toute une équipe. tout le monde opère sous les mêmes «règles de base».
    • Les changements sont ordonnés et chaotiques, ce qui permet de gagner du temps de développement.
    • La capacité de suivre les changements favorise la responsabilisation et facilite la recherche de la personne à même de résoudre les problèmes rencontrés dans les documents.
    • Une liste des modifications exactes effectuées peut être générée rapidement et facilement, ce qui facilite l’information des utilisateurs sur la manière dont ils ont changé de version en version.
    • Il est facile de revenir à une version antérieure de l’information si une erreur grave a été commise lors d’un changement.

    Le contrôle des sources est comme une assurance! Vous espérez que vous n’en aurez jamais besoin, mais vous êtes heureux de l’avoir quand vous le faites!

    Pourquoi faire une présentation formelle?

    En supposant que la taille de l’équipe est d’au moins deux, faites un exemple réel: laissez deux (ou plus, mieux c’est) obtenir le code, apportez vos modifications et montrez ce qu’il faut pour intégrer toutes ces modifications en utilisant n’importe quel contrôle non-source signifie que vous utilisez.

    Ensuite, faites le même scénario en utilisant le contrôle de source.

    La quantité de temps et de douleur que vous économisez en utilisant le contrôle de la source parlera d’elle-même.

    Tenez-vous à la ligne du bas, expliquez comment cela se rapporte à l’argent et votre patron va probablement écouter.

    Si vous n’êtes qu’un programmeur, je dirais que l’argument principal est la réduction du risque de perdre du temps (et donc de l’argent) à réparer des erreurs simples, à essayer d’annuler le code qui s’est révélé être une mauvaise idée, etc.

    Si vous êtes plus d’un programmeur, ce qui précède va deux fois plus et c’est la seule façon sensée de pouvoir travailler ensemble sur la même base de code sans perdre encore plus de temps à vous attendre,

    Visual Source Safe est mieux que rien mais il existe des options gratuites qui sont meilleures à presque tous les égards. Si votre patron a besoin d’une présentation pour comprendre pourquoi le contrôle des sources est essentiel, il peut ne pas se soucier de l’outil que vous utilisez une fois qu’il a été éclairé. Le fait que vous ayez de l’expérience avec d’autres outils et non vss concerne à nouveau la ligne du bas, ce qui pourrait suffire.

    Je suis vraiment désolé mais si vous devez réellement défendre [la formalisation] du contrôle des sources dans un environnement de développement, vous êtes dans une situation désespérée. Si votre patron a réellement besoin d’être convaincu que le contrôle de la source est une entreprise rentable, votre patron n’est tout simplement pas apte à diriger un groupe de développeurs de logiciels. Pour que quelqu’un puisse gérer efficacement, il lui faut au minimum une compréhension de base du paysage. Je ne peux même pas imaginer ce qui va se passer quand vous aurez réellement besoin de plaider pour quelque chose qui vaut la peine d’être argumenté et de faire une présentation.

    Développer sans contrôle de source, c’est comme conduire une voiture sans pauses. Vous perdez la capacité de faire du développement simultané en toute transparence, vous perdez votre code en le sauvegardant dans des copies de travail, vous perdez la possibilité de faire des recherches historiques via des annotations de code, vous perdez le bénéfice de voir le contexte et les commentaires perdre, point. L’utilisation du contrôle de source est tellement évidente et présente de nombreux avantages, il est choquant de devoir le justifier.

    Au travail, nous utilisons subversion, mais certains développeurs (y compris moi-même) utilisent Git localement via le pont git-svn. Pour le travail personnel, j’utilise Git.

    Car:

    1. Cela réduira les coûts – Les développeurs devront passer moins de temps à vérifier un élément dans un vrai VCS que leur approche ad hoc actuelle.

    2. Cela protégera la propriété intellectuelle de l’organisation – cela devrait être la considération la plus importante pour toute entreprise de logiciels (autre que les données …). Vous êtes payé pour créer un logiciel – ne devrait-il pas être accessible dans son intégralité?

    3. Il fournira des mécanismes de sauvegarde plus rapides, plus fiables et plus simples – tous les VCS ont des capacités de dumping intégrées. Celles-ci ont tendance à être plus matures qu’une simple copie de fichier.

    4. Il agira comme un mécanisme de communication entre les développeurs – selon le système de contrôle de version, vous pouvez utiliser le statut commentaires / libellés / extraction pour déterminer si quelqu’un d’autre a travaillé sur un fichier, s’il a été pris en charge. numéro de ticket etc.

    5. Il rationalise le développement – la possibilité de comparer les versions de fichiers ainsi que les autres mécanismes sera bénéfique pour votre entreprise.

    Pourquoi votre équipe ne devrait-elle pas adopter le contrôle des sources?

    Même en tant que développeur solo, j’utilise le contrôle de source. Dans un environnement de développement logiciel moderne, je ne peux penser à aucune raison, sinon aucune, pour laquelle vous ne souhaitez pas utiliser le contrôle de code source. Il est plus surprenant que vous ne l’ayez pas déjà. La question me frappe comme quelque chose comme des peintres en bâtiment qui demandent “Pourquoi devrions-nous utiliser les échelles? Vous savez, les échelles ne font pas peindre la maison – les brosses font.”

    La principale raison pour laquelle nous utilisons le contrôle de version est la cohérence.

    Si les projets ne sont pas cohérents, des problèmes surviendront et le code sera perdu.

    Assurez-vous que vous avez acheté pour le rest de l’équipe. Peut-être que vous pouvez tester votre présentation sur eux? Espérons qu’ils voient aussi le besoin.

    Ravi de voir les bonnes pratiques initiées de bas en haut. Peut-être chacun sera-t-il plus susceptible d’adopter la pratique si elle vient de l’un des leurs plutôt que d’un mandat de gestion.

    Pour éviter des choses comme

      "Hey! What happens ? It worked yesterday." 

    Le moyen le plus simple de convaincre la direction d’investir Time dans un SCCS est la sauvegarde et l’archivage. En utilisant quelque chose comme Subversion (SVN), vous pouvez restaurer n’importe quel projet instantanément à n’importe quel moment. Il n’est pas nécessaire que quelqu’un examine les bandes de sauvegarde ou se soucie de suivre plusieurs versions dans une structure de répertoire obtuse.

    Il y a évidemment beaucoup d’autres avantages (c.-à-d. 2 personnes travaillant sur le même fichier en même temps), mais les sauvegardes sont ce qui a rapidement vendu mon entreprise il y a plusieurs années.

    D’autres ont mentionné les avantages spécifiques du contrôle de source ailleurs, mais je voulais aborder explicitement la partie “VSS” de la question.

    Si votre patron veut utiliser un outil Microsoft, Team Foundation Server avec Team Suite est une très bonne combinaison. D’autres outils sont également inclus, tels que le suivi des bogues, les documents et les fonctionnalités de création de rapports, ce qui en fait une plate-forme intéressante pour améliorer ultérieurement votre processus. Nous sums très satisfaits de mon travail et mes collègues m’ont raconté des histoires d’horreur au sujet de VSS.

    Gardez à l’esprit les TFS en réponse à la question de «Microsoft Tools».