Réflexions sur le développement à l'aide de machines virtuelles [fermé]

Je vais travailler en tant que responsable du développement pour une startup et j'ai suggéré d'utiliser des VM pour le développement. Je ne parle pas de chaque développeur ayant un ordinateur de bureau avec des machines virtuelles à des fins de test / développement, je veux dire un rack de serveur où toutes les machines virtuelles sont gérées et que les développeurs travaillent à partir d'un microPC (ChromeOS??) Localement, ou même à distance de leur domicile. ordinateur.

Pour moi, les avantages sont le fait qu’il est extrêmement évolutif, moins cher à long terme, plus facile à gérer et que nous utilisons le matériel de manière optimale. En ce qui concerne les inconvénients, je ne peux penser à aucun arrêt particulier, sinon nous aurons besoin de quelqu'un pour configurer / maintenir ladite configuration.

J'espérais que certains d'entre vous pourraient avoir une configuration similaire sur votre lieu de travail et être capable d'influencer vos opinions. Merci.

Qu'espérez-vous économiser en tant que fraction du budget de développement? Il me semble que vous vous inquiétez d'un epsilon. Le coût des machines pour les développeurs est inférieur à 5% du coût total pour garder un développeur dans son personnel. Par conséquent, la seule question importante est "est-ce que cela va faire gagner du temps aux développeurs?" Cela pourrait être le cas si elles ne perdaient pas de temps à installer et à mettre à niveau leurs logiciels de développement. Cela peut aussi prendre du temps, si le réseau tombe en panne, ou le serveur, ou très probablement, si la réactivité sur le réseau manque le moins du monde. Le développement moderne dépend de l'interaction frappe par frappe avec un IDE, ou du moins un éditeur très intelligent. Retarder cette interaction de quelques dizaines de millisecondes même réduit la productivité des développeurs. Les développeurs doivent également apprendre à utiliser cette nouvelle méthode de travail.

Ce ne sont pas des objections aux machines virtuelles, mais des objections potentielles au développement à distance.

Je pense que vous êtes sage-penny et stupide.

Tout d'abord, les coûts de la machine sont triviaux comparés au coût d'un développeur. Vous devez travailler à maximiser la productivité, pas à minimiser les coûts de la machine.

Deuxièmement, la latence (et non la bande passante) est la clé de nombreuses tâches de programmation, notamment l'édition de texte. Pour chaque dollar / livre / euro que vous économisez sur les machines de vos développeurs, vous dépenserez au moins dix sur les mises à niveau du réseau afin de maintenir un semblant de productivité - et même dans ce cas, elles seraient probablement plus productives si vous économisiez en fournissant les avec Pentium III que vous avez trouvé dans une benne à ordures quelque part.

Je pense également qu'il est très avantageux que vos développeurs utilisent un environnement au moins raisonnablement proche de celui attendu par l'utilisateur final cible. Quels que soient les objectifs de performance officiels définis dans une spécification, la plupart des programmeurs se basent un peu sur le "ressenti" du code lorsqu’il le teste. Lorsqu'ils utilisent un environnement complètement différent de celui de l'utilisateur final, ils risquent de perdre du temps sur des trivialités tout en négligeant complètement les problèmes majeurs.

Aussi attrayant qu'un environnement homogène puisse sembler d'un point de vue de support, vous devez généralement encourager autant que possible la variété des machines des développeurs. De toute façon, les développeurs ont rarement besoin de beaucoup d’assistance, et savoir immédiatement quand un code va échouer avec une puce graphique, un processeur, une carte réseau, etc., est plus qu’un simple investissement.

En bout de ligne: si vous écrivez du code destiné (au moins principalement) à être utilisé dans un environnement de serveur virtualisé, il vous suffit de le fournir à vos développeurs. Si vous le faites quand même pour des tests, cela peut (mais pas nécessairement) avoir un sens pour le développement également. De même, si vous avez besoin (ou du moins avez) un serveur et un réseau très sur spécifiés, il pourrait être judicieux de tirer parti de cela en utilisant ce que vous avez déjà disponible.

Dans la plupart des cas, cependant, il me semble que cela risque de créer plus de problèmes que de solutions.

