3

現在、当社のイントラネット全体にさまざまな Web サイトの長いリストがあります。ほとんどはファイアウォール内にあり、アクセスするには Active Directory アカウントが必要です。最近の問題の 1 つは、Web サイトの数の増加と、データベース アクセス クラス、共通ヘルパー関数、シリアル化メソッドなどを格納する共通コード ライブラリの追加です。会社全体のすべての Web サイト。

現在、社内のデータ入力アプリケーションをこれらの変更に合わせて一貫してアップグレードしています。最新です。ただし、問題は他のすべての Web サイトを維持することです。各 Web サイトのバージョンを見つけてそれに応じてアップグレードするベスト プラクティスまたは方法はありますか? これらの DLL を保持し、サイトがそれらを参照する一元化された場所を持つことはできますか? これらの Web サイトにあるバージョンを、すべての Web サイトを調べて、バージョンを調べ、変更のたびにアップグレードすることなく、調べるための最良の方法は何ですか?

私たちは最新の TFS を実行しており、.NET 開発チームであることを覚えておいてください。

4

2 に答える 2

2

私の仕事では、あなたと同様の設定があり、共通のライブラリを使用する多くの内部アプリケーションがあり、1 年の大半を費やしてこれらをすべて整理しました。

最初に注意すべきことは、あなたが言及したことは実際にはTFSとは何の関係もありませんが、実際にはアプリケーションとそのコンポーネントがパッケージ化されて展開される方法の兆候です.

開始するためのいくつかのアイデアを次に示します。

自動化された/継続的なビルドをセットアップする

これは、最初に行う必要があることです。必要に応じて TFS のビルド機能を使用するか、TeamCity などに投資してください (これは素晴らしいことです)。すべてを評価します。あなたが愛し、他の誰もが一緒に暮らすことができるものを見つけてください。自分が好きなものを見つける必要があるのは、最終的には自分が責任を負うからです。

自動ビルドの設定が非常に重要である理由は、それが残りの問題を解決するための出発点だからです。

自動展開のセットアップ

デプロイ可能なアーティファクトはすべて、ビルド サーバーによってビルドされているはずです。手動で展開する必要はもうありません。ワークステーションからの導入はもう必要ありません。Visual Studio の発行機能はもうありません。ここから離れるのは難しいですが、それだけの価値はあります。

多数の Web プロジェクトがある場合は、msbuild/powershell を使用して簡単に自動化できる Web デプロイを使用するか、夢中になって octopus deploy のようなものを試してみてください。

nuget を使用して共通コンポーネントをパッケージ化する

ここまでで、共通コードには独自の自動ビルドが必要ですが、共通コンポーネントを自動的にデプロイするにはどうすればよいでしょうか? それを nuget にパッケージ化し、共有に配置して消費するか、nuget サーバーでホストします (TeamCity には 1 つが組み込まれています)。優れたビルド サーバーは、nuget パッケージを自動的に更新できます (常に最新バージョンを使用する必要がある場合) packages.config。.


理解しなければならないことがたくさんあることは承知していますが、本質的には、継続的デリバリー (http://continuousdelivery.com/) に移行するための基本事項です。

これを正しく行うには長い時間がかかりますが、プロセスは漸進的であり、時間をかけて進化させることができることに注意してください. ただし、長く待つほど難しくなります。すべてのプロジェクトを同時にアップグレードする必要があるとは思わないでください。最も痛みを引き起こしているものだけです。

これが役立つことを願っています。

于 2012-09-14T02:28:54.613 に答える
0

I'd just like to step outside the space of a specific solution for your problem and address the underlying desire you have to consolidate your workload. Be aware that any patching/upgrading scenario will have costs that you must address - there is no magic pill. Particularly, what you want to achieve will typically incur either a build/deploy overhead (as jonnii has outlined), or a runtime overhead (in validating the new versions to ensure everything works as expected).

In your case, because you have already built your products, I expect you will go the build/deploy route.

Just remember that even with binary equivalence (everything compiles, and unit tests pass), there is still the risk that the application will behave somehow differently after an upgrade, so you will not be able to avoid at least some rudimentary testing across all of your applications (the GAC approach is particularly vulnerable to this risk).

You might find it easier to accept that just because you have built a new version of a binary, doesn't mean that it should be rolled out to all web applications, even ones that are already functioning correctly (if something ain't broke...).

If that is acceptable, then you will reduce your workload by only incurring resource expense on testing applications that actually need to be touched.

于 2012-09-17T02:57:41.327 に答える