Le patron est sceptique quant à l'utilisation d'un système de contrôle de version pour un nouveau projet, dois-je quand même?

Voir /software/109817/superior-refusing-to-use-subversion

Ma question est similaire, mais voici les principales différences dans mon scénario:

• Nous commençons un nouveau projet à partir de zéro, en utilisant PHP et la technologie Web. Il n'y aurait pas de temps d'arrêt dans le développement car nous l'adopterions depuis le début, si je le peux.

• Mon équipe de développement se compose de moi et de mon patron. Nous sommes le département "IT" d'une entreprise relativement petite.

L'application Web remplacera une application héritée sans aucun contrôle de source. En raison des variations des exigences légales géographiques, la décision a été prise (avant mon embauche) de bifurquer l'application en 7 répertoires complètement séparés pour chaque version. Après cela, différents développeurs ont fait des choses différentes à différents endroits et à différents moments. Corriger les changements entre eux, eh bien, je pense que cela pourrait être mieux fait, je suppose que c'est pourquoi je poste.

La proposition de mon patron, directement collée à partir d'un e-mail:

• Les mises à jour doivent être soumises sous forme de packages dans le dossier SUBMISSIONS. Le package doit contenir tous les fichiers pertinents ainsi qu'un fichier 'UPDATE.NFO' qui contient une description de la mise à jour, une liste de tous les nouveaux fichiers inclus (avec descriptions) et une liste de tous les fichiers modifiés avec les détails de la modification.

• Les packages de mise à jour doivent se concentrer sur un élément individuel et ne pas s'éloigner de son objectif. Le code doit être conçu pour être modulaire et réutilisable dans la mesure du possible.

• Tous les packages soumis doivent être installés dans l'environnement de test de chaque développeur peu après leur soumission. Chaque développeur doit examiner le nouvel ajout et exprimer ses préoccupations concernant son installation dans l'environnement de production. Une mise à jour standard du package doit être conservée pendant au moins 3 jours ouvrables pour ce processus de révision avant d'être chargée dans l'environnement de production. Les mises à jour / correctifs de haute priorité peuvent ignorer cette exigence.

La raison pour laquelle le contrôle des sources a été inventé est de rendre tout cela automatique, non? J'ai suggéré la subversion, parce que c'est ce que j'ai utilisé au collège. Le patron n'aime pas la subversion parce que "ça gâche le code" (c'est-à-dire utilise la magie binaire et n'est pas clairement lisible). Nous l'avons essayé une fois, mais je pense qu'en essayant de l'utiliser sur Windows, nous avons fait des erreurs étranges en minuscules / majuscules et nous n'avons pas pu vérifier nos fichiers. Je ne sais pas si ce n'est que la subversion ou tous les produits de contrôle de source qui sont répréhensibles.

Alors, quel genre d'argument dois-je faire à mon patron? Ou a-t-il raison, et il pourrait y avoir un risque de perdre tout notre travail à cause d'un bug étrange?

Ou ai-je tout à fait tort? Le contrôle des sources est-il vraiment nécessaire dans ma situation? Il s'agit de notre principal logiciel critique dont nous parlons, il finira donc sans aucun doute par être énorme. Mais il n'y a que 2 développeurs (maintenant).