C’était l’une de mes idées par le passé: disposer d’un serveur hautes performances doté de tous les logiciels requis et d’un ensemble de PC de bureau peu performants qui ne seraient utilisés que pour se connecter au serveur via Remote Desktop.

Les avantages seraient:

• La sauvegarde solide. Certains développeurs peuvent ne pas vouloir sauvegarder régulièrement leurs ordinateurs de bureau. Une solution centrale serait donc plus fiable.
• La possibilité, pour chaque développeur, de travailler de n'importe où. Par cela, je veux aussi dire travailler à partir de n’importe quel PC de la société. Disons que dans la matinée, le développeur souhaite des conditions de travail silencieuses. Il va dans sa propre chambre et y travaille. Ensuite, il souhaite faire de la programmation en binôme ou travailler dans un environnement plus social. Il éteint simplement son ordinateur de bureau, se rend dans une autre pièce où se trouvent dix ordinateurs et se connecte à partir de là. Non "Je dois recharger à nouveau toutes mes applications".

Eh bien, cela pose plusieurs problèmes graves, ce qui me fait penser que je n’utiliserai jamais ce genre de chose les années suivantes.

• Spécificité des solutions à distance. Qu'en est-il de travailler à distance en utilisant plusieurs écrans d'ordinateur à la fois? Je veux dire, est-ce facile? Est-ce évident? Les raccourcis que j'utilise quotidiennement sont-ils activés lorsque je travaille à distance? Je ne suis pas si sûr. Et si j'appuyais sur Ctrl + Maj + Échap pour voir la liste des programmes en cours d'exécution? Oh oui, ça ne marche pas, alors maintenant je dois me souvenir de l'avoir fait différemment.

• Performance frappé. Je ne suis pas sûr qu'il n'y aura aucune baisse de performance. Et rappelez-vous, un programmeur qui utilise un ordinateur lent est un programmeur malheureux. Et la société qui rend ses programmeurs mécontents de conditions déplorables ne produira jamais de logiciels de haute qualité.

• Impact accru d'une catastrophe. Allez-vous héberger la solution sur un serveur redondant? Avez-vous un réseau redondant dans votre entreprise? Disons que le routeur tombe en panne et n'est pas redondant. Cela signifie que tous les développeurs sont maintenant incapables de travailler. Du tout. Parce qu'ils n'ont pas de logiciel installé localement. Parce qu'ils n'ont même pas de code source: c'est sur le serveur. Donc, tout le monde s'arrête et vous payez toutes ces personnes à l'heure juste pour attendre que le routeur soit remplacé.

• Coûts de matériel. Si c'est un et un seul serveur, combien cela coûtera-t-il? Si vous avez, par exemple, vingt développeurs, 64 Go de RAM sur le serveur seraient-ils suffisants? Pas si sûr. Une solution quadricœur avec deux processeurs serait-elle suffisante? Encore une fois, j'ai des doutes. Sinon, à quoi pensez-vous? Une sorte de nuage? Ou avez-vous une solution évolutive qui fonctionne sur plusieurs serveurs? Êtes-vous prêt à payer le coût de Windows Server (si vous utilisez Windows) par ordinateur?

• Coût de l'électricité. Si vous travaillez complètement à distance, cela signifie que vous dépensez la même quantité d'énergie côté serveur que si vous travailliez localement, plus la quantité d'énergie perdue par la machine locale et le réseau.

• Licences Je ne sais pas si je dois le considérer comme un avantage ou un problème, mais j’ai l’impression que le coût des licences logicielles sera beaucoup plus élevé dans ce cas.

Et encore une fois, pensez à tous les coûts de gestion, de support, de déploiement, de maintenance. Avec une solution personnalisée comme celle-ci, elle peut facilement devenir énorme, sans compter que chaque fois que quelque chose échouera, vous verrez tous les développeurs se débrouiller seuls, attendant de pouvoir continuer son travail.

Nous utilisons des instances amazon ec2 à la demande en tant que machines de développement. Cela n'a rien à voir avec les coûts. Nous avons un "pool de développeurs" travaillant sur plusieurs projets et nous avons besoin de la capacité de passer rapidement d'un projet à l'autre.

