Bonnes raisons simples pour avoir plusieurs environnements
Tout au long de ma carrière, j'ai travaillé dans des entreprises qui avaient une collection d'environnements différents à des fins différentes. Nous avons toujours eu plus ou moins notre environnement de bureau, un environnement de test, un environnement QA, un environnement de staging et un environnement de production. Cela vaut pour les serveurs/applications et toutes les sources de données que nous utilisons.
Lorsque j'ai commencé dans mon entreprise actuelle, j'ai constaté que 90% des applications étaient développées sur un environnement de bureau contre des sources de données de production ou développées directement sur le serveur de production en fonction de la plate-forme. Ce n'était pas particulièrement surprenant, car j'ai été embauché en partie pour apporter des modifications afin d'améliorer le fonctionnement de l'équipe de développement, ce qui ressort clairement de mon processus d'entrevue. Nous avons lentement commencé à changer la philosophie et très bientôt, la plupart des applications pouvaient être exécutées dans un environnement de bureau, de test ou de production. Peu de temps après, cette mise en scène est également arrivée.
Aujourd'hui, la plupart de nos développeurs voient l'intérêt de cette méthodologie et la défendent avec vigilance. Cependant, nous avons un certain nombre d'applications héritées qui n'ont jamais été migrées. Nous avons également un certain nombre de programmeurs hérités qui considèrent cela comme une perte de temps. Malheureusement, nous avons reçu des paroles élogieuses, mais nous n'avons jamais obtenu l'adhésion totale de la direction. Nous avons obtenu ce que nous pensions être un engagement à investir substantiellement dans ce domaine il y a environ un an, mais rien ne s'est concrétisé malgré la planification considérable que nous y avons mise. Nous constatons maintenant que nous avons besoin de plus en plus d'environnements. Nous avons besoin de l'aide des équipes d'administration du serveur/réseau pour la configuration et nous avons besoin de la participation des parties prenantes de l'entreprise pour soutenir le cycle de publication. Nous sommes maintenant à un endroit où un projet peut fonctionner ce que les développeurs raisonnables considéreraient "normalement" uniquement si vous avez les bonnes personnes sur le projet et le temps de configurer les environnements appropriés.
J'adorerais présenter un argument complet, mais la direction n'a vraiment pas le temps ni l'intérêt de m'écouter jusqu'à ce qu'il y ait un problème critique. Je ne peux pas vraiment exprimer les avantages simplement car cela m'a toujours semblé une seconde nature. Je me demandais s'il y avait bonnes raisons simples et irréfutables pour la séparation des environnements qui amèneraient les gestionnaires manquant d'expérience en développement à soutenir cette idée?. Existe-t-il de bonnes ressources/documentation sur le sujet?
La réponse: Argent
Peu m'importe la vraie raison. L'argent DOIT être à la base de tout votre raisonnement, surtout lorsqu'il s'agit de gestion.
Si nous nous asseyions tous les deux dans une pièce pendant 2 heures, nous pourrions trouver des dizaines des raisons pour lesquelles il est préférable d'avoir plusieurs environnements.
Voici le problème: si les raisons ne sont pas basées sur l'argent, alors aucune d'entre elles n'a d'importance.
Les programmeurs ne sont pas embauchés pour être intelligents. Ils ne sont pas embauchés pour être créatifs. Ils sont embauchés pour augmenter les revenus - soit en gagnant de l'argent, soit en économisant de l'argent. Si vous ne faites ni l'un ni l'autre, vous feriez mieux de préparer votre CV.
En le considérant de ce point de vue, la réponse est simple:
Le fait d'avoir un seul environnement augmente nos temps d'arrêt et entraîne une perte de revenus. Des environnements multiples nous permettent de protéger nos profits en offrant à nos utilisateurs un front-end qui est tout aussi fiable et fiable que notre entreprise.
Répétez-le tous les jours.
Il y a quelques bons commentaires ci-dessous qui ajoutent une réelle valeur à cette réponse, je vais donc les mentionner:
Karl Bielefeldt avait un grand point quand il a mentionné que l'analyse coûts/avantages est un facteur important. Un économiste pourrait l'appeler le coût d'opportunité de la poursuite d'environnements multiples. Bien qu'il puisse être surprenant d'entendre cela, il existe des scénarios où plusieurs environnements peuvent ne pas être la réponse ! Si le site Web de votre entreprise est un ajout très mineur, un temps d'arrêt inattendu peut en fait être plus coûteux manière efficace de faire des affaires. Cela ne ressemble pas à la position dans laquelle vous vous trouvez, mais cela vaut la peine d'être mentionné.
BlairHippo avait un bon point en ce que vous devriez vous sentir libre de faire en sorte que cela ressemble à une catastrophe (et si vous perdez vos données, c'est le cas!). La responsabilité est un excellent outil pour convaincre les gestionnaires, mais toujours pour la même raison - les poursuites sont coûteuses. Les éviter permet d'économiser de l'argent.
En complément, j'ai trouvé cet article assez bon. Il ne répond pas directement à votre question, mais vous permet de reconnaître la façon dont les programmeurs sont perçus par la direction, ce qui, à son tour, conduit à cette réponse. Bonne lecture.
Point de défaillance unique
En l'absence d'un environnement de développement ou de transfert, vous disposez d'un Single Point of Failure pour ces applications héritées. La direction vous entendra si vous décrivez les applications héritées en ces termes.
Vous devez être en mesure de présenter votre message en octets sonores qui ont du sens pour eux. Retirez le "Programmer Speak" de la discussion et remplacez-le par "Manager Speak". Imaginez également que vous avez un trajet de 30 secondes en ascenseur pour obtenir votre point de vue.
J'ai eu une situation où mon patron était un marine d'infanterie. Je n'arrêtais pas de lui dire que j'avais besoin d'outils logiciels et d'une formation en informatique pour mes Marines afin d'être plus productif. Il ne l'a pas compris. Un jour, je suis entré dans son bureau et je lui ai dit que tout allait bien.
J'ai dit quelque chose en ce sens ... "Si je menais une guerre, j'utiliserais des bâtons, des rochers et des branches d'arbres. Ce dont j'ai besoin, ce sont des grenades, des bazookas et des mitrailleuses." Il a compris le message.
Est-ce réellement critique?
Je peux comprendre le désir d'utiliser des environnements séparés. La question non évidente est:
Est-il réellement essentiel de migrer un système hérité ?
Je pense que la plupart des gens soucieux de la technique ont tendance à se concentrer sur la question académique de savoir quelle est la meilleure solution, ce qui est bien dans le monde universitaire. En affaires, le meilleur ne l'emporte pas toujours. Je ne dis pas que ce soit négatif, ni déclencher une guerre des flammes. J'énonce l'évidence, ou ce qui devrait être évident pour ceux d'entre nous qui travaillent dans le domaine des logiciels depuis quelques années.
Toutes les décisions commerciales sont généralement prises en fonction du rapport coût/bénéfice perçu. La question que l'entreprise pose probablement est donc:
Le coût du système supplémentaire et des investissements de développement dans une application héritée en vaut-il la peine par rapport à ce même investissement dans un autre projet/produit?
J'ai et fais régulièrement des analyses coûts-avantages pour faire des déterminations non seulement dans les logiciels de migration/réécriture, mais dans les décisions quotidiennes, un lead s'engage généralement. J'ai transmis la réécriture/migration d'anciens logiciels car donc valeur.
séparation des environnements
Les raisons commerciales de séparer les environnements.
- Moins de risques dans les versions et corrections de bogues. Prouvez-le avec des chiffres. Combien de fois le produit a-t-il échoué et a-t-il coûté des revenus aux clients en raison d'une mauvaise version/bug.
- Moins de risques en développement. Souffler accidentellement la base de développement est différent de souffler accidentellement la base de production
- La capacité de séparer clairement les rôles et l'accès, par exemple. une meilleure sécurité. limiter le nombre de doigts dans le graphique de production est une bonne chose
- La possibilité de séparer les environnements, ainsi que les pratiques et procédures associées à ce style de développement, permettent une intégration future dans les systèmes cloud.
- La séparation de l'environnement devrait forcer l'efficacité dans la réplication des environnements qui peuvent être utiles dans une mise à l'échelle programmée et dynamique.
Il semble que vous ayez déjà tous les "bons" arguments en place. Au lieu de cela, vous rencontrez un "red-hareng", si vous voulez. Ou, "courir après la carotte"
la direction n'a vraiment pas le temps ni l'intérêt de m'écouter jusqu'à ce qu'il y ait un problème critique
C'est ce que je considère comme le vrai problème. D'après mon expérience, si une entreprise a des pratiques de développement inférieures à la normale aussi mauvaises que vous le décrivez. Il ne s'agit pas simplement de "nous ne savions pas mieux". Il s'agit plutôt d'une compilation de la dette technique causée par une équipe de direction supérieure qui ne connaît pas (se soucie?) Des problèmes qu'elle présente.
Dans de tels cas, un bon discours d'encouragement ne fera pas basculer les choses dans votre direction. Peut-être un traumatisme grave (défaillance du produit visible par le client et directement liée à de mauvaises pratiques), mais je suis sûr que les techniciens avertis sont sensés avant que vous n'essayiez de parler.
Ma suggestion est de le sucer et de prendre les choses pour ce qu'elles sont ou de chercher un nouveau poste.
Combien de groupes de personnes prévoient de travailler sur l'application à la fois? Habituellement, j'ai vu un environnement pour chaque groupe de personnes. Il s'agit des développeurs (ils obtiennent un environnement DEV et un environnement d'intégration DEV - certains diront que ce n'est pas nécessaire à 100%, je dirais que cela varie selon le projet), deux environnements de test (un groupe de testeurs effectuant des tests très détaillés, l'autre pour testeurs QA de haut niveau - ils sont généralement de vrais utilisateurs professionnels, pas des testeurs formés). Il existe également généralement un environnement de test de performances isolé (vous pouvez donc tester d'énormes volumes de données, simuler d'énormes volumes d'utilisateurs, etc ... g).
Pourquoi tous ces environnements? Ainsi, différents groupes peuvent tester différentes fonctionnalités sans marcher l'un sur l'autre. Si les développeurs et les testeurs travaillent dans le même environnement, c'est un cauchemar: un testeur peut ouvrir un défaut sur une fonctionnalité qui est activement modifiée chaque minute par un développeur. S'il y a deux niveaux de test, ils peuvent se concentrer sur une activité différente et ne pas s'inquiéter de gâcher les données les uns des autres. Le fait d'avoir un environnement de performances isolé vous permet d'exécuter des tests qui peuvent bloquer la machine, mais s'il est isolé, aucun autre testeur ne sera affecté.
Quand trop de gens essaient de faire trop de choses différentes dans le même environnement, vous vous retrouvez avec beaucoup de temps perdu alors qu'un groupe attend que le test d'un autre groupe se termine pour pouvoir exécuter le leur. Et cela fait perdre du temps, et le temps perdu peut conduire à un gaspillage d'argent, ce qui a souligné Stargazer712 pourrait constituer l'argument le plus fort.
Une autre raison (moins courante) est les données: si votre application contient des données personnelles ou des données de carte de crédit sensibles, vous ne pouvez généralement pas les mettre dans des environnements de test, et il y a généralement des exigences de masquage pour tout sauf les environnements QA et Production.
Vous semblez avoir investi beaucoup d'efforts pour provoquer un changement culturel dans votre milieu de travail. C'est une grande réussite car le changement est difficile dans le meilleur des cas, mais le changement culturel ne consiste pas simplement à changer les esprits des gens, mais à changer les habitudes, à briser les préjugés et, finalement, à ouvrir les esprits potentiellement fermés à de plus grandes possibilités. Donc, la question à vous poser à ce stade est "Qu'est-ce que j'ai raté?". La réponse est simple: vous ne vous êtes peut-être pas pleinement engagé dans la gestion.
Obtenir l'adhésion de la direction est facile, mais il est encore plus difficile de se faire accepter. Indépendamment des arguments concernant l'argent, etc., la réalité est que vous devez être en mesure d'influencer la vision des priorités de la direction. Votre responsable aura un budget et voudra montrer que le budget a été appliqué de manière raisonnable et en accord avec les valeurs et les priorités de l'entreprise. Certaines de ces priorités seront d'ordre financier, mais d'autres viseront à répondre à d'autres besoins. Dans certains cas, cela peut signifier graisser les paumes des autres managers afin d'obtenir la promotion que votre patron a toujours voulu. Dans la plupart des cas, cependant, il s'agira probablement de trouver des moyens de gagner plus d'affaires ou d'améliorer les relations avec les partenaires et les clients. Si vous ne pouvez pas faire valoir vos arguments en ces termes, vous ne pourrez aller aussi loin avant de vous retrouver dans une impasse.
Ma suggestion est d'essayer de faire un cas sur la productivité et comment cela affecte le budget, comme d'autres l'ont suggéré, mais aussi de le faire en termes de priorités de votre entreprise et comment votre productivité pourrait avoir un impact direct sur les relations de l'entreprise avec d'autres entreprises.
En voici une: la testabilité.
Avoir un environnement de test vous donne la liberté d'effectuer des tests sur une base de données qu'il serait déconseillé d'effectuer dans un environnement de production.
Vous souhaitez changer la façon dont votre organisation développe ses logiciels? Oubliez de vous soucier des "raisons" de "faire les choses différemment". Les humains ne changent pas de comportement à cause d'arguments rationnels. Ils changent en raison des influences psychologiques sur leurs habitudes.
Alors, où vais-je avec ça?
Alors que occasionnellement vous pouvez réussir à changer le comportement d'une organisation grâce à l'argumentation, il existe d'autres tactiques qui fonctionnent mieux. Ceux-ci inclus:
Support de base: trouvez UN autre développeur "hérité" qui est prêt à vous donner une chance. Faites équipe avec lui et changez la façon dont les choses fonctionnent. N'annoncez pas le changement. Faites le changement. Si quelqu'un vous pose des questions à ce sujet, dites simplement "Oh oui, c'est comme ça que nous le faisons maintenant."
Prenez la responsabilité. Bénévole pour gérer les déploiements pour les personnes héritées. Agissez comme vous l'aimez. Ils peuvent être heureux de renoncer à cette responsabilité. Ensuite, exécutez-le comme vous le souhaitez.
Blâmez les bonnes personnes pour leurs erreurs. La prochaine fois qu'un bogue d'application hérité sera introduit en production en raison de votre mécanisme de déploiement de l'âge de pierre, signalez-le. Faites-le subtilement ... Pas dans un e-mail. La prochaine fois que vous êtes en réunion avec un responsable, mentionnez avec désinvolture l'exemple d'une raison pour laquelle le déploiement a été problématique. "Ouais, rappelez-vous comment nous avons brouillé vendredi dernier à cause du bug de Foo que Bob a mis en production? Ouais, c'était beaucoup d'efforts gaspillés!"
Rendez-le plus facile à faire. Regardez l'iphone, par exemple. Il y a UN bouton dessus. (Eh bien, deux). C'est TRÈS facile à allumer. Rendez le déploiement dans plusieurs environnements stupide et facile. Rendez-le si facile que tous les gestionnaires peuvent le faire!
C'est plus un problème lorsque vous commencez à traiter avec des systèmes interconnectés ou hérités, des systèmes dont l'entreprise dépend pour fonctionner et être précis. C'est important car il doit y avoir une ségrégation entre les étapes, c'est la raison pour laquelle vous ne DEV sur PROD parce qu'il a le potentiel de causer des millions de dollars de dommages en temps perd.
Nous faisons toujours DEV -> QA -> PROD (parfois ces étapes sont divisées en petits morceaux) avec du matériel identique derrière elles. Les données de production actuelles sont toujours transmises de PROD à QA à DEV.
DEV: est destiné à être le bac à sable de développement, où les choses sont essayées, itérées et battues sur toutes les données de cet environnement ne doivent jamais faire confiance et est régulièrement saccagée par les développeurs qui trouvent simplement des moyens de résoudre un problème.
QA: Une fois que vos développeurs sont satisfaits des tests unitaires, il est temps pour le groupe de test d'y jeter un œil. Ils exécutent des cas de test, des tests de performances et trouvent des bogues. Ces bugs/améliorations sont renvoyés à DEV et le cycle continue jusqu'à ce que tout le monde soit satisfait.
PROD: Une fois arrivé à ce stade, vous devez vous assurer que le code fonctionne en conjonction avec les données actuelles et que votre groupe QA/utilisateurs professionnels sont satisfaits de la mise en œuvre. Si vous avez tout fait correctement, vous devriez simplement pouvoir mettre à jour le code et en finir avec lui.
De la même manière que vous ne diffuseriez jamais un produit non testé aux clients, vous ne devriez jamais publier de code non testé dans un environnement de production.
Si l'entreprise n'est pas disposée à investir du temps pour le faire correctement, elle remboursera le coût de la maintenance d'urgence et des erreurs 10 fois.
À titre d'exemple: nous avions une entreprise qui avait décidé de modifier elle-même un rapport en production. Personne ne savait que cela avait changé jusqu'à ce que nous intervenions pour régler divers problèmes un an ou deux plus tard.
Lorsque nous avons souligné l'irrégularité du rapport, le visage du directeur financier est devenu blanc, il s'est avéré qu'ils perdaient environ 250 000 $ par trimestre en raison d'une modification rapide.
Cela arrive plus souvent que vous ne le pensez, si vous ne pouvez pas vous permettre de le faire correctement, alors ne le faites pas.
La direction a une grande part derrière le succès des sociétés de logiciels et des produits logiciels qui ont nécessité de générer ces environnements. Prenons un exemple de votre projet. Si votre logiciel est développé à grande échelle, alors si vous ne gérez pas les exigences de votre projet, le contrôle des processus, les versions de test, etc., ce sont les chances d'échec. pour que la gestion de projet existe.
Je suis quelque peu d'accord avec @ Stargazer712 que votre déclaration pointe sur l'argent compte, mais vérifiez la déclaration suivante que j'ai tirée du livre de Marc Hamilton sur le développement de logiciels: construire des systèmes fiables (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Après avoir examiné tous ces facteurs; Mon opinion sur votre question est que l'environnement unique ne vous permet pas de faire des économies, il faudra un processus à long terme pour terminer le projet/logiciel. Les environnements distribués permettront d'économiser du temps et des revenus car j'ai appris et vu dans mon expérience que ce qui s'est passé avec les sociétés de logiciels de démarrage à partir desquelles j'ai démarré mon opérateur.
Il y a beaucoup d'articles qui démontrent que ce qui compte pour le succès, vérifiez celui-ci Organiser pour un développement logiciel réussi
Chaque individu dans une organisation possède certaines compétences, et ces compétences sont généralement mesurées par rapport à des mesures de performance formelles ou informelles conduisant à des récompenses (rémunération) comme incitations à la performance future. Les gens d'une organisation établissent sa culture - ces modèles de comportement et ces valeurs qui sont généralement reconnus comme étant adoptés.
Un grand nombre de développeurs de logiciels auront du mal et ne parviendront finalement pas à atteindre leurs objectifs s'ils doivent passer tout leur temps à lutter contre une structure organisationnelle inappropriée.
Beaucoup de startups logicielles commencent leur vie avec pas plus de deux développeurs travaillant dans un garage. Peu de structure organisationnelle est requise à ce stade de l'histoire d'une entreprise, mais la structure organisationnelle existe toujours. Par exemple, en 1977, lorsque Bill Gates et Paul Allen ont formé leur partenariat et l'ont officiellement nommé Microsoft, l'entreprise avait une structure organisationnelle minimale. Moins d'une douzaine d'employés travaillaient dans le premier bureau de Microsoft à Albuquerque, au Nouveau-Mexique, et tout le monde savait qui était en charge. Aucun organigramme compliqué n'était nécessaire pour comprendre la structure hiérarchique de chacun. En même temps, tous les employés connaissaient leur rôle dans l'entreprise et ce qu'ils essayaient d'accomplir. En effet, toute structure organisationnelle nécessaire pouvait être communiquée de manière informelle entre chacun des employés.
On dirait que vous avez de nombreux environnements différents et qu'il en coûte beaucoup de temps aux gens pour configurer un "environnement".
Vous devriez avoir le le moins grand nombre d '"environnements" différents avec lequel vous pouvez vous en sortir, mais être capable de cloner de nombreuses copies pour autant de raisons que vous et l'entreprise souhaitez. (en utilisant "environnement pour désigner la configuration du système)!
De manière optimale, les seules différences devraient être:
- Taille (minimale, recommandée, la plus grande prise en charge/testée);
- La mise en scène et la production ne disposent pas d'outils de développement
- La production est protégée contre l'écrasement accidentel des données
- Vous pouvez très facilement charger des données clients de démonstration, de test ou [anoymisées] sur des serveurs de développement ou de transfert
ALORS, la question de savoir combien et quel type de test doit être effectué est une évaluation des risques/coûts de l'entreprise et décidée au niveau de l'entreprise, car c'est l'entreprise dans son ensemble qui souffrira si des défauts importants se manifestent auprès d'une gamme de clients. .
Édition ultérieure: cela m'a incité à rationaliser mes conventions de dénomination avec mes produits Web (merci pour la question). J'ai choisi quatre "environnements", avec des tests répartis entre qa (niveau unique minimal pour tester les fonctionnalités uniquement) et la mise en scène (même architecture que la production, pour les tests de charge/performances/volume).
La seule vraie différence dans l'approvisionnement est la production/mise en place, installez une base de données sur un système séparé, que je contrôle par quels groupes se trouvent les différents serveurs. Qa/dev ont à la fois le serveur Web et les rôles db. L'équilibrage de charge est effectué par cloudflare.
J'ai également une variable ENV_NO, qui est transmise aux systèmes afin que je puisse choisir d'avoir autant d'exemples "qa" ou "staging" que je le souhaite.
Donc, pour configurer un deuxième environnement qa incluant ma dernière sauvegarde en direct, les commandes seraient:
git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch
git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two
ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)
Enfin, j'ai un serveur supplémentaire (en option) appelé "readonly" comme dernier filet de sécurité avant de toucher le sol. Il est provisionné comme un système qa mais avec la sauvegarde et la mise à jour des dernières nuits désactivées (le logiciel est également mis à jour la nuit dernière).
Il utilise une approche "Tous les œufs dans un panier différent": il est approvisionné avec un emplacement différent/un registraire DNS, un hôte DNS et des fournisseurs de services d'hôte système. C'est l'ultime/dernier filet de sécurité, donc si tout s'est enflammé, vous pouvez au moins accéder aux données jusqu'à la nuit dernière. Les scripts de provisioning isolent la différence entre les différents fournisseurs, donc 99% est le même, juste l'indicateur en lecture seule. L'équilibreur de charge Cloudflare redirigera le trafic vers le site en lecture seule si tous les serveurs actifs sont en panne.
Oubliez le temps, l'argent, la testabilité, la qualité ... que diriez-vous de la réputation .
bonnes raisons simples et irréfutables pour la séparation des environnements qui amèneraient les gestionnaires manquant d'expérience en développement à soutenir cette idée.
ber a récemment expédié du code à github qui contenait des mots de passe pour leur environnement en direct , permettant aux "pirates" de télécharger toutes les informations de leurs clients. Uber dit que c'était une violation, tout le monde dit "ne mettez pas les clés de vos verrous à la vue du public. Si leurs développeurs travaillaient entièrement sur un environnement de développement, ils auraient peut-être publié les clés de leur environnement de développement sur github, mais c'est entièrement Le fait que ceux de production aient été publiés montre à quel point cette idée de faire du développement dans l'environnement de production est médiocre.
Rappelez simplement à votre manager que des erreurs se produisent, donc la façon d'éviter qu'il ne soit traîné devant le PDG qui est sur le point de se faire griller devant des journalistes et de se moquer du public technologique est de prendre des mesures simples et évidentes pour éviter que ces erreurs ne soient catastrophiques. ceux.
Quand il s'agit de faire un changement, vous aurez la chance d'avoir quelqu'un qui écoutera simplement votre opinion professionnelle et mettra en œuvre les changements suggérés.
D'après mon expérience, chaque fois que je devais faire un changement majeur, je devais le justifier en termes d'économies que l'entreprise allait réaliser. Par exemple, l'introduction de ReSharper dans le pipeline de développement a été assez facile, car j'ai pu dire quelque chose sur les lignes:
ReSharper coûte environ 50 £ par développeur. Le coût moyen d'un développeur par an est de 40 000 £. ReSharper devrait augmenter la productivité des développeurs d'au moins 20% compte tenu de son utilisation à son plein potentiel. Supposons que le développeur passe 75% de son temps à écrire du code dans IDE. 75% de 40k est £ 30k. 30 000 £ représentent désormais le coût de la productivité du développeur. Un pourcentage supplémentaire de productivité (1%) par an coûte 300 £. Pour obtenir une productivité supplémentaire de 20%, l'entreprise devrait dépenser 6 000 £.
Si vous mettez cela en perspective pour l'entreprise, vous pouvez dire que vous pouvez embaucher quelqu'un d'autre et obtenir une productivité supplémentaire de 20% pour 6 000 £, ou vous pouvez obtenir le même résultat en dépensant 50 £ sur une licence ReSharper. Une fois les chiffres devant l'entreprise, la décision sera facile à prendre.
Maintenant, en ce qui concerne vos questions concernant la multiplicité des environnements, tout ce que vous avez à faire est de trouver un moyen de calculer combien il en coûte à l'entreprise chaque année pour disposer de ces environnements.
Vous pouvez demander à vos collègues développeurs de garder une trace des heures consacrées chaque semaine à la configuration des applications pour le développement, le déploiement, etc. Par exemple, dix heures de temps pour un développeur senior peuvent coûter 500 £ aux entreprises. C'est 10 heures qui peuvent être consacrées au développement, ou quelque chose de beaucoup plus important. Vous rassemblez les chiffres pour une certaine période de temps et offrez aux entreprises un coût annuel.
Personnellement, je déteste ce genre de politique, mais c'est courant et nous devons vivre avec.