- PR -

Javaでの本番反映（本番サーバへのデプロイ）について

1|2 次のページへ»
投稿者投稿内容
未記入
常連さん
会議室デビュー日: 2007/07/18
投稿数: 26
投稿日時: 2008-05-26 21:32
こんばんは。

現在、Javaにて業務アプリを作成しています。

当然、開発環境、本番環境があるのですが、
みなさんは、本番環境へデプロイする際は、どのようにされていますか？

私は、warなどは使っておらず、クラス、JSPなどのファイルをtarで固めて、それを展開しています。

できれば、warも使いたいのですが、JSPのみの修正（文言修正や、デザイン変更など）が頻繁にありますので、
Tomcatの再起動もせずに、JSPのみをtarで固めて、本番反映を行っています。

ただ、できれば、war化しておけば、いざというときに、１つ前のレベルに戻せるなど、
簡単にモジュールの差し替えが可能だと思います。

極力サーバの再起動はなしで、必要なときにのみ、再起動する方法がよいと思っています。

みなさんは、どのようにしていますか？
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-05-26 21:39
私はwarでのデプロイ派ですね。
Tomcatの再起動はどのみち不要ですよ。コンテキストのリロードだけです。

引用:

ただ、できれば、war化しておけば、いざというときに、１つ前のレベルに戻せるなど、
簡単にモジュールの差し替えが可能だと思います。

これが特別warのメリットではありませんね。ソース管理で十分です。
文言修正などのコンテンツのアップロードだけであれば、
私もJSPをtarで固めてアップする方をオススメします。
それならリロードすら不要ですね。
わたなべ
大ベテラン
会議室デビュー日: 2007/12/09
投稿数: 123
お住まい・勤務地: 札幌
投稿日時: 2008-05-26 22:47
tarにして展開という方法は聞いたことないです。
antなりmaven2なりを使えば自動化できますし、warがあるのに何故？って感じがします。

>JSPのみの修正（文言修正や、デザイン変更など）が頻繁
頻繁にある時期に、頻繁にデプロイしなければならない状況ってよく解らないんですが…。
もしかして、各開発者のマシンにTomcatをいれない派？
未記入
常連さん
会議室デビュー日: 2007/07/18
投稿数: 26
投稿日時: 2008-05-26 23:08
ご返信ありがとうございます。

かつのり様
> これが特別warのメリットではありませんね。ソース管理で十分です。
確かにおっしゃるとおりですね。
ただ、war１つで各レベルに戻せるのは、かなり良いのではと思っています。

> Tomcatの再起動はどのみち不要ですよ。コンテキストのリロードだけです。
すいません、よく分かっていないのですが、このコンテキストのリロードというのは、
サーバの再起動ではないということでしょうか？
具体的には、どのようにリロードするのでしょうか？

ついでの質問になってしまいますが、
たとえば、１つのJSPを変更した場合でも、
warを作成した場合、すべてのクラス、JSPなどが含まった状態になると思います。

で、起動中のTomcatに対して、直接warを置き換えた場合、とくに問題はないのでしょうか？

また、Tomcatの設定で、「unpackWARs」があると思いますが、
これをtrueにした場合と、falseにした場合では、速度的に遅くなったりするのでしょうか？
（reloadbleをtrueにすると遅くなるみたなことはあるのでしょうか？）


わたなべ様
> antなりmaven2なりを使えば自動化できますし、warがあるのに何故？って感じがします。
antから、直接warを作れることは知っていますし、warの存在有無については聞いていません。

> 頻繁にある時期に、頻繁にデプロイしなければならない状況ってよく解らないんですが…。
これの意味が良く分かりません。

> もしかして、各開発者のマシンにTomcatをいれない派？
入れてます。
開発環境というのは、各開発者のローカルのPCではなく、開発サーバのことです。
わたなべ
大ベテラン
会議室デビュー日: 2007/12/09
投稿数: 123
お住まい・勤務地: 札幌
投稿日時: 2008-05-26 23:36
>コンテキストのリロード
warを配備しなおせば、勝手に配備したWebアプリを読み込みなおす機能

>>>JSPのみの修正（文言修正や、デザイン変更など）が頻繁
>>頻繁にある時期に、頻繁にデプロイしなければならない状況ってよく解らないんですが…。
>これの意味が良く分かりません。
文言修正や、デザイン変更が頻繁に発生する時期に、warを作る事が面倒なほど頻繁に本番環境にデプロイする必然性がよく解らないです、と言う意味です。

まあ、本番環境で確認する場合は、warを配備して再起動でしょうね。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-05-26 23:54
引用:

>JSPのみの修正（文言修正や、デザイン変更など）が頻繁
頻繁にある時期に、頻繁にデプロイしなければならない状況ってよく解らないんですが…。
もしかして、各開発者のマシンにTomcatをいれない派？

外向けのWEBサイトをやっていて、コンテンツの内容を差し替えるときとかに、
JSPだけ変えるというのは普通にやったりしますね。
ちょっとしたお知らせを変えるとか・・・。

例えばお知らせを変えるだけで、コンテキストのリロードで待たされるのも困るので、
JSPだけ固めてアップするというのは十分有り得るシチュエーションかと。
PHPとかだと全然気にしないで済むんですけどね。
未記入
常連さん
会議室デビュー日: 2007/07/18
投稿数: 26
投稿日時: 2008-05-26 23:55
> 文言修正や、デザイン変更が頻繁に発生する時期に、warを作る事が面倒なほど頻繁に本番環境にデプロイする必然性がよく解らないです、と言う意味です。
war作成が面倒だとは言っていません。
また、頻繁に本番環境にデプロイするとも言っていません。

> まあ、本番環境で確認する場合は、warを配備して再起動でしょうね。
ですから、warを作成して、本番環境へ適用した場合、
たとえ、JSP１本しか更新していない場合でも、再起動が入るのを避けたいのです。
通常JSPの変更のみの場合、本来Tomcatの再起動は不要のはずですし。
わたなべ
大ベテラン
会議室デビュー日: 2007/12/09
投稿数: 123
お住まい・勤務地: 札幌
投稿日時: 2008-05-27 00:15
>できれば、warも使いたいのですが、JSPのみの修正（文言修正や、デザイン変更など）が頻繁にありますので、
>Tomcatの再起動もせずに、JSPのみをtarで固めて、本番反映を行っています。
頻繁にあるので〜と書いてあるんだけどなぁ。
そもそも頻繁ではないならば、再起動しても問題にならないでしょう。

JSP1本であろうとアプリケーションに修正を入れたという事実は変わりません。
よく解らない独自の方法でデプロイルールを作ったり、JSPだけの時は直接編集OKだったり、そんな運用方法はトラブルの元です。
しっかりとソースコード管理を行い配備のルールはJSP1本であろうと追加機能であろうと同じにする（コストは低くコマンド1本で可能にしておく）方が良いと思いますよ。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）