I am developing 2 applications in Rails 3.1 (will upgrade soon), and have noticed that my current strategy has its drawbacks. What I am doing currently is:
- Work directly on the development directory, have there version control with Git (which works perfect for me).
I have defined the databases like (omitted not interesting parts):
development:
database: db/dev.db
production:
database: db/dev.db
I have both applications running all the time in production mode, where the ports are defined as 3008 and 3009.
- From time to time, I want to change little things, and start then a development server for one of the two applications directly with the defaults:
rails s thin
(port == 3000).
I have noticed that the following things don't work very well.
- When I change CSS or Javascript files, I have often to cleanup (and after development rebuild) the assets.
- Sometimes, the development server takes the files (CSS and Javascript) from one server and uses them for the other server. I have to manually clean the caches for the browser to avoid that.
What would be a better strategy to develop and use the two applications in parallel locally on my computer? Any tips and hints are welcome. Should I use a deployment tool (Capistrano) for that? Shall I roll my own Rake task for the divide? Or do I miss some magic switch that will heal the wounds (sounds pathetic :-))?
At the end, it is a mix of changes, so I answer my own questions and hope that others may learn something from it. At the end, there are 2 major decisions (and some minor ones):
- Work with different repositories for development and production, even on the same machine. Add another one (a bare one) to synchronize the two. Push only from the development, pull only from production.
- Use different ports all the time for different applications. Make a scheme like:
- appA: dev ==> 4001, prod ==> 3001
- appB: dev ==> 4002, prod ==> 3002
- ...
Here are the changes that I have done. rails/root
is the root directory of my application, the overall directory structure is the following:
rails/
root/
another/
...
bare/
root.git/
another.git/
...
production/
root/
another/
...
- Create 2 new repositories from the old one, one as a bare repository, the other one for production only:
mkdir rails/production
mkdir rails/bare
cd rails/bare
git clone ../root --bare
cd ../root
git remote add bare ../bare/root
cd rails/production
git clone ../bare/root
cd root
git remote add bare ../../bare/root
- Don't use one (the same) database for development and production, just to be sure that Git can do its magic.
- Develop (only) on the development repository.
- After enough tests, do the following 2 steps:
root> git push bare
root/../production/root> git pull bare
- Start the development server (only) with:
root> rails s thin -p 4009
- and the production server (only) with:
root/../production/root> rails s thin -e production -p 3009
So as a result, I have a little more work to do, to stage changes from development to production, but I will eliminate those small irritations that were around all the time.
Running production servers on the development machine, or developing on the production machine is an unusual, even discouraged setup. Use your local machine to develop, run the server in development mode and run your test suite. Commit changes to git. Then, from time, to time, deploy to a server that runs in production mode. That's the recommended setup. As production server you could set up your own (e.g. your own machine or one in the cloud like EC2) and use Capistrano for deployment. More simply and with a lot less trouble, however, you can deploy to a service like Heroku. All you need to do is a git push
and the app will deploy. A single instance of concurrency on Heroku is free, even.
Also, Windows is not a very well supported environment for running a Rails server, you're better off with Linux. For development, Windows may do the trick, but you'll definitely be in the minority. Most people are on Mac or Linux. Sometimes people recommend installing Ubuntu Linux on top of Windows in a virtual machine for Rails development.