Должна ли машина разработки находиться внутри виртуальной машины? [закрыто]

В этом посте Роба Конери (обратите внимание на слаг) говорится, что среду разработки следует запускать внутри виртуальной машины. Я вижу, что он говорит, и склонен соглашаться, но все еще чувствую себя немного неловко. Теперь, когда виртуализация настолько развита, что даже рабочие системы работают на скорости виртуальных машин, это не проблема, но, как я уже сказал, что-то меня здесь беспокоит.

Как вы относитесь к виртуализации своей машины разработки? Вы уже сделали это? Если вы сделали, какие-нибудь подводные камни или ошибки вдоль дороги?

Мой опыт разработки на виртуальных машинах в корпоративной среде заключается в том, что из-за сложностей, связанных с виртуализацией нескольких ядер, трудно получить ту производительность, которая нужна многим компьютерам для разработки на предприятиях.

Для того, чтобы внутренний цикл code-compile-test был максимально быстрым, требуются лучшие машины - компиляция и запуск тестов, очевидно, быстрее выполняются на машинах с большим количеством ядер, поскольку эти действия могут быть довольно легко выполнены параллельным образом * ,

До тех пор пока основные операционные системы разработки не смогут справиться с изменчивостью числа доступных ядер, и пока программное обеспечение для виртуализации не сможет разумно предложить какой-то контракт «до N ядер», виртуализированные машины разработки не будут обеспечивать такой же возврат производительности, как физические устройства.

РЕДАКТИРОВАТЬ: Это просто излагает мои личные ощущения от разработки с использованием корпоративных виртуальных машин, которые часто запрещают сокращать расходы на оборудование, которые, как правило, работают на серверах. Запуск локальной виртуальной машины кажется в большинстве случаев излишним, если вы соблюдаете хорошую дисциплину контроля версий, если только для вашего проекта не требуется специально разрабатывать код для нескольких ОС.

*: под этим я подразумеваю подзадачи внутри этапов компиляции и этапов тестирования, которые могут выполняться одновременно, а НЕ компилироваться и тестироваться одновременно :)

Я делаю все свое личное развитие в виртуальных машинах. У меня есть несколько виртуальных машин, настроенных для разных сред, и они отлично работают.

У меня ноутбук Dell Studio 15 (Quad I7 2,8 ГГц, 8 ГБ RAM, ATI Graphics), работающий на Win 7 Ultimate 64bit с установленной виртуальной коробкой. Все мои виртуальные машины работают на внешнем 500-гигабайтном USB-накопителе, прикрепленном к ноутбуку.

VM 0 - Win 7 64bit, чистая установка в качестве базового шаблона

VM 1 - Win 7 64bit (2 процессора, 4 ГБ оперативной памяти, 120 ГБ HD) с набором инструментов Visual Studio 2008

VM 2 - Win 7 64bit (2 процессора, 4 ГБ оперативной памяти, 120 ГБ HD) с набором инструментов Visual Studio 2010

VM 3 - Win 7 64bit (2 процессора, 2 ГБ оперативной памяти, 120 ГБ HD) с набором инструментов Eclipse Java

Если я не делаю что-то, что требует очень высокого ввода-вывода, я чувствовал, что производительность хорошая, и я не знал бы, что я нахожусь внутри виртуальной машины, если кто-то только что вручил мне ноутбук и сказал начать разработку.

Я хотел бы добавить, что некоторые типы разработки намного сложнее (если не невозможны) с помощью виртуальных машин.

Мне довелось работать в компании, где мы предлагаем пакеты программного обеспечения, которые интегрируются с различными периферийными устройствами USB (например, веб-камеры, принтеры этикеток, считыватели магнитных полос и т. Д.). Даже если бы я подключил порты USB к виртуализированному серверу, я заметил странные и необъяснимые проблемы с драйверами устройств сторонних производителей.

Как я уже сказал, я не думаю, что такая ситуация НЕ гарантирует работу на виртуализированных машинах разработки, однако это та, которую мы еще не выяснили, поэтому мы поддерживаем физические рабочие станции для различных сред в лаборатории.

