Comment puis-je convaincre les programmeurs cow-boys d'utiliser le contrôle de source?

UPDATE
Je travaille sur une petite équipe de développeurs, 4 gars. Ils ont tous utilisé le contrôle de source. La plupart d'entre eux ne supportent pas le contrôle de code source et choisissent plutôt de ne pas l'utiliser. Je crois fermement que le contrôle à la source est une partie nécessaire du développement professionnel. Plusieurs problèmes rendent très difficile de les convaincre d'utiliser le contrôle de source:

• L'équipe n'est pas habituée à utiliser TFS . J'ai eu 2 séances d'entraînement, mais une heure seulement m'a été allouée, ce qui est insuffisant.
• Les membres de l'équipe modifient directement le code sur le serveur. Cela empêche le code de se synchroniser. Exiger une comparaison pour être sûr de travailler avec le dernier code. Et des problèmes de fusion complexes se posent
• Les estimations de temps offertes par les développeurs excluent le temps nécessaire pour résoudre ces problèmes. Donc, si je dis nono, cela prendra 10 fois plus longtemps ... Je dois constamment expliquer ces problèmes et me risquer car, à présent, la direction peut me percevoir comme "lente".
• Les fichiers physiques sur le serveur diffèrent de manière inconnue de plus de 100 fichiers. La fusion nécessite une connaissance du projet en cours et, par conséquent, une coopération entre développeurs que je ne parviens pas à obtenir.
• D'autres projets ne sont plus synchronisés. Les développeurs continuent de se méfier du contrôle de source et aggravent donc le problème en n'utilisant pas le contrôle de source.
• Les développeurs affirment que l'utilisation du contrôle de source est un gaspillage, car la fusion est source d'erreurs et difficile. C'est un point difficile à argumenter, car lorsque le contrôle de source est si mal utilisé et que le contrôle de source est contourné en permanence, il est en effet sujet à des erreurs. Par conséquent, la preuve "parle d'elle-même" à leur avis.
• Les développeurs affirment que modifier directement le code du serveur en contournant TFS permet de gagner du temps. C'est également difficile à argumenter. Parce que la fusion requise pour synchroniser le code de départ prend beaucoup de temps. Multipliez cela par les 10 projets que nous gérons.
• Les fichiers permanents sont souvent stockés dans le même répertoire que le projet Web. Ainsi, la publication (publication complète) efface ces fichiers qui ne sont pas dans le contrôle de source. Cela entraîne également une méfiance vis-à-vis du contrôle de source. Parce que "la publication casse le projet". La résolution de ce problème (déplacement des fichiers stockés hors des sous-dossiers de la solution) prend beaucoup de temps et de débogage, car ces emplacements ne sont pas définis dans web.config et existent souvent entre plusieurs points de code.

Ainsi, la culture persiste elle-même. Une mauvaise pratique engendre plus de mauvaise pratique. Les mauvaises solutions amènent les nouveaux utilisateurs à "résoudre" des problèmes beaucoup plus profonds et prenant beaucoup de temps. Les serveurs, l’espace disque sont extrêmement difficiles à trouver. Pourtant, les attentes des utilisateurs augmentent.

Que peut-on faire dans cette situation?

Ce n'est pas une question de formation, c'est une question de facteurs humains. Ils ne veulent pas et créent des barrages routiers. Traitez avec la dynamique de groupe brisée, quelle est la cause fondamentale de leur objection - généralement la peur, s'agit-il simplement de la peur du changement ou est-ce plus sinistre?

Aucun développeur professionnel n'a résisté au contrôle de la source aujourd'hui ou au cours des 20 dernières années. Une fois, il y a environ 30 ou 40 ans, lorsque les ordinateurs étaient lents, le contrôle de la source encore plus lent et les programmes constitués d'un fichier de 500 lignes, c'était pénible et il y avait des raisons valables de ne pas l'utiliser. Ces objections ne peuvent venir que du pire type de cow-boys auquel je puisse penser.

