以下は私の実際の運用とメンテナンスの経験です:

1. war パッケージを一度だけ作成してさまざまな環境に適用できるように、構成はプロジェクトから独立している必要があります。

SaltStack、Ansible、Jenkins などの自動運用およびメンテナンス ツールを使用して、バッチ操作を実行します。

2. 静的リソースが頻繁に変更されることが予想される場合は、静的リソースを Java プロジェクトから分離して別のサイトにデプロイするか、転用に nginx を使用することをお勧めします。

war ファイルを解凍するプログラムをデプロイし (Tomcat 自身で解凍させるのではなく)、Tomcat を停止し、ln -s を使用して ROOT ディレクトリを新しいディレクトリに誘導してから、Tomcat を起動することをお勧めします。よりスムーズに実行されます
現時点では古いディレクトリを削除しないでください。デプロイメントが間違っている場合は、ln -s を使用して ROOT ディレクトリを古いディレクトリに切り替え、迅速なロールバックを実現します。

実務経験:
私が担当したプロジェクトはすべてweblogic上のディレクトリ形式で公開されています:

私は、開始、停止、監視、更新などの運用および保守タスクを自動化するために、この標準構造に従っていくつかのシェル スクリプトを作成しました。実際には数日しかかからず、コードもそれほど多くありませんでしたが、今では手動で行うことはありませんもう一度、運用と保守の問題について説明します。

基本的なプロセスは次のとおりです: コード開発の送信 -> SVN 増分更新パッケージのエクスポート -> サーバーへのアップロード -> サーバー上で実行

HTML ページを変更した場合、間違ったファイルを入力した場合は、再パッケージ化する必要があります。 静的なものは個別に公開できるので、JAVA を変更しただけの場合、再パッケージ化する必要があり、それに値するのでしょうか?

war パッケージ内のアプリケーションを実際に公開して提供するコンテナはありません。war パッケージは圧縮形式になっており、リクエストを処理するたびにコンテナにリソースを読み取らせる必要があります。 (少なくとも JSP については) パフォーマンスの問題が発生します。

これは、いくつかの小規模プロジェクトに対する私の個人的な解決策です。大規模なプロジェクトの場合は、継続的インテグレーションなどのフルプロセスのツールチェーンが必要になる場合があります。