開発時は play run でサーバを起動する。
run でサーバを立ち上げた場合、リクエスト時にソースの更新が検知され、更新があればコンパイルが走る。コンパイルが終わるまでリクエストは待たされる。リクエスト結果は常に最新のコードが反映されたものになる。
play ~ run で実行するとソースを更新するたびにコンパイルが実行される。
通常の run だとソースを修正した後にリクエストをするとコンパイルが走り、終わるまで待たされることになる。ScalaはJavaよりも数倍コンパイル時間がかかるので、待ち時間が体感的に許容できない長さになることもある。~ run の場合は保存時にコンパイルが走る為、リクエストの際の待ち時間が体感的に短くなることが期待できる。
但し保存のたびにバックグラウンドでコンパイルが走るので、コア数が少ない非力なマシンの場合は開発時にストレスになる場合もある。
start は run などのデバッグモードと違い、リクエスト時にソースコードの更新チェックやコンパイルは行われない。
start コマンドで本番サーバを運用しても良いらしい。でも普通は dist して start シェルを叩くか、stage を叩くかするような気が。うちでは実際に運用するアプリは dist してます。
stage は start と同じく本番モードでサーバを起動します。
start の場合はコンソール上にログが出力されますが、stage の場合はバックグラウンドで実行されます。あと、taget 配下に staged というディレクトリを作ってその中で隔離された状態で動きます。ドキュメントによると start だと Ctrl+D しないとプロセスと切り離せないので、自動化するには stage の方が向いているとのこと。
【参考】
Play 2.0 コンソールを使う
http://www.playframework-ja.org/documentation/2.0.3/PlayConsole
アプリケーションを本番モードで起動する
http://www.playframework-ja.org/documentation/2.0.3/Production
スタンドアロンで実行可能なアプリケーションのビルド
http://www.playframework-ja.org/documentation/2.0.3/ProductionDist