En général, la VM enregistre le temps de configuration initiale. Mais à long terme, cela fait perdre du temps en raison de la perte de productivité. Le coût est un non-axe, car le coût de développement est beaucoup plus que le coût de la machine.

Les coûts de productivité comprennent: le temps nécessaire pour démarrer une image de machine virtuelle (plusieurs minutes), une réactivité médiocre et des contraintes de ressources / mémoire. Ce ne sont pas beaucoup au début, mais avec le temps, ils deviennent ennuyeux.

Sur l'un de nos projets, nous avons refactorisé le code afin de simplifier la configuration initiale afin de "télécharger le code et exécuter maven". Avec ce changement, il était simple pour un nouveau développeur de commencer à travailler sur le projet - et maintenant personne n’utilise l’image amazon VM. Nous cherchons à imiter cela sur d’autres projets également, mais cela prendra du temps. Jusque-là, nous avons nos images ec2.

Soyez très prudent ici. J'ai récemment été déployé auprès d'un client où tous les membres du service informatique avaient leur machine virtuelle essentiellement pour la même raison: leur permettre d'avoir des ordinateurs bas de gamme sur le bureau, puis de les installer à distance et d'effectuer leur travail normal.

L'expérience là-bas n'était pas jolie. Au moins une fois par semaine, nous courions extrêmement lentement pour diverses raisons. Généralement, nous pouvions savoir quand un membre de l'équipe exécutait un ensemble de packages SSIS gourmands en ressources processeur. Ils ont finalement déplacé certains d'entre nous sur différents serveurs, ce qui a aidé certains, mais les performances n'ont jamais été à la hauteur.

Je pense que si vous allez le faire - faites preuve de diligence raisonnable en ce qui concerne l'alimentation du serveur, vos besoins en traitement, le nombre de machines que vous allez desservir, etc. des maux de tête.

Remarque: ceci n’est PAS une flamme de l’architecture d’une machine virtuelle, mais un simple avertissement pour ceux qui s’intéressent à cette question. Assurez-vous d’avoir vos canards alignés avant la mise en œuvre.

Le développement sur des machines virtuelles peut très bien fonctionner, mais seulement si c'est bien fait:

• Le fait d’utiliser des ordinateurs virtuels vous permet d’avoir un seul ordinateur pour l’ensemble de votre équipe plutôt qu’un ordinateur par développeur ne signifie pas que c’est une bonne idée.
• Le redémarrage ne devrait pas nécessiter l'ouverture d'un ticket d'assistance avec un temps de réponse de 24 heures
• Les machines virtuelles de développement ne doivent pas se trouver dans un centre de données à une distance de 5000 km des développeurs.
• Bien que les VM puissent être gérées par les développeurs et donc non prises en charge, cela ne signifie pas qu’elles ne devraient pas être en mesure d’accéder aux services réseau tels que le contrôle de source.
• La connexion de bureau à distance doit être standard et non pas une applet personnalisée "haute sécurité" qui convertit les guillemets saisis en trémas.
• Obtenir une nouvelle machine virtuelle ou reconstruire une machine existante devrait prendre quelques minutes, pas plusieurs semaines

J'ai vu tous ces problèmes et je n'aime pas particulièrement travailler avec eux. Cependant, j'ai aussi une configuration de VM à la maison que j'utilise par choix. Cela s'exécute plus rapidement qu'une installation locale et permet des choses comme des environnements distincts pour différents projets et des reconstructions rapides lorsqu'un environnement devient instable.

Je travaille avec des machines virtuelles, mais je ne le recommande pas pour votre projet principal.

J'utilise des machines virtuelles pour le développement parce que je dois prendre en charge des projets hérités (par exemple, VB6, .NET 1.1, etc.) et que je ne veux pas salir ma machine principale en installant VS2003 / 2005 / vb6 / etc. ... Ça marche, mais il y a des problèmes intermittents ici et là.

De plus, l’interaction est plus lente, les machines virtuelles mettent un certain temps à démarrer / s’arrêter, n’ont pas d’effets d’interface utilisateur natifs (comme Aero dans Win7), etc.

