Agile Deployment: Unified Repository

Source code management is closely tied to deployment. Creating a deployment strategy that truly feels agile requires careful management and preparation of the source repository.

Branched Environments

My first approach worked like this:

  • I had subversion branches for each server type (pre–production, production)
  • These branches had their own settings files suited to their environments
  • We’d merge changes from forks into trunk, then merge into pre–production, then production

This worked relatively well and was easy to understand. The main issue I had with this approach was it added overhead to deploying that I wasn’t prepared to deal with. Having to carefully merge new changes every time was a real chore. I often didn’t feel secure that we’d merged in all the changes, and I’d have to open up Changes to visualise the differences.

Read More →

Quickly Load Rails Projects

Here’s a huge Rails productivity tip. It’s a shell command that does the following:

  • Changes directory to a Rails project
  • Opens $EDITOR (set this as TextMate, MacVim, etc.)
  • Opens a tab for script/console
  • Opens a tab for logs
  • Names the tabs so switching between them is easier
  • Gives your Rails projects tab completion

It doesn’t start script/server because I use Passenger Preferences Pane -- this is another excellent productivity-increasing Rails-oriented secret.


Type r projectname.

Read More →

A Rails Plugin for Tokyo Dystopia

Dystopian Index is a Rails plugin for Tokyo Dystopia. I’m using it with small projects that don’t really need a more sophisticated indexing solution like Sphinx or Solr. There’s no daemon, so setup is less of a headache.

It uses Dystopia to build disk–based indexes. At the moment it stores one index per ActiveRecord model, but I might change this to an index per field later.

I’ve made it support sorting by date, just because clients always ask for it. To achieve this, dates are stored in the first 12 characters of each index record. The plugin uses these to sort in Ruby. I’ve been working on benchmarks to figure out the fastest way to handle this.

Read More →

Vlad Debugging and Solutions

Vlad the Deployer is a well–written piece of software. It demonstrated that a realistic alternative to Capistrano is possible, with way less code. I’ve come to rely on it for a few projects and I like the design. There are times, however, when using Vlad can feel like pulling teeth.

This is another deployment–themed article about how to fix issues when using Vlad. If you’d like to read more about deployment, visit my agiledeployment tag.

Read More →

Agile Deployment: Taxonomy

It’s important to select the appropriate deployment technology for your project, especially if you need to take colleagues and workflow into consideration. This post outlines different approaches to deployment.

Rails deployment is dominated by technologies like Capistrano and Vlad. These deployment frameworks_ represent one approach, but there are others that are just as valid depending on the project.

Manual Uploading

Uploading files is how most projects used to be deployed. FTP, SFTP, and maybe even rsync.

Read More →

Agile Deployment: Checklist

Auditing your application is an important stage of deployment. Mature Rails applications have a tendency to get complicated — they typically require a host of libraries, background tasks and their own settings files. To feel confident deploying it’s important to be aware of these dependencies.

Ideally, deployment should just work. Deploying a tweak, bug fix or new feature should all be performed through a single command. However, there’s going to come a time when you or your colleagues haven’t updated an application for a few weeks or months, and deploying suddenly feels daunting. This type of document would help in that situation. It will also help you plan deployment before starting up Vlad or Cap.

Use the following checklist to build your own blueprint of your application’s dependencies. Keep it up to date but don’t go overboard — use Rails to enforce dependencies where possible — config.gem with a specified library version can help.

Read More →

Agile Deployment

Deployment should be bullet–proof, predictable and fast. You might even say it should be agile. Unfortunately, it's difficult to create an agile deployment environment. One of the reasons for this is that deployment is left as a last minute concern. It's a spectre lurking in the corners of a project manager's Gantt charts.

To make matters worse, learning and configuring deployment tools can be difficult — the documentation isn’t always great, and it’s hard to relate recipes to your particular environment. They also require a leap of faith before running with a live application.

It’s impossible to claim to be “agile” if you’re not 100% comfortable deploying.

Read More →

Using Jekyll

Please accept my apologies if I’ve flooded your feed reader with articles: I owe you a beer. The reason for this is I’ve moved my blog over to a new system and new design. To make up for it I’ve lovingly curated all of my old posts by adding syntax highlighting, resizing images and fixing typos.

In fact, I’ve almost killed myself porting this blog over to Jekyll. My old blog was a simple Rails application I built based on code from Helipad. It did a sterling job, but I have so many Rails applications to maintain it added too much to my workload. Writing a blog with Jekyll is relatively simple, but deciding to make a redesign at the same time is not.

Here’s why I like Jekyll, and why you might too:

Read More →

Rapid Rails: Boot Up Time

Rails boot up time really starts to drag when you’re working in a TDD or BDD style. There’s projects out there that create long running distributed processes to ease this, but it’s interesting to look at exactly why Rails might boot up slowly.

I have a project that isn’t massively complicated, but it has suffered from “just add” culture. I’ve been told to “just add” Excel support, PDF generation, and a lot more features that require complex libraries. This naturally increases the memory footprint of my application, and it also increases boot time.

Before I started my analysis, the boot time averaged at 11.6 seconds. After my improvements the boot time is 7 seconds. By comparison, the code for Deadline boots in 4 seconds, but it has few dependencies (it’s a joy to work on by the way).

Read More →

Rapid Rails: Mastering Indexes

I wrote a series last year called “Rapid Rails”. It was all about making your Rails app and development process faster. I’ve been analysing the performance of some mature Rails projects recently, so rapid rails is back.

If I’m tasked with improving an application’s performance, the first thing I look at is indexes. Indexes are something you’re told are important when you learn about relational databases, but the effort of domain modeling usually makes most people forget all about them. That means you’ll often come across a slow project that can be improved just by adding indexes.

Rails lets you add these in a migration with add_index :table, :row or even add_index :table, [:row1, :row2]. Most of you probably already know this. What you might not know is your RDBMS might be ignoring your indexes anyway!

Read More →