6

以下の問題があります。開発者は、Webアプリケーションに小さな変更を加える必要があることがよくあります。私が小さいと言うとき、私はウェブページまたは同様のもののつづりを訂正するようなことを意味します。このようなシナリオでは、戦争アーカイブの生成と再展開に時間がかかり、コストがかかる可能性があります。

変更を段階的に自動化してインストールするにはどうすればよいですか？たとえば、新しい爆発的な戦争を生成し、本番環境で爆発的な戦争とファイルを比較してから、変更の影響を受けるファイルのみを本番環境で置き換えます：.jsp.html.classなど。

これはホットデプロイメントである必要はありません。サーバーを再起動しても問題ありません。私が避けたいのは、80Mbのサイズの戦争をコピーして展開する必要があることです。接続が遅く、単純なスペル修正に数時間かかるなど、Webアプリケーションにわずかな変更を加える場合があります。

Mavenを使用してビルドプロセスを自動化します。重要な問題は、プロセス全体を自動化することです。これにより、Subversionのアプリv2.2.3が、増分展開後に本番環境で使用しているものとまったく同じになるようになります。

4

8 に答える 8

1

私たちはいつもこの種のことをしていました。私たちは銀行で働いていましたが、今日 (通常は昨日) に変更する必要のある法的表現や条件が変更されることがありました。

迅速に展開できるように、2 つのことを行いました。適切な変更管理とビルド プロセスがありました。好きなバージョンを変更してデプロイできました。また、変更を簡単にテストできる優れたテスト スイートもありました。

2番目はもっと物議をかもしました。すべての html は、サーバー上に個別のファイルとしてデプロイされました。戦争はありませんでした。したがって、テキストをすばやく変更する必要があるという状況が発生したときに、それを行うことができました。Java を変更する必要がある場合は、常に完全なビルドとデプロイを行いました。

これは私がお勧めするものではありませんが、私たちの状況には適していました。

WAR のポイントは、すべてが同時にデプロイされるようにすることです。WAR を使用している場合、それは一度に展開する必要があることを意味します。

1 つの提案は、そのような修正を頻繁に (週に 1 回?) 行わないことです。そしたらそんなに痛くない。

于 2009-11-26T23:08:25.160 に答える
1

言いにくい。もちろん、展開された webapp 内の単一のクラス ファイルを置き換えることはできますが、これは一般的に悪い考えであり、これを行っている人は多くありません。

その理由は、小さな変更を加えると、本番環境と開発環境の違いを検出するのがますます難しくなるからです。間違ったクラスファイルを送信して本番サーバーを破壊する可能性は、時間の経過とともに増加します。

テキストの変更と言うとき、テキスト リソースを war ファイルから分離しておくのは考えではありませんか? そうすれば、開発者だけでなく、顧客も簡単に翻訳を追加/変更できます。

顧客にとっては重要ですが、技術的には、小さなタイプミスを修正するために低速回線で 80MB の展開を行うのはばかげています。

また、ビルド/デリバリー サイクルを調べて、これらの小さな変更を防ぐためにテスト作業を増やすこともできます。

お役に立てれば。

于 2009-11-26T22:30:47.557 に答える
0

現時点では、SVN をリモート サーバーにインストールしたので、単純な更新の場合は、単一のファイルを更新するだけで済みます。大きな WAR ファイルを転送するのは非常に現実的ではありません。

ローカル マシンに単純なスクリプトを作成し、リモート マシンに別のスクリプトを作成することで、[Windows を使用している場合] putty / plink を使用してシングル クリック展開を自動化できます。

現時点では、DEVELOPMENT SVN と LIVE SVN があります。ANT ビルドは、DEV を LIVE にマージし、コミットを再び LIVE リポジトリに戻します。その段階で、リモート サーバーは SVN UP を実行でき、要求されたファイルが自動的に取得されます。

一部のクラスが変更された場合にサーバーを再起動し、スクリプト/JSP を更新する場合は再起動しないように更新スクリプトをさらに改善できます。

このようにして、以前のバージョンにロールバックして、Web アプリが常に機能していることを確認することもできます。

SVN をマージするプロセスを改善するには、このツールが非常に便利です。: http://www.orcaware.com/svn/wiki/Svnmerge.py

于 2009-11-26T23:02:04.497 に答える
0

実行中のサーバーがアクセスできる場所にマスター戦争を展開することができます。戦争ファイルを個々のサーバーに展開する代わりに、rsync と perl を使用して、マスター戦争のファイルに変更があるかどうかを判断し、それらをサーバーに配布できます。再起動を実行します。

于 2009-11-26T22:28:22.303 に答える
0

通常の答えは、Subversion を監視し、アーティファクトをビルドしてデプロイする継続的インテグレーション システムを使用することです。Web アプリケーションを再デプロイした後でも機能するようにしたいだけです。問題は、それが十分に速いかどうかです。

于 2009-11-27T07:18:22.173 に答える
0

これに対する直接的な答えはないと思います。T

ここで鍵となるのはモジュール化です。この問題は、現時点では Java アプリケーションではうまく解決されていないと思います。OSGi または動的モジュールを見たいと思うかもしれませんが、この問題に関してそれらがどれほど効果的かはわかりません。

クラスをアプリケーションサーバー/サーブレットコンテナーにドロップするソリューションを見たことがありますが、私はそれに同意しませんが、うまくいくようです...ただし、ホラーストーリーがあると確信しています!

Maven は確かにアプリケーションをモジュールに分割することで作業を容易にしますが、これを行ってモジュールを個別にデプロイする場合は、最初にテスト環境でさまざまなバージョンがうまく動作することを確認する必要があります...

別の方法として、アプリケーションを機能別に分割し、さまざまなサーバーで個別の機能をホストする方法があります。たとえば、次のようになります。

  • 顧客アカウント - サーバー A
  • 検索 - サーバー B
  • オンライン予約 - サーバー C
  • 支払いサービス - サーバー D

パーティショニングにより、アプリケーションのデプロイが容易になりますが、モジュールがうまく連携して動作することを最初に確認する必要があります。それが役立つことを願っています。

于 2009-11-27T07:30:27.437 に答える
0

差分とパッチ:

http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html

于 2009-11-26T22:48:38.930 に答える
0

私は以前に同様の状況にありました。これは本当に懸念事項の分離の問題であり、あまり単純ではありません。必要なことは、テンプレート/HTML ページからテキストを分離することです。

テキストをデータベース テーブルに配置し、そのテーブルをメッセージ リソースとして使用することでこれを解決しました。これには 2 つの利点があります。テキストを i8n でき、コードをデプロイしなくても製品を即座に簡単に変更できます。また、テーブルをキャッシュして、パフォーマンスがまったく低下しないようにしました。

すべての人にとっての解決策ではありませんが、私たちにとっては非常にうまく機能しました。

于 2011-05-27T12:11:02.153 に答える