仮想マシンを使用した開発に関する考え方[終了]

私はスタートアップの開発リーダーとして働き、開発にVMを使用することを提案しました。各開発者がテスト/開発用のVMを備えたデスクトップを持っているということではなく、すべてのVMが管理され、ローカルまたはリモートからでもマイクロPC（ChromeOSの誰か）で開発者が作業するサーバーラックがあることを意味しますコンピューター。

私にとっての利点は、非常にスケーラブルで、長期的には安価で、管理しやすく、ハードウェアを最大限に活用できることです。短所については、セットアップをセットアップ/メンテナンスする人が必要になる以外、特定のショートッパーについて考えることはできません。

私はあなたの何人かがあなたの職場で同様の設定をして、あなたの意見に重みをつけることができることを望んでいました。ありがとう。

開発予算の一部として、何を節約したいですか？あなたはイプシロンを心配しているように思えます。開発者のマシンのコストは、開発者をスタッフにとどめるための総コストの5％未満です。したがって、唯一の重要な質問は「開発者の時間を節約できますか？」です。開発ソフトウェアのインストールとアップグレードに時間を費やす必要がなければ、可能性があります。または、ネットワークがダウンした場合、サーバーがダウンした場合、またはおそらく、ネット全体の応答性が最も不足していない場合、時間がかかります。最近の開発は、キーストロークごとのIDEとの対話、または少なくとも非常にインテリジェントなエディターに依存しています。その相互作用を数十ミリ秒でも遅らせると、開発者の生産性が損なわれます。開発者がこの新しい作業方法を学ぶためのコストもあります。

これらはVMに対する異論ではなく、リモート開発に対する潜在的な異論です。

私はあなたがペニーワイズでパウンドバカだと思います。

まず第一に、マシンのコストは開発者のコ​​ストと比較してささいなものです。マシンのコストを最小化するのではなく、生産性を最大化するように作業する必要があります。

第二に、待ち時間（帯域幅ではない）が多くのプログラミングタスク、特にテキスト編集の鍵となります。開発者用のマシンで節約するドル/ポンド/ユーロごとに、ネットワークのアップグレードに少なくとも10を費やして、生産性をかなり維持します。どこかのゴミ箱で見つけたPentium IIIを使ってください。

また、ターゲットエンドユーザーに期待される環境に少なくとも合理的に近い環境を開発者に使用させることには、大きなメリットがあると思います。仕様などの公式のパフォーマンス目標に関係なく、ほとんどのプログラマーは、テスト時にコードがどのように「感じる」かにかなり基づいています。エンドユーザーの環境とはまったく異なる環境を使用している場合、重大な問題を完全に見落としながら、些細なことに時間を浪費する可能性があります。

均一な環境がサポートなどの観点から見れば魅力的であるため、一般的に開発者のマシンの可能な限り多様性を奨励する必要があります。開発者がとにかく多くのサポートを必要とすることはほとんどなく、異なるグラフィックチップ、CPU、ネットワークアダプターなどで失敗するコードがある場合、最小限の投資を返済する以上のことをすぐに知ることができます。

結論：仮想サーバー環境で（少なくとも主に）使用することを意図したコードを作成する場合、開発者に提供する必要があります。とにかくテストのためにそれをやっているなら、それは開発のためにも同様に理にかなっています（しかし必ずしもそうではありません）。同様に、とにかくひどく過剰に指定されたサーバーとネットワークが必要な（または少なくとも持っている）場合、既に利用可能なものを使用することでそれを利用することは理にかなっているかもしれません。

しかし、ほとんどの典型的な状況では、これは解決するよりも多くの問題を引き起こす可能性が高いように思えます。

これは過去の私のアイデアの1つでした。必要なすべてのソフトウェアを備えた高性能サーバーと、リモートデスクトップ経由でサーバーに接続するためだけに使用される多数の低パフォーマンスデスクトップPCを所有することです。

利点は次のとおりです。

