We were using `server` on staging but `server1` and `server2` on
preproduction and production.
The reason behind it is we've always used one server on staging but
sometimes we've used several servers on preproduction and production.
However, this is a bit of a mess on installations which have only one
server on preproduction or production and need to use the `server` key
for the staging environments but `server1` for other environments.
So, in order to keep compatibility with existing Consul installations,
we're now allowing either `server` or `server1` on any environment.
We added the background role to the production and preproduction
environments in commit d0b0782c4, but forgot to add it to the staging
environment as well.
Deploy environment files were loaded after config/deploy.rb was loaded,
meaning if we used settings like `deploy_to` or `current_path` to set
variables inside the config/deploy.rb file, we'd be using the default
settings instead of the ones dictated by the deploy environment files.
These files are only loaded when the stage already has the value set
inside them, so we don't need to set it again.
On the other hand, the `rails_env` setting is configured in the
`config/deploy.rb` file.
The following parameters have been added to deploy-secrets.yml:
* **use_rvm**: yes/no
* **ruby_version**: Ruby version for rvm. Defaults to 2.3.2
* **repository**: Git repository. Defaults to the oficial repository
* **branch**: Branch to deploy. Defaults to master
* **rails_env**: Defaults to the stage.
Fixed migrations that required admin rights. Now first check if the postgress extensions are available. If so finish without doing nothin.
Added support for passenger.
