Bonnes raisons simples d'avoir plusieurs environnements

Tout au long de ma carrière, j'ai travaillé dans des entreprises qui disposaient d'un ensemble d'environnements différents pour des objectifs différents. Nous avons toujours eu plus ou moins notre environnement de bureau, un environnement de test, un environnement de contrôle qualité, un environnement de transfert et un environnement de production. Cela concernait à la fois les serveurs / applications et toutes les sources de données que nous utilisions.

Lorsque j'ai commencé à travailler pour ma société actuelle, j'ai constaté que 90% des applications avaient été développées sur un environnement de bureau en utilisant des sources de données de production ou directement sur le serveur de production, en fonction de la plate-forme. Cela n’était pas particulièrement surprenant, car j’avais été embauché en partie pour apporter des changements afin d’améliorer le fonctionnement de l’équipe de développement, ce qui ressort clairement de mon processus d’entretien. Nous avons lentement commencé à adopter cette philosophie et très bientôt, la plupart des applications pourraient être exécutées dans un environnement de bureau, de test ou de production. Peu de temps après, cette mise en scène a également eu lieu.

Maintenant, la plupart de nos développeurs voient les avantages 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 de longue date qui considèrent cela comme une perte de temps. Malheureusement, nous avons eu la parole, mais jamais la direction n’a pleinement souscrit. Nous avons eu ce que nous pensions être un engagement à investir de manière substantielle dans ce projet il y a environ un an, mais rien ne s'est concrétisé malgré la planification considérable que nous avons mise en œuvre. Nous constatons maintenant que nous avons besoin de plus en plus d'environnements. Nous avons besoin de l’aide des équipes d’administration de serveur / réseau pour la configuration et nous avons besoin de la participation des parties prenantes de l’entreprise pour prendre en charge le cycle de publication. Nous sommes maintenant à un endroit où un projet peut fonctionner ce que les développeurs raisonnables considéreraient "normalement"

J'aimerais présenter un argument complet, mais la direction n'a vraiment pas le temps et l'intérêt de m'écouter tant qu'il n'y a pas de problème critique. Je ne peux pas vraiment expliquer les avantages simplement, car cela me semblait toujours une seconde nature. Je me demandais s’il existait des raisons valables, simples et irréfutables justifiant la séparation des environnements, ce qui donnerait aux gestionnaires un manque d’expérience en matière de développement pour appuyer cette idée. . Existe-t-il de bonnes ressources / littérature sur le sujet?

La réponse: l' argent

Je me fiche de la raison réelle. L'argent DOIT être à la base de tout votre raisonnement, en particulier lorsque vous traitez avec la direction.

Si nous restions tous les deux assis dans une pièce pendant 2 heures, nous pourrions trouver des dizaines de 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 leurs revenus - en gagnant de l'argent ou en économisant de l'argent. Si vous ne faites pas l’un ou l’autre de ceux-ci, vous feriez mieux de préparer votre CV.

Quand on la regarde de ce point de vue, la réponse est simple:

Avoir un seul environnement augmente nos temps d'arrêt et entraîne une perte de revenus. Les environnements multiples nous permettent de protéger nos profits en offrant à nos utilisateurs un frontal aussi fiable et fiable que notre société.

Répétez tous les jours.

Vous trouverez ci-dessous d'excellents commentaires qui ajoutent une valeur réelle à cette réponse. Je les mentionnerai donc:

• Karl Bielefeldt a souligné le fait que l'analyse coûts / avantages est un facteur important. Un économiste pourrait s'y référer comme le coût d'opportunité de la poursuite de plusieurs environnements. Bien que cela puisse paraître surprenant, il existe des scénarios dans lesquels plusieurs environnements peuvent ne pas être la solution! Si le site Web de votre entreprise est un ajout très mineur, un temps d'arrêt imprévu peut en fait constituer le moyen le plus rentable 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 sens que vous devriez vous sentir libre de faire croire à une catastrophe (et si vous perdez vos données, c'est!). La responsabilité est un excellent outil pour persuader les gestionnaires, mais pour la même raison, les poursuites coûtent cher. Les éviter permet d'économiser de l'argent.

En addendum, j'ai trouvé cet article plutôt bon. Cela ne répond pas directement à votre question, mais vous permet de reconnaître la façon dont les programmeurs sont considérés par la direction, ce qui 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 point de défaillance unique pour ces applications héritées. La direction vous entendra si vous décrivez les applications existantes en ces termes.

Vous devez être capable de présenter votre message dans des octets sonores qui leur conviennent. Enlevez le " Programmeur Parler " de la discussion et remplacez-le par " Manager Parlez ". Imaginez également que vous disposez d'un ascenseur de 30 secondes pour faire passer votre message.

J'ai eu une situation où mon chef était un marin 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 n'a pas compris. Un jour, je suis finalement allé dans son bureau et je lui ai dit que tout allait bien.

J'ai dit quelque chose à l'effet ... "Si je faisais la guerre, j'utiliserais des bâtons, des pierres et des branches d'arbres. Ce dont j'ai besoin, ce sont des grenades, des bazookas et des mitrailleuses." Il a eu le message.

Est-ce réellement critique?

Je peux comprendre le désir d'utiliser des environnements distincts. La question non évidente est:

Est-il réellement essentiel de migrer un système hérité ?

Je pense que la plupart des gens d’esprit technique ont tendance à se concentrer sur la question académique de savoir quelle est la meilleure solution, ce qui est acceptable dans le monde universitaire. En affaires, le meilleur ne gagne pas toujours. Je ne dis pas que ce soit négatif, ou déclencher une guerre de flammes. Je lapalissade, ou ce qui devrait être évident pour ceux d' entre nous qui ont été dans le logiciel d' affaires depuis quelques années.

Toutes les décisions d’entreprise sont généralement prises en fonction du coût / bénéfice perçu. La question que l'entreprise se pose probablement est la suivante:

Le coût du système supplémentaire et des investissements de développement dans une application existante en vaut-il la peine par rapport au même investissement que dans un autre projet / produit?

Je fais toujours régulièrement des analyses coûts-avantages pour prendre des décisions, pas seulement pour la migration / la réécriture de logiciels, mais aussi pour les décisions au jour le jour. donc valeur.

Environnements de séparation

Les raisons commerciales pour séparer les environnements.

• Moins de risques dans les versions et les corrections de bugs. Prouvez-le avec des chiffres. Combien de fois le produit a-t-il échoué et coûté des revenus à la clientèle à cause d'une mauvaise publication / d'un mauvais bogue?
• Moins de risque en développement. Souffler accidentellement la base de données dev 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. meilleure sécurité. limiter le nombre de doigts dans la tarte 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, permet une future intégration dans les systèmes en nuage.
• La séparation de l'environnement doit forcer l'efficacité dans la réplication des environnements, ce qui peut être utile pour une mise à l'échelle planifiée ou dynamique.

Il semble que vous ayez tous les "bons" arguments déjà en place. Au lieu de cela, vous rencontrez un "red-hareng", si vous voulez. Ou, "chassant la carotte"

la direction n'a vraiment pas le temps et l'intérêt de m'entendre jusqu'à ce qu'il y ait un problème critique

C'est ce que je considère être le vrai problème. D'après mon expérience, si une entreprise a des pratiques de développement médiocres aussi médiocres que vous le décrivez. Ce n'est pas simplement une question de "nous ne savions pas mieux". C’est plutôt une compilation de dettes techniques causées par une équipe de direction qui ne connaît pas les problèmes qu’elle pose.

Dans de tels cas, un bon discours d'encouragement ne va pas soudainement faire 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 avisés sont sensés avant que vous n'ayez essayé le sujet.

Ma suggestion est soit de faire le plein et de prendre les choses pour ce qu’elles sont, soit de chercher un nouveau poste.

Combien de groupes de personnes envisagent 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 ont un environnement DEV et un environnement d’intégration DEV - certains diraient que ce n’est pas nécessaire à 100%, je dirais que cela varie d’un projet à l’autre), deux environnements de test (un groupe de testeurs effectuant des tests très détaillés, l’autre pour testeurs d’assurance qualité de haut niveau - en général, ce sont des utilisateurs professionnels, et non des testeurs formés). Il existe également un environnement de test des performances isolé (vous pouvez ainsi tester d’énormes volumes de données, simuler d’énormes volumes d’utilisateurs, etc.).

Pourquoi tous ces environnements? Ainsi, différents groupes peuvent tester différentes fonctionnalités sans se marcher sur les pieds. 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 des activités différentes sans avoir à s'inquiéter de falsifier leurs données. Avoir un environnement de performance isolé vous permet d'exécuter des tests pouvant bloquer la machine, mais si elle est isolée, aucun autre testeur ne sera affecté.

Quand trop de gens essaient de faire trop de choses différentes dans le même environnement, vous perdez beaucoup de temps alors qu'un groupe attend le test d'un autre groupe pour pouvoir le faire. Et cela fait perdre du temps, et du temps perdu peut conduire à un gaspillage d’argent, ce qui, selon Stargazer 712, pourrait constituer l’arugment le plus puissant.