• 確実なバックアップ。一部の開発者は、デスクトップコンピューターを定期的にバックアップしたくない場合があります。そのため、中央のソリューションの方が信頼性が高く、
• すべての開発者がどこからでも作業できる可能性。これにより、社内のどのPCからでも作業することも意味します。朝、開発者が静かな労働条件を望んでいるとしましょう。彼は自分の部屋に行き、そこで働いています。それから彼はペアプログラミングをしたい、あるいはもっと社会的な環境で働きたいと思っています。彼はデスクトップPCをシャットダウンし、10台のコンピューターがある別の部屋に行き、そこから接続します。いいえ、「すべてのアプリを再度リロードする必要があります」。

まあ、それにはいくつかの深刻な問題があり、今後数年間はこのようなものを決して使用しないと思います。

• リモートソリューションの特異性。一度に複数のコンピューター画面を使用して遠くで作業するのはどうですか？つまり、簡単ですか？明らかですか？遠くで作業するときに、毎日使用するショートカットは有効になっていますか？私はちょっと確信が持てません。現在実行中のプログラムのリストを表示するためにCtrl + Shift + Escを押すとどうなりますか？ああ、それは機能しないので、今は別の方法でそれを覚えている必要があります。

• パフォーマンスヒット。パフォーマンスがまったく低下しないかどうかはわかりません。また、遅いコンピューターを使用するプログラマーは不幸なプログラマーであることを忘れないでください。そして、プログラマーを安っぽい状態に不満にさせる会社は、高品質のソフトウェアを決して生産しません。

• 災害の影響が大きい。ソリューションを冗長サーバーでホストしますか？会社に冗長ネットワークがありますか？ルーターがダウンし、冗長ではないとしましょう。これは、すべての開発者が作業できなくなったことを意味します。まったく。ソフトウェアがローカルにインストールされていないためです。彼らはソースコードさえ持っていないからです：それはサーバー上にあります。そのため、誰もが停止し、ルーターが交換されるのを待つためだけに1時間ごとにすべての人に支払います。

• ハードウェアのコスト。サーバーが1つだけの場合、どれくらいの費用がかかりますか？たとえば、20人の開発者がいる場合、サーバー上の64 GBのRAMで十分ですか？よくわからない。2つのCPUを搭載したクアッドコアソリューションで十分ですか？繰り返しますが、いくつか疑問があります。そうでなければ、あなたはどう思いますか？ある種のクラウド？または、複数のサーバーで動作するスケーラブルなソリューションをお持ちですか？マシンごとにWindows Server（Windowsを使用している場合）のコストを支払う準備はできていますか？

• 電気代。完全にリモートで作業している場合、ローカルで作業している場合とほぼ同じ量の電力をサーバー側に費やし、さらにローカルマシンとネットワークによって浪費されている電力量を費やしています。

• ライセンス。私はそれを利益と問題のどちらにすべきかはわかりませんが、この場合のソフトウェアライセンスのコストははるかに高くなると思います。

繰り返しになりますが、管理、サポート、展開、保守のすべてのコストについて考えてください。このようなカスタムソリューションを使用すると、何かが失敗するたびにすべての開発者がNOPを実行し、作業を続行できるのを待つことをカウントせずに、簡単に巨大になる可能性があります。

オンデマンドのAmazon ec2インスタンスを開発者のマシンとして使用します。これはコストとは関係ありません。いくつかのプロジェクトに取り組んでいる「開発者のプール」があり、プロジェクト間をすばやく移動する能力が必要です。

一般に、VMは初期セットアップ時間を節約します。しかし、長期的には、生産性の低下により時間を無駄にします。開発者のコ​​ストは機械のコストよりもはるかに大きいため、コストは軸ではありません。

生産性コストには、VMイメージの起動にかかる時間（数分）、応答性の低さ、およびリソース/メモリの制約が含まれます。これらは最初はそれほどではありませんが、時間が経つと迷惑になります。

プロジェクトの1つで、コードをリファクタリングして、初期セットアップを「コードをダウンロードしてmavenを実行する」ように簡素化しました。この変更により、新しい開発者がプロ​​ジェクトの作業を開始するのは簡単でしたが、現在では誰もAmazon VMイメージを使用していません。他のプロジェクトでもこれをエミュレートしようとしていますが、時間がかかります。それまでは、ec2イメージがあります。

ここでは非常に注意してください。私は最近、IT部門の全員が基本的に同じ理由でVMを使用している顧客に導入されました。デスクにローエンドPCを配置し、VMにリモート接続して通常の作業を行えるようにするためです。

そこの経験はきれいではありませんでした。少なくとも週に1回は、さまざまな理由で非常に低速で実行されていました。一般的に、チームの誰かがプロセッサを集中的に使用するSSISパッケージのセットを実行していることがわかります。彼らは最終的に私たちの何人かを別のサーバーに移動しました。

あなたがそれをやろうと思うなら、サーバーのパワー、処理のニーズ、何台のマシンにサービスを提供するかなどに十分な注意を払ってください。お金を節約できますが、正しく実装されていない場合は、頭痛の。

注意してください：これはVMアーキテクチャのフレームではありません-それを探している人々への警告です-実装する前にアヒルが一列に並んでいることを確認してください。

仮想マシンでの開発は非常にうまく機能しますが、適切に行われた場合のみです。

• VMを使用すると、開発者ごとに1台ではなく、チーム全体で1台のコンピューターを使用できるからといって、それが良いアイデアであるとは限りません
• 再起動には、24時間の応答時間でサポートチケットを開く必要はありません。
• 開発VMは、開発者から5000マイル離れたデータセンターには配置しないでください。
• VMは開発者によって管理されているためサポートされていない場合がありますが、ソース管理などのネットワークサービスにアクセスできないという意味ではありません。
• リモートデスクトップ接続は標準であり、入力された引用符をウムラウトに変換するカスタム「高セキュリティ」アプレットではありません。
• 新しいVMの取得または既存のVMの再構築には、数週間ではなく数分かかります

私はこれらの問題をすべて見てきましたが、それらと一緒に仕事をするのは特に好きではありません。ただし、自宅でVMをセットアップすることもできます。これは、ローカルインストールよりも高速に実行され、異なるプロジェクトの個別の環境や、環境が不安定になった場合の高速な再構築などを可能にします。

私はVMを使用していますが、メインプロジェクトにはお勧めしません。

開発にVMを使用する理由は、レガシープロジェクト（VB6、.NET 1.1など）をサポートする必要があり、VS2003 / 2005 / vb6 / etcをインストールすることでメインマシンを汚したくないためです。 ...うまくいきましたが、あちこちで断続的な問題があります。

さらに、相互作用が遅くなり、VMの起動/シャットダウンに時間がかかり、ネイティブUI効果（Win7のAeroなど）がなくなります...

あなたが無駄にするお金の面で節約しようとしているものは何でも、あなたがあなたのチームに課そうとしている手間によってもっと多くなります。さらに、ここで誰かが言ったように、マルチスクリーンのサポートはありません。可能な限り生産性を高めるには、少なくとも3つの画面が必要です。

開発の一番のルールは、開発者を満足させることです。リモートVMではほとんど不可能に近いことがわかります。マルチモニターのサポートはむらがあり、ネットワークの遅延とブリップは面倒であり、コスト削減は一般に最小限です。

確かにVMで作業しますが、ローカルVMも許可し、物理コンピューターも途方もなく高速な獣にします。

私は100％在宅勤務し、個人用ISPとVPNの間では-高い信頼性にもかかわらず-オフラインモードで作業できなかった場合に私を怒らせる十分なブリップを持っています。

私は通常、さまざまなVirtualBoxイメージをスピンアップし、それらから作業します。新しいものがローカルに必要な場合でも、数百MBをネットワーク経由でコピーするのは時間のかかる作業ではありません。

私のチームは「低速PC /高速VMサーバー」構成を正常に実装しました。20人の開発者からなるチームの場合、8プロセッサ、256 GB RAMサーバーをファイバー経由で非常に高速なSANに接続しました。高価でしたが、各開発者に同様のパフォーマンスのワークステーションを提供するよりも安価でした。小規模なチーム（4人の開発者）にとって、規模の経済が機能し、実際に何かを節約できるかどうかはわかりません。

開発用の仮想マシンは一見の価値がありますが、財務コストが間違った理由です。

これについては、NAntとCruiseControl.netを使用したMarc HolmesのExpert .NET Deliveryで簡単に説明しました。要するに、VMで開発するための議論は、作業のあらゆる側面が開発者の特定の構成に依存することを妨げるということです。すべてのプロジェクトの開始時にVMを破棄します。実際に特定のツールが必要な場合を除いて、それは動き回っていません。これにより、あなたが行った変更があなた以外のマシンで破壊される可能性が最小限に抑えられます。開発者は自分のおもちゃを奪うことで泣き叫ぶかもしれませんが、最終的には、ツールへの依存は弱点であり、クリーンな環境では直感的にできないことは臭いです。

上記の議論を必ずしも信じているわけではないことに注意してください。私はそれらを理解し、ある程度はそれらと一致しますが、議論を生み出すために議論のためにそれらを作成しています。

潜在的な欠点

• VMホストがダウンした場合...あなたはすべてうんざりしています。20人のチームが「GAH！HOST NOT RESPONDING !?」と叫んだことがある場合。一斉に...それは楽しいものではありません。
• スナップショットを許可している場合...それらはすぐにリソースを使い果たします。20人* 10〜20個のスナップショットはそれぞれ、大量のHDDスペースを作成します（または、少なくとも問題を引き起こすには十分です）。
• ホストでリソースの使用に問題が発生した場合も、誰もが痛みを経験します。

IME、それは良い解決策であり、動作しますが、ホスト上にまともなハードウェアが必要です。

これは、ジョエルテストの最も重要な基準の1つに失敗します。

すべての開発者が、少なくともi3以上のラップトップまたはデスクトップに、可能な限り多くのRAMを搭載していることを確認します。

8GBは私が目指しているものです。

生産性が向上し、高価なサーバーの保守ではなく、開発およびテスト用にローカルマシンでVirtual Boxを実際に実行できます。彼らは、Virtual Boxのインストールのクレイジーなものをスナップショットし、さまざまなブラウザーとインストーラーとすべてをテストし、「IT」サービスに連絡する必要なく、すぐに既知の適切な構成に戻ることができます。

開発者には、ローカルマシンで最も多くのRAMおよびルート権限を持つ、会社で最速のマシンが必要です。物語の終わり。

ローカルVM（ローカルPC上で実行）とリモートVMの両方で、開発前にVMに取り組んできました。ローカルのものはリモートのものよりもはるかに優れていました。

RDPで接続していたリモートVMには、キーストロークとアクションの間にわずかな遅れがありました。このような状況下で短期間で開発することは可能ですが、日中は非常にイライラします。

LinuxマシンでFlash Builderを実行する必要があるため、VMWareのローカルVMで開発しました。十分なメモリがある限り、非常に満足していました。

リモートマシンに対してこれを行いますが、かなりうまく機能します。ほとんどの場合、自宅で仕事をすることはほとんどありません（通常、あちこちで緊急修正が必要な場合のみ）。かなりローエンドのネットブックを使用し、オフィスの高速デスクトップマシンにリモート接続します。これらは間違いなくまだ遅いですが（おそらくネットワークによって何よりも制限されています）、時々短いタスクで動作します。しかし、これはフルタイムの作業馬にとっては実際に受け入れられないでしょう。なぜなら、VMは頻繁にわずかな遅延を引き起こし、それが最高のハードウェアであるIMHOでさえ少し気を散らすからです。

私の最後の仕事で、私たちはまさにそれをしました。

すべての開発者がアカウントを持っているWindowsターミナルサーバーを使用しました。開発者はまだ通常のPCを使用していました（既に存在していたため）が、PCはRDPクライアントのみを実行していました。

Java開発を行ったため、ソフトウェアはJavaコンパイラ+ IDE（主にEclipse）に加えて、Webブラウザ、DBクエリツール、バージョン管理クライアント、場合によってはoffice sw（この場合はOpenOffice.org）を使用しました。

本当の問題は発生せず、パフォーマンスはかなりまともでした。

唯一の問題は、1つのシステムを共有しているため、状況によっては他の人を混乱させないように注意する必要があることです。ITオペレーションが大規模なファイルコピーを実行するか、サーバーでバックアップを実行する必要がある場合、すべてのユーザーのパフォーマンスが低下しました。これを特定して解決したとき（優先度の低いコピー、または夜間）、すべてがうまく機能しました。

