I already have a production instance deployed on the server. Its working well.
Here is what I need to do.
Deploy a staging and Development environment on the server.
I have already created a branch in github to do that.
Config
1) Ruby 1.8.6
2) Rails is being vendored
3) Webserver Nginx and Thin
4) I have already create a file under /usr/local/nginx/sites-enabled and sites-available folders
5) Added yml file under /etc/thin
6) Made edits to the deploy.rb and have added dev.rb under the config and deploy folders
7) Capistrano is being used on the server for deploy
Questions:
How to deploy the dev environment from separate github branch different that production ? Will that reboot/affect the current production environment too ?
I want to make sure the production wont get affected by this. Please provide a list of commands
or tutorials that will help me with this. I am into very early stages of of learning ROR so please be
a little details. Help is very much appreciated.
EDIT:
1) Capify the project by installing the gem locally and running capify locally.
2) Make changes to you deploy.rb under config
3) set :stages with staging and production
4) set :default_stage as staging .. You have to edit this file more to customize your deployment
5) Under config/deploy/ : Create you production and staging ".rb" files. set the branch to master or any specific branch. Set your rails_env to staging in staging.rb and to production in production.rb.
Set deploy_to as xxxpath/staging and xxxpath/production in those appropriate files.
6) cap deploy will deploy in staging as default due to 4)
7) cap production deploy for production
It looks like you're most of the way there. The key will be to ensure that Capistrano deploys each branch to a separate location on the filesystem -- the sites-available document roots should be different (in other words, don't overwrite your production files!).
Two methods, if you have set stable production, staging and development branches, use the method documented here http://help.github.com/deploy-with-capistrano/
You can use this method for one-off branch deployments Using capistrano to deploy from different git branches.
Passenger looks for the file tmp/restart.txt to know when to restart; this is under the application tree so should only affect the specific variant of the site.
Depending on your server's capacity, the production site may suffer a brief performance hit from the restart of another environment. When you are able, you should consider getting a separate server for staging, test, dev, etc.
Related
I am coming in late to add some functionality to an already existing app hosted on heroku. The original builder has given me access and I 'heroku git:clone -a app-name' to my local computer.
I've found some conflicting instructions on how to set up a staging environment for this site. I don't want to push to the original site but want a way to try out functionality.
If anyone has had experience with staging and heroku, I'd appreciate any clarification.
You'll need to create a staging.rb file in config/environments. You can copy development.rb or production.rb and adjust whatever values you need.
Heroku will handle configuring the database configuration and such. You can clone an app in Heroku or just create a new one, then set it's RAILS_ENV and RACK_ENV environment variables to staging, and push to it.
Please refer: Heroku - Managing Multiple Environments for an App
You Need to create a second Heroku application that hosts your staging application.
Follow the instructions provided in the link for working with multiple environment in heroku.
I have the production application in the server in a subdirectory like www.server.cl/myapp.
But when I am in the development enviroment (running rails server) the application run on localhost:3000 and I can not check if the routes are 100% correct in the production enviroment (subdirectory) especially the assets paths.
Create staging environment (similar or identical to production environment) and deploy and test in this environment before deploy to production environment.
Here is more detail description.
I have an app being developed on github. I want to opensource it. Currently we use a capistrano script to deploy to our staging & production servers.
I am trying to figure out how we can put our config files in a separate repo, and still use capistrano to execute one touch deploys. The goal is that we can open up our repo for anyone to use.
You have some options.
Use environment variables: You can set environment variables at both your local and production machines. In your app you'll read these vars by doing: <%= ENV['my_var'] %>. Doing this you can commit your app to a public repo without worrying about expose sensitive information like passwords and keys. For example, set a db_password environment var to store your database password and in your database.yml you could read it doing: password: <%= ENV['db_password'] %>
You can use gems link dotenv (https://github.com/bkeepers/dotenv) or figaro (https://github.com/laserlemon/figaro): By using these gems you won't need to set environment variables manually on your machines, you will define them in a .env file instead. You'll be able to read them the same way using <%= ENV['my_var'] %>. You will have to ignore your .env files at your .gitignore and tell capistrano to create the environment variables at your production server reading from your .env file.
Another alternative would be make different config files for development and production and ignore them in your .gitignore. You can store your config production files in a different repo and have it updated on your machine at the time of your deploy. You'll just need to copy your config files from your local machine to the production server (https://coderwall.com/p/wgs6gw/copy-local-files-to-remote-server-using-capistrano-3) after updating the app repo on your production server.
The last alternative is the one I use most (in my case I use ansible in place of capistrano).
If you wanna see an example I have an application and a deployment task currently running in production that you can checkout:
Application: https://github.com/josuelima/bolao
Provisoning and Deployment: https://github.com/josuelima/ansible-sandbox
Hope I made myself clear and you got the idea.
TL;DR: Running assets:precompile injects production asset hosts into the generated assets for non-prod environments.
Background: The current way we deploy our Rails app is that the CI server deploys each successful build to the integration env as a tarball. And this tarball keeps getting promoted all the way to the prod env. But even before we tar the app to promote to different environments, we run
rake assets:precompile
Once this command is run before tarring, we ended up with the compiled assets as a part of the tarball and this saves deployment time for individual environments (The precompile is sloow).
Problem:
This arrangement worked fine until we introduced the asset_host property in the production environment. Because the assets:precompile is run in Production env by default, and the sass files refer to image assets using the image-url tag, the asset host started getting picked up by the precompile and the generated assets started having direct URL references to the production asset_host's servers. Obviously this is not acceptable.
Searching on the internet led to this Github Issue which is a pretty close description of the problem I'm having. Seeing the reaction of the gem maintainers, it seems like running assets:precompile once for ALL environments instead of once PER environment seems like a bad idea. But given slow precompile times, it seems to be the only way our for us.
So how are other Rails deployments dealing with this issue?
I was solving very similar problem. Our solution was to run the pre-compilation for every individual environment - in our case that were staging and production environments. The reason was the same - different asset hosts.
If you can, run the pre-compilation only in environments where it is necessary and where assets are really needed.
We are using Capistrano to do deployments along with the capistrano-ext gem. This allows us to specify different stages and to each stage settings and methods that are specific for the stage (or environments if stage == environment).
check public/assets/manifest.yml into source control
I have started developing a new Rails app on my server using RVM, Rails 3, & Ruby v1.9.2. I am using Git as my code repository. It's a simple app and I don't want to use an extra server. I just want to deploy my app directly from the same server I am developing on.
I've installed Phusion Passenger w/ Apache to serve my app, but have realized that I can't do that pointing to my development directory as my RAILS_ENV is set to "development". (I found I got file permission errors on the asset pipeline and other issues when I attempted to set RAILS_ENV to "production" and serve the app)
What's the simplest/easiest way to deploy the app? Can I simply:
1) Create a separate user to run rails production (Rails in dev currently runs as me on my Ubuntu server)
2) Clone my repo into a separate dir and configure Apache accordingly
3) Seed my database with the data needed for production (not much data needed here)
4) What else?
I've looked briefly at Capistrano, but it seems like overkill for this simple app. I only need to be able to provide a simple web interface for some data entry. Seems like git push should be sufficient, but I haven't done this before so maybe I'm wrong? Also, if I git push how do I ensure file permissions in the "production" directories are all set properly, particularly for any new files that get created in the originating app directory structure?
Thanks for any ideas.
No- you do not need Capistrano for the above; at this stage I feel it will only serve to confuse you further.
I'd suggest you first save your repo to a private Github or free BitBucket account. What you should do is keep one folder for 'development'.
Remember that Passenger is 'just' a module working with Apache. So what you need to do is setup a virtual host under apache and direct that to another folder on your system. For this example, consider:
~/rails/myapp_development/ and ~/rails/myapp_production/
Passenger always runs the app in production, so that should not be an issue. You can do bundle --without=production in your development setup to ignore any gems listed in the Gemfile under the production namespace, i.e. say you've got the mysql adaptor specified, you can ignore this and have Rails only rely on the SQlite gem.
You can now simply develop in the development folder, commit, push to BitBucket. Deploying will be as simply going into the production folder and doing a git pull and touch tmp/restart.txt.