windows - 開発者は、ワークステーションソフトウェア/開発スタックの更新を恐れるべきですか?

Question

私が発見したように、多くの開発者は更新 (自動または手動) を避けています。これは、自分が理解していないマシンに変更が加えられる可能性があることや、開発中のソフトウェアが何らかの理由で失敗する可能性があることを恐れているためです。 .

戦略 A.) 可能な限りシステムを現状のままにしておく。

個人的には、自分のシステム (OS とアプリ) をできるだけ「最新」にするのが好きです。

戦略 B.) 常に最新

あなたはどのタイプの開発者ですか？なぜ？

score 8 · Accepted Answer

B.間違いなく。

更新の系統が不確かなプラットフォーム (例: The Real World) 向けに開発している場合、仮想マシンは重要な武器ですが、リリース時にできるだけ最新の状態にすることが重要です。

問題の原因となっている可能性のあるパッチ履歴を推測するよりも (または、少なくとも問題を除外できるようにするために)、ユーザーに「更新を実行してください」と伝える方がはるかに簡単です。

純粋に内部ユーザー向けに開発している場合は、質問は 1 つだけです。

会社の更新スケジュールはありますか？
- はい: 次に、ソフトウェアが本番環境と今後の予定の両方で実行されることを確認する必要があります
- いいえ：おそらくそれを修正するのが最善です。

score 3 · Accepted Answer

いいえ。

これが、神が仮想マシンを発明した理由です。

ただし、OS X プログラマーの場合は、OS のハードウェアベースのコピー保護のため、ちょっと残念です (Apple に恵まれたハードウェアで実行する必要があります)。

score 3 · Accepted Answer

オペレーティングシステムを可能な限り最新の状態に保ち、できればシステム管理者にパッチをテストしてもらってから、会社全体にパッチをリリースしてください。

開発環境のサービスパックをかなり迅速に適用しますが、最初に VM をチェックして、ビルドがまだ機能するかどうかを確認してから、開発マシンをアップグレードする前にスモークテストのためにそのビルドを QA に渡します。

真のメリットが見られる場合は、開発環境 (および/またはプラットフォーム、たとえば Java 5 から Java 6 へのアップグレード) を変更しますが、予算を考慮した明示的なタスクとして許可します。理想的には、開発者が最大限に活用できるように、開発者を最新の状態に保つためにプロジェクトの時間を予算に入れます。リリースの近くではこれを行わないでください。

score 2 · Accepted Answer

作成中のソフトウェアのターゲットマシンが開発マシンと同じであることはめったにありません。したがって、更新せずにマシンをすべて静的に保つことはあまり意味がありません。

さて、ターゲットマシン..それは別の話です。絶対に必要でない限り、変更は必要ありません。

score 1 · Accepted Answer

1

噛まれたら二度恥ずかしがる。

于 2008-12-30T08:24:14.913 に答える

score 1 · Accepted Answer

これの良い例は、先日私の職場で起こりました。IT チームは開発サーバーに更新を展開しましたが、最初は無害に見えました。マシンには無人ログインがあり、24 時間年中無休でログインしたままにしておく必要がありました。Windows の更新プログラム (KB を引き出す必要があります) は、実際にはそのタイプのユーザーを自動的にログアウトさせます。私たちがサーバー上で実行するアプリケーションを実行するには、有人ログインが必要です (はい、ばかげたことですが、それは別の話です)。突然、システムがおかしくなり始め、使用されているソフトウェアシステムの一部が機能していないという苦情が寄せられました。

問題を追跡し、管理者ユーザーを再度ログインさせましたが、その後 Windows が原因で約 3 回ログアウトするまで、何が起こっているのかを本当に理解することはできませんでした。幸い大きな被害はありませんでしたが、残業を余儀なくされた人もいました。

アップデートは、展開する前に OS に与える可能性のある環境への影響を確認する必要があり、その後もテストする必要があります。

score 1 · Accepted Answer

B、セキュリティ上の理由から。

ただし、アプリ内の機能を壊すことをどの程度気にする必要があるかは、行っている開発の種類によって異なります。通常のケースは、開発マシンのように構成されているユーザーマシンはほとんどないため、別のターゲットのクロスコンパイルに似ています。

Web アプリケーションの場合、「プラットフォーム」はブラウザと、サーバー側で使用するものです。私にとっては、Ruby、Rails、プラグインに加えて apache/mysql などです。クライアント側を制御することはできません。サーバー側には、少なくともセキュリティパッチを適用したいと考えています(余談ですが、サーバー側の開発者には、機能変更とは別のサイクルでセキュリティパッチをリリースしてください!)。. しかし、OS の更新は、通常、私が使用している開発サーバースタックにはほとんど影響を与えません。いずれにせよ、私の展開環境では別の OS を使用しています (私は OSX と Ubuntu で開発し、Debian と Solaris に展開しています)。