Tout ce que vous allez économiser en termes d’argent sera gaspillé et plus encore par les tracas que vous allez imposer à votre équipe. De plus, comme quelqu'un l'a mentionné, pas de support multi-écrans. J'ai besoin d'au moins 3 écrans pour être aussi productif que possible.

La règle n ° 1 du développement est de garder vos développeurs heureux. Vous trouverez cela presque impossible à faire avec les ordinateurs virtuels distants. La prise en charge de plusieurs moniteurs est inégale, les retards et les problèmes de réseau sont gênants et les économies réalisées sont généralement minimes.

Travaillez sur des ordinateurs virtuels, bien sûr, mais autorisez également les ordinateurs virtuels locaux et faites de l'ordinateur physique une bête ridiculement rapide.

Je fais du télétravail à 100%, et entre mon FAI personnel et le VPN - malgré une fiabilité élevée -, ils ont suffisamment de signaux qui me rendraient dingue si je ne pouvais pas travailler en mode hors connexion.

En général, je ne fais que créer une variété d’images VirtualBox et travailler à partir d’elles. Copier quelques centaines de Mo sur le réseau n’est pas une perte de temps si vous en avez besoin d’un nouveau sur place.

Mon équipe a implémenté avec succès une configuration "serveur lent PC / Fast VM". Pour une équipe de 20 développeurs, nous avions un serveur RAM de 8 Go à 8 processeurs connecté via fibre à un réseau SAN très rapide. C'était cher, mais moins cher que de donner à chaque développeur un poste de travail avec des performances similaires. Pour une petite équipe (4 développeurs), je ne suis pas sûr que les économies d'échelle se concrétiseraient et vous épargneraient quoi que ce soit.

Les ordinateurs virtuels pour le développement valent la peine d’être examinés, mais le coût financier n’est pas la bonne raison.

Ceci a été brièvement décrit dans Expert .NET Delivery de Marc Holmes utilisant NAnt & CruiseControl.net - en résumé, l’argument en faveur du développement sur une machine virtuelle est qu’il décourage tout aspect du travail de devenir dépendant de la configuration particulière du développeur. Vous démarrez votre machine virtuelle au début de chaque projet et, à moins que vous n'ayez réellement besoin d'un outil en particulier, celui-ci ne perd pas de temps. Cela minimise la probabilité que les changements que vous apportez se répercutent sur la machine de quiconque, à l'exception de la vôtre. Les développeurs peuvent pleurer de voir leurs jouets leur être retirés - mais au final, la confiance dans les outils est une faiblesse et tout ce que vous ne pouvez pas faire intuitivement dans un environnement propre est une odeur.

Notez que je ne crois pas nécessairement aux arguments présentés ci-dessus. Je comprends et, dans une certaine mesure, je m'aligne sur eux, mais je les fais pour des arguments, pour générer une discussion.

Inconvénients potentiels

• Si l'hôte de la VM tombe en panne ... vous êtes tous blessés. Si vous avez déjà eu une équipe de 20 personnes, criez "GAH! HOST NE RÉPONDANT PAS !?" à l'unisson ... ce n'est pas amusant.
• Si vous permettez des instantanés ... ceux-ci consomment rapidement des ressources. 20 personnes * 10 à 20 instantanés représentent chacun beaucoup d’espace disque dur (ou au moins assez pour causer des problèmes).
• Si vous rencontrez des problèmes d'utilisation des ressources sur l'hôte, encore une fois, tout le monde ressent la douleur.

IME, c'est une bonne solution et ça marche, mais vous avez besoin de matériel décent sur l'hôte et quand de mauvaises choses arrivent, elles arrivent à tout le monde.

Cela échoue l'un des critères les plus importants du test de Joel.

Je m'assure que tous mes développeurs ont au moins un ordinateur portable ou de bureau i3 ou supérieur avec autant de RAM que possible.

8 Go est ce que je m'efforce.