Les données constituent une autre raison (moins courante): si votre application contient des données personnelles sensibles ou des données de carte de crédit, vous ne pouvez généralement pas utiliser ces informations dans des environnements de test.

Vous semblez avoir déployé beaucoup d'efforts pour amener un changement de culture dans votre lieu de travail. C’est un grand exploit, car le changement est difficile dans le meilleur des cas, mais le changement culturel ne consiste pas simplement à changer les mentalités, mais aussi à changer les habitudes, à éliminer les préjugés et, en fin de compte, à ouvrir davantage les esprits potentiellement fermés. Donc, la question à vous poser à ce stade est "Qu'est-ce que j'ai manqué?". La réponse facile est que vous n’avez peut-être pas pleinement travaillé avec la direction.

Il est facile d'obtenir l'adhésion de la direction, mais l'acceptation est encore plus difficile. Quels que soient les arguments relatifs à l'argent, etc., la réalité est qu'il faut pouvoir influencer le point de vue de la direction sur les priorités. Votre responsable disposera d'un budget et voudra montrer que ce budget a été appliqué de manière judicieuse, conformément aux valeurs et aux priorités de l'entreprise. Certaines de ces priorités seront d'ordre fiscal, mais d'autres viseront à répondre à d'autres besoins. Dans certains cas, cela peut signifier graisser la paume des mains d’autres gestionnaires afin d’obtenir la promotion que votre patron a toujours souhaitée. Cependant, dans la plupart des cas, il s'agira probablement de trouver des moyens d'accroître les ventes ou d'améliorer les relations avec les partenaires et les clients. Si vous ne pouvez pas défendre votre cause dans ces termes, vous ne pourrez aller si loin avant de vous retrouver dans une impasse.

Ma suggestion est d'essayer de défendre la productivité et son impact sur le budget, comme d'autres l'ont suggéré, mais également de définir les priorités de votre société et l'impact que votre productivité pourrait avoir sur les relations de la société avec d'autres sociétés.

En voici un: 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é de réaliser dans un environnement de production.

Vous voulez changer la façon dont votre organisation développe ses logiciels? Ne vous souciez plus des "raisons" pour "faire les choses différemment". Les humains ne changent pas de comportement à cause d'arguments rationnels. Ils changent à cause d'influences psychologiques sur leurs habitudes.

Alors, où vais-je avec ça?

Bien que vous puissiez parfois modifier avec succès le comportement d'une organisation grâce à l'argumentation, il existe d'autres tactiques qui fonctionnent mieux. Ceux-ci inclus:

• Soutien à la base: Trouvez UN SEUL autre développeur "traditionnel" qui est prêt à vous donner l’occasion. Associez-vous à lui et changez le fonctionnement des choses. Ne pas annoncer le changement. Juste faire le changement. Si quelqu'un vous pose des questions à ce sujet, dites simplement "Oh oui, c'est comme ça que nous procédons maintenant."

• Assumer la responsabilité. Volontaire pour gérer les déploiements pour les anciens. Agis comme tu l'aimes. Ils peuvent être heureux de renoncer à cette responsabilité. Puis lancez-le comme vous le souhaitez.

• Blâmez les bonnes personnes pour leurs erreurs. La prochaine fois qu'un bogue d'application héritée entrera en production à cause de votre mécanisme de déploiement de l'âge de pierre, signalez-le. Faites-le subtilement ... pas dans un courriel. La prochaine fois que vous rencontrerez un responsable, citez simplement l'exemple de la raison pour laquelle le déploiement posait problème. "Ouais, souviens-toi de la façon dont nous nous sommes débrouillés vendredi dernier à cause du bug de Foo que Bob a enregistré dans la production? Ouais, c'était beaucoup d'efforts perdus!"

• Rendez-le facile à faire de la meilleure façon. Regardez l'iphone, par exemple. Il y a UN bouton dessus. (Eh bien, deux). C'est très facile à allumer. Faites en sorte que le déploiement dans plusieurs environnements devienne fou, 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éparation entre les étapes. C’est la raison pour laquelle vous ne devenez pas DEV sur PROD car il peut potentiellement causer des millions de dollars de dommages en moins de temps .

Nous faisons toujours DEV -> QA -> PROD (parfois ces étapes sont divisées en morceaux plus petits) avec le même matériel derrière elles. Les données de production actuelles sont toujours transférées 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 être approuvées et sont régulièrement détruites par les développeurs qui cherchent 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 de s'y intéresser. Ils exécutent des cas de test, des tests de performance et trouvent des bogues. Ces bugs / améliorations sont renvoyés à DEV et le cycle continue jusqu'à ce que tout le monde soit heureux.

