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


51

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.


7
Ce n'est pas IBM VM / ESA de votre père! Retour à l'ordinateur central IBM.
Vitor Py

23
Pour moi, le seul obstacle qui se présenterait serait la prise en charge de plusieurs écrans. Je ne pouvais pas développer sur moins de 2 écrans.
Justin Shield

27
Il existe de nombreuses raisons exotiques: Parfois, une clé USB doit être connectée à un ordinateur physique à des fins de licence. Parfois, vous avez affaire à de vrais CD. Parfois, vous avez besoin de redémarrer le meunier. Parfois, vous devez mesurer les performances comme sur un ordinateur réel. Parfois, vous développez des pilotes. Parfois, vous avez besoin de toute la vitesse que vous pouvez obtenir. Parfois, vous devez faire une démonstration du produit quelque part sans accès à Internet. Parfois, vous devez vous connecter à un système à l'aide de la validation par empreinte digitale.
Job

47
Les IDE modernes nécessitent un matériel local dédié. Avant même de penser à faire cela, vous devriez avoir un banc d’essai et une étude pour voir si c’est viable. Vous pouvez apprendre une ou deux choses que vous ne saviez pas sur la façon dont les gens interagissent avec les machines. Si vous me dites que vous n'avez ni le temps ni l'argent pour effectuer une telle étude, je vous dirai que vous ne disposez pas d'une échelle suffisante pour justifier votre configuration.
Robert Harvey

4
N'oubliez pas que vous avez également besoin de machines physiques. Nos serveurs de test sont presque tous sur des ordinateurs virtuels répartis sur deux hôtes SAN. Mais nous rencontrons des problèmes pour lesquels nous voulons / devons vérifier que la virtualisation n’est pas un facteur, ni même le coupable. De plus, toutes les machines virtuelles ne prennent pas en charge la thématisation du verre. Si vous développez des interfaces graphiques, vous devez également vérifier votre interface graphique dans un environnement à thème de verre.
Marjan Venema

Réponses:


96

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 vois ce que vous dites, mais le serveur sera local (même salle) que les développeurs. La latence sera si ils travaillent à domicile et cette latence sera là, peu importe si c'est à partir d'une machine virtuelle ou si c'est la boîte du développeur. Le budget de développement inclut non seulement la création de machines virtuelles de développement, mais également des environnements de test. Je pensais que cette méthode était beaucoup plus évolutive que chacune ayant sa propre boîte, et plus facile à gérer. Merci pour la réponse cependant, cela m'a fait penser à autre chose :)
J_A_X

5
Cette approche peut en effet économiser un temps de maintenance. Mais probablement pas à une échelle de démarrage. Il faut 20 utilisateurs ou plus pour commencer à être financièrement intéressant.
SK-logic

6
Si vous placez le serveur dans une salle d’équipement, vous obtenez une séparation environnementale meilleure pour le serveur et les personnes. Le bruit de fond dans les bureaux est réduit et la chaleur peut être mieux gérée.
mattnz

1
@J_A_X: Cette latence n'existerait pas lorsque vous travaillez à domicile si les machines sont des ordinateurs portables. La latence du réseau sur le VPN serait certainement là, mais pas la latence des interactions avec la machine elle-même.
Adam Robinson

1
@J_A_X: la latence n'est pas là si tout l'environnement de développement est contenu dans l'ordinateur portable du développeur. Et il pourrait toujours y avoir une latence notable poussant les mises à jour d'écran dans la salle, lorsque l'interaction se produit à chaque frappe. Un retard de 50 millisecondes dans l'écho des personnages serait très pénible. Peut-être que tout se passerait bien, mais vaut-il vraiment la peine de le savoir?
kevin cline

58

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.


4
Je sais que ce n'était pas censé être pris au sérieux, mais je prendrais absolument un environnement virtuel décent sur certains "Pentium III que vous avez trouvés dans une benne à ordures quelque part"
Davy8

Non non Non. N'encouragez pas autant de variété parmi les machines de développement. Si vous avez besoin de développer pour du matériel, faites-le correctement, en utilisant un ensemble de zones de test représentant le matériel sur lequel vous avez besoin de votre logiciel. Vous n'encouragez jamais, jamais, jamais de déviations aléatoires de matériel sur vos machines de développement individuelles, c'est une des pires pratiques de développement logiciel .
dietbuddha

19

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.


Si le serveur est arrêté, vous perdrez tout. Sauf si vous répliquez ce serveur également ...
Rudy

