In our protocol guide, we instruct new developers to set up an existing Rails app like this:
git clone email@example.com:organization/app.git cd app ./bin/setup
The goal of the
bin/setup script is quick, reliable, consistent setup. It is
placed in the
bin directory to match new Rails conventions about
Here’s an example
#!/bin/sh # Set up Rails app. Run this script immediately after cloning the codebase. # https://github.com/thoughtbot/guides/tree/master/protocol # Set up Ruby dependencies bundle install # Set up staging and production git remotes git remote add staging firstname.lastname@example.org:app-staging.git git remote add production email@example.com:app-production.git # Set up database bundle exec rake db:setup # Set up configurable environment variables for Foreman if [ ! -f .env ]; then echo "RACK_ENV=development" > .env fi echo "port: 7000" > .foreman # Set up DNS through Pow if [ -d ~/.pow ] then echo 7000 > ~/.pow/`basename $PWD` else echo "Pow not set up but the team uses it for this project. Setup: http://goo.gl/RaDPO" fi
The first section installs or uses cached Ruby dependencies via Bundler.
The second section sets up git remotes for staging and production commands.
The third section creates the development and test databases, loads the schema, and initializes with the seed data. It does not need to run all the migrations.
The last two sections use Foreman as process manager, Pow as DNS server and HTTP proxy.
This is just an example
bin/setup file. Each project will be different. Some
might not use Pow. Some might test if Redis or MongoDB is installed and run,
install, or print a message if not. Some might want to pull some
.env from Heroku.
Regardless of the
bin/setup file’s contents, a developer should be able to
clone the project and run a single, consistent, reliable command to start