J'ai travaillé en tant que chef d'équipe / développeur dans un environnement de grande entreprise financière pendant environ trois ans. Notre processus de sortie de production est un cauchemar car il tourne autour de Clearcase. Nous avons un groupe de gestion du changement qui exécute toutes les versions et qui n'autorisera que le code en production qui en a été extrait.
L'une des premières choses que j'ai faites en me joignant a été de constituer mon équipe avec Git. Tout le monde a convenu que Clearcase était horrible et n'était pas pratique pour gérer les questions de contrôle des sources au jour le jour. Nous avons donc mis en place une sorte de référentiel "non officiel" sur ma machine locale et j'ai écrit un script pour synchroniser nos référentiels git et Clearcase autour de la date de sortie.
Cette nouvelle s'est répandue auprès d'autres équipes et plusieurs ont adopté le même processus. Utiliser git de manière "non officielle" pour les activités quotidiennes et utiliser "officiellement" Clearcase pour les versions. Je suis devenu une sorte de go to guy pour tout problème avec Git.
J'ai donc une réunion cette semaine avec le SVP en changement d'infrastructure qui veut spécifiquement que je lui explique les mérites de Git. Apparemment, je lui ai fait part de mes fréquentes diatribes sur Clearcase. Si elle accepte mes arguments, j'aurai une chance réelle d'aider mon employeur à se débarrasser de cette abomination.
Mon expérience avec les dirigeants me dit qu'ils a) veulent des explications extrêmement concises pour tout b) ne sont intéressés que par des faits impliquant des chiffres en dollars
À un développeur, je peux expliquer les avantages de Git sur Clearcase (ou de tout autre système de contrôle de version sur Clearcase, d'ailleurs), mais je dessine un blanc sur la façon de le faire à un responsable technique sans formation technique (elle a un MBA et a fait son premier cycle en géographie).
Je sens que tout argument que je lui ferai ressemblera à du charabia technique ou que j'évangélise mes préférences personnelles.
Ce que j'essaie de trouver, ce sont des faits concrets démontrant que les développeurs travaillent plus efficacement avec Git, ou TOUT système de contrôle de source moderne.
Je pense que le fait que les autres équipes aient commencé à utiliser Git en interne est un signe significatif, mais il n'est toujours pas assez fort car il peut toujours être rejeté comme préférence personnelle.
Ce dont j'ai vraiment besoin, c'est de quelque chose d'assez puissant pour franchir le "Ce processus fonctionne depuis 20 ans, pourquoi devrions-nous le changer?" argument.
Réponses:
J'ai été dans des situations très similaires (dans les industries aérospatiale et automobile). Ne vous attendez pas à progresser très loin dans cette réunion ou dans les réunions suivantes. Ces deux situations ont survécu à mon désir de continuer à me battre pour l'amélioration, mais voici la meilleure tactique que j'ai vue jusqu'à présent ...
Vous dites "ce processus fonctionne depuis 20 ans", mais est-ce vraiment le cas? Commencez par décrire ce que vous entendez par «notre processus de mise en production est un cauchemar». Créez une liste de problèmes avec le processus / outil actuel qui est aussi indépendant de ClearCase que possible.
Ensuite, créez une liste de "solutions" de processus / outils qui sont aussi agnostiques que possible pour Git (bien que Git ou tout autre DVCS moderne puisse convenir exactement à la facture). Expliquer pourquoi Git est meilleur que ClearCase ne signifie rien pour les non-utilisateurs.
Permettez à l'équipe d'infrastructure de confirmer que l'approche actuelle présente les problèmes que vous identifiez. Cela les amènera probablement à demander l'assistance d'IBM pour «résoudre» ces problèmes. Restez connecté pour vous assurer qu'IBM n'ignore pas les problèmes. Parce que ClearCase n'a pas les propriétés de base de notre compréhension moderne du contrôle de version, la plupart de ces problèmes ne peuvent pas être résolus ou nécessiteront un changement majeur d'infrastructure.
J'espère qu'à ce stade, l'équipe d'infrastructure y verra un problème commercial, mais sans solution facile. À ce stade, vous proposez de comparer des solutions supplémentaires avec des coûts estimés. Étant donné que plusieurs de vos équipes utilisent déjà Git, vous devriez pouvoir supprimer la formation en tant que dépense.
Bonne chance!
la source
Non, votre processus est un «cauchemar» en raison de votre groupe de gestion des changements et de vos procédures de publication. Allez-y et remplacez Clearcase pour SVN ou git ou Fossil. Vous aurez exactement les mêmes problèmes . (Je pense qu'ils le font correctement TBH, des contrôles de libération solides sont essentiels).
C'est sur cela que vous devez vous concentrer, pas sur les informations d'identification geek de git (qui ne sont pas pertinentes pour tous sauf pour les développeurs), vous devez vous concentrer sur l'analyse de rentabilisation pour changer le processus afin de le rendre moins onéreux. Il y a de fortes chances que vous puissiez le faire en utilisant Clearcase, mais cela vous donne la possibilité de vous faire une idée de l'utilisation de git de toute façon.
Si vous ne regardez pas la "vue d'ensemble" ici, dans le meilleur des cas, vous obtiendrez qu'il utilise git avec les mêmes restrictions que le groupe de versions requiert. Si vous tenez compte des aspects plus larges de ce à quoi sert le contrôle des modifications, vous apprécierez les restrictions que vous devrez mettre en œuvre pour rendre git utile dans le type de processus de publication fortement contrôlé dont votre organisation a besoin.
Quelques idées pour vous: faites-leur voir les problèmes de productivité avec le système actuel du point de vue du développeur. Pour ce faire, en tant que partie 1 sur 2. Partie 2, allez travailler avec eux sur une version afin que vous puissiez voir les problèmes de contrôle que les développeurs doivent comprendre. Traitez-le comme un exercice d'apprentissage pour les deux parties afin de voir la vue de l'autre côté, et vous devriez alors être en mesure de trouver une solution qui résout toujours les principales exigences de chaque côté. Notez que les versions sont plus importantes que dev, vous devez donc être celui qui est prêt à donner plus de terrain que vous ne le pensez.
Une fois que vous avez connaissance de ce qui est requis pour les versions, vous devez accepter de rédiger un document de processus détaillé (avec des détails à suivre) que vous pouvez leur montrer en leur donnant ce dont ils ont besoin. La façon dont vous pouvez masser cela pour que le côté développement soit meilleur pour vous dépend de vous. J'imagine qu'ils ne se soucient pas vraiment de la façon dont le développeur fait le développement, tant que la source est correctement gérée et les publications correctement organisées - cela signifie que vous devrez montrer comment les modifications de code peuvent être liées à des tickets de changement, comment prendre le code qui a fait une version pour patcher, compiler et republier.
la source
Des exemples spécifiques impressionneront plus que des avantages abstraits. Je pense que vous trouverez le plus de succès si vous pouvez documenter des exemples particuliers où (a) Clearcase a causé des problèmes qui ont pris du temps à résoudre et (b) Git résout ces problèmes. N'oubliez pas que vous n'avez pas besoin d'entrer dans les détails techniques de la raison pour laquelle il en est ainsi (sauf si demandé), montrez simplement que c'est le cas; la direction n'a pas besoin de connaître les détails techniques, c'est pour cela que vous êtes payé.
Si vous pouvez joindre des délais et des dates spécifiques à ces exemples, tant mieux. Vous pouvez également compléter cela en montrant que la tâche X que vous faites beaucoup prend Y minutes dans Clearcase et Z minutes dans Git.
N'oubliez pas que le temps c'est de l'argent, donc si vous pouvez montrer que travailler avec Git est plus rapide, vous pouvez montrer que cela aura également un sens financier.
la source
Voici une tentative sur la façon dont j'essaierais cela.
Cela peut sembler stupide pour un développeur, mais pour la direction, les changements technologiques sont considérés comme risqués.
"Si le truc magique fonctionne déjà, pourquoi prendre le risque de le casser?"
Ainsi, vous devez tourner la table. Rendez plus risqué de ne pas passer à git. À tout prix, ne donnez pas l'impression que c'est un nouveau jouet.
Je commencerais par dire que git est maintenant largement utilisé. Utilisez des chiffres, comme ceux-ci: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/
Pour un manager, cela implique qu'il devrait être en mesure de trouver de nombreux développeurs utilisant git. Et tout un écosystème d'outils tiers (j'ai entendu dire que même Microsoft intègre maintenant git avec visual studio).
De plus, un gestionnaire ne peut pas vraiment être blâmé d'avoir suivi les choses courantes, n'est-ce pas? En revanche, qui utilise $ other_cvs ici?
Mettez l'accent sur la façon dont les grands projets l'utilisent, car il est simple, rapide, flexible, puissant ... Trouvez de gros projets avec de grands noms qui lui sont attachés (GNU / Linux, Google, Microsoft ...) qui utilisent git.
Après avoir démontré que cela ne peut pas être une mauvaise décision, vous pouvez ensuite voir comment cela améliorerait les choses dans votre cas.
Vous voulez que l'entreprise reste compétitive et ne soit pas distancée par des équipes plus rapides et plus agiles, non? J'essaierais de trouver des estimations internes (écrites) sur la façon dont la productivité a changé en utilisant Clearcase vs Git. Vous pouvez utiliser l'aide de vos collègues développeurs là-bas. Extrapoler ensuite pour l'ensemble de l'entreprise (c'est-à-dire tous les développeurs de logiciels), avec les chiffres et le coût estimé de rester avec Clearcase.
Je voudrais même, le cas échéant, récapituler le tout dans un e-mail écrit après la réunion (inclure les bonnes personnes).
la source
C'est un argument invalide (les voitures tirées par des chevaux "ont fonctionné pendant des siècles", mais vous voudrez probablement acheter une voiture à la place).
J'ai entendu le même argument à propos de svn vs mercurial (j'étais celui qui utilise mercurial sur mon système de développement).
Ce problème n'est pas de remplacer ce qui fonctionne; N'essayez pas de le formuler comme tel, et si c'est la question que vous devez "vaincre", vous devriez commencer par souligner que ce n'est pas une question de ce qui fonctionne ou non - mais une question de quels avantages vous avez avec git , quand les deux fonctionnent (et pourquoi git fonctionne mieux).
Bons arguments pour utiliser git:
git est centré sur les modifications au lieu de centré sur le fichier. Cela signifie que les modifications sont plus faciles à suivre à travers les fichiers (traçabilité à travers le projet).
git est distribué au lieu d'être centralisé; Cela signifie que l'enregistrement des éléments n'est pas limité par la vitesse du réseau, ce qui permet également de gagner beaucoup de temps. Cela signifie également que vous n'avez aucun point de défaillance unique au cas où votre serveur ClearCase tomberait en panne.
en raison de son système de branchement, git minimise le besoin de fusionner (c'est-à-dire que vous ne fusionnez pas les fichiers à chaque enregistrement, mais à chaque fonctionnalité terminée). Vous passez de la résolution des conflits de fusion (le cas échéant) quelques fois par jour (à chaque validation) à une ou deux fois par semaine (à chaque fonctionnalité terminée). Cela signifie plus de temps de développement pour vos développeurs (quelque chose que les gestionnaires voudront maximiser).
Vous pouvez souligner que la différence qualitative est si grande que les développeurs de votre entreprise préfèrent les complications d'installation, de configuration et d'utilisation de git, en plus de Clearcase, pour ses fonctionnalités supplémentaires. C'est en fait un argument solide (s'il ne fournissait pas une meilleure expérience utilisateur et un ensemble de fonctionnalités améliorés, les gens n'iraient pas plus loin pour l'utiliser - d'autant plus que ce n'est pas requis par l'entreprise).
Dessinez un graphique représentant les validations avec les deux systèmes et montrez la rationalisation obtenue par les développeurs ne s'engageant pas publiquement (c.-à-d. Si vous borkez un fichier, le reste de l'équipe n'est pas bloqué et incapable de se conformer jusqu'à ce que vous le corrigiez). Expliquez également les contrôles de qualité supplémentaires que vous pouvez effectuer lorsque vous pouvez effectuer des validations intermédiaires sans affecter personne d'autre, le fait que vous pouvez obtenir des différences propres par fonctionnalité (essentiel pour les révisions de code).
la source
Il est difficile de vraiment juger ce qui serait un bon argument sans être témoin de la scène. Mais je vais essayer de vous aider à cadrer vos arguments pour qu'ils soient entendus.
Je suppose que votre public doit avoir un niveau de connaissance non expert sur le sujet et avoir un intérêt à maintenir le cap actuel. Ils ont des préoccupations et des responsabilités différentes, et ils peuvent subir de graves conséquences en cas de problème, vous devrez donc travailler dans cet état d'esprit. Anticipez certaines des questions ou des inquiétudes qu'ils pourraient avoir:
Quelles nouvelles capacités cela apporterait-il? Y a-t-il quelque chose que nous ne pouvons pas faire actuellement, que nous aimerions faire et que cette nouvelle chose nous permettrait? Commencez sur une note positive.
Quel est l'impact sur les calendriers de sortie? Quel est le coût de la mise en œuvre de ce changement vers la prochaine version immédiatement? Quels sont les coûts et les avantages des versions suivantes?
Cela entraînera-t-il un changement de processus? À la différence du calendrier de sortie, ce changement exigera-t-il que les personnes dans le processus de sortie changent de façon? Cela leur sera-t-il transparent ou devra-t-il s'adapter? Aurez-vous besoin de coopérer avec d'autres départements? Les gens résistent au changement.
Y a-t-il des dangers imminents à s'en tenir au système actuel? Le processus actuel a-t-il des dépendances logicielles ou matérielles qui ont disparu ou seront bientôt en fin de vie? S'appuie-t-il sur des connaissances spécialisées d'individus qui font augmenter les coûts d'embauche? Y a-t-il un trou de sécurité potentiel que le nouveau système bouche (points bonus si ce trou peut conduire à une action en justice)? Ne faites pas signe de la main ou «peut-être» ou «probablement» ceci: le sentiment est que cela a bien fonctionné pendant 20 ans, donc la charge de la preuve incombe à l'avocat du changement.
En outre, être précis sur les problèmes et les solutions . Si vous ne trouvez pas d'exemples précis, utilisez des estimations honnêtes de votre position en tant qu'expert. Des exemples d'autres sociétés / départements / entités adoptant un tel changement, de préférence de votre secteur, et leur évaluation de ce changement, vous seront utiles. (Ne choisissez pas d'exemples qui ont eu une sorte de problème informatique publicisé ces dernières années, sinon il vous incombera de prouver que ce changement n'était pas la cause.)
Vous pouvez trouver cette réponse pour convaincre la société pour laquelle je travaille de mettre en œuvre le contrôle de version? utile.
la source