¿Debería una máquina de desarrollo estar dentro de una VM? [cerrado]

Esta publicación de Rob Conery (tenga en cuenta la babosa) dice que el entorno de desarrollo debe ejecutarse dentro de una máquina virtual. Veo lo que dice y tiendo a estar de acuerdo, pero aún me siento un poco incómodo. Ahora que la virtualización es tan madura que incluso los sistemas de producción que se ejecutan dentro de la velocidad de las máquinas virtuales no son un problema, pero como digo, algo me molesta aquí.

¿Cuál es su opinión sobre la virtualización de su máquina de desarrollo? ¿Ya lo has hecho? Si lo hiciste, ¿alguna trampa o trampa en el camino?

Mi experiencia con el desarrollo en máquinas virtuales en un entorno corporativo es que debido a que la virtualización de múltiples núcleos está llena de dificultades, es difícil obtener el tipo de rendimiento que necesitan muchas máquinas de desarrollo empresarial.

Hacer que el bucle interno de prueba de compilación de código sea lo más rápido posible requiere las mejores máquinas posibles: la compilación y la ejecución de pruebas obviamente se ejecutan más rápido en máquinas con más núcleos, ya que esas actividades se pueden ejecutar fácilmente de manera simultánea * .

Hasta que los sistemas operativos de desarrollo convencionales puedan manejar la cantidad de núcleos disponibles que sean volátiles, y hasta que el software de virtualización pueda ofrecer de manera inteligente algún tipo de contrato "hasta N núcleo", las máquinas de desarrollo virtualizadas no ofrecerán el mismo tipo de rendimiento de productividad que los dispositivos físicos.

EDITAR: Esto solo relata mis sentimientos personales sobre el desarrollo utilizando máquinas virtuales dictadas por la empresa, que a menudo están prohibidas para reducir los costos de hardware, que tienden a ejecutarse en servidores. Ejecutar una máquina virtual local parece superfluo siempre y cuando esté aplicando una buena disciplina de control de fuente, a menos que su proyecto requiera específicamente que desarrolle código para múltiples sistemas operativos.

*: con lo que quiero decir que las subtareas dentro de las etapas de compilación y prueba se pueden ejecutar simultáneamente, NO compilando y probando simultáneamente :)

Hago todo mi desarrollo personal en máquinas virtuales. Tengo varias máquinas virtuales configuradas para diferentes entornos y funciona bien.

Tengo una laptop Dell Studio 15 (quad I7 2.8ghz, 8gb ram, ati graphics) con win 7 ultimate 64bit con virtualbox instalado. Tengo todas mis máquinas virtuales funcionando con una unidad USB externa de 500 gb con velcro a la computadora portátil.

VM 0 - Win 7 64bit instalación limpia como plantilla base

VM 1 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) con el conjunto de herramientas Visual Studio 2008

VM 2 - Win 7 64bit (2 cpu, 4gb ram, 120gb hd) con el conjunto de herramientas Visual Studio 2010

VM 3 - Win 7 64bit (2 cpu, 2gb ram, 120gb hd) con el conjunto de herramientas Eclipse Java

A menos que esté haciendo algo que requiera un IO muy alto, he sentido que el rendimiento es bueno y no sabría que estoy dentro de una VM si alguien me hubiera entregado la computadora portátil y me dijera que comience a desarrollar.

Me gustaría agregar que ciertos tipos de desarrollo son mucho más difíciles (si no imposibles) a través de máquinas virtualizadas.

Trabajo en una empresa donde ofrecemos paquetes de software que se integran con varios dispositivos periféricos USB diferentes (por ejemplo, cámaras web, impresoras de etiquetas, lectores de banda magnética, etc.). Incluso si tuviera que asignar puertos USB a un servidor virtualizado, he notado problemas extraños e inexplicables con los controladores de dispositivos del proveedor externo.

Como dije, no creo que esta situación justifique NO trabajar en máquinas de desarrollo virutalizadas, sin embargo, es una situación que aún no hemos descubierto, por lo que mantenemos estaciones de trabajo físicas para diferentes entornos en un laboratorio.

En nuestra empresa ahora estamos utilizando la VM para el desarrollo y las pruebas. Aunque hay algunos inconvenientes para usar VM, sus beneficios los superan significativamente.