Cela les rend plus productifs et ils peuvent en fait exécuter Virtual Box sur leurs ordinateurs locaux à des fins de développement et de test, plutôt que sur des serveurs coûteux. Ils peuvent prendre des clichés de leur boîte virtuelle pour installer des trucs déjantés et tester différents navigateurs et installateurs, et tout en quelques secondes pour revenir à une configuration correcte connue sans avoir besoin de contacter les services "informatiques".

Les développeurs ont besoin des machines les plus rapides de la société, avec le plus grand nombre d'autorisations de RAM et de racine sur leurs machines locales. Fin de l'histoire.

J'ai déjà travaillé sur des ordinateurs virtuels pour le développement, aussi bien des ordinateurs virtuels locaux (s'exécutant sur un PC local) que des ordinateurs distants. Les locaux étaient beaucoup plus agréables à travailler que les plus éloignés.

Les ordinateurs virtuels distants, auxquels nous nous connections par RDP, présentaient un léger décalage entre chaque frappe et chaque action. Il est possible de se développer dans de telles conditions pendant une courte période, mais jour après jour, cela est devenu très frustrant.

J'ai heureusement évolué sous une machine virtuelle locale sur VMWare, car je devais exécuter Flash Builder sur une machine Linux. J'en étais très content, à condition qu'il dispose de suffisamment de mémoire, il était tout à fait utilisable.