В нашей компании мы сейчас используем виртуальную машину для разработки и тестирования. Хотя есть некоторые недостатки использования виртуальных машин, их преимущества значительно перевешивают их.

До того, как мы начали использовать виртуальные машины, у нас были проблемы с настройкой машин для новых разработчиков. Первым заданием для нового разработчика в команде, как правило, было создание собственной машины для разработки. Мы небольшая компания, и у нас не всегда есть кадры, чтобы помочь новым членам команды настроить свою машину. Это приводило к различным проблемам: иногда ошибка воспроизводилась только на их компьютере, или они вообще не могли ее воспроизвести, приложение не могло быть построено должным образом и т. Д. Также была проблема, что некоторые из наших старших разработчиков работали над несколькими проектами. на рабочих средах, которые не всегда были совместимы.

Когда мы перешли на виртуальные машины, все изменилось. Теперь только один человек отвечает за настройку среды на ВМ со всем, что связано с проектом. Когда он закончил, всем членам команды предоставляется копия виртуальной машины. Это сокращает время на настройку среды для каждого нового члена команды (копирование ВМ не должно занимать более 1 часа). Это также позволяет нам работать в нескольких рабочих средах параллельно.

Недостатки использования виртуальных машин: скорость. Хит производительности на ВМ виден. На медленных рабочих станциях это может сделать разработку практически невозможной. Если у вас есть хорошая рабочая станция (четырехъядерный процессор, 8 + ГБ ОЗУ, SSD), вы, вероятно, этого не заметите.

Как уже упоминали другие, это зависит от нескольких вещей:

• Как выглядит ваша среда?
• Достаточно ли у вас прав доступа для разработки?
• Ваш HW нюхает?

Среда

Использование ВМ может помочь, если вы работаете над несколькими версиями проекта; несколько проектов; или нацеливание на другую ОС, отличную от той, которую вы обычно запускаете (ОС хоста). Я много работаю над SharePoint, и возможность запуска другой машины для разных версий выпуска полезна, поскольку я могу просто запустить другую машину и хорошо оценить состояние GAC / базы данных. Также, если вам нужно ориентироваться на среду приложений * nix, но иметь компьютер с Windows, вы все равно можете заниматься разработкой на виртуальной машине (именно так я изучаю Ruby дома, хотя обычно я работаю с .NET dev). Обычно я выступаю за тестирование / разработку ASP.NET на той же версии IIS, под которой в конечном итоге будет работать приложение (это же относится и к другим целевым средам сервера). В зависимости от версии ОС могут быть небольшие, но критические различия. Обратите внимание, что это не означает, что вы должны писать код для конкретной версии IIS / OS, но давайте будем честными, это действительно, действительно должно работать там, где вы собираетесь развернуть его, а не только на вашей локальной машине.

Кроме того, виртуальные машины (в зависимости от используемого программного обеспечения) позволяют делать снимки текущего состояния машины и / или клонировать их. Это может иметь неоценимое значение при создании прототипа, и вам не нужно беспокоиться о том, что происходит в вашем GAC / реестре / и т. Д. Я также нашел их очень ценными при предварительной настройке клиентской демонстрации. Поскольку демонстрационная среда была на виртуальной машине, я мог продолжать работать вплоть до момента, когда клиент мог показать, что мы выполнили, потому что я работал на другой машине .

Достаточные права

Как правило, это относится к людям, которые работают в компании с довольно строгим набором политик для прав доступа. Если вы не можете иметь неограниченного администратора на своем компьютере, то это подходящее время для работы на виртуальной машине. Обычно полномочия беспокоятся только о блокировке вашей хост-ОС, гость может быть широко открыт (с точки зрения разрешений). Я столкнулся со странными проблемами с перемещаемыми профилями, ограниченными правами администратора и запуском VS 2010; использование виртуальной машины позволило мне избежать этих проблем.

Ваш HW нюхает?

