If your remote server has enough memory and CPU it's much better option to create
dist package on the destination machine(s). It's pretty similar like described in the post mentioned by Frederic, however main difference is that
what you have to send. Often you need to fix one file (ie. 20kb.) so sending 50MB+ every time doesn't make a sense. When your app will grow and you'll have to set-up many instances in the future you'll see why it's
uncomfortable idea. Instead you can just push small fixes with git and then re-deploy it in on the remote destination(s).
Your re-deploying should be as easy as writing the command:
git push some-remote master
and happily Play allows that! (with git+some bash scripting)
Although I'm obligated to keep scripts unpublished, there is very general checklist of our solution:
* Create a git repository on the remote
* configure some lightweight HTTP server with load-balance at least to the 2 ports
* Install current Play version on the remote
* Ignore
dist folder in git
* Commit/push source files of your app into the repo
* use post-receive hook on the remote to:
- create dist package
- unzip dist package
- move unzipped folder to new destination outside the dist folder of your app (because it will be deleted BEFORE next play dist operation!)
- start the application on the second LB port (stop app on this port before if required)
- start the application on the first LB port (stop app on this port before if required)
- Remove the folder created while previous 're-deploy`
Tip: keep your static public assets in separate folder and git repository to avoid re-deploying your app every time when you need to fix layout's CSS or images. You can use HTTP server to access them or maybe better some 3-rd party CDN solutions allowing for geo-replication, advanced caching (without writing it manually) etc.