sfg
Certain sites/apps will have different setup tools (e.g - AWS for JumpQ and Dan Harris for MFPA) - And specific instructions should be written in individual repos for them.
But by and large - we manage our own Bytemark servers running on Debian. The deployment tool of choice is Capistrano. It's ace for managing all required tasks that need to be ran on every deployment - as well as keeping 5-6 full backup versions on the server which can be fallen back on should a deployment fail.
A really good guide to setting up the capistrano can be found here, which deals with the full process of hooking up with Git / connecting it to your server / deployment commands.
You can also set up cap configuration for different environments here - so if you need to set up configuration for a separate staging and production site then you can can do. Under config/deploy directory add in a staging.rb file - most of the code from the production.rb can be copied across other than to differentiate between the file paths, git branch and state name, eg:
set :stage, :staging
set :application, 'cineplace-staging'
set :branch, :staging
The cinevents repo has a good example of the split of environments can be set up.
Once set up - it's a simple command to deploy:
cap [ENVIRONMENT] deploy
So if your environment is 'Production' then
cap production deploy
All being well this should just work. Cap is generally pretty good at spitting out useful error messages if a deployment fails for any reason.
By default, on the sever the rails apps will live in:
/home/admin/apps/appname
Capistrano will store date-referenced versions of the project (going back 5-6 versions) - and the current deployed version will live in:
/home/admin/apps/appname/current
From here you should be able to run any rails tasks you would be able to run in the local machine.
A useful command to run if a a server needs to be started straight from the command line without having to SSH onto the server:
cap production deploy:restart