De plus, si je ne peux pas le convaincre, y aurait-il un intérêt pour moi à ne l'utiliser que pour moi? Je parle comme quelqu'un avec une expérience très limitée utilisant réellement svn; tout ce que je sais, c'est commander et m'engager. Quelles sont les fonctionnalités du contrôle de code source (pouvant inclure d'autres produits que svn) qui pourraient m'aider dans mon effort de développement individuel?

S'il vous plaît pas de commentaires "obtenir un autre emploi". Cela n'aide pas le débat.

Ne lui demandez pas. Ne lui dis pas. Montre lui.

Installez svn, ou git, ou ce que vous voulez sur une machine supplémentaire. Entrainez-vous à l'utiliser jusqu'à ce que vous vous sentiez à l'aise non seulement de l'utiliser, mais de l'expliquer. Si vous voulez le mettre à l'aise avec votre nouveau système, vous devrez être plus que confortable avec lui-même. Vous devrez être en mesure de l'aider à récupérer facilement quand il échoue à une fusion ou vérifie quelque chose au mauvais endroit.

Lorsque vous êtes prêt, montrez-lui exactement de quoi vous parlez. Montrez-lui que cela ne "gâche" rien. Faites remarquer qu'il ne vous permet pas seulement de récupérer facilement n'importe quelle version précédente de votre code, il permet également de savoir exactement ce qui a changé entre deux versions.

Faites remarquer que si quelque chose arrive au serveur (bug grave, virus, hacker, crash de disque ...), vous ressemblerez tous les deux à des héros si vous pouvez reconstruire instantanément la version nécessaire. Faites également remarquer que vous serez deux fois plus beau si vous pouvez produire n'importe quelle version à la demande. Recherchez votre ancien e-mail et compilez une liste des problèmes que vous avez rencontrés au cours de l'année écoulée que vous auriez pu éviter avec le contrôle de version.

Donnez-lui une feuille de triche qui lui permettra d' utiliser facilement votre système de contrôle de version.

Enfin, suggérez quelques options mais laissez-lui la décision . Devriez-vous configurer votre propre serveur ou utiliser l'un des nombreux services hébergés ? Devriez-vous utiliser svn, git ou autre chose? Devez-vous migrer les sept projets vers le système, ou l'essayer avec un ou deux au début?

Les avantages du contrôle de code source vont bien au-delà du fait de permettre à plusieurs développeurs de travailler sur un seul morceau de code. Eric Sink, le fondateur de SourceGear , énumère quelques raisons convaincantes d' utiliser le contrôle de code source en tant que développeur unique :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Il se trouve également qu'Eric a un très bon guide de contrôle des sources pour les débutants . Joel Spolsky propose un didacticiel Mercurial en ligne gratuit . Mercurial est un système de contrôle de version distribué populaire.

Comme étape suivante, je vous suggère de commencer à utiliser le contrôle de code source localement sur votre machine, en tant que développeur unique. Très vite, votre patron remarquera que vous êtes capable de magie pure, comme dire en quelques minutes, voire quelques secondes, à quelle distance remonte un bug super-critique et ensuite vous lui diriez précisément quels comptes clients ont été affectés et doivent être réparés avant tout l'enfer se déchaîne. Ou être en mesure d'annuler tout changement que le PDG désapprouve super rapidement.

Et enfin, avant d'essayer de convaincre votre patron, vous voudrez peut-être approfondir le sujet du traitement des objections . C'est 101 des ventes.

En cas d'échec - continuez dès que possible, inutile de perdre votre temps à vous pencher sur les moulins à vent.

Oui, l'utilisation du contrôle de source, même si ce n'est que pour vous, en vaut la peine. Git, par exemple, fonctionne très bien pour un développeur autonome et vous permet de faire des choses telles que la branche et la fusion (avec le coût le plus bas possible) et la version de vos modifications au fur et à mesure.

SVN - ou n'importe quel système de contrôle de version, vraiment - vous permet de le faire aussi, mais la fusion est un peu plus problématique.

Si je ne peux pas le convaincre, y aurait-il un intérêt pour moi à ne l'utiliser que pour moi?

Oui. Il est avantageux de l'utiliser uniquement pour vous. Vous obtenez l'historique des modifications afin de voir ce qui est différent.

Non. Il n'y a aucun avantage parce que votre patron a condamné votre projet à de nombreuses retouches inutiles car elles ont sali les choses.

Je recommande fortement comme mentionné avant l'utilisation de git, la raison n ° 1 est que tout VCS est un filet de sécurité en cas de catastrophe. Recherchez l'autocollant «En cas d'incendie: git commit, git push, quittez le bâtiment». Le code peut être stocké ailleurs, mais pas dans un ordinateur portable qui peut tomber en panne, être volé ou autre ... même un serveur de réseau local n'est pas l'endroit le plus sûr pour quelque chose d'aussi précieux que le code.

Numéro 2. Traçabilité des modifications, qui a fait quoi, quand, etc. Fusionne, annule. Numéro 3. Diff l'outil magique pour # 2 et bien d'autres cas. Numéro 4. Branches Numéro 5. Étiquetage des versions, des versions, etc.

Vous pouvez trouver plus d'informations sur l'un des flux de travail git les plus courants ici: https://nvie.com/posts/a-successful-git-branching-model/

Je sais que l'utilisation de git peut être intimidante au début, mais c'est un bon investissement pour une compétence, et un must have pour toute équipe de développement.

À propos de votre problème avec la casse de texte, évitez d'utiliser Tortoise, je sais que la plupart des gens l'utilisent comme interface graphique pour git, car il était très courant pour SVN, il peut donc être de premier choix, utilisez plutôt la ligne de commande, ou une autre interface graphique comme github desktop ou le SourceTree d'Atlasian.