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