Robby on Rails

In a previous post, I showed how we’ve been working on an interactive deployment process for Rails applications to reduce the time it takes to deploy to a Boxcar.

We began to move our Boxcar deployment recipes into it’s own Rails plugin and just made it available on GitHub.

Introducing Boxcar Conductor

The Boxcar Conductor plugin aims to automate the entire process for deploying to your Boxcar. We’re down to just a few simple commands to run to get your application up and running. While mileage may vary with other hosting providers, we did want to open up this work to the community and centralize our work with the community of Boxcar customers who have helped us build and test these tools.

Install Boxcar Conductor

If you’re running on Edge Rails… you can take advantage of the new support for installing plugins in git repositories.

  $ ./script/plugin install git://github.com/robbyrussell/boxcar-conductor.git

note: If you’re not using edge rails, you can download a tarball and install the plugin manually.

Installing the plugin will add a custom Capfile and config/deploy.rb, which has a few things for you to define based on your Boxcar subscription.

Configure Your Boxcar

Once the plugin is installed, you can run the following task:

  $ cap boxcar:config

This will ask you a few questions about your deployment needs.

• Which database server will you be using? (along with db user/pass info)
• How many mongrels should run in your cluster?

After a few quick multiple choice answers, you’re application is ready to be deployed and you can run an Boxcar-specific deployment task.

  $ cap deploy

We’ve also created a new public project on Lighthouse so that you can submit tickets and ideas to us. With Boxcar, we’re really aiming to remove as many steps from the deployment process that aren’t necessary.

To follow along, visit the project on lighthouse or GitHub.

If you’re interested in learning more about Rails Boxcar, feel free to drop us a line.

Related Posts

• Deploying Rails with an interactive Capistrano recipe to your Boxcar
• Announcing Cobalt and monthly subscriptions for Boxcar

We’re not looking for rock stars or ninjas at Planet Argon. ;-)

We’re looking for individuals that share our core values.

• COLLABORATION – We believe that an open dialogue between all members of a group helps to produce more reasoned and intelligent decisions.
• ENTHUSIASM – We recognize the unique power of people who are passionate about their craft. We believe that fun is an essential ingredient in a collaborative and vibrant company culture. We think happy people make better software.
• COMMUNITY – We are part of many communities. Our neighborhoods, our cities, our workplace, and our professional communities. We give back to our communities by implementing socially responsible business practices and sharing our knowledge and tools with our peers.
• VERSATILITY – We believe that it is important for our team to be open and flexible, as well as the work that we do. This allows us to adapt to change and encourage innovation.
• EXECUTION – We value action and when people make things happen. It is important that we follow through on our commitments, plans, and ideas.

..maybe you’re a .NET/Java/PHP/Python developer (who secretly plays with Ruby on Rails at night/weekends). We’re looking for an intermediate-level Rails developer to join our team. Ideal candidates would be in the Portland, Oregon area or willing to relocate.

If you’re interested, take a moment and introduce yourself.

We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.

I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).

What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.

For example:

$ cat REQUIRED_GEMS

actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools

Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.

This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?

Our team has been migrating towards using Git as our primary SCM. We have way too many Subversion-based projects and repositories to just do a clean switch over and not everybody on the team has had time to start playing with it. Baby-steps…

So, for those of us who want to use it day-to-day, we’re using git-svn.

Andy Delcambre has posted the first in a series of blog articles to help you pick up on using Git on Subversion-based projects. Check out his article, Git SVN workflow to get up to speed.

Also, if you’re on OSX and using Git… check out Justin Palmer’s new project, GitNub, which describes itself as, “a Gitk-like application written in RubyCocoa that looks like it belongs on a Mac.” This looks promising. :-)

Just when you think that you’re sneaking through Fall/Winter without getting sick… it hits you. Been sick the last week and am finally coming up for air. :-)

Anyhow, I’m going to be traveling a few times over the coming weeks/months and wanted to reach out…

Dear Londoners,

A few of us from the Planet Argon team, (Andy, Paige, and myself) are heading to London in just over a week to visit one of our big clients. We’ll also be staying for a few more days to explore. If you’re interested in grabbing a few pints and/or interested in meeting up, drop me an email we’ll try to coordinate something when we’re over there. =)

One of the reasons why I’ve been too busy to write on my blog lately is that we recently moved into to a new studio. We had a lot of preparation to do before we moved in and are finally getting settled in the new space.

We took the space from…

To this…

As you can see.. we have lots of natural light for the entire team…

I think that Chris Griffin shares the same excitement that I do about the new space. ;-)

We’ll be posting more photos on the Planet Argon flickr stream over the coming weeks as we get the studio organized. :-)