そのため、注意点は次のとおりです。できるだけ早くパフォーマンスを評価し、それに応じてハードウェアとその使用を計画します。

TL; DR：私は複数の仕事でそれをやりましたが、今はそれを好みます。

コストは、注目すべき間違った理由です。ここにいくつかのより良いものがあります。

理由

• さまざまな環境（開発、テスト、実稼働）でのプラットフォームの一貫性。
  • 理由：さまざまな環境のプラットフォームの違いによる欠陥ベクトル、欠陥を完全に排除します。
• 開発VMで最初に発生するアップグレードなどのシステム変更、検証、テストへのロールアップ、検証、実稼働へのロールを許可します。開発（およびテスト）vmsを使用すると、すべてがはるかに簡単になります。
  • 理由：コントロール。スナップショットを作成し、ロールバックし、デルタを特定し、1つのサーバーで変更を行い、単にvmを複製することで成功を伝達できます。
• 開発対象のシステムは、セキュリティで保護されたネットワークでのみ利用できる場合があります。または、ソフトウェアを実行するサーバーのアクセスが制限されているか、ネットワークの特性が異なる場合があります。
  • 理由：開発VMは、ロックダウンされたシステムまたはサービスにアクセスできるVLAN上に配置できます。あるいは、開発サーバーがテストおよび実稼働サーバーと同じ制限されたアクセスを持っている場合、利用できないネットワーク特性またはアクセスに関する要件を誤ってコーディングすることはありません。

課題

ゲートウェイまたはジャンプサーバーを経由する必要がある場合は特に、リモート開発が最大の課題です。特に、開発者が十分な知識を持たない場合（システムエンジニアリングの知識、ネットワークの知識などがある場合）、困難になります。

リモート開発には多くのバリエーションがありますが、通常は2つの主な違いに要約されます。

• 開発環境をリモート環境で実行し、RDPクライアント、リモートX11クライアントなどのプロトコルを使用します。
• 開発ツールをローカルで実行し、プロトコルを使用して透過的に同期またはリモートサーバー上で実行します。多くの場合、トランスポート層としてsshを使用します。

道具

リモート開発を支援するツールがあり、それを促進するIDEがあります。リモート開発が可能な範囲を調査する必要があります。多くの場合、コードが開発されている同じサーバーで実行する必要があります。ただし、他のツールがあります。

• セキュアシェル：ほとんどの成功したリモート開発セットアップでは、パスワードなしのログイン（キー認証を使用）、透過的なマルチホップ（ジャンプサーバーの問題を解決）、および応答時間を改善する他の構成オプションを使用して、sshを大幅に使用します。注：私は、SSHのOpenSSH以外の実装を使用するときに常に問題を抱えてきました。
• GNU Screen / TMUX：端末マルチプレクサ。Screenはそれらの祖父であり、まだ強くなっていますが、ほとんどの人はTMUXで切り替えを開始（または開始）していると思います。
• Vim / Emacs：古いガードですが、どちらもさまざまな方法でのリモート開発に最適です。Vimなので、必要なのはシェルだけですが、Emacsはローカルで実行し、リモート開発にTRAMPを使用できます。

少し異なる方法で-あなたはあなたのマネージャー/会計士にこれらの遅いマシンを使うコストを強調するスプレッドシートを与えましたか？VMソリューション（適切に行われ、簡単でない限り）が開発者、ひいては会社を同じ船に乗せる可能性があることを指摘します。

これは、VMwareインストールに対する管理力に依存します。優先度の低いサブプールに入れられると、他のサブプールのアクティビティに応じてマシンが遅くなります。

ハードウェアは安く、プログラマーは高価です。

遅い開発マシンを提供することでプログラマにイライラさせて欲しいのはなぜですか？ハードウェアをアップグレードするコストは、それらが得るパフォーマンスの利点と比べると劣ります。

より良いマシンを求めてください。少なくとも4 GBのRAMを要求してください。別の2GBタブレットを追加すると、1週間以内に回収されます。