Le système leur est-il imposé de manière à rendre leur vie difficile? Découvrez ce que c'est et modifiez le système pour invalider l'objection. Répéter jusqu'à la fin.

Je suggère de regarder GIT ou Mercurial. Vous pouvez créer un référentiel dans chaque arborescence de code source, ils ne le remarqueront même pas et pourront continuer à pirater comme ils le font maintenant. Vous pouvez suivre les modifications apportées à la base de code, effectuer des commits, les fusionner dans d'autres arborescences de sources, etc. Lorsqu'ils vous voient fusionner en quelques secondes d'effort dans un autre produit, ils peuvent changer d'idée. Lorsque vous annulez un de leurs problèmes avec une seule commande et que vous sauvez leur cul, ils pourraient même vous remercier (ne comptez pas dessus). Dans le pire des cas, vous avez fière allure devant le patron et, pour un bonus, faites en sorte qu'ils ressemblent aux cow-boys qu'ils sont.

La fusion nécessiterait non seulement une grande connaissance du projet

Dans ce cas, j'ai bien peur que vous n'ayez plus de pagaie dans la crique proverbiale. Si la fusion n’est pas une option, son implémentation n’est pas non plus implémentée. Vous dites donc que vous ne pouvez plus ajouter de fonctionnalités déjà existantes dans une branche (terme utilisé de manière vague) à une autre.

Si j'étais vous, je reconsidérerais mes perspectives de carrière ...

Parfois, les problèmes du monde réel rendent son utilisation peu pratique.

Faux.

Si l’équipe n’est pas habituée à utiliser le contrôle de source, des problèmes d’entraînement peuvent survenir.

Cela n’a rien à voir avec le contrôle du code source et tout avec la formation. La formation est facile, peu coûteuse, efficace et se fait en quelques heures. Ne pas utiliser le contrôle de code source est coûteux, risqué, inefficace et les problèmes persistent pour toujours .

Si un membre de l'équipe modifie directement le code sur le serveur, divers problèmes peuvent survenir.

C'est la question de la formation. Encore. Rien à voir avec le contrôle du code source et tout ce qui concerne la formation.

Les développeurs continuent de se méfier du contrôle à la source et ne font donc qu'aggraver le problème en n'utilisant pas le contrôle à la source

Ils doivent être formés à l'utilisation du contrôle de code source. Il réduit les coûts, les risques, simplifie les choses et est plus efficace. C'est un investissement ponctuel qui rapporte des dividendes à chaque instant.

Que peut-on éventuellement faire dans ce type de situation?

Commencez à former tout le monde sur l'utilisation du contrôle de code source.

Mise à jour

Les développeurs affirment que la modification directe du contrôle de code source permet de gagner du temps.

Puisqu'ils se trompent, il est important de rassembler des données pour démontrer avec précision à quel point c'est faux.

Malheureusement, la direction semble récompenser une réponse immédiate coûteuse à long terme.

Le seul moyen de surmonter ce système de récompense est de

A) Identifiez que le coût à long terme est supérieur à la valeur apparente à court terme.

B) Identifiez les récompenses réellement en place qui font que la corruption à court terme (c'est-à-dire les modifications directes) semble plus utile que le contrôle correct du code source à long terme. Qui reçoit une tape dans la tête pour avoir fait la mauvaise chose? Quel genre de tape sur la tête reçoivent-ils? Qui le donne? Afin de réparer les choses, vous devez nommer les choses qui ne vont pas et le (s) responsable (s) spécifique (s) qui encourage (nt) réellement les gens.

C) Recommander un système de récompense révisé qui valorise la valeur à long terme plutôt que la réponse rapide à court terme. Différentes caresses sur la tête pour différentes raisons.

D) Former les gens dans les récompenses que vous avez trouvées pour une valeur à long terme; valeur nettement supérieure à la réponse rapide à court terme.

