-
Notifications
You must be signed in to change notification settings - Fork 82
Staging Environment Setup For Chef and Rails? #144
Comments
Hey @conradwt. You are completely correct. Did you try this and did it work out for you? Michiel |
Hello @conradwt That staging.rb is initially created by Capistrano install script, and it should be nearly identical to production.rb. The main reason of why you might need a staging or pre-production server is because there are too many differences between the development and production environments like SSL, assets, or how HTTP and Rails servers are different too. Or perhaps you want to test newest migrations, tasks or scripts right before they go to production. So if you use staging for this purpose you'll probably need it to be started with production environment settings (just to make sure your staging is as close as possible to the production instance) and there is no need to create another environment config. Finally, deploy/staging.rb and deploy/production.rb are not used on production or staging. These are just some config files needed to run Capistrano tasks locally. |
@oiuzikov deploy/staging.rb and deploy/production.rb are being used to configure the settings for the particular environment on deploy. For example, I moved the deploy_to setting to the particular environments (i.e. deploy/production.rb and deploy/staging.rb). Otherwise, if deploy_to setting is defined within the deploy.rb which is the current default, a deploy to staging will override your production environment by creating another directory and symbolic linking to the current directory. In short, I need to staging server to both test new code and allow the client to preview updates. |
@michiels I'm seeing the following issue when I try deploy to the production server:
Next, I have the following within my runlist: "run_list":["role[postgresql]","role[rails_passenger]"], Do I need to update to the new sample_host.json structure because it has changed from the time that I had created my version of it? |
OK, I was able to resolve the issue, "PG::ConnectionBad: FATAL: password authentication failed for user "deploy" that I'm was seeing when using "bundle exec cap production deploy" by doing the following after provisioning the server: In the file, /etc/postgresql/9.3/main/pg_hba.conf, on the provisioned server: from: host all all 127.0.0.1/32 md5 to: host all all 127.0.0.1/32 trust Next, I updated the runlist to look like the following: "run_list": [ "recipe[postgresql::server]", "role[rails_passenger]", "role[sysadmins]" ], Furthermore, I made sure that deploy user and the database owner were using the same username and password. I'm not sure if this correct way of doing things but it's working now. Finally, after deploying to staging and navigating to the site at www.example.com:2222 or example.com:2222 doesn't bring up the site. |
I noticed that a staging.rb was created within the following location:
Thus, I'm guessing that it's necessary to add a staging entry to the host.json by doing the following:
Next, should environment specific deployment configuration be moved from config/deploy.rb to their respective locations:
For example, deploy_to which will be different for each environment because I would prefer using the following for staging:
Lastly, I'm guessing that it's necessary to add a staging.rb to the rails config/environments directory. Then one can deploy and access the staging environment by doing the following:
The text was updated successfully, but these errors were encountered: