Dan Croak

In our protocol guide, we instruct new developers to set up an existing Rails app like this:

git clone git@github.com:organization/app.git
cd app

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 executables.

Rails as of version 4.2.0 generates a bin/setup file by default.

Here’s an example bin/setup:


# 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 git@heroku.com:app-staging.git
git remote add production git@heroku.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

echo "port: 7000" > .foreman

# Set up DNS through Pow
if [ -d ~/.pow ]
  echo 7000 > ~/.pow/`basename $PWD`
  echo "Pow not set up but the team uses it for this project. Setup: http://goo.gl/RaDPO"

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 variables into .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 contributing.