PROD: une fois que vous en êtes à cette étape, vous devez être sûr que le code fonctionne en conjonction avec les données actuelles et que votre groupe d'assurance qualité / vos utilisateurs sont satisfaits de la mise en œuvre. Si vous avez tout fait correctement, vous devriez simplement pouvoir mettre à jour le code et en finir.

De la même manière que vous ne publiez jamais un produit non testé pour les clients, vous ne devez jamais diffuser de code non testé pour un environnement de production.

Si l'entreprise n'est pas disposée à investir suffisamment de temps pour le faire correctement, elle remboursera 10 fois les coûts liés à la maintenance d'urgence et aux erreurs.

Petit exemple: une entreprise a décidé de modifier elle-même un rapport en production. Personne ne savait que cela avait changé jusqu'à ce que nous arrivions pour régler divers problèmes un an ou deux plus tard.

Lorsque nous avons signalé l'irrégularité dans le rapport, le visage du directeur financier est devenu blanc, il s'est avéré qu'il perdait environ 250 000 dollars par trimestre en raison de la rapidité avec laquelle quelqu'un a effectué un changement.

Cela se produit plus souvent que vous ne le pensez, si vous ne pouvez vous permettre de le faire correctement, alors ne le faites pas.

La direction contribue en grande partie au succès des éditeurs de logiciels et des produits logiciels nécessaires à la création de ces environnements. Prenons un exemple de votre projet. Si votre logiciel est développé à grande échelle, si vous ne gérez pas les exigences de votre projet, le contrôle des processus, les versions de test, etc., vous risquez alors un échec. de sorte que la gestion de projet existe.

Je suis un peu d'accord avec @ Stargazer712 sur le fait que votre déclaration souligne les questions d'argent, mais vérifiez la déclaration suivante que je viens de lire dans le livre de Marc Hamilton intitulé Développement de logiciels: Construire des systèmes fiables (Prentice Hall, 1999, ISBN 0-13-081246- 3) Après avoir examiné tous ces facteurs; Mon opinion sur votre question est que Single Environment ne vous permet pas de faire des économies, mais que le processus / logiciel sera achevé à long terme. Les environnements distribués permettront d'économiser du temps et des revenus au fur et à mesure de mon expérience et de l'expérience de ce que sont devenus les éditeurs de logiciels de démarrage à partir desquels j'ai démarré ma carrière.

Il y a beaucoup d'articles qui démontrent que ce qui compte pour réussir, Cochez cette case. Organiser pour réussir le développement de logiciels

Chaque personne dans une organisation possède certaines compétences, et ces compétences sont généralement comparées à des mesures de performance formelles ou informelles conduisant à des récompenses (rémunération) en tant qu'incitatifs pour des performances futures. Les membres d’une organisation établissent sa culture, à savoir les comportements et les valeurs généralement reconnus comme adoptés.

Un grand nombre de développeurs de logiciels auront du mal à atteindre leurs objectifs s’ils doivent passer tout leur temps à lutter contre une structure organisationnelle inappropriée.

Beaucoup de start-up de logiciels commencent leur vie avec seulement deux développeurs travaillant dans un garage. À ce stade de l’histoire de l’entreprise, la structure organisationnelle n’est pas très lourde, mais elle existe toujours. Par exemple, en 1977, lorsque Bill Gates et Paul Allen ont formé leur partenariat et l'ont officiellement baptisé Microsoft, la société disposait d'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 le responsable. Aucun organigramme compliqué n'était nécessaire pour comprendre la structure hiérarchique de chacun. Dans le 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.

Oubliez le temps, l'argent, la testabilité, la qualité… que diriez-vous de la réputation .

bonnes, simples et irréfutables raisons de la séparation des environnements, ce qui aurait pour conséquence que les gestionnaires manquant d’expérience en développement soutiendraient cette idée.

Uber a récemment envoyé à github du code contenant des mots de passe pour leur environnement en direct , permettant ainsi aux "pirates" de télécharger toutes les informations de leurs clients. Uber dit que c'était une faille, tout le monde dit "ne mettez pas les clés de vos serrures à la vue du public. Si leurs développeurs travaillaient entièrement dans un environnement de développement, ils auraient peut-être publié les clés de leur environnement de développement sur github, mais c'est tout à fait Le fait que les versions de production aient été publiées montre à quel point l’idée de réaliser un développement sur l’environnement de production est médiocre.

