As a subscriber to Railscasts Pro, I was pleasantly surprised when Ryan released a series of screencasts on Deploying to a VPS and Capistrano Recipes and discovered how eerily similar our strategies are for deploying a Rails app. Up to this point, I just had a text file that I copy and pasted commands from into the terminal. I do a few more things such as setting up a firewall with UFW, setting the timezone to UTC, having nginx detect the standard capistrano maintenance page and tailing logs. I pinged him on Twitter to get his approval for combining my code with his and releasing it as a gem and thus, cap_bootstrap was born.

There are a number of other solutions out there for server provisioning but my plan for this one is to keep it opinionated and lean with only the latest Rails best practices for deployment. Right now that means nginx, Unicorn and PostgreSQL on Ubuntu LTS.

I’m considering including Linode provisioning, MySQL, Apache/Passenger and multiple apps on a single server.

I’ve been using my Rails 3 quick start template with much success to rapidly build out prototypes, but sometimes Rails is overkill. I have a few micro app ideas that I want build and wish to bypass that initial tedium as quickly as possible. My first thought was to write a Thor script, but then I realized a template system for Sinatra was not the problem I wanted to solve. (I’m aware of Padrino but I chose Sinatra because of its simplicity.)

Enter Bash.

Note that $1 is the first argument passed on the command line.

function cotb {
  mkdir $1
  cd $1

  cat >> $1.rb <<HERE
set :root, File.dirname(__FILE__)
get '/' do
  'Hello World'
end
HERE

  cat >> config.ru <<HERE
require 'rubygems'
require 'bundler'
Bundler.require
require '$1'
run Sinatra::Application
HERE

  cat >> Gemfile <<HERE
source :rubygems
gem 'sinatra'
HERE

  bundle install
  git init
  git add .
  git commit -m "Setting up a base Sinatra App"
}

Add this to your .bash_profile, .bashrc, or .profile.

Use it.

cotb my_awesome_app

This will create a project folder, generate the files Gemfile, config.ru and my_awesome_app.rb, run bundle install and set up a new git project.

Executing commands and piping text into files makes Bash perfect. Using Ruby would require executing shell commands through another function.

Bonus points if you figure out what cotb is an acronym for.

Riffing on Bruno’s post, “It’s a Global Market, why are you cornering yourself?”, I’m going to follow-up and give a detailed explanation of the tools we use at Todobebé to collaborate with our distributed agile team. I’m going to assume you have a working knowledge of an agile methodology. We adopted Extreme Programming as our development methodology about a year and a half ago, coming from the typical, let’s have some meetings, build it and pray that it works methodology that most small businesses practice. If XP isn’t your flavor of software religion, most of the software should still be applicable to Scrum or other agile development methodologies.  If you need a quick overview of XP, check out Extreme Programming: A Gentle Introduction first and then pop back over here.

The software we use isn’t going to surprise anybody, but the combination of which work really well for us:

• Pivotal Tracker
• Campfire
• Basecamp
• Webex
• Skype
• Github
• Integrity
• Remote Desktop

I told you it wasn’t going to be a surprise. We reviewed, tried  and waffled back and forth on quite a number tools over the past year to arrive at this list, both free and paid and some of them quite expensive. We’ve found that the simplest tools work best. At one point we moved from Pivotal Tracker, which we enjoyed logging into every day, to a very expensive tool which took us 2 weeks to configure. After several weeks, we realized that flexibility is a synonym for “crappy usability”, and switched back to Pivotal Tracker.

The Standup

The standup is our daily therapy session that we hold in Campfire; “What did you accomplish yesterday?”, “What are you working on today?”, and the question that really matters, “Is anything preventing you from completing your stories?” We use a script that posts a reminder message into campfire every day.

A cron job on our staging server kicks off the standup script. (Niñera is our helpful campfire bot.) There are alternatives to Campfire, including IRC, but Campfire’s dinstinct advantages include ease of use for non-techie users, searchable and persistent history, inline code pasting and inline image sharing.

Iteration Meeting & Demo

Until recently, our iteration meetings were in person. However, we’ve now moved to holding them virtually, allowing everyone to join, even if they can’t physically be at the office. Skype allows us to conference for free, including our developers in Brazil, and still works great on poor internet connections. Everyone logs into Campfire in case they need to share links, screenshots, etc. Webex is used to screenshare a demo of the work completed and the next iteration’s work is planned in Pivotal Tracker.

Retrospective

After the iteration meeting, we hold a retrospective in Campfire with each person typing in their positives and negatives of the process and everyone revealing them all at once. The results are aggregated and stored in a Basecamp message, to be reviewed the next week for improvements. This is a key aspect of XP and keeping an easy to access history is important to the health of the process.

Release Planning Meeting

The release planning meeting has been our one exception. It’s infrequent and important enough to fly everyone in to meet in person. Potential stories are written on 3x5 cards. Developers discuss the stories with the business team and estimate a cost on the cards. The business team chooses the most important stories for the release. The stories are then entered into Pivotal Tracker and become part of our virtual process.

We are going to hold our next release planning meeting virtually though. If it differs greatly from the iteration meeting, I’ll update this post.

Engineering Meeting

After the iteration meeting, we roll directly into the engineering meeting with the developers to flesh out the tasks for each story.

Bug Tracking

We go old school with this one. Issues are reported via email to our QA person and consolidated to bugs in Pivotal Tracker. This allows our small team of developers to work from one tool and also makes it easier to plan all the work for the iteration. Any bug tracking tool can act as your bug inbox, but I still highly recommend having someone consolidate, verify and filter before it reaches the developer.

We deviate slightly from XP as our team isn’t quite big enough to have a dedicated batman to handle unplanned issues. If your team does utilize a batman, they can work directly from the separate bug tracking tool.

Pair Programming

Our team uses Macs and the built-in screen sharing works great. The audio in iChat tends to be a bit flaky so that gets turned off and we use Skype instead. Remote desktop is also built into Windows, but don’t bother asking me for help.

Stories

As I’ve already mentioned, we keep our stories in Pivotal Tracker. It’s built using generic agile principles and not one specific dogma in mind. I have not found this to be an issue. When it’s time for a developer to work on a story, collaboration with the business owner happens with screen sharing for one-on-one sessions and Webex if multiple people are involved.

SCM, Continuous Integration & Testing

All of our source is stored at Github, which provides an easy hook system for notification to other systems. Commits get posted to our private Twitter account and Campfire. Integrity gets notified and the build status gets posted to Twitter and Campfire as well. When someone breaks the build, then entire team knows right away and you are shamed into fixing it. ;-)

I’m not going to lie to you, remotely collaborating requires much more effort than working in a classic XP room. But it can be done, and done well. Eliminating your geographic borders for hiring means you can tap into the best programmers in the world. A not-so-obvious advantage of keeping the entire process online is greater visibility into the project by management, which translates to less meetings for us developers. And that makes me very, very happy.

If your team is doing remote collaboration, I would love to hear which tools you use in the comments.