Having created a few new Rails apps lately I thought I’d document my process of getting a new Edge Rails project, ready for development.
The following is my recipe for creating a new application we’ll call “idol.” Obviously this whole thing is specific to the tools I use and how I like things set up, so firstly Ill just lay out my tools of choice: subversion, piston, mysql5 client and capistrano.
Without further ado, here tis:
mkdir idol
cd idol
# Checkout edge rails
svn co http://dev.rubyonrails.com/svn/rails/trunk rails
# Create new rails app using edge rails
ruby rails/railties/bin/rails idol
rm -Rf rails
rm idol/log/*
# Prepare app for initial SVN
mv idol trunk
mkdir files branches tags
svn import . https://dev.aviditybytes.com/svn/idol -m "Initial import of project"
# Remove local and check out working copy
rm -Rf *
svn co https://dev.aviditybytes.com/svn/idol/trunk
svn co https://dev.aviditybytes.com/svn/idol/files
# Set up various sexy SVN parts
cd trunk
svn propset svn:ignore '*' log
svn propset svn:ignore '*' tmp/cache
svn propset svn:ignore '*' tmp/pids
svn propset svn:ignore '*' tmp/sessions
svn propset svn:ignore '*' tmp/sockets
svn commit -m "Set various ignores"
# Piston all our dependencies
svn up
piston import http://dev.rubyonrails.org/svn/rails/trunk vendor/rails
svn commit -m "Added Piston'd Edge Rails"
svn up
piston import http://dev.rubyonrails.org/svn/rails/plugins/exception_notification vendor/plugins/exception_notification
svn commit -m "Added Piston'd ExceptionNotification plugin"
# Cap baby, cap!
cap --apply-to .
svn add config/deploy.rb
svn add lib/tasks/capistrano.rake
svn commit -m "Added Capistrano"
svn mv config/database.yml config/database.example.yml
svn propset svn:ignore "database.yml
lighttpd.conf" config
svn commit -m "Moved database.yml and set various config ignores"
# Hosted @ segpub.com.au
rm config/deploy.rb
curl http://svn.aviditybytes.com/rails/libs/segpub_capistrano_recipe/deploy.rb > config/deploy.rb
svn commit -m "Changed deployment recipe to the Segpub family recipe"
# Topfunky's hot tip: cache_svn
curl http://pastie.caboo.se/2973/download > config/cache_svn.rb
svn add config/cache_svn.rb
svn commit -m "Added cache_svn.rb from http://pastie.caboo.se/2973"
# Database foobar
cp config/database.example.yml config/database.yml
echo "create database idol_development; create database idol_test;" | mysql5 -u root
./script/generate session_migration
rake db:migrate
echo "* Update your config/environment.rb to use ActiveRecord session store"
echo "* Modify the dispatcher.* shebangs"
echo "* Customise config/deploy.rb"
echo "* Start a codin..."
Add salt as required.
Archived comments
Comments were previously allowed on articles. Though no new comments are being accepted you can see the old comments below.
-
Nice article Tim. However, can you clarify why you need to change the dispatcher shebangs?
-
And I assume it can take a command-line arg to specify the name of the app you’re building?
-
Awesome article. very helpful for getting things setup in a best-practices way. topfunky: the script starts out like a log of a shell session but ends up like a shell script. i think you’re going to need some $1 vars to take the project name on the command line.
-
You might find my SVN cache diff useful. Saves a few headaches.
-
we <3 Tim!
-
Ben: It’s only if you’re using cgi or fcgi. If the shebang doesn’t point to the ruby interpreter then your dispatcher won’t spawn. In the case of segpub you just change it to use
/usr/bin/env ruby(which should also work in your dev environment).topfunky: Yeah it’s not a shell script, as it’s not useful to anybody w/o some modification. It’s more of a recipe. I just figured it might be good for people to see how to set things up properly from the beginning. I’m not gonna bother turning it into a shell script for my own use as I don’t use it often enough.
Nathan: cheers!
-
cool… I can understand ignoring lighttpd.conf, but why database.yml?
-
I don’t store database.yml in SVN, instead I just have
database.example.yml -
Yep, but why not store it? Just curious :)
-
Because if you store database.yml in your svn it A) has your database passwords in it (if that’s an issue—depending on who has access to your repository), and B) will overwrite changes on other systems you may not want it to change (multiple developers working with local dbs for development and testing with different credentials)
-
What Steve said ;)
-
A thought:
For the curl-fetched script about cache_svn, try this URL:
http://pastie.caboo.se/2973.txt
instead of this:
http://pastie.caboo.se/2973
-
Feh, nevermind, the /download is as good as txt. Sorry for not paying better attention.
-
I Guess you need to use
capify .instead of “cap—apply-to .” nowdays… right?// Jonas Montonen
-
Thanks a lot!