Чи повинна машина для розробки знаходитися всередині ВМ? [зачинено]

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

Як ви ставитесь до віртуалізації вашої машини розвитку? Ви вже зробили це? Якщо ви це зробили, якісь підводні камені чи ґатчі по дорозі?

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

Якнайшвидше зробити внутрішній цикл кодування-тестування коду вимагає найкращих можливих машин - компіляція та виконання тестів, очевидно, працюють швидше на машинах з більшою кількістю ядер, оскільки ці дії досить легко виконуватись одночасно * .

Поки ОС на розробці не зможуть вирішити кількість доступних ядер, які є нестабільними, і поки програмне забезпечення для віртуалізації не зможе інтелектуально запропонувати якийсь контракт «до N ядра», віртуалізовані машини для розробки не будуть пропонувати такий же рівень віддачі продуктивності, як фізичні пристрої.

EDIT: Це просто переказує мої особисті почуття щодо розробки за допомогою корпоративних диктованих віртуальних машин, які часто забороняються скорочувати витрати на обладнання, які, як правило, працюють на серверах. Запуск локального VM здається в основному зайвим за умови, що ви дотримуєтесь належної дисципліни управління джерелом, якщо ваш проект спеціально не вимагає розробити код для декількох ОС.

*: під якими я маю на увазі підзадачі всередині етапів компіляції та тестових етапів можна виконувати одночасно, НЕ компілюючи і тестуючи одночасно :)

Я весь свій особистий розвиток роблю у вітчизняних машинах. У мене є кілька налаштувань VM для різних середовищ, і це працює чудово.

У мене є ноутбук Dell Studio 15 (квадратик I7 2,8 ГГц, 8 ГБ оперативної пам’яті, графічна графіка), виграйте win 7 ultimate 64bit з встановленим virtualbox. У мене всі VM працюють із зовнішнім 500 Гб USB-накопичувачем на липучці.

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

VM 1 - Win 7 64bit (2 процесор, 4gb ram, 120gb hd) з набором інструментів Visual Studio 2008

VM 2 - Win 7 64bit (2 процесор, 4gb ram, 120gb hd) з набором інструментів Visual Studio 2010

VM 3 - Win 7 64bit (2 процесор, 2 Гб оперативної пам’яті, 120 Гб hd) з набором інструментів Eclipse Java

Якщо я не роблю щось, що вимагає дуже високого IO, я відчував, що продуктивність хороша, і я б не знав, що я всередині VM, якби хтось щойно передав мені ноутбук і сказав, що я починаю розвиватися.

Хочу додати, що певні типи розробки набагато складніше (якщо не неможливо) через віртуалізовані машини.

Мені здається, я працюю в компанії, де ми пропонуємо програмні пакети, які інтегруються з низкою різних периферійних пристроїв USB (наприклад, веб-камери, принтери етикеток, зчитувачі магнітних смуг тощо). Навіть якби я мапив порти USB на віртуалізований сервер, я помітив химерні та незрозумілі проблеми із сторонніми драйверами постачальників пристроїв.

Як я вже говорив, я не думаю, що ця ситуація не вимагає того, щоб НЕ працювали на віруалізованих розроблювальних машинах, однак ми це ще не з'ясували, тому ми підтримуємо фізичні робочі станції для різних середовищ у лабораторії.

Зараз у нашій компанії ми використовуємо VM для розробки та тестування. Хоча є деякі недоліки використання VM, їх переваги значно перевищують їх.

Перш ніж ми почали використовувати VM, у нас виникли проблеми з налаштуванням машин для розробників для нових розробників. Першим завданням нового розробника в команді було, як правило, створити власну розроблювальну машину. Ми невелика компанія, і не завжди у нас є достатня кількість людей, щоб допомогти новим членам команди створити свою машину. Це призвело до різних проблем: іноді помилка була відтворюваною лише на своїй машині або вони взагалі не могли її відтворити, програма не могла скластися належним чином тощо. Також була проблема, що деякі наші старші розробники працювали над кількома проектами на робочих середовищах, які не завжди були сумісні.

Коли ми перейшли на VM, все змінилося. Зараз лише одна людина відповідає за налаштування середовища у ВМ із усім, що пов'язано з проектом. Коли він закінчить, всі члени команди отримують копію VM. Це скорочує час на створення середовища для кожного нового члена команди (копіювання VM не повинно зайняти більше 1 години). Це також дозволяє нам працювати в декількох робочих середовищах паралельно.

Недоліки використання ВМ: швидкість. Видимий удар на VM видно. На повільних робочих станціях це може зробити розвиток майже неможливим. Якщо у вас хороша робоча станція (чотирьохядерний, 8 + ГБ оперативної пам’яті, SSD), ви, ймовірно, цього не помітите.

Як згадували інші, це залежить від кількох речей:

• Як виглядає ваше оточення?
• Чи є у вас достатні права доступу для розвитку?
• Це ваш HW до нюхання?

Середовище