Antes de comenzar a usar máquinas virtuales, tuvimos problemas para configurar máquinas de desarrollo para nuevos desarrolladores. La primera tarea para un nuevo desarrollador en el equipo generalmente era configurar su propia máquina de desarrollo. Somos una empresa pequeña y no siempre tenemos la mano de obra para ayudar a los nuevos miembros del equipo a configurar su máquina. Esto condujo a diferentes problemas: a veces el error era reproducible solo en su máquina o no podían reproducirlo en absoluto, la aplicación no podía compilarse correctamente, etc. También había un problema de que algunos de nuestros desarrolladores principales estaban trabajando en múltiples proyectos en entornos de trabajo que no siempre fueron compatibles.

Cuando cambiamos a máquinas virtuales, todo cambió. Ahora solo una persona es responsable de configurar el entorno en una VM con todo lo relacionado con el proyecto. Cuando termina, todos los miembros del equipo reciben la copia de la VM. Esto reduce el tiempo de configuración del entorno para cada nuevo miembro del equipo (copiar la VM no debería tomar más de 1 hora). También nos permite trabajar en múltiples entornos de trabajo en paralelo.

Los inconvenientes para usar máquinas virtuales: velocidad. El rendimiento alcanzado en la VM es visible. En estaciones de trabajo más lentas, puede hacer que el desarrollo sea casi imposible. Si tiene una buena estación de trabajo (cuatro núcleos, 8 + GB de RAM, SSD), probablemente no lo note.

Como otros han mencionado, depende de varias cosas:

• ¿Cómo es tu entorno?
• ¿Tiene suficientes derechos de acceso para hacer desarrollo?
• ¿Tu HW está preparado para el tabaco?

Medio ambiente

Usar una máquina virtual puede ayudar si está trabajando en varias versiones de un proyecto; múltiples proyectos; o apuntar a un sistema operativo diferente del que normalmente ejecuta (sistema operativo host). Hago mucho trabajo de SharePoint y poder ejecutar una máquina diferente para las diferentes versiones de una versión es útil, ya que puedo iniciar una máquina diferente y tener una buena idea del estado de la base de datos / GAC. Además, si necesita apuntar a un entorno de aplicación * nix pero tiene una máquina Windows, aún puede desarrollar en una VM (así es como estoy aprendiendo Ruby en casa, aunque generalmente hago trabajo de desarrollo de .NET). En general, defiendo cuando hago pruebas de desarrollo ASP.NET / desarrollo en la misma versión de IIS que la aplicación se ejecutará en última instancia (esta misma racional se aplica a otros entornos de destino del servidor). Dependiendo de la versión del sistema operativo, puede haber algunas diferencias pequeñas pero críticas. Tenga en cuenta que esto no implica que deba codificar una versión específica de IIS / OS, pero seamos honestos, realmente tiene que funcionar donde lo va a implementar, no solo en su máquina local.

Las máquinas virtuales también (según el software utilizado) le permiten tomar instantáneas del estado actual de la máquina y / o clonarlas. Esto puede ser invaluable al crear prototipos de algo y no tiene que preocuparse tanto por lo que está sucediendo en su GAC / Registro / etc. También los he encontrado muy valiosos para configurar una demostración de cliente con anticipación. Debido a que el entorno de demostración estaba en una VM, pude continuar trabajando hasta el punto de mostrarle al cliente lo que habíamos completado porque estaba trabajando en una máquina diferente .

Derechos suficientes

Esto generalmente se aplica a las personas que trabajan para una empresa con un conjunto bastante estricto de políticas de derechos de acceso. Si no puede tener un administrador sin restricciones en su máquina, este sería un buen momento para trabajar en una máquina virtual. Por lo general, los poderes solo están preocupados por bloquear el sistema operativo host, el invitado puede estar abierto (permisos). Me he encontrado con problemas extraños con perfiles móviles, derechos de administrador paralizados y con VS 2010; El uso de una máquina virtual me permitió evitar estos problemas.

¿Tu HW está preparado para el tabaco?