デスクトップアプリケーションの場合は、プラットフォームとの統合度と、ターゲット環境でそれを制御できるかどうかによって異なります。私は一般的に Java を使用しているので、OS ではなくプラットフォームであると考えていますが、さまざまな OS フレーバーと Java バージョンでテストする必要があります。OS へのパッチによって Java が壊れる場合、それは別の問題です。

OS に非常に緊密に結合されている場合、更新の依存関係をテストするのは非常に難しく、仮想マシンやスナップショットなどを多用しないとほとんど不可能です。また、OS の変更に関して脆弱な場合、アプリはおそらくいずれにせよ、ターゲットマシンのソフトウェアロードまたは構成が異なる場合は失敗します。これもテストが非常に困難です。

score 0 · Accepted Answer

注目すべき点がいくつかあります（私はlinux / unixの経験から書いていますが、他のオペレーティングシステムにも当てはまるはずです）。

壊れた更新に注意してください。壊れた更新が発生し、他の人に破損を被らせることが賢明です。cライブラリ（通常含まれるOSインターフェイスを含む）、リンカ、コンパイラなどのコアコンポーネントに特に注意してください。
製品のコンポーネントライブラリの更新は慎重に行う必要があります（または最初にテストシステム/ vmで）。通常、Cライブラリなどの使用頻度の高いライブラリは問題ありませんが、使用頻度の低いライブラリには、APIブレークやAPIのセマンティック変更が含まれている場合があります。
その環境に寛容になるようにソフトウェアを作成します。
- できれば、さまざまな異なる構成のシステムを使用して書き込みます
- 環境の属性を想定せずに書く
- 何かが壊れた場合は、必要に応じてシステムを更新し、根本的な原因を突き止めてそれを排除します。
- 剛性のコストに加えて、複雑なシステム依存のビルドシステム（単純な（または自動化された）システムよりもはるかに多くのメンテナンスが必要）には特に注意してください。

私は、UNIXライクなシステムには、Windowsシステムよりも独立しているという伝統があることを知っています。それは、OSの仮定の独立性のエンジニアリングの健全性を変えるものではありません。したがって、新しい更新が利用可能になったらすぐに更新することをお勧めします（通常は初日ではありません）が、実際に問題が発生した場合に簡単にロールバックできるようにします。プロジェクトが失敗した場合、ほとんどの開発者はロールバックし、小さなチームがプロジェクトの修正に取り組みます。

score 0 · Accepted Answer

OS: Up to Date (私は熱狂的ではありませんが)。

小さなアプリケーション: それほど多くはありません。私は更新を警戒しており、私にとって付加価値がない限りアップグレードしません.

score 0 · Accepted Answer

更新を行いますが、開発サイクルの重要な時期ではありません。可能な限り安定していることが知られており、アップデートをリリースする頻度が控えめであることが知られている OS ディストリビューションを使用してください。

開発者がチェックインしようとするときはいつでもコードをテストするように強制します。アップグレードを行う前に、すべてのテストに合格することを確認してください。これにより、彼らは何が壊れているかについてある程度のアイデアを得ることができます。

score 0 · Accepted Answer

古いことわざがあります。「実行中のシステムを変更しないでください」。惨めな更新に関するホラーストーリーは山ほどあると思います。私は私の経験から言うことができます。ソフトウェアを「うまくハングアップした」コンポーネントに基づいている場合、それらが壊れる可能性は、急速な変化のペースの下にあるものよりもはるかに少なくなります。いくつかの例: 私たちの IDE は Win API に基づいており、Windows 3.1 (それが開発された場所) 以降ほとんど変更されずに動作します。長年にわたっていくつかの機能を追加したため、パッケージを実行するには少なくとも Windows 2000 が必要であるに違いありません。しかし、Windwos NT、Windows 2000、Windows 2003、Windows XP、Windows 2003-64、および「非常に光沢のある」Vista を介した XP からの多くの OS アップデートに耐えられることを保証できます。

一方で、Linux の gtk ベースのポートを最新の状態に保つことができませんでした。API の変更は極端です。ですから、これが私がオープンソースの支持者について最も嫌いな点です。現実にとどまるために、何度も何度も作業をやり直す必要があります。

バージョン 1.1.6 から 2.2 への非常に小さな Rails アプリケーションの更新に少なくとも 1 週間はかかった別の例です。（そしてそれはわずか2年で）。私はそれが最悪になるのではないかと恐れていましたが、やや積極的に驚いていました.

よろしく

windows - 開発者は、ワークステーション ソフトウェア/開発スタックの更新を恐れるべきですか?

11 に答える 11

Related

Reference

windows - 開発者は、ワークステーションソフトウェア/開発スタックの更新を恐れるべきですか?