Les développeurs qui refusent d'utiliser le contrôle de source / version doivent être renvoyés, aussi simple que cela. Comme vous l'avez déjà souligné, les risques et les coûts inhérents à la non-utilisation de ce logiciel dépassent les coûts indirects engendrés par de très nombreux ordres de grandeur. Quiconque essaie de contester cela ne devrait tout simplement pas participer au développement de logiciels et je refuserais catégoriquement de travailler avec de telles personnes.

Nous avons d'abord résolu le problème en configurant un serveur d'intégration continue pour intégrer notre contrôle de source dans dev. Deuxièmement, verrouillez l'accès aux dossiers en lecture seule pour empêcher les personnes de contourner le contrôle de source et de modifier les fichiers directement.

C'est un PITA les jours où vous ne pouvez pas reproduire le bogue localement, mais à part cela, il est plus agréable de pouvoir travailler, archiver et continuer, sachant qu'il sera automatiquement transféré par le serveur CI.

J'entends ta douleur. Je suis entré dans quelques lieux de travail pour découvrir que le «contrôle de source» était un dossier partagé sur un lecteur réseau. Le problème n’est généralement pas lié au fait qu’ils pensent que leur approche est supérieure à toute autre solution, qu’il fonctionne simplement et qu’ils n’ont jamais été initiés à un flux de travail intégrant avec succès le contrôle de source.

Avec la structure d’équipe de Terre plate, expliquez que le changement ne peut pas être la meilleure façon d’aborder la situation. Une méthode qui vaut la peine d’être essayée est d’obtenir l’adhésion directe d’un ou deux autres développeurs pour permettre au concept de prendre de l’élan. Une fois que vous avez même un autre développeur à bord, il sera beaucoup plus facile de l'étendre au reste de l'équipe. Présentez-les lentement au concept, par exemple, commencez à travailler sur un petit projet parallèle, lancez-le et allez-y dans Git , ou branchez quelque chose hébergé sur GitHub .

