私は(サポート対象外の)ミドルウェアスタックを安定しているがサポートされているバージョンに更新するプロジェクトに取り組んでいます。現在本番環境にあるバージョンでアプリケーションを実行しているチームがいくつかありますが、当然のことながら、新しいバージョンで最初に実行されるリスクを負うことは誰も望んでいません。
過去にこのような新しいリリースに移行するために使用した、または最も説得力のある戦略は何ですか?
新しいバージョンによって提供されるパフォーマンスと機能上の利点はいくつかありますが、チームが移動するための主要な技術的インセンティブは実際にはありません。これは今のところ必須です。これは主に、古いバージョンの拡張サポートのコストと、新しいバージョンによって提供される改善された管理を備えたサポートされたバージョンで実行したいというインフラストラクチャチームの要望によって推進されています。
テクノロジーの質問というよりは、人の質問です。
非推奨または廃止された製品またはフレームワークは、通常、 技術的負債 として最もよく分類(および「販売」)されます。
新しいバージョンが素晴らしい改善または利点を提供する場合、あなたの仕事はより簡単です。ただし、そうでない場合でも、古いバージョンを使用し続けると、いくつかのリスクが発生します。
これは、everythingの最新かつ最高のバージョンを常に使用している必要があるという意味ではありません。これにも、関連する問題があるためです。しかし、私のチームでは、すべてのスプリントの開始時に、少なくとも1つのフレームワークを最新バージョンにアップグレードすることに重点を置いています。問題が発生した場合は、修正するか、ロールバックします。維持するのは難しいペースではありません。つまり、通常単一の製品またはフレームワークで1〜2か月遅れていることを意味します。 ITまたは企業が関与する必要がある場合。
要するに:ソフトウェア開発者やプロジェクトマネージャーに何か新しいものを導入したり、アプリケーションをアップグレードしたりするよう説得する方法には、まったく異なるアプローチがあります。
したがって、ソフトウェア開発者は時間の節約と、さまざまなフレーバーで一般的でやりがいのあるタスクを実行する際の便利な機能に関心があり、PMは提案された新規/アップグレードの実装による進行中の運用のコストの節約。
現在のアプリケーションテストがスクリプトによって自動化されていない場合、QAチームメンバーからは主な重要な欠点のみがもたらされます。 QAチームは当然この変更に反対するかもしれません。
How to convince
には、引数を使用して変更を加えるための関連するSEの質問があります。