4
@Rudy: Dans la plupart des magasins, si le serveur tombe en panne, vous ne pouvez pas vraiment travailler en local non plus (pas d'accès à la base de données pour les tests, pas de checkins, pas de sorties, pas d'accès au suivi des bogues, pas d'email, ...)
sleske

4
@sleske est d'accord avec DB, email et d'autres choses, mais avec DVCS, vous pouvez au moins enregistrer / branche / ...
mbx

La plupart des magasins, en particulier ceux qui envisagent d'utiliser des ordinateurs virtuels sur un rack pour héberger des environnements de développement, disposeraient de serveurs distincts pour la base de données, le courrier électronique, etc. De plus, même si certains de ces services cessaient, vous pouviez toujours accéder à votre bureau local et à tout ce que vous aviez à faire. travailler sur le moment.
Pete

@sleske - Existe-t-il aujourd'hui un moteur de base de données qui ne peut pas être exécuté sur le poste de travail d'un développeur?
kevin cline

18

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.


14

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.


1
+1 Faites vos devoirs! Le gars qui l’a fait dans ma dernière entreprise avait de l’expérience et cela s’est passé sans encombre. C’était le meilleur système que j’ai utilisé pour le développement, mais il a fallu une année-homme pour la concevoir et la mettre en œuvre.
Christopher Bibbs

12

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.


9

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.


J'utilise VMWare Workstation pour le développement sur trois moniteurs.
JC01

8

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.


5

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.


1
Avez-vous rencontré des problèmes dans d'autres ordinateurs virtuels lorsque vous avez commencé à compiler un projet volumineux ou avez-vous exécuté d'autres tâches gourmandes en ressources?
TheLQ

@TheLQ Pas de problème, mais le concepteur du système l'avait déjà fait. Le matériel a donc été sélectionné et réglé juste pour cette tâche. La dernière fois que je le lui ai demandé, il a dit que les processeurs étaient toujours principalement inactifs, mais les disques tournaient comme des fous.
Christopher Bibbs

Donc, un disque san partait avec 8 développeurs - que diriez-vous à environ 20? combien de san avons-nous besoin pour cette tâche?
Toskan

1
@Toskan Non, nous avions 20 développeurs et 8 processeurs sur le serveur. En ce qui concerne le nombre de disques, je pense que notre réseau SAN comptait 12 disques, mais je ne peux pas en être certain.
Christopher Bibbs

5

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.


7
C'est pourquoi vous avez un moteur de construction - l'intégration continue devrait capturer de telles dépendances. Cependant, les développeurs ont besoin de tous les outils qu’ils peuvent obtenir.

4
Oui, n'emporte pas mes jouets. Ils me rendent productif pour faire des choses. Construire pour le déploiement et tester dans un environnement cible sont des problèmes différents à résoudre.
Rapidement maintenant

Une option consiste à développer des scripts de configuration qui copieront vos alias, fichiers de configuration et autres fichiers de configuration. Par exemple, sur Linux, un alias est configuré pour extraire tout cela de Git.
Michael Durrant

4

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.


4

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.


4

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.


Je dois juste ajouter que vous avez besoin d'un processeur avec des tables de pages imbriquées (2.Gen Virtualization Support) pour obtenir de bonnes performances. L'utilisation de VM Ware avec des chemins d'accès partagés est assez lente lorsque vous ne disposez pas de disques SSD (cela prend plus de 20 secondes pour git addou git statussur le référentiel avec 7 000 fichiers)
mbx

3

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.


2

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.


Les développeurs peuvent-ils installer des logiciels sur ces comptes? Parfois, Eclipse n'est pas l'outil idéal.
kevin cline

@ kevin cline: Oui, l'installation sw était autorisée et possible. Cependant, les développeurs ne disposant pas de droits d'administrateur, vous ne pouvez installer que des logiciels nécessitant des droits d'administrateur pour être installés ou exécutés. Je pouvais installer tout ce dont j'avais besoin sans problèmes, mais j’entends dire qu’il existe encore des applications nécessitant des droits d’administrateur pour pouvoir être installées ou même pour être exécutées.
Sleske

@sleske Dans mon expérience, les développeurs devraient avoir des droits d'administrateur, virtuels ou non, sur leur machine de développement. À mon avis, un développeur doit s'approprier les outils qu'il utilise et la machine de développement n'est qu'un autre outil.
Manfred

@ John: Cela dépend vraiment des outils dont vous avez besoin. Si aucun de vos outils n'a besoin d'un accès administrateur, vous n'avez pas besoin d'un accès administrateur. Je ne vois pas pourquoi vous devriez toujours avoir besoin d'un accès administrateur. Bien sûr, si vous devez effectuer des tâches telles que l’installation de pilotes de périphériques ou l’exécution de tâches sur le port 80, vous devez disposer d’un accès administrateur.
Sleske

2

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.

1

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.


1

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.


1

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.


problème est les fenêtres 32 bits qui est installé sur les ordinateurs portables
Toskan

1

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.


RDP prend en charge le multi-moniteur dans la version la plus récente.
Andrew Lewis


Je pensais que nous parlions de VMs et non de RDP ici. . .
Wyatt Barnett

Désolé, je parlais de machines virtuelles distantes. Vous pouvez faire plusieurs moniteurs avec VMWare Workstation 7+
Andrew Lewis

Je pense que cela dépend de la taille du moniteur.
Manfred

0

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).


0

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.


0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.