Réflexions sur le développement à l'aide de machines virtuelles
Je travaillerai en tant que responsable du développement pour une startup et j'ai suggéré d'utiliser des machines virtuelles pour le développement. Je ne parle pas de chaque développeur ayant un bureau avec des machines virtuelles pour les tests/développement, je veux dire avoir un rack de serveur où toutes les machines virtuelles sont gérées et faire travailler les développeurs à partir d'un microPC (ChromeOS n'importe qui?) Localement, ou même à distance depuis 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 au maximum de son potentiel. Quant aux inconvénients, je ne peux penser à aucun showstoppers particulier autre que 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 en mesure de prendre en compte 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 au sein du personnel. Par conséquent, la seule question importante est "cela fera-t-il gagner du temps aux développeurs?" Cela pourrait, s'ils n'ont pas à passer du temps à installer et à mettre à niveau un logiciel de développement. Ou cela pourrait coûter du temps, si le réseau tombe en panne, ou le serveur tombe en panne, ou, très probablement, si la réactivité à travers le net est le moins manquante. Le développement moderne dépend de l'interaction touche par touche avec un IDE, ou au moins un éditeur très intelligent. Retarder cette interaction de quelques dizaines de millisecondes seulement détruit la productivité du développeur. Il y a aussi le coût pour les développeurs d'apprendre cette nouvelle façon de travailler. Si cela ne prend qu'un jour par développeur, vous avez déjà dépensé plus en main-d'œuvre que le coût d'un nouveau bureau.
Ce ne sont pas des objections aux VM, mais des objections potentielles au développement à distance.
Je pense que vous êtes sage et insensé.
Tout d'abord, les coûts des machines sont triviaux par rapport au coût d'un développeur. Vous devez travailler à maximiser la productivité, pas à minimiser le coût de la machine.
Deuxièmement, la latence (pas la bande passante) est la clé de nombreuses tâches de programmation - en particulier l'édition de texte. Pour chaque dollar/livre/euro que vous économisez sur les machines pour vos développeurs, vous dépenserez au moins dix pour les mises à niveau du réseau pour maintenir même un semblant de productivité - et même alors, ils seraient probablement plus productifs si vous économisiez en fournissant les avec Pentium III que vous avez trouvé dans une benne à ordures quelque part.
Je pense également qu'il y a un avantage substantiel à ce que vos développeurs utilisent un environnement au moins raisonnablement proche de celui attendu de l'utilisateur final cible. Indépendamment des objectifs de performance officiels dans une spécification et autres, la plupart des programmeurs se basent un peu sur la façon dont le code "se sent" lorsqu'ils le testent. Lorsqu'ils utilisent un environnement complètement différent de celui de l'utilisateur final, ils perdront probablement du temps sur des trivialités tout en ignorant complètement les problèmes majeurs.
Aussi attrayant que puisse paraître un environnement homogène du point de vue du support, vous devriez généralement encourager autant de variété dans les machines des développeurs que possible. Les développeurs ont rarement besoin de beaucoup de support de toute façon, et sachant immédiatement quand vous avez du code qui va échouer avec une puce graphique, un processeur, une carte réseau, etc. différents, plus que de rembourser l'investissement minimal.
Bottom line: si vous écrivez du code qui est destiné (au moins principalement) à être tilisé dans un environnement de serveur virtualisé, vous avez juste besoin de fournir cela à vos développeurs. Si vous le faites de toute façon pour les tests, cela peut (mais pas nécessairement) a également un sens pour le développement. De même, si vous avez besoin (ou du moins avez) un serveur et un réseau extrêmement sur-spécifiés de toute façon, il pourrait avoir un sens d'en tirer parti en utilisant ce que vous avez déjà disponible.
Dans la plupart des circonstances, cependant, il me semble que cela est susceptible de créer plus de problèmes qu'il n'en résout.
C'était une de mes idées dans le passé: avoir un serveur haute performance qui possède tous les logiciels requis, et un tas de PC de bureau basse performance 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, donc une solution centrale serait plus fiable,
- La possibilité, pour chaque développeur, de travailler de n'importe où. J'entends par là également travailler à partir de n'importe quel PC de l'entreprise. Disons que le matin, le développeur veut des conditions de travail silencieuses. Il va dans sa propre chambre et y travaille. Ensuite, il veut faire de la programmation en binôme ou travailler dans un environnement plus social. Il arrête simplement son ordinateur de bureau, se rend dans une autre pièce où il y a dix ordinateurs et se connecte à partir de là. Non "Je dois recharger toutes mes applications à nouveau".
Eh bien, il y a plusieurs problèmes sérieux avec cela, ce qui me fait penser que je n'utiliserai jamais ce truc comme ça les prochaines années.
Spécificité des solutions distantes. Que diriez-vous 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. Que faire si j'appuie sur Ctrl + Maj + Echap pour voir la liste des programmes en cours d'exécution? Oh oui, cela ne fonctionne pas, alors maintenant je dois me souvenir de l'avoir fait d'une manière différente.
Coup de performance. Je ne suis pas sûr qu'il n'y aura aucune baisse de performances. Et rappelez-vous, un programmeur qui utilise un ordinateur lent est un programmeur malheureux. Et l'entreprise qui rend ses programmeurs mécontents des conditions de merde ne produira jamais de logiciels de haute qualité.
Impact plus élevé 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 désormais 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 le remplacement du routeur.
Coûts du matériel. S'il s'agit d'un seul et unique serveur, combien cela coûtera-t-il? Si vous avez, disons, vingt développeurs, 64 Go de RAM sur le serveur suffiront-ils? Pas si sûr. Une solution quadricœur avec deux CPU serait-elle suffisante? Encore une fois, j'en ai doutes. Sinon, qu'en pensez-vous? Une sorte de cloud? 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 machine?
Coût de l'électricité. Si vous travaillez complètement à distance, cela signifie que vous dépensez presque la même quantité d'énergie côté serveur que si vous travailliez localement, plus la quantité d'énergie gaspillée par la machine locale et le réseau.
Licences. Je ne sais pas si je dois en faire un avantage ou un problème, mais je pense que le coût de la licence logicielle dans ce cas sera beaucoup plus élevé.
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 chaque développeur NOPing autour, attendant de pouvoir continuer son travail.
Nous utilisons des instances Amazon ec2 à la demande comme machines de développement. Cela n'a rien à voir avec le coût. Nous avons un "pool de développeurs" travaillant sur plusieurs projets, et nous avons besoin de pouvoir nous déplacer rapidement d'un projet à l'autre.
En général, le VM économise le temps de configuration initiale. Mais à plus long terme, il perd du temps en raison de la perte de productivité. Le coût est un non-axe, car le coût du développeur est bien plus que le coût de la machine.
Les coûts de productivité incluent - le temps nécessaire pour démarrer une image VM (plusieurs minutes), une faible réactivité et des contraintes de ressources/mémoire. Ce ne sont pas beaucoup au départ, mais avec le temps, elles deviennent ennuyeuses.
Sur l'un de nos projets, nous avons refactorisé le code pour simplifier la configuration initiale pour "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 à émuler cela sur d'autres projets également, mais ça va prendre du temps. Jusque-là, nous avons nos images ec2.
Soyez très prudent ici. J'ai récemment été déployée chez un client où tous les membres du service informatique avaient leur VM essentiellement pour la même raison - pour leur permettre d'avoir des PC bas de gamme sur le bureau, puis de se connecter à distance au VM et font leur travail normal.
L'expérience là-bas n'était pas jolie. Au moins une fois par semaine, nous étions extrêmement lents pour diverses raisons. En règle générale, nous pouvions savoir quand un membre de l'équipe exécutait un ensemble de packages SSIS gourmands en processeur. Ils ont finalement déplacé quelques-uns d'entre nous vers différents serveurs, ce qui a aidé certains, mais les performances n'ont jamais été bonnes.
Je pense que si vous allez le faire - faites votre diligence raisonnable en ce qui concerne l'alimentation du serveur, vos besoins de traitement, le nombre de machines que vous allez servir, etc. Cela pourrait vous faire économiser de l'argent, mais s'il n'est pas mis en œuvre correctement, cela peut causer beaucoup des maux de tête.
Veuillez noter: ce n'est PAS une flamme de l'architecture VM - juste un avertissement pour les gens qui la regardent - assurez-vous d'avoir vos canards dans une rangée avant la mise en œuvre.
Le développement sur des machines virtuelles peut très bien fonctionner, mais seulement s'il est bien fait:
- Ce n'est pas parce que l'utilisation de machines virtuelles vous permet d'avoir un seul ordinateur pour toute votre équipe plutôt qu'un par développeur 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 VM de développement ne doivent pas se trouver dans un datacenter à 5000 miles des développeurs.
- Bien que les machines virtuelles puissent être gérées par des 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 au bureau à distance doit être standard, pas une applet "haute sécurité" personnalisée qui convertit toutes les citations tapées en trémas.
- Obtenir un nouveau VM ou reconstruire un existant devrait prendre des minutes, pas des semaines
J'ai vu tous ces problèmes et je n'aime pas particulièrement travailler avec eux. Cependant, j'ai également une configuration VM à la maison que j'utilise par choix. Cela fonctionne plus rapidement qu'une installation locale et permet des choses comme des environnements séparés 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.
La raison pour laquelle j'utilise des machines virtuelles pour le développement est parce que je dois prendre en charge les projets hérités (par exemple VB6, .NET 1.1, etc ...) et que je ne veux pas salir ma machine principale en devant installer VS2003/2005/vb6/etc ... Cela fonctionne bien, mais il y a des problèmes intermittents ici et là.
De plus, l'interaction est plus lente, les VM prennent un certain temps pour démarrer/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 que vous gaspillerez et plus encore par les tracas que vous êtes sur le point d'imposer à votre équipe. De plus, comme quelqu'un l'a mentionné ici, pas de support multi-écrans. J'ai besoin d'au moins 3 écrans pour être aussi productif que possible.
La règle de développement n ° 1 est de garder vos développeurs heureux. Vous constaterez que cela est presque impossible à faire avec des machines virtuelles distantes. La prise en charge de plusieurs moniteurs est inégale, les retards et les défauts de réseau sont gênants et les économies de coûts sont généralement minimes.
Travaillez sur des machines virtuelles, bien sûr, mais autorisez également les machines virtuelles locales et faites de l'ordinateur physique une bête ridiculement rapide aussi.
Je fais du télétravail à 100%, et entre mon FAI personnel et le VPN - malgré une grande fiabilité - ils ont suffisamment de blips qui me rendraient fou si je ne pouvais pas travailler en mode hors ligne.
Je tourne généralement une variété d'images VirtualBox et je travaille à partir de celles-ci. Copier quelques centaines de Mo sur le câble n'est pas trop long si vous en avez besoin d'un local non plus.
Mon équipe a réussi à mettre en œuvre une configuration "PC lent/Rapide VM"). Pour une équipe de 20 développeurs, nous avions un processeur 8, 256 Go RAM connecté via la fibre vers un SAN très rapide. C'était cher, mais moins cher que de donner à chaque développeur une station de travail aux performances similaires. Pour une petite équipe (4 développeurs), je ne suis pas sûr que les économies d'échelle interviendraient et vous feraient réellement économiser quoi que ce soit.
Les machines virtuelles pour le développement méritent d'être examinées, mais le coût financier est la raison erronée.
Cela a été brièvement abordé dans la livraison Expert .NET de Marc Holmes en utilisant NAnt & CruiseControl.net - en bref l'argument pour développer sur un VM est qu'il décourage tout aspect du travail de devenir dépendant de la configuration particulière du développeur. Vous nuke votre VM au début de chaque projet, et sauf si vous avez réellement besoin d'un particulier outil, il ne continue pas de tourner. Cela minimise la probabilité que les modifications que vous apportez ne se brisent sur la machine de quiconque, sauf la vôtre. ne 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 les comprends et, dans une certaine mesure, je m'aligne avec eux, mais je les fais à des fins d'argumentation, pour susciter la discussion.
Inconvénients potentiels
- Si l'hôte VM tombe en panne ... vous êtes tous arrosé. Si vous avez déjà eu une équipe de 20 personnes criez "GAH! L'hôte ne répond pas! ? "à l'unisson ... ce n'est pas amusant.
- Si vous autorisez les instantanés ... ceux-ci consomment rapidement des ressources. 20 personnes * 10 à 20 instantanés chacun font beaucoup d'espace sur le disque dur (ou au moins assez pour causer des problèmes).
- Si vous rencontrez des problèmes avec l'utilisation des ressources sur l'hôte, encore une fois, tout le monde éprouve la douleur.
IME, c'est une bonne solution et cela fonctionne, mais vous avez besoin d'un matériel décent sur l'hôte et quand de mauvaises choses se produisent, elles arrivent à tout le monde.
Cela échoue l'un des critères les plus importants du test Joel.
Je m'assure que tous mes développeurs ont au moins un ordinateur portable ou de bureau i3 ou supérieur avec autant RAM qu'il peut en contenir).
8 Go est ce que je recherche.
Cela les rend plus productifs et ils peuvent réellement exécuter Virtual Box sur leurs machines locales pour le développement et les tests, plutôt que sur des serveurs coûteux à entretenir. Ils peuvent instantaner leur Virtual Box installer des trucs fous et tester différents navigateurs et installateurs et tout et en quelques secondes revenir à une bonne configuration connue sans avoir besoin de contacter les services "IT".
Les développeurs ont besoin des machines les plus rapides de l'entreprise, avec le plus RAM et les autorisations root sur leurs machines locales. Fin de l'histoire.
J'ai déjà travaillé sur des machines virtuelles pour le développement, à la fois des machines virtuelles locales (fonctionnant sur le PC local) et des machines distantes. Les locaux étaient beaucoup plus agréables à travailler que ceux distants.
Les machines virtuelles distantes, auxquelles nous nous connections par RDP, avaient un petit 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 au jour le jour, c'est devenu très frustrant.
J'ai heureusement développé sous un local VM sur VMWare parce que j'avais besoin d'exécuter Flash Builder sur une machine Linux, et j'en étais très content tant qu'il avait suffisamment de mémoire - c'était assez utilisable.
Nous le faisons pour nos machines distantes et cela fonctionne assez bien. Le plus rarement, vous travaillez à domicile (normalement uniquement pour un correctif d'urgence ici et là), nous utilisons donc des netbooks assez bas de gamme, distants dans nos machines de bureau rapides au bureau. Ils sont certainement encore plus lents (probablement limités par le réseau plus que tout), mais travaillent de temps en temps pour de courtes tâches. Cependant, cela ne serait vraiment pas acceptable pour un cheval de trait à temps plein, car VM peut souvent causer un peu de retard qui, même avec le meilleur matériel, à mon humble avis, est un peu gênant.
Lors de mon dernier emploi, nous avons fait exactement cela:
Nous avons utilisé un Windows Terminal Server, où chaque développeur avait un compte. Les développeurs avaient toujours des PC réguliers (car ils étaient déjà là), mais les PC ne faisaient fonctionner que le client RDP.
Nous avons fait Java développement, donc le logiciel utilisé où Java compilateur + IDE (principalement Eclipse), plus un navigateur Web, Outils de requête de base de données, client de contrôle de version et parfois sw de bureau (OpenOffice.org dans notre cas).
Nous n'avons rencontré aucun problème réel et les performances étaient assez correctes.
Le seul vrai problème était que vous devez vraiment prendre soin de ne pas perturber les autres dans certaines situations, car vous partagez un seul système. Lorsque les opérations informatiques devaient effectuer des copies de fichiers volumineux ou exécuter 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 copiant avec une faible priorité ou du jour au lendemain), tout fonctionnait bien.
La mise en garde est donc la suivante: évaluer les performances dès que possible et planifier votre matériel et son utilisation en conséquence.
TL; DR: Je l'ai fait pour plusieurs tâches et je le préfère maintenant.
Le coût est la mauvaise raison de se concentrer. En voici de meilleurs.
Raisons
- Cohérence de la plateforme dans les différents environnements (développement, test et production).
- Pourquoi: Il élimine complètement un vecteur de défaut, les défauts des différences de plate-forme dans différents environnements.
- Permet aux modifications du système, telles que les mises à niveau, de se produire en premier dans les vms de développement, d'être vérifiées, de passer au test, d'être vérifiées et de passer en production; beaucoup plus facile avec le développement (et le test) vms.
- Pourquoi: contrôler. Je peux instantané, restaurer, identifier les deltas, faire le changement sur un serveur et propager un succès en dupliquant simplement le vm, etc.
- Parfois, les systèmes contre lesquels vous développez ne sont disponibles que sur un réseau sécurisé. Alternativement, le serveur sur lequel votre logiciel fonctionnera peut avoir un accès limité ou des caractéristiques de réseau différentes.
- Pourquoi: Le développement VM peut être sur le VLAN qui a accès au système ou service verrouillé. Alternativement si le serveur de développement a le 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 réseau ou un accès qui ne sera 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 équilibrés (ils ont des connaissances en ingénierie système, des connaissances en réseau, etc.).
Il existe de nombreuses variantes du développement à distance, mais elles se résument généralement à 2 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 synchroniser ou exécuter de manière transparente sur le serveur distant, en utilisant souvent ssh comme couche de transport.
Outils
Il existe des outils qui aideront au développement à distance, et il y a des IDE qui le facilitent. Vous devrez déterminer dans quelle mesure il est capable de développement à distance, beaucoup ne sont pas sans s'exécuter sur le même serveur sur lequel le code est développé. Cependant, il existe d'autres outils.
- Secure Shell: La plupart des configurations de développement à distance réussies utilisent ssh dans une plus grande mesure, en utilisant des connexions sans mot de passe (à l'aide de l'authentification par clé), des magasins multiples transparents (résout le problème du serveur de saut) et d'autres options de configuration pour améliorer le temps de réponse. Remarque: J'ai toujours eu des problèmes avec les implémentations non OpenSSH de SSH.
- Écran GNU/TMUX: Multiplexeurs de terminaux. L'écran est leur grand-père et fonctionne toujours bien, mais je pense que la plupart des gens ont commencé à basculer (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 fonctionner localement et utiliser TRAMP pour le développement à distance.
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 dérisoire par rapport aux avantages en termes de performances qu'ils en retireront.
Demandez de meilleures machines. Demandez au moins 4 Go de RAM. L'ajout d'une autre tablette de 2 Go sera gagné en moins d'une semaine.
Sur une approche légèrement différente - avez-vous donné à vos gestionnaires/comptables une feuille de calcul soulignant le coût d'utilisation de ces machines lentes? Faites-leur remarquer qu'une solution VM (sauf si elle est bien faite, et ce n'est pas facile) pourrait simplement mettre les développeurs et donc l'entreprise dans le même bateau.
Le manque de prise en charge du double écran a toujours été le tueur. 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/le déploiement/le violon, donc je ne pense pas qu'ils devraient tomber de la pile non plus.
Cela dépendra de la puissance adminsitrative 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.
Comme indiqué par d'autres, cela dépend vraiment du problème que vous essayez de résoudre avec les ordinateurs de bureau VM, puis en pesant les avantages de la résolution de ce problème par rapport aux inconvénients de la VM l'environnement encourra.
Nous évoluons vers un environnement hybride où tous nos développeurs onshore disposeront de machines physiques traditionnelles mais les développeurs offshore (travaillant actuellement avec une petite société d'externalisation) utiliseront des bureaux virtuels. Les problèmes que nous essayons de résoudre avec les bureaux distants sont liés à la sécurité et aux performances. L'environnement virtuel nous fournira évidemment un meilleur contrôle du point de vue de la sécurité et pour les performances, nous ne transférerons que les "pixels modifiés" plutôt que le code source complet et nous devrons implémenter des serveurs proxy et autres.
Je ne sais toujours pas si c'est la bonne voie à suivre, mais c'est là que nous nous dirigeons.
Je ne pense pas que vous souhaitiez opter pour une solution à distance VM. La connexion réseau sera le goulot d'étranglement et même sur une connexion rapide, cela peut suffire à provoquer de la frustration. Nous nous éloignons de cette technique à l'utilisation d'environnements de développement local.
Nous développons sur iMacs, ce qui est vraiment sympa, mais nos applications web tournent sur un environnement Linux en production. Le problème avec cela est que finalement, nous pouvons rencontrer un problème qui ne se produit que sous Linux et peut ê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 un VM 100% du temps.
J'ai récemment découvert Vagrant (http://vagrantup.com/docs/getting-started/why.html) et Chef pour avoir rendu le travail avec VirtualBox super facile. Vagrant vous donne la possibilité de démarrer facilement un VM quand vous en avez besoin, et de détruire un VM quand vous ne le faites pas. Donc je pourrais faire tout mon développement en utilisant mon Mac. Ensuite, quand je suis prêt à tester mon code, je peux démarrer un VM pour le tester et le garder uniquement aussi longtemps que j'en ai besoin. Vagrant vous donne également la possibilité de partager facilement des machines virtuelles avec vos collègues afin que vous puissiez tous être sûrs que vous travaillez dans le même environnement.
Je recommanderais de vérifier Vagrant afin que vous soyez au moins au courant des options disponibles lorsqu'il s'agit de développer et de travailler avec des machines virtuelles.
Si vous avez un ordinateur central avec 50 disques SSD en RAID10, et que vous n'utilisez que 3-4 machines sur cet ordinateur principal, cela peut fonctionner.
Sinon, ils sont décalés, vraiment décalés (bien que dans de rares cas, les instantanés puissent compenser cela).
J'ai travaillé sur un projet hérité concernant 5 machines, chacune a un rôle dans un pipeline de calcul (la machine 1 envoie la demande à la machine 2, qui à son tour enverra la demande à la machine 3, etc.). Cependant, le déploiement des paramètres sur la machine virtuelle nous a fait gagner énormément de temps: 1. Le système était incontestable 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 prendre du temps pour les organiser en groupes.
Maintenant, je l'utilise parce que je travaille sur trop de projets à la fois. Le principal problème que j'ai maintenant est le suivant: 1. Les machines virtuelles prennent beaucoup trop de temps à entretenir. 2. Les machines virtuelles consomment d'énormes quantités de mémoire pour fonctionner
Cela rend les machines virtuelles difficiles à utiliser lorsque vous essayez de les utiliser pour avoir de l'ordre. Gardez une machine principale avec votre e-mail et votre texte, développez sur des machines virtuelles dédiées. Garde votre vie propre et propre à un prix.
J'ai une machine de bureau décente au bureau à laquelle je peux me connecter depuis mon ordinateur portable via VPN en utilisant le partage d'écran.
Il fonctionne pour les incidents de support en dehors des heures d'ouverture et le travail à distance forcé occasionnel. C'est certainement mieux que de maintenir un environnement entièrement configuré sur une deuxième machine, ou de développer des choses qui nécessitent une faible latence vers le centre de données sur un WAN.
Cependant, il est frustrant de travailler de cette façon pendant de longues périodes. Je me suis parfois rendu au travail pour la deuxième moitié de la journée une fois que tout ce qui m'a gardé à la maison a été écarté.
La latence et l'immobilier d'écran sont les deux tueurs pour moi.