Une machine de développement doit-elle être dans une VM? [fermé]

Ce message de Rob Conery (notez le slug) indique que l'environnement de développement doit être exécuté à l'intérieur d'une machine virtuelle. Je vois ce qu'il dit et j'ai tendance à être d'accord, mais je me sens toujours un peu mal à l'aise. Maintenant que la virtualisation est si mature que même les systèmes de production fonctionnent dans les ordinateurs virtuels, la vitesse est quasiment un problème, mais comme je le dis, quelque chose me dérange ici.

Quelle est votre vision de la virtualisation de votre machine de développement? L'avez-vous déjà fait? Si c'est le cas, des pièges ou des pièges sur la route?

Mon expérience du développement sur des machines virtuelles dans un environnement d'entreprise est la suivante: en raison de la difficulté de la virtualisation de plusieurs cœurs, il est difficile d'obtenir le type de performances dont de nombreuses machines de développement d'entreprise ont besoin.

Pour que la boucle interne code-compilation-test soit aussi rapide que possible, il faut disposer des meilleures machines possibles - la compilation et l'exécution des tests s'exécutent évidemment plus rapidement sur les machines dotées de plus de cœurs, car ces activités peuvent facilement être exécutées de manière concurrente * .

Tant que les systèmes d’exploitation traditionnels ne seront pas en mesure de gérer le nombre de cœurs disponibles, et jusqu’à ce que les logiciels de virtualisation puissent proposer intelligemment un type de contrat «jusqu’à N cœur», les machines de développement virtualisées n’offriront pas le même type de gains de productivité que les périphériques physiques.

EDIT: Ceci ne fait que rappeler mes sentiments personnels sur le développement à l’aide de machines virtuelles dictées par les entreprises, qui sont souvent interdites pour réduire les coûts de matériel, qui ont tendance à fonctionner sur des serveurs. L'exécution d'une machine virtuelle locale semble généralement superflue si vous appliquez une discipline stricte en matière de contrôle des sources, à moins que votre projet ne vous oblige spécifiquement à développer du code pour plusieurs systèmes d'exploitation.

*: j'entends par là que les tâches secondaires à l'intérieur des étapes de compilation et des étapes de test peuvent être exécutées simultanément, PAS pour la compilation et le test simultanés :)

Je fais tout mon développement personnel dans les VM. J'ai plusieurs configurations de machines virtuelles pour différents environnements et cela fonctionne bien.

J'ai un ordinateur portable Dell Studio 15 (quad I7 2.8ghz, 8 Go de RAM, ati graphics) en cours d'exécution gagner 7 ultime 64 bits avec virtualbox installé sur. Toutes mes machines virtuelles sont connectées à un lecteur USB externe de 500 Go velcroed à l'ordinateur portable.

VM 0 - Installation propre Win 7 64 bits en tant que modèle de base

VM 1 - Win 7 64 bits (2 cpu, 4 Go de RAM, 120 Go de disque dur) avec les outils Visual Studio 2008

VM 2 - Win 7 64 bits (2 cpu, 4 Go de RAM, 120 Go de disque dur) avec les outils Visual Studio 2010

VM 3 - Win 7 64 bits (2 cpu, 2 Go de RAM, 120 Go de disque dur) avec les outils Java Eclipse

À moins que je ne fasse quelque chose qui nécessite des entrées-sorties très élevées, j'ai pensé que les performances étaient bonnes et que je ne saurais pas si je suis dans une machine virtuelle si quelqu'un venait de me remettre l'ordinateur portable et de commencer à développer.

J'aimerais ajouter que certains types de développement sont beaucoup plus difficiles (voire impossibles) par le biais de machines virtualisées.

Il se trouve que je travaille dans une entreprise où nous proposons des progiciels s’intégrant avec différents périphériques USB (par exemple, des webcams, des imprimantes d’étiquettes, des lecteurs de pistes magnétiques, etc.). Même si je mappais les ports USB sur un serveur virtualisé, j'ai constaté des problèmes bizarres et inexplicables avec les pilotes de périphérique d'un fournisseur tiers.

Comme je l'ai dit, je ne pense pas que cette situation justifie de NE PAS travailler sur des machines de développement virtualisées, mais c'est une machine que nous n'avons pas encore comprise. Nous maintenons donc des postes de travail physiques pour différents environnements dans un laboratoire.

Dans notre entreprise, nous utilisons maintenant la machine virtuelle pour le développement et les tests. Bien que l’utilisation des ordinateurs virtuels présente certains inconvénients, leurs avantages l’emportent largement.