Это сводится к тому, что ваши образы виртуальных машин находятся на сервере, а ваш удаленный - в них, ИЛИ вы запускаете их локально. Если вы работаете на сервере, то, вероятно, самой большой проблемой будет слишком много виртуальных машин, работающих на одном и том же оборудовании. Локально, вы в основном хотите много оперативной памяти и минимизировать частоту перегрузки буфера R / W для вашего жесткого диска. Для базовой разработки LOB / SharePoint / ASP.NET я обнаружил, что минимум 8 ГБ ОЗУ и конфигурация с двумя жесткими дисками на практике работают очень хорошо (работает на i5, но я также работал с Core 2). Второй жесткий диск имеет самое большое значение в производительности.

Примечание. У меня нет статистики, подтверждающей это, но я заметил, что Virtual PC имеет тенденцию к снижению производительности по сравнению с VMWare и Virtual Box. Я не могу говорить с Hyper-V, так как я не работал с ним. Я не удивлюсь, если использование Virtual PC (как начальный шаг в использовании виртуальных машин) заставит разработчиков использовать программное обеспечение для виртуализации.

Как обычно: это зависит. Например, я определенно не рекомендовал бы это для любой разработки в реальном времени или связанной с компьютерной игрой.

Мой личный опыт: у меня есть iMac, выпущенный в конце 2009 года, и я обнаружил, что Visual Studio 2010 практически невозможно использовать в Parallels Desktop, так что нажатие клавиши в редакторе кода занимает несколько секунд для регистрации. Windows в SQL Server Management Studio будет расфокусировать и переключать фокус, очевидно, наугад. Я только закончил тем, что пошел с учебным лагерем.

Конечно, в моем новом проекте будет задействовано приложение для iOS с инструментом настройки на базе Windows, поэтому может быть слишком болезненно не использовать виртуализацию, но если технология виртуализации десктопов недостаточно продвинулась за последний год или около того, Я, наверное, просто настрою другой рабочий стол здесь.

Когда дело доходит до тестирования серверного приложения, это другая ситуация, я очень рад виртуализировать это, но мне нужно реагирование в моих приложениях разработки.

Я использовал виртуальные машины для разработки, и в целом она ничем не отличается от разработки на моей собственной машине. Если вы используете Source Control правильно, различий не так много.

Основные отличия заключаются в том, что если вы по какой-либо причине не в сети, у вас нет машины для разработки, поэтому не так уж и здорово, если вы много путешествуете или работаете из дома. Также я никогда не понимал, как запустить несколько мониторов на удаленном рабочем столе, но я уверен, что это моя ошибка, а не проблема с принципом. Я обычно использовал свой основной монитор для разработки и оставлял второй для своего настольного компьютера с электронной почтой, браузерами и так далее.

Я добавлю, что если вы работаете так, что вам нужно проверить, работает ли ваш код на разных платформах - особенно таких, как разработка инсталляторов, - то возможность запуска виртуальных машин для разных версий ОС удивительно удобна.

Я использовал их в предыдущей компании. Несколько сторонних контролей не сосуществовали хорошо с другими версиями той же компании. Я также использовал пару для тестирования и отладки других операционных систем (XP против Vista против 7). Один виртуальный имел VB6 и VS2003 для более старых продуктов. Да, на типичной машине разработчика она может быть медленной и громоздкой, но у меня было несколько запасных жестких дисков, которые я «пожертвовал» и поместил виртуальные устройства на свои собственные жесткие диски на свои контроллеры. Я был последним, кто продолжал использовать виртуалы, и из-за некоторых ошибок только я мог работать над ними (из-за проблем с операционной системой и компонентами).

Некоторые парни были обожжены установкой бета-версии программного обеспечения, а некоторые бета-версии от MS не могли быть удалены, поэтому они были вынуждены использовать виртуальные компьютеры, пока они не переформатировали свои жесткие диски.

Для разработки в виртуалах я советую получить что-то с минимум 8 ГБ ОЗУ. 16 или больше будет лучше, так как для любой виртуальной студии вам понадобится около 1,5 ГБ ОЗУ хоста для работы на скорости выше «ледниковой». Кроме того, получите много жестких дисков при покупке компьютера. Для дисков, которые вы выбираете из своего запаса аппаратного обеспечения, ищите по крайней мере в два раза больше виртуального жесткого диска, который вы будете использовать.