Commencez simplement, introduisez les concepts lentement et séparément de leur flux de travail quotidien. Les humains sont doués pour apprendre des choses et s’adapter au changement, en particulier lorsque ce changement leur procure des avantages directs (pensez à l’évolution). Cependant, lorsque présenté avec tout un tas de petits changements à la fois, il devient aliénant. Une fois qu'ils ont compris le fonctionnement du contrôle de source et les avantages qu'il procure, essayez de l'intégrer à l'un de vos projets internes (si vous démarrez un nouveau projet, le moment est mal choisi pour l'introduire). Si vous le souhaitez, laissez les autres projets fonctionner de la même manière, ce qui sera particulièrement efficace pour mettre en évidence les avantages d'un contrôle de code décent.

Si cela échoue, lancez.

Vous avez évidemment les compétences techniques pour identifier et corriger votre situation, vos problèmes sont humains et liés au processus.

Les gens ont tendance à réagir beaucoup mieux à l'exemple qu'à la vision, aussi je suggérerais de "réparer" vous-même

Prenez une copie de la dernière source, restructurez-la pour qu'elle soit conviviale pour le contrôle de version, créez un nouveau projet avec une structure utile et prospective (déterminez comment vous allez gérer les branches, placer les dépendances de tiers, etc.). Vous devrez probablement le faire à votre rythme.

Amenez ensuite vos collègues et la direction dans une pièce et montrez- leur à quoi ressemble le développement logiciel au XXIe siècle. Illustrez les défaillances de votre système actuel et montrez comment elles ont été éliminées avec votre nouvelle structure.

Vous devrez également vous installer en tant que Gardien de la source - puisque vous semblez être le seul à vous en soucier, il vous appartient de forcer les gens (avec les moyens techniques ou psychologiques à votre disposition) à s'y tenir. le plan. Assurez-vous que la seule chose transmise à un client provient d'une machine de génération hors du contrôle de source. Rituellement humilier les gens qui enfreignent les règles et causent des ravages. Les corrompre avec des beignets ... tout ce qui fonctionne.

Si tout cela vous semble demander trop d'efforts, alors (comme cela a été dit dans presque toutes les autres réponses), trouvez un autre emploi Ils ne valent pas votre temps.

Étape 1 - congédiez un directeur incompétent!

Si vous ne pouvez pas effectuer l'étape 1, essayez de demander au gestionnaire de limiter le déploiement à la production uniquement aux scripts extraits du contrôle de source. Si les développeurs (qui ne devraient pas disposer de droits de production sur prod, reportez-vous à l’étape 1 si ils le souhaitent) veulent que leur contenu soit déployé, il doit provenir du contrôle de source. Cela a résolu notre problème de ne pas utiliser le contrôle de source assez bien lorsque nous avons commencé à l'utiliser pour la base de données ainsi que le code C #.

Comment peut-on ne pas vouloir différentes versions de leurs fichiers et la possibilité de voir les différences? Oubliez les branches et tout ce qui est complexe. Ils ne comprennent même pas les bases. Modifier directement un fichier de production sans apporter les modifications les plus rudimentaires dans un environnement de test est insensé. J'ai travaillé avec certaines personnes et, heureusement, nous n'avons jamais travaillé sur les mêmes projets.

Vos collègues sont trop stupides pour être paresseux. C'est une perte de temps. Tout ce que vous pouvez espérer, c'est former votre manager. La direction devrait aimer le contrôle de la source, car elle aime toutes les formes de contrôle. Les fait se sentir important. Visser les autres; Fixer le leader est votre seul espoir puisque vous ne pouvez pas le remplacer. Commencez à créer des réseaux avec d'autres développeurs compétents et essayez de les amener à rejoindre votre équipe lorsque vous avez une ouverture ou de les faire embaucher dans leur magasin.

C’est un bon exemple de projet dans lequel de mauvaises pratiques ont été utilisées de manière si répandue qu’il devient pratiquement impossible de les corriger. Le réparer nécessiterait un gel afin que tout puisse être nettoyé sans interruption. Malheureusement, de tels projets sont généralement (pour des raisons évidentes) trop complexes pour être gelés pendant plusieurs mois. Des bogues critiques doivent être corrigés tous les deux jours.

Vous pourriez être tenté de créer un fichier propre avec le projet alors que la version modifiée est traitée avec ces corrections de bugs quotidiennes; mais le résultat le plus probable est qu'après plusieurs mois, lorsque la version "propre" est terminée, personne ne peut vous dire quelles corrections de bugs et modifications ont été incorporées depuis la fourchette (parce que le même état d'esprit qui laisse les gens glisser dans de telles pratiques rend peu probable ils gardent des traces des changements qu’ils font). La version propre est obsolète, la version sale fonctionne toujours un peu, alors que se passe-t-il? La version épurée est mise au rebut, les affirmations se sont avérées justes.

Autre que l'évidence Trouver un nouvel emploi, je pense que la réponse est plus que tout ce qui précède.

Adressez-vous d’abord à la direction pour les inciter à passer au contrôle de la source et à l’appliquer. Ensuite, déterminez ce qui doit être fait pour que les choses continuent de fonctionner, même si cela signifie que vous travailliez directement sur le serveur. Démarrez le processus d'obtention de tout dans le contrôle de code source.

Une autre option consiste à vérifier que la dernière version est sur le serveur (ce que vous devez faire indépendamment) et à démarrer un nouveau référentiel à partir de la dernière. Vous allez perdre l'histoire, mais à ce stade, il s'agit de petites pommes de terre.

D'après votre description, il semble que la situation pose un ou plusieurs problèmes: l'équipe de développement est hors de contrôle ou une solution de contrôle de source source incorrecte a été mise en œuvre. Quoi qu’il en soit, il incombe à l’équipe de développement d’utiliser une solution de contrôle de source - la modification directe du code source sur le service de production ne fait que prier pour que des problèmes se produisent.