Avant de commencer à utiliser des machines virtuelles, nous avions des problèmes de configuration des machines de développement pour les nouveaux développeurs. La première tâche du nouveau développeur de l'équipe était généralement de configurer sa propre machine de développement. Nous sommes une petite entreprise et nous n'avons pas toujours la main-d'œuvre nécessaire pour aider les nouveaux membres de l'équipe à configurer leur machine. Cela posait différents problèmes: parfois, le bogue n'était reproductible que sur leur machine ou ils ne pouvaient pas le reproduire du tout, l'application ne pouvait pas se construire correctement, etc. De plus, certains de nos développeurs principaux travaillaient également sur plusieurs projets. sur des environnements de travail pas toujours compatibles.

Lorsque nous sommes passés aux machines virtuelles, tout a changé. Désormais, une seule personne est responsable de la configuration de l'environnement dans une machine virtuelle avec tout ce qui est lié au projet. Lorsqu'il a terminé, tous les membres de l'équipe reçoivent la copie de la machine virtuelle. Cela réduit le temps nécessaire à la configuration de l'environnement pour chaque nouveau membre de l'équipe (la copie de la machine virtuelle ne doit pas prendre plus d'une heure). Cela nous permet également de travailler sur plusieurs environnements de travail en parallèle.

Les inconvénients liés à l’utilisation de machines virtuelles: la vitesse. La performance atteinte sur la machine virtuelle est visible. Sur des postes de travail plus lents, le développement peut être presque impossible. Si vous avez un bon poste de travail (quad core, 8 Go + RAM, SSD), vous ne le remarquerez probablement pas.

Comme d'autres l'ont mentionné, cela dépend de plusieurs choses:

• À quoi ressemble votre environnement?
• Avez-vous des droits d'accès suffisants pour faire du développement?
• Votre HW est-il prêt à fumer?

Environnement

L'utilisation d'un ordinateur virtuel peut vous aider si vous travaillez sur plusieurs versions d'un projet. plusieurs projets; ou ciblant un système d'exploitation différent de celui que vous exécutez normalement (système d'exploitation hôte). Je fais beaucoup de travail sur SharePoint et il est utile de pouvoir exécuter une machine différente pour les différentes versions d'une version, car je peux simplement démarrer une machine différente et avoir une bonne idée de l'état du GAC / de la base de données. De même, si vous devez cibler un environnement d'application * nix mais une machine Windows, vous pouvez toujours effectuer le développement dans une machine virtuelle (c'est ainsi que j'apprends Ruby à la maison, même si je travaille généralement sous .NET). Lorsque je teste / développe des développements ASP.NET sur la même version d’IIS, j’encourage généralement l’application à s’exécuter (cette même raison s’applique également aux autres environnements cibles de serveur). Selon la version du système d'exploitation, il peut exister des différences minimes mais critiques. Notez que cela ne signifie pas que vous devriez coder vers une version spécifique d'IIS / OS, mais soyons honnêtes, il faut vraiment que cela fonctionne vraiment là où vous allez le déployer, pas seulement sur votre ordinateur local.

Les machines virtuelles permettent également (en fonction du logiciel utilisé) de prendre des instantanés de l'état actuel de la machine et / ou de les cloner. Cela peut être inestimable lorsque vous prototypez quelque chose et vous n'avez pas à vous soucier de ce qui se passe dans votre GAC / Registre / etc. Je les ai également trouvés très utiles pour préparer une démonstration client à l'avance. Étant donné que l'environnement de démonstration était dans une machine virtuelle, je pouvais continuer à travailler jusqu'à montrer au client ce que nous avions accompli car je travaillais sur une machine différente .

Droits suffisants

Cela s’applique généralement aux personnes qui travaillent pour une entreprise avec un ensemble de règles relativement contraignantes pour les droits d’accès. Si vous ne pouvez pas avoir un administrateur libre sur votre machine, ce serait un bon moment pour travailler dans une VM. En règle générale, les puissances ne sont préoccupées que par le verrouillage de votre système d'exploitation hôte. L'invité peut être grand ouvert (en termes d'autorisations). J'ai rencontré des problèmes étranges avec les profils itinérants, les droits d'administrateur invalidés et l'exécution de VS 2010; L'utilisation d'une machine virtuelle m'a permis d'éviter ces problèmes.

Votre HW est-il prêt à fumer?

Cela se résume à ce que vos images de machine virtuelle se trouvent sur un serveur et votre télécommande y soit OU que vous les exécutiez localement. Si vous exécutez sur le serveur, la plus grande préoccupation sera probablement de savoir s'il y a trop de machines virtuelles exécutées sur le même matériel. Au niveau local, vous souhaitez essentiellement disposer de beaucoup de RAM et minimiser la fréquence à laquelle vous surchargez la mémoire tampon R / W de votre disque dur. Pour le développement LOB / SharePoint / ASP.NET de base, j'ai constaté qu'un minimum de 8 Go de RAM et une configuration à deux disques durs fonctionnaient très bien dans la pratique (utiliser un i5 mais j'ai également travaillé avec un Core 2). Le deuxième disque dur fait la plus grande différence en termes de performances.

Remarque: je n'ai aucune statistique à l'appui, mais j'ai remarqué que Virtual PC avait tendance à sous-performer par rapport à VMWare et à Virtual Box. Je ne peux pas parler à Hyper-V car je n'ai pas travaillé avec. Je ne serais pas surpris si l'utilisation de Virtual PC (en tant que première incursion dans l'utilisation de machines virtuelles) rendait le développeur fatigué d'utiliser un logiciel de virtualisation.

Comme d'habitude: ça dépend. Par exemple, je ne le recommanderais certainement pas pour un développement en temps réel ou lié au jeu informatique.

Mon expérience personnelle: j’ai un iMac de la fin de 2009 et j’ai constaté que Visual Studio 2010 est inutilisable dans Parallels Desktop, au point qu’il suffit de quelques secondes pour enregistrer une touche dans l’éditeur de code. Windows dans SQL Server Management Studio se défocaliserait et changerait de focus apparemment de manière aléatoire. Je viens de finir avec le camp d'entraînement.

Bien sûr, un de mes nouveaux projets implique une application iOS avec un outil de configuration basé sur Windows. Il est donc peut-être trop pénible de ne pas utiliser la virtualisation, mais si la technologie de virtualisation des postes de travail n’a pas suffisamment évolué au cours de la dernière année, Je vais probablement juste installer un autre bureau ici.

En ce qui concerne le test d’une application serveur, la situation est différente, je suis parfaitement heureux de la virtualiser, mais j’ai besoin de réactivité dans mes applications de développement.

J'ai utilisé des machines virtuelles pour le développement et, dans l'ensemble, ce n'est pas très différent du développement sur ma propre machine. Si vous utilisez correctement le contrôle de source, il n'y a pas beaucoup de différences.

Les principales différences sont que si vous êtes hors ligne pour une raison quelconque, vous n’avez pas de machine de développement à votre disposition, donc vous n’êtes pas si génial si vous voyagez ou travaillez souvent à la maison. En outre, je n’ai jamais compris comment exécuter plusieurs moniteurs sur le Bureau à distance, mais je suis certain que c’est mon échec, et non un problème de principe. J'utilisais généralement mon moniteur principal pour le développement et gardais le deuxième pour mon ordinateur de bureau avec la messagerie, les navigateurs, etc.

J'ajouterai que si vous devez vérifier que votre code fonctionne sur différentes plates-formes, notamment le développement d'installateurs, il est extrêmement pratique de pouvoir exécuter des machines virtuelles pour différentes versions de système d'exploitation.

Je les ai utilisés à la société précédente. Plusieurs contrôles tiers n'ont pas bien coexisté avec d'autres versions de la même société. J'ai également utilisé un couple pour tester et déboguer d'autres systèmes d'exploitation (XP vs Vista vs 7). Un virtuel avait VB6 et VS2003 pour les produits plus anciens. Oui, sur un ordinateur de développeur typique, cela peut être lent et fastidieux, mais j’avais «donné» quelques disques durs de rechange et mis les disques virtuels sur leurs propres disques durs sur leurs propres contrôleurs de disque. J'étais le dernier à continuer à utiliser les logiciels virtuels, et pour certains bogues, je pouvais seulement y travailler (en raison de problèmes liés au système d'exploitation et aux composants).

Certains d'entre eux ont été brûlés en installant une version bêta du logiciel, et certaines des versions bêta de MS n'ont pas pu être supprimées. Ils ont donc été forcés d'utiliser des logiciels virtuels jusqu'à ce qu'ils reformatent leurs disques durs.

Pour développer en virtual, mon conseil est d’obtenir quelque chose avec un minimum de 8 Go de RAM. 16 ou plus serait mieux, car vous constaterez que tout studio équipé de Visual Studio nécessite environ 1,5 Go de RAM de l'hôte pour fonctionner à une vitesse supérieure à "glacial". En outre, obtenez beaucoup de disques durs lors de l'achat d'un ordinateur. Pour les disques que vous choisissez dans votre pile de matériel de rechange, recherchez-en au moins deux fois la taille du disque dur virtuel que vous utiliserez.