Rappelez simplement à votre responsable que des erreurs sont commises. Par conséquent, pour éviter que le directeur de la technologie, qui est sur le point de craquer devant les journalistes et que le monde de la technologie se moque de lui, se moque bien, il suffit de prendre des mesures simples et évidentes pour éviter que ces erreurs ne deviennent catastrophiques. les uns.

Cela ressemble à de nombreux environnements différents et cela prend beaucoup de temps aux utilisateurs de mettre en place un "environnement".

Vous devriez avoir le moins de "environnements" différents que vous puissiez utiliser, mais vous pouvez également copier plusieurs copies pour autant de raisons que vous le souhaitez et le souhait de la société (utiliser "environnement" pour désigner la configuration du système)!

De manière optimale, les seules différences devraient être:

1. Taille (minimum, recommandé, le plus grand supporté / testé contre);
2. La mise en scène et la production ne disposent pas d'outils de développement
3. La production est protégée contre l'écrasement accidentel des données
4. Vous pouvez très facilement charger des données de clients de démonstration, de test ou [anonymes] sur des serveurs de développement ou de stockage intermédiaire.

ALORS, la question du nombre et du type de tests à effectuer est une évaluation commerciale risques / coûts, décidée au niveau de l’entreprise, car c’est l’entreprise dans son ensemble qui pâtira des conséquences si des fautes importantes parviennent à divers clients .

Plus tard, Edit: Cela m’a incité à rationaliser mes conventions de nommage avec mes produits Web (merci pour la question). J'ai choisi quatre "environnements", avec des tests répartis entre qa (un seul niveau minimal pour les fonctionnalités de test uniquement) et le transfert (même architecture que la production, pour les tests de charge / performance / volume).

La seule différence réelle dans le provisionnement réside dans l’installation en production / intermédiaire d’une base de données sur un système distinct, que je contrôle en fonction des groupes dans lesquels se trouvent les différents serveurs. Qa / dev possède à la fois les rôles de serveur Web et de base de données. L'équilibrage de la charge se fait par cloudflare.

J'ai également une variable ENV_NO, qui est transmise aux systèmes afin que je puisse choisir autant d'exemples "qa" ou "staging" que je le souhaite.

Donc, pour configurer un second environnement qa incluant ma dernière sauvegarde de live, 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 (facultatif) appelé "readonly" comme dernier filet de sécurité avant de toucher le sol. Il est configuré comme un système qa mais avec la sauvegarde et la mise à jour de la nuit dernière désactivée (le logiciel est également mis à jour à la nuit dernière).

Il utilise l'approche "Tous les oeufs dans un panier différent": il est configuré avec un emplacement / registre DNS différent, un hôte DNS, des fournisseurs de services d'hôte système. C'est le dernier / dernier filet de sécurité, donc si tout est en flammes, 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, de sorte que 99% est identique, juste pour l'indicateur readonly. L'équilibreur de charge Cloudflare redirigera le trafic vers le site en lecture seule si tous les serveurs actifs ont échoué.

Lorsqu'il s'agira de faire un changement, vous aurez de la chance d'avoir quelqu'un qui écoutera votre avis professionnel et mettra en œuvre les changements suggérés.

D'après mon expérience, chaque fois que je devais effectuer un changement majeur, je devais le justifier en termes d'économies que l'entreprise réalisera. Par exemple, l'introduction de ReSharper dans le pipeline de développement était assez facile, car j'ai pu dire quelque chose sur les lignes suivantes:

ReSharper coûte environ 50 £ par développeur. Le coût moyen par développeur est de 40 000 £ par an. ReSharper devrait augmenter la productivité des développeurs d'au moins 20%, étant donné qu'elle est pleinement utilisée. Supposons que les développeurs passent 75% de leur 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 avec l'entreprise, vous pouvez dire que vous pouvez engager quelqu'un d'autre et gagner 20% de productivité supplémentaire pour 6 000 £, ou vous pouvez obtenir le même résultat en dépensant 50 £ sur une licence ReSharper. Une fois que les chiffres sont en face de l'entreprise, la décision sera facile à prendre.

Maintenant, en ce qui concerne vos questions relatives à plusieurs environnements, tout ce que vous avez à faire est de trouver un moyen de calculer combien il en coûte à l’entreprise chaque année d’avoir maintenant ces environnements.

Vous pouvez demander à vos collègues développeurs de garder la trace des heures consacrées chaque semaine à la configuration d'applications de développement, de déploiement, etc. C'est 10 heures qui peuvent être consacrées au développement, ou quelque chose de beaucoup plus important. Vous rassemblez les chiffres pendant un certain temps et fournissez aux entreprises un coût annuel.

Personnellement, je déteste ce genre de politique, mais c'est courant et nous devons vivre avec.