開発マシンはVM内にある必要がありますか？
これ Rob Coneryによる投稿（スラッグに注意）は、開発環境は仮想マシン内で実行する必要があると述べています。私は彼の言っていることを見て同意する傾向がありますが、それでも少し不安を感じます。仮想化が非常に成熟しているため、VM内で運用システムを実行する場合でも速度はほとんど問題になりませんが、私が言っているように、ここで私は困っています。
開発マシンの仮想化についてどう思いますか？あなたはすでにそうしましたか？もしそうなら、道に沿って落とし穴や落とし穴はありますか？
企業環境でのVMの開発に関する私の経験では、複数のコアの仮想化には困難が伴うため、多くのエンタープライズ開発マシンに必要な種類のパフォーマンスを得るのは困難です。
コードコンパイルテストの内部ループを可能な限り高速にするには、可能な限り最高のマシンが必要です。コアの数が多いマシンでは、コンパイルとテストの実行が明らかに速く実行されます。これは、これらのアクティビティを同時に簡単に実行できるためです* 。
主流の開発OSが利用可能なコアの数を揮発的に処理できるようになるまで、仮想化ソフトウェアが何らかの「最大Nコア」の契約をインテリジェントに提供できるようになるまで、仮想化開発マシンは物理デバイスと同じ種類の生産性リターンを提供しません。
編集：これは、サーバーで実行される傾向のあるハードウェアコストを削減することがしばしば禁止されている、企業が指示するVMを使用して開発することに対する私の個人的な感情を詳述しています。ローカルで実行するVMは、プロジェクトで複数のOS用のコードを開発する必要がない限り、優れたソース管理規則を適用している限り、ほとんど不要です。
*：つまり、コンパイルステージとテストステージ内のサブタスクは、コンパイルとテストを同時に実行するのではなく、同時に実行できるということです。
私はすべてVMで個人的な開発を行っています。さまざまな環境用にいくつかのVMをセットアップしていますが、正常に動作します。
私は、Dell Studio 15ラップトップ（クワッドI7 2.8 GHz、8 GB RAM、ATIグラフィックス）を実行しており、virtualboxがインストールされたWindows 7 Ultimate 64ビットを実行しています。外付けの500GB USBドライブで実行しているすべてのVMをラップトップにベルクロで留めています。
VM 0-ベーステンプレートとしてのWin 7 64ビットクリーンインストール
VM 1-Win 7 64ビット（2 CPU、4 GB RAM、120 GB HD）、Visual Studio 2008ツールセット
VM 2-Win 7 64ビット（2 CPU、4 GB RAM、120 GB HD）、Visual Studio 2010ツールセット
VM 3-Win 7 64ビット（2 CPU、2GB RAM、120GB HD）、Eclipse付きJavaツールセット
非常に高いIOを必要とする何かをしているのでない限り、パフォーマンスは良いと感じていて、自分がラップトップを手に取って言った場合、VMの中にいることはわかりません。開発を開始します。
仮想化されたマシンでは、特定のタイプの開発は（不可能ではないにしても）はるかに難しいことを付け加えたいと思います。
私は、さまざまなUSB周辺機器（ウェブカメラ、ラベルプリンター、磁気ストライプリーダーなど）と統合するソフトウェアパッケージを提供している会社で働いています。 USBポートを仮想サーバーにマッピングする場合でも、サードパーティベンダーのデバイスドライバーに関する奇妙で不可解な問題に気づきました。
私が言ったように、私はこの状況が仮想化された開発マシンで動作しないことを保証するとは思いませんが、それはまだわかっていないため、ラボ内のさまざまな環境の物理ワークステーションを維持します。
私たちの会社では、VMを開発とテストに使用しています。VMを使用することにはいくつかの欠点がありますが、その利点はVMをはるかに上回ります。
VMの使用を開始する前は、新しい開発者用の開発マシンのセットアップに問題がありました。チームの新しい開発者の最初のタスクは、通常、自分の開発マシンをセットアップすることでした。私たちは小さな会社であり、新しいチームメンバーがマシンをセットアップするのを手伝う人材が常にいるわけではありません。これにより、さまざまな問題が発生しました。バグが自分のマシンでのみ再現可能だったり、まったく再現できなかったり、アプリケーションが適切にビルドできなかったりすることもありました。また、一部の上級開発者が複数のプロジェクトに取り組んでいるという問題もありました。常に互換性があるとは限らない作業環境で。
VMに切り替えると、すべてが変わりました。これで、VMにプロジェクトに関連するすべてのものを含む環境を設定する責任があるのは1人だけです。終了すると、すべてのチームメンバーにVMのコピーが提供されます。これにより、新しいチームメンバーごとに環境をセットアップするための時間（VMをコピーするのに1時間以上かかることはありません）。これにより、複数の作業環境で並行して作業することもできます。
VMを使用する場合の欠点：速度。 VM=のパフォーマンスヒットは目に見えます。遅いワークステーションでは、開発がほぼ不可能になる可能性があります。良いワークステーション（クアッドコア、8 + GB RAM、SSD）を使用している場合、おそらく気づく。
他の人が述べたように、それはいくつかの事柄に依存します：
- あなたの環境はどのように見えますか？
- 開発を行うための十分なアクセス権がありますか？
- あなたのハードウェアは嗅ぎまわっていますか？
環境
VMを使用すると、プロジェクトの複数のバージョン、複数のプロジェクト、または通常実行しているもの（ホストOS）とは異なるOSをターゲットにしている場合に役立ちます。多くのSharePointを実行します。リリースのさまざまなバージョンで異なるマシンを実行して実行できることは、別のマシンを起動するだけでGAC /データベースの状態を把握できるので役立ちます。* nixアプリケーションをターゲットにする必要がある場合も環境がありますが、Windowsマシンがあれば、VMで開発を行うことができます（通常、私は自宅でRubyを学んでいます）。 NET dev work）私は一般的に、同じバージョンのIISでアプリが最終的に実行されるというASP.NET開発テスト/開発を行うときに推奨します（この同じ合理性は他のサーバーターゲット環境に適用されます） 。OSのバージョンによっては、小さいが重要な違いがある場合があります。これは、IIS/OSの特定のバージョンにコーディングする必要があることを意味するわけではありません。正直に言うと、ローカルマシンだけでなく、展開する場所でも機能する必要があります。
VMを使用すると（使用するソフトウェアに応じて）、現在のマシンの状態のスナップショットを取得したり、クローンを作成したりできます。これは何かをプロトタイピングする際に非常に貴重な場合があり、GAC /レジストリなどで何が起こっているかについて心配する必要はありません。クライアントデモを事前にセットアップするのに非常に役立つこともわかりました。デモ環境がVMにあったため、クライアントが完了したことをクライアントに示すまで、引き続き作業を続けることができました。 machine。
十分な権利
これは一般に、アクセス権のポリシーのセットがかなり厳格な会社で働く人々に適用されます。マシン上で自由な管理を行うことができない場合、これはVMで作業する良い機会です。通常、権限はホストOSのロックダウンについてのみ懸念されており、ゲストは広く開くことができます（権限に関して）。ローミングプロファイル、不自由な管理者権限、およびVS 2010の実行に関する奇妙な問題に遭遇しました。 VMを使用することで、これらの問題を回避することができました。
あなたのハードウェアは嗅ぎまわっていますか？
これは、VMイメージがサーバー上にあり、リモートがそれらにある[〜＃〜]または[〜＃〜]ローカルで実行することになります。サーバー上で実行している場合、最大の懸念はおそらく同じハードウェア上で実行されているVMが多すぎることでしょう。ローカルでは、基本的にRAMハードドライブ用のR/Wバッファー。基本的なLOB/SharePoint/ASP.NET開発では、8 GB以上のRAMおよびデュアルハードドライブ構成が練習（i5を実行していますが、Core 2でも作業しました。）2番目のハードドライブは、パフォーマンスに最大の違いをもたらします。
注：これを裏付ける統計情報はありませんが、Virtual PCはVMWareとVirtual Boxの両方に比べてパフォーマンスが低い傾向があることに気付きました。 Hyper-Vを使用していないため、話せません。 Virtual PCを使用して（VMを使用する最初の試みとして）、開発者が仮想化ソフトウェアの使用に夢中になっているとしても、私は驚かないでしょう。
いつものように：状況によって異なります。たとえば、リアルタイムやコンピュータゲーム関連の開発には絶対にお勧めしません。
私の個人的な経験：2009年後半のiMacを使用していて、Visual Studio 2010は基本的にParallels Desktopで使用できないことがわかりました。コードエディターでキーを押すと、登録に数秒しかかかりません。 SQL Server Management StudioのWindowsは、フォーカスをぼかして、明らかにランダムにフォーカスを切り替えます。私は結局、ブートキャンプに行きました。
もちろん、私の新しいプロジェクトには、Windowsベースの構成ツールを備えたiOSアプリケーションが含まれるため、仮想化を使用しないのは大変なことかもしれませんが、デスクトップ仮想化テクノロジーが昨年ほど十分に進んでいない場合は、おそらくここに別のデスクトップをセットアップします。
サーバーアプリケーションのテストに関しては、それは別の状況ですが、それを仮想化して完全に満足していますが、開発アプリケーションでは応答性が必要です。
前の会社で使っていました。いくつかのサードパーティコントロールは、同じ会社の他のバージョンとうまく共存しませんでした。また、他のオペレーティングシステム（XPとVistaと7）のテストとデバッグにもいくつか使用しました。 1つの仮想には、古い製品用のVB6とVS2003がありました。はい、典型的な開発者のマシンでは遅くて扱いにくい場合がありますが、「寄付」してスペアのハードドライブをいくつか用意し、仮想マシンを独自のドライブコントローラ上の独自のハードドライブに配置しました。私は仮想マシンを使い続ける最後の男であり、一部のバグについては、（オペレーティングシステムとコンポーネントの問題により）私だけが仮想マシンに取り組むことができました。
ベータ版ソフトウェアをインストールすると、やけどしたり、MSからのベータ版を削除できなかったりしたため、ハードドライブを再フォーマットするまで仮想マシンを使用せざるを得ませんでした。
仮想環境で開発する場合、私のアドバイスは、RAMが8GB以上あるものを入手することです。ホストの1.5 GB程度の仮想スタジオに仮想のニーズがあるRAM「氷河」以上の速度で実行するには、16以上のほうがよいでしょう。また、多くのハードドライブを入手してください。コンピューターを購入するときは、予備のハードウェアの山から取り出すドライブについて、実行するVHDのサイズの2倍以上のドライブを探します。
私は開発にVMを使用しましたが、大体それは自分のマシンで開発するのと大差ありません。ソース管理を適切に使用している場合、多くの違いはありません。
主な違いは、何らかの理由でオフラインになっている場合、開発マシンを利用できないため、旅行や自宅での作業が多い場合はそれほど大きくありません。また、リモートデスクトップで複数のモニターを実行する方法もわかりませんでしたが、それは原則の問題ではなく、私の失敗です。私は通常、メインモニターを開発に使用し、2番目のモニターをデスクトップマシン用に維持し、電子メール、ブラウザーなどを実行していました。
特に、インストーラーの開発など、さまざまなプラットフォームでコードが動作することを確認する必要がある場合は、さまざまなOSバージョンのVMを実行できるので非常に便利です。