Nous le faisons pour nos machines distantes et cela fonctionne assez bien. La plupart du temps, nous travaillons rarement à domicile (normalement uniquement pour des réparations d'urgence ici et là). Nous utilisons donc des netbooks assez bas, distants de nos ordinateurs de bureau rapides au bureau. Ils sont certainement toujours plus lents (probablement limités par le réseau plus que tout autre chose), mais travaillent de temps en temps pour des tâches courtes. Cela ne serait vraiment pas acceptable pour un cheval de travail à temps plein, cependant, étant donné que la VM peut souvent causer un peu de retard qui, même avec le meilleur matériel, IMHO, est un peu distrayant.

Lors de mon dernier emploi, nous avons fait exactement cela:

Nous avons utilisé un serveur Windows Terminal Server, où chaque développeur avait un compte. Les développeurs disposaient toujours de PC normaux (car ils s'y trouvaient déjà), mais seuls le client RDP était exécuté.

Nous avons développé Java, donc le logiciel utilisé était un compilateur Java + IDE (principalement Eclipse), ainsi qu'un navigateur Web, des outils de requête de base de données, un client de contrôle de version et occasionnellement des logiciels de bureau (OpenOffice.org dans notre cas).

Nous n'avons rencontré aucun problème réel et la performance était plutôt correcte.

Le seul problème réel est que vous devez vraiment prendre soin de ne pas déranger les autres dans certaines situations, car vous partagez un système. Lorsque les opérations informatiques devaient effectuer des copies de fichiers volumineuses ou des sauvegardes sur le serveur, les performances se dégradaient pour tout le monde. Lorsque nous avons identifié et résolu ce problème (en effectuant une copie avec une priorité faible ou du jour au lendemain), tout a bien fonctionné.

La mise en garde est la suivante: évaluez les performances le plus rapidement possible et planifiez votre matériel et son utilisation en conséquence.

TL; DR: Je l'ai fait à plusieurs emplois et je le préfère maintenant.

Le coût est la mauvaise raison de se concentrer. Voici quelques meilleurs.

Les raisons

• Cohérence de la plateforme dans les différents environnements (développement, test et production).
  • Pourquoi: Il élimine complètement les vecteurs de défauts, défauts dus aux différences de plates-formes dans différents environnements.
• Permet aux modifications du système, telles que les mises à niveau, d’apparaître en premier dans les vms de développement, d’être vérifiées, d’être mises à l’essai, d’être vérifiées et d’être mises en production; le tout beaucoup plus facile avec le développement (et le test) vms.
  • Pourquoi: Contrôle. Je peux prendre des instantanés, revenir en arrière, identifier les deltas, effectuer la modification sur un serveur et propager un succès en dupliquant simplement la machine virtuelle, etc.
• Parfois, les systèmes contre lesquels vous développez ne sont disponibles que sur un réseau sécurisé. Sinon, le serveur sur lequel votre logiciel s'exécutera peut avoir un accès limité ou des caractéristiques de réseau différentes.
  • Pourquoi: La VM de développement peut être sur le VLAN qui a accès au système ou au service verrouillé. Si le serveur dev dispose du même accès limité que le serveur de test et de production, il n’est jamais question de coder accidentellement une exigence sur une caractéristique de réseau ou d’accès qui ne serait pas disponible.

Défis

Le défi numéro un est le développement à distance, surtout si vous devez passer par une passerelle ou un serveur de saut. Cela rend les choses difficiles, surtout si les développeurs ne sont pas bien formés (ils ont des connaissances en ingénierie système, en réseau, etc.).

Il existe de nombreuses variantes de développement à distance, mais elles se résument généralement à deux différences principales.

• Exécutez vos outils de développement dans l'environnement distant et utilisez des protocoles tels que les clients RDP, les clients X11 distants, etc.
• Exécutez vos outils de développement localement et utilisez des protocoles pour effectuer une synchronisation ou une exécution transparente sur le serveur distant, en utilisant souvent ssh comme couche de transport.

Outils

Il existe des outils qui aident au développement à distance, et des IDE qui le facilitent. Vous devrez étudier dans quelle mesure il est capable de développement à distance. Beaucoup ne sont pas sans exécuter sur le même serveur sur lequel le code est développé. Cependant, il existe d'autres outils.

• Secure Shell: Les configurations de développement à distance les plus réussies utilisent davantage ssh, à l'aide de connexions sans mot de passe (avec authentification par clé), de multihops transparents (permettant de résoudre le problème du serveur de saut) et d'autres options de configuration permettant d'améliorer le temps de réponse. Remarque: j'ai toujours eu des problèmes avec les implémentations SSH non OpenSSH.
• GNU Screen / TMUX: multiplexeurs de terminaux. Screen est leur grand-père et continue de bien fonctionner, mais je pense que la plupart des gens ont commencé à changer (ou même à démarrer) sur TMUX.
• Vim / Emacs : La vieille garde, mais les deux fonctionnent très bien pour le développement à distance de différentes manières. C'est Vim donc tout ce dont il a besoin est un shell, tandis qu'Emacs peut s'exécuter localement et utiliser TRAMP pour le développement à distance.

Sur un plan légèrement différent, avez-vous remis à vos gestionnaires / comptables un tableur mettant en évidence le coût d’utilisation de ces machines lentes? Faites-leur remarquer qu'une solution de VM (à moins que cela soit bien fait et que ce n'est pas facile) pourrait simplement mettre les développeurs et donc la société dans le même bateau.

Cela dépendra du pouvoir d’administration que vous avez sur l’installation de VMware. Si vous êtes placé dans un sous-pool de faible priorité, vous aurez des machines lentes en fonction de l’activité des autres sous-pools.

Le matériel est bon marché, les programmeurs sont chers.

Pourquoi voudriez-vous que vos programmeurs soient frustrés en leur donnant des machines à développement lent? Le coût de la mise à niveau du matériel est minime par rapport aux avantages en termes de performances.

Demandez de meilleures machines. À tout le moins, demandez 4 Go de RAM. L'ajout d'un autre comprimé de 2 Go sera gagné en moins d'une semaine.

Le manque d'assistance sur deux écrans a toujours été le principal problème. Je ne peux tout simplement pas imaginer faire un travail de développement important sur un seul écran.

Maintenant, ils font du rock pour les tests, les déploiements et les manipulations, alors je ne pense pas qu'ils devraient tomber de la pile non plus.

Si vous avez un ordinateur central avec 50 disques SSD dans RAID10 et que vous utilisez uniquement 3 ou 4 ordinateurs sur cet ordinateur central, cela peut fonctionner.

Autrement, elles sont lentes, vraiment lentes (bien que dans de rares cas, la capture instantanée puisse compenser cela).

Au bureau, j’ai un ordinateur de bureau auquel je peux me connecter à partir de mon ordinateur portable via un réseau privé virtuel (VPN) en utilisant le partage d’écran.

Il fonctionne pour les incidents d'assistance en dehors des heures de travail et les travaux occasionnels forcés à distance. Cela vaut certainement mieux que de maintenir un environnement entièrement configuré sur une deuxième machine ou de développer des tâches nécessitant une faible latence vers le centre de données via un réseau étendu.

Cependant, il est frustrant de travailler ainsi pendant de longues périodes. Je me suis parfois rendu au travail pour la deuxième partie de la journée, une fois que tout ce qui me retenait à la maison était écarté.

La latence et l'écran immobilier sont les deux tueurs pour moi.

Je ne pense pas que vous souhaitiez utiliser une solution de machine virtuelle distante. La connexion réseau constituera le goulot d'étranglement et, même sur une connexion rapide, cela peut suffire à créer de la frustration. Nous nous éloignons de cette technique pour utiliser des environnements de développement locaux.

Nous développons sur des iMac, ce qui est vraiment agréable, mais nos applications Web s'exécutent sur un environnement Linux en production. Le problème, c’est qu’éventuellement, nous risquons de rencontrer un problème qui ne se produit que sous Linux et qui pourrait être difficile à résoudre. C'est là que la puissance des machines virtuelles entre en jeu. Cependant, je n'aime même pas l'idée d'utiliser une machine virtuelle 100% du temps.

J'ai récemment appris l'existence de Vagrant (http://vagrantup.com/docs/getting-started/why.html) et de Chef pour avoir rendu le travail avec VirtualBox super facile. Vagrant vous permet de démarrer facilement une machine virtuelle lorsque vous en avez besoin et de la démolir lorsque vous n'en avez pas besoin. Donc, je pourrais faire tout mon développement en utilisant mon Mac. Ensuite, lorsque je suis prêt à tester mon code, je peux démarrer une machine virtuelle pour le tester et le conserver aussi longtemps que j'en ai besoin. Vagrant vous permet également de partager facilement des ordinateurs virtuels avec vos collègues afin que vous puissiez tous être sûrs de travailler dans le même environnement.

Je vous recommanderais de vérifier Vagrant afin d’être au moins au courant des options disponibles pour le développement et le travail avec des machines virtuelles.

J'ai travaillé sur un projet hérité concernant 5 machines, chacune jouant un rôle dans un pipeline de calcul (la machine 1 envoie une requête à la machine 2, qui à son tour enverra une requête à la machine 3, etc.). Le déploiement des paramètres sur la machine virtuelle nous a toutefois fait gagner énormément de temps: 1. Le système était indubitable, car les développeurs étaient paresseux / n’avaient pas le temps d’incorporer les tests dans la conception. 2. Trop de configurations ont été déployées et je devais perdre du temps à les organiser en groupes.

Maintenant, je l'utilise parce que je travaille sur trop de projets à la fois. Les principaux problèmes que j'ai maintenant sont les suivants: 1. Les ordinateurs virtuels prennent trop de temps à entretenir. 2. Les VM consomment d’énormes quantités de mémoire pour fonctionner

Cela rend un peu les machines virtuelles difficiles à utiliser lorsque vous essayez de les utiliser pour avoir de l'ordre. Gardez une machine principale avec votre email et votre texte, développez sur des VM dédiées. Garde votre vie propre et propre à un coût.

Comme d'autres l'ont indiqué, cela dépend vraiment du problème que vous essayez de résoudre avec les ordinateurs de bureau VM, puis vous comparez les avantages de la résolution de ce problème aux inconvénients de l'environnement de la machine virtuelle.

Nous nous dirigeons vers un environnement hybride où tous nos développeurs onshore disposeront de machines physiques traditionnelles, mais les développeurs offshore (qui travaillent actuellement avec une petite entreprise de sous-traitance) utiliseront des ordinateurs de bureau virtuels. Les problèmes que nous essayons de résoudre avec les postes de travail distants sont liés à la sécurité et aux performances. L’environnement virtuel nous fournira évidemment un plus grand contrôle du point de vue de la sécurité. Pour des performances optimales, nous ne transférerons que les "pixels modifiés" plutôt que le code source complet et nous devrons mettre en œuvre des serveurs proxy, etc.

Vous ne savez toujours pas si c'est la bonne façon de faire, mais c'est la direction que nous prenons.