デュアルスクリーンのサポートの欠如は、常に取引のキラーでした。単一の画面で重要な開発作業を行うことは想像できません。

今、彼らはテスト/展開/いじくりのためにロックしているので、スタックから落ちるべきではないと思います。

RAID10に50個のSSDディスクを備えたメインフレームがあり、そのメインフレームで3〜4台のマシンのみを使用している場合、動作する可能性があります。

それ以外の場合、それらはラグがあり、本当にラグがあります（ただし、まれにスナップショットがそれを相殺する場合があります）。

オフィスにはまともなデスクトップマシンがあり、画面共有を使用してVPN経由でラップトップから接続できます。

それは時間外のサポートインシデントと時折の強制リモートワーキングで機能します。2台目のマシンで完全に構成された環境を維持したり、WANを介したデータセンターへの低遅延が必要なものを開発したりするよりも、確かに優れています。

ただし、その方法で長期間作業するのはイライラします。私が家に居続けていたことが何であれ邪魔にならないようになったら、私はその日の後半に仕事に駆け込むことがありました。

レイテンシーとスクリーンリアルネスが私にとっての2つのキラーです。

リモートVMソリューションを使用したいとは思わない。ネットワーク接続はボトルネックになり、高速接続でもフラストレーションを引き起こすのに十分な場合があります。この手法から、ローカル開発環境の使用に移行しています。

私たちはiMacで開発していますが、これは本当に素晴らしいことですが、Webアプリケーションは実稼働環境のLinux環境で実行されています。これに伴う問題は、最終的に、Linuxでのみ発生する問題に遭遇し、トラブルシューティングが困難になる可能性があることです。そこで仮想マシンの力が発揮されます。しかし、100％の時間でVMを使用するというアイデアすら嫌いです。

私は最近、Vagrant（http://vagrantup.com/docs/getting-started/why.html）とVirtualBoxでの作業を非常に簡単にするためのChefについて学びました。Vagrantは、必要なときにVMを簡単に起動し、不要なときにVMを破棄する機能を提供します。だから、Macを使ってすべての開発を行うことができました。次に、コードをテストする準備ができたら、VMを起動してテストし、必要な間だけ保持します。Vagrantでは、同僚とVMを簡単に共有できるため、同じ環境で作業していることを確認できます。

Vagrantをチェックアウトすることをお勧めします。そうすれば、VMでの開発と作業に関して、少なくとも利用可能なオプションを認識できます。

私は5台のマシンに関するレガシープロジェクトに取り組んでおり、それぞれが計算パイプラインで役割を果たしています（マシン1はマシン2にリクエストを送信し、ehichはマシン3にリクエストを送信します）。ただし、仮想マシンでの設定の展開により、膨大な時間を節約できました。1.開発者が設計にテストを組み込む時間がなかったため、システムは議論の余地がありませんでした。2.あまりにも多くのセットアップがデプロイされており、それらをグループに配置するのに時間を費やす必要がありました。

私は一度に多くのプロジェクトに取り組んでいるので、今それを使用しています。私が今抱えている主な問題は次のとおりです。1. VMは、メンテナンスに時間がかかりすぎています。2. VMは実行に膨大な量のメモリを消費している

この種のVMを使用すると、VMを使用して秩序を持たせることが困難になります。電子メールとテキストを1台のメインマシンに保持し、専用のVMで開発します。コストをかけずにあなたの人生をきれいに保ちます。

他の人が述べたように、それは実際にVMデスクトップで解決しようとしている問題に依存し、その問題を解決するメリットとVM環境に生じるデメリットを比較検討します。

私たちは、すべてのオンショア開発者が従来の物理マシンを使用し、オフショア開発者（現在は小さなアウトソーシング会社と協力している）が仮想デスクトップを使用するハイブリッド環境に移行しています。リモートデスクトップで解決しようとしている問題は、セキュリティとパフォーマンスに関連しています。仮想環境は、セキュリティの観点からより優れた制御を提供します。パフォーマンスのために、完全なソースコードではなく「変更されたピクセル」のみを転送し、プロキシサーバーなどを実装する必要があります。

これが正しい方法であるかどうかはまだわかりませんが、私たちが向かっているところです。