D'après mon expérience, la première étape à effectuer immédiatement consiste à synchroniser le contrôle de source avec le serveur de production. Cette étape peut être aussi simple que de prendre une copie du code de production et de l'enregistrer - le code de produit est probablement la base que votre équipe est en train de développer. Cette étape peut devoir être complétée par une fusion avec du code flottant dans le système de contrôle de code existant. Le code doit passer de dev à intégration / assurance qualité (ou aux deux), puis à l'étape ou à l'étape / production.

Ensuite, la direction doit imposer l’utilisation du contrôle de source. Tout simplement, si la construction ne provient pas du système de contrôle de code source, le code ne doit pas être déployé en production. L’accès à la production doit être limité à l’équipe de support, avec un accès limité aux développeurs pour résoudre les problèmes de production. Les développeurs ne doivent généralement jamais déployer de code à chaud en production - des problèmes de production pourraient certainement se produire, en particulier si les développeurs sont sous pression.

La direction a certainement besoin de mieux maîtriser les problèmes ici - il sera presque impossible de poursuivre le développement si le code est appliqué directement à prod (sans entrer dans le contrôle de source).

Le vrai problème n'est pas que les codeurs cow-boys n'utilisent pas le contrôle de version. Le vrai problème, c'est qu'ils ont déjà choisi une façon de faire et que vous essayez de changer leur processus. Le processus choisi n'inclut pas le contrôle de version. Tous les changements de processus sont difficiles, à moins que les programmeurs eux-mêmes ne remarquent un problème. Si l’on a l’impression que le système existant est assez bon, essayer d’imposer un autre système est tout simplement vain. Nous sommes le borg, vous serez assimilés. Bien sûr, ils essaient de se battre pour devenir borg.

Pour votre santé mentale, je vous conseillerais de configurer Git ou un autre DVCS sur votre propre machine afin de pouvoir suivre les modifications. Importez souvent les modifications de vos collègues dans votre référentiel. Résoudre les conflits du mieux que vous pouvez. Cela vous protégera partiellement de la folie de vos collègues.

Vous avez mentionné que la direction avait déclaré que les développeurs devaient utiliser le contrôle de source. Si vous voulez être méchant, vous pouvez le faire en vérifiant les modifications dans TFS et en publiant périodiquement le référentiel, annulant ainsi toutes les modifications non contenues dans TFS. (Si vous gérez également votre propre DVCS, vous devez garder les deux synchronisés.) Vous justifiez ainsi le fait que vous suivez les ordres de la direction. Si vos collègues en ont assez de voir leurs modifications écrasées, invitez-les à utiliser TFS. Et gardez les changements qui ne sont pas enregistrés. Continuez jusqu'à ce que vos collègues se relâchent ou que vous soyez viré.

Verrouillez tout serveur autre que leur développement. Utilisez un gestionnaire de configuration. Faites des constructions identifiables régulières (contre les tags). Marquez chaque ensemble de modifications (c.-à-d. 1 ensemble de modifications par bogue). Nous mettons également une balise sur chaque build. Avoir un système de type QA entre le développement et la production (au minimum). Effectuez les constructions sur le système d'assurance qualité en utilisant la balise de construction correcte. Donnez leur du chagrin pour "briser la construction".

Je ne me suis jamais retrouvé dans une situation où je ne pouvais pas recréer / résoudre un problème (qui n'apparaît qu'en production). Oui, j'ai passé des heures à faire en sorte que le problème soit recréé sur un système de développement (de plus, lorsque vous le découvrez, vous pouvez l'ajouter à votre test de régression).

Nous avons réalisé un projet avec un groupe d’entrepreneurs de cow-boys qui ont fait toutes ces mauvaises choses. Je passe ensuite 4 semaines à nettoyer, puis à mettre en place les pratiques ci-dessus. Le projet n'a eu aucun problème avec aucune de ces choses depuis lors.

Citation:

L'équipe n'est pas habituée à utiliser TFS

TFS s'avère être Microsoft Team Foundation Server.

Mon premier instinct dit: "Ceci est la dernière version de Microsoft Visual SourceSafe"

Je serais du côté de vous, collègues de travail, et j'irais vraiment contre cela.