Використання VM може допомогти, якщо ви працюєте над декількома версіями проекту; кілька проектів; або націлювання на іншу ОС від тієї, яку ви зазвичай запускаєте (хост ОС). Я багато працюю в SharePoint, і можливість запускати іншу машину для різних версій випуску є корисною, оскільки я можу просто запустити іншу машину і добре відчувати стан GAC / бази даних. Крім того, якщо вам потрібно орієнтуватися на середовище додатків * nix, але у вас є машина Windows, ви все одно можете займатися розробкою в VM (саме так я вчу Рубі вдома, хоча я, як правило, працюю в .NET dev). Як правило, я виступаю за тестування / розробку ASP.NET на тій же версії IIS, під якою програма в кінцевому підсумку буде працювати (це ж раціонально застосовується до інших цільових середовищ сервера). Залежно від версії ОС можуть бути невеликі, але критичні відмінності. Зауважте, це не означає, що ви повинні кодувати певну версію IIS / OS, але, будьмо чесними, це дійсно, справді має працювати там, де ви збираєтесь розгорнути її не лише на своїй локальній машині.

Відеомагнітофони також (залежно від використовуваного програмного забезпечення) дозволяють робити знімки поточного стану машини та / або клонувати їх. Це може бути безцінним при прототипуванні чогось, і вам не доведеться так сильно турбуватися про те, що відбувається у вашому GAC / реєстрі / тощо. Я також вважав їх дуже цінними в налаштуванні для демонстрації клієнта достроково. Оскільки демонстраційне середовище було у вітчизняній машині, я міг продовжувати працювати до того моменту, як показувати клієнту, що ми закінчили, оскільки я працював на іншій машині .

Достатньо прав

Це, як правило, стосується людей, які працюють у компанії з досить досконалим набором політик щодо прав доступу. Якщо ви не можете мати на своєму комп'ютері безперервного адміністратора, це був би хороший час для роботи у вітчизняній машині. Зазвичай повноваження турбуються лише про блокування вашої хост-операційної системи, гість може бути широко відкритим (дозволені). У мене виникли дивні проблеми з роумінговими профілями, каліками права адміністратора та запуском VS 2010; використання VM дозволило мені уникнути цих проблем.

Це ваш HW до нюхання?

Це зводиться до того, що ваші зображення ВМ знаходяться на сервері, а ваш віддалений в них АБО ви запускаєте їх локально. Якщо ви працюєте на сервері, то найбільша стурбованість, мабуть, викликає те, чи занадто багато VM працює на одному апараті. Зазвичай ви бажаєте багато оперативної пам’яті та мінімізувати, як часто ви перевантажуєте буфер R / W для вашого жорсткого диска. Для базової розробки LOB / SharePoint / ASP.NET я виявив, що як мінімум 8 ГБ оперативної пам’яті та подвійний конфігурація жорсткого диска на практиці спрацьовує чудово (працює i5, але я також працював із Core 2). Другий жорсткий диск робить найбільшу різницю в продуктивності.

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

Як завжди: це залежить. Наприклад, я, безумовно, не рекомендував би його для розробки в режимі реального часу або для комп'ютерних ігор.

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

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

Що стосується тестування серверного додатка, то це вже інша ситуація, я абсолютно радий, що це віртуалізує, але мені потрібна чуйність у моїх розробках.

Я використовував VM для розробки, і за великим рахунком це не дуже відрізняється від розробки на моїй власній машині. Якщо правильно керувати джерелом, відмінностей не так багато.

Основні відмінності полягають у тому, що якщо ви перебуваєте в автономному режимі з будь-якої причини, у вас немає машини для розробки, тому не так вже й здорово, якщо ви багато подорожуєте чи працюєте вдома. Крім того, я ніколи не придумав, як запустити кілька моніторів на віддаленому робочому столі, але я впевнений, що це мій збій, а не проблема з принципом. Зазвичай я використовував свій головний монітор для розробки, а другий зберігав для свого робочого столу з електронною поштою, браузерами тощо.

Додам, що якщо ви працюєте таким чином, коли вам потрібно перевірити, чи працює ваш код на різних платформах - особливо таких, як розробники інсталяторів, - тоді можливість запускати VM для різних версій ОС надзвичайно зручна.

Я використовував їх у попередній компанії. Кілька сторонніх органів контролю не співпадали з іншими версіями тієї ж компанії. Я також використав пару для тестування та налагодження інших операційних систем (XP проти Vista проти 7). Один віртуальний мав VB6 та VS2003 для старих продуктів. Так, на типовій машині розробника це може бути повільно і громіздко, але у мене було кілька запасних жорстких дисків, які я "пожертвував" і поставив віртуальні власні жорсткі диски на власні контролери накопичувачів. Я останній хлопець, який продовжував користуватися віртуалами, і над деякими помилками над ними працював лише я (через проблеми з операційною системою та компонентами).

Деякі хлопці отримали спалення, встановлюючи бета-версію програмного забезпечення, а деякі бета-версії з MS не можна було видалити, тому вони змушені були використовувати віртуальні програми, поки вони не переформатували жорсткі диски.

Для розвитку віртуальності моя порада - придбати щось із мінімальними 8 ГБ оперативної пам’яті. 16 або більше було б краще, оскільки ви знайдете віртуальну студію, що обладнана віртуальними, потребує близько 1,5 ГБ оперативної пам’яті хоста для роботи зі швидкістю вище «льодовикової». Також придбайте багато жорстких дисків, купуючи комп’ютер. Що стосується накопичувачів, які ви вибрали зі своєї запасної купи обладнання, шукайте їх принаймні в 2 рази, розмір VHD, який ви будете працювати.