Esto se reduce a que sus imágenes de VM estén en un servidor y su control remoto en ellas O las ejecute localmente. Si está ejecutando en el servidor, entonces la mayor preocupación probablemente será si hay demasiadas máquinas virtuales en el mismo hardware. A nivel local, básicamente, desea mucha RAM y minimizar la frecuencia con la que sobrecarga el búfer R / W para su disco duro. Para el desarrollo básico de LOB / SharePoint / ASP.NET, he encontrado que un mínimo de 8 GB de RAM y una configuración de disco duro dual funcionan bien en la práctica (ejecutando un i5 pero también he trabajado con un Core 2). El segundo disco duro marca la mayor diferencia en el rendimiento.

Nota: No tengo estadísticas para respaldar esto, pero he notado que Virtual PC tiene una tendencia a tener un rendimiento inferior en comparación con VMWare y Virtual Box. No puedo hablar con Hyper-V ya que no he trabajado con él. No me sorprendería si usara Virtual PC (como una incursión inicial en el uso de máquinas virtuales) el desarrollador hastiado de usar software de virtualización.

Como de costumbre: depende. Por ejemplo, ciertamente no lo recomendaría para ningún desarrollo en tiempo real o relacionado con juegos de computadora.

Mi experiencia personal: tengo un iMac de finales de 2009, y descubrí que Visual Studio 2010 es básicamente inutilizable en Parallels Desktop, hasta el punto de que presionar una tecla en el editor de código tarda unos segundos en registrarse. Windows en SQL Server Management Studio desenfocaría y cambiaría el foco aparentemente al azar. Acabo de ir al campo de entrenamiento.

Por supuesto, un nuevo proyecto mío involucrará una aplicación iOS con una herramienta de configuración basada en Windows, por lo que puede ser demasiado doloroso no usar la virtualización, pero si la tecnología de virtualización de escritorio no se ha movido lo suficiente en el último año, Probablemente solo configure otro escritorio aquí.

Cuando se trata de probar una aplicación de servidor, esa es una situación diferente, estoy perfectamente feliz de virtualizar eso, pero necesito capacidad de respuesta en mis aplicaciones de desarrollo.

He usado máquinas virtuales para el desarrollo y, en general, no es tremendamente diferente del desarrollo en mi propia máquina. Si está utilizando el control de origen correctamente, no hay muchas diferencias.

Las principales diferencias son que si está desconectado por cualquier motivo, no tiene una máquina de desarrollo disponible, por lo que no es tan bueno si viaja o trabaja mucho desde casa. Además, nunca descubrí cómo ejecutar varios monitores en Escritorio remoto, pero estoy seguro de que es mi falla en lugar de un problema con el principio. Usualmente usé mi monitor principal para el desarrollo y mantuve el segundo para mi máquina de escritorio con correo electrónico, navegadores, etc.

Agregaré que si está trabajando de una manera en la que necesita verificar que su código funcione en diferentes plataformas, particularmente cosas como el desarrollo de instaladores, entonces poder ejecutar máquinas virtuales para diferentes versiones del sistema operativo es increíblemente útil.

Los usé en la compañía anterior. Varios controles de terceros no coexistieron bien con otras versiones de la misma compañía. También usé un par para probar y depurar otros sistemas operativos (XP vs Vista vs 7). Una virtual tenía VB6 y VS2003 para los productos más antiguos. Sí, en una máquina típica de desarrollador puede ser lento y engorroso, pero tenía algunos discos duros de repuesto que "doné" y puse los virtuales en sus propios discos duros en sus propios controladores de disco. Fui el último tipo en seguir usando virtuales, y para algunos errores, solo pude trabajar en ellos (debido a problemas con el sistema operativo y los componentes).

Algunos de los chicos se quemaron al instalar el software beta, y algunas de las versiones beta de MS no se pudieron eliminar, por lo que se vieron obligados a usar virtuales hasta que formatearon sus discos duros.

Para desarrollar en virtuales, mi consejo es obtener algo con un mínimo de 8 GB de RAM. 16 o más sería mejor, ya que encontrará que cualquier estudio virtual equipado con virtual necesita alrededor de 1.5 GB de la RAM del host para funcionar a velocidades superiores a las "glaciales". Además, obtenga muchos discos duros al comprar una computadora. Para las unidades que elija de su pila de hardware de repuesto, busque las que tengan al menos el doble del tamaño del VHD que ejecutará.