VersaPay Development Flow

Thoughtbot, Github and PlataformaTech shared their development flow over the past few months. Our development flow differs quite a bit as well as our Product Management process so we believe that they are worth sharing!

Flow

VersaPay development flow features:

  • 2 week iterations
  • planning poker
  • feature branches
  • CI against all branches
  • code & UX review
  • QA
  • deploy at the end of each iteration

Tools

To support our workflow, we use a couple of well known open source tools, and a few we’ve built ourselves and released on Github. We use the following well known tools:

We developed the following tools to support our work flow:

  • gitmine – A command line tool for Git and Redmine!
  • Alfred – A dashboard linking Git branches, Redmine and Jenkins.
  • viewcumber – Cucumber formatter to browse your application by clicking through your cucumber scenarios.
  • mothership – Anyone can deploy in one click!
  • jenkins-github-autobranch – Create, Run or Delete Jenkins jobs whenever a new branch is Created, Updated or Deleted on Github or Gitorious.

Each feature is described in a Redmine ticket and will live in a feature branch starting with its ticket number followed by an explicit name. We use gitmine to automate creating, checking-out, reviewing and deleting branches.

Product Management

We used Basecamp for a while. It is a great tool for small projects but the todo list became hairy after a while. So we gave a try to Pivotal Tracker. It is great as long as you have a small amount of tickets and don’t want to store discussion around features. So we ended up going with Redmine. Ok, it feels like getting back to a tool from the 2000s but it is so customizable that it really fits our Product Management and Support processes now.

Epics – 60.000 foot plan

We are a public company, so we need to have quarterly plans. The “big” features we want to implement in a quarter are stored in Epics. The Product Manager takes care of those.

An Epic has many Features.

Support and Problem Statements

All emails sent to are turned into Redmine Support Tickets. We relate most Support Tickets to Problem Statements.

Problem Statements centralize similar issues or feature request into one ticket. They are defined in a weekly meeting involving the Product Manager and the Support team.

Features

Most Features relate to Epics and Problem Statements. They are stored in the Backlog that we keep ordered using the Backlogs plugin.

The Features are defined by the Product Owner and the development team before each iteration.

Let’s do some real work :)

We work on two weeks iteration. Each iteration starts with a planning session where we fetch the Features from the top of the backlog and estimate them using planning poker.

Ignition!

When you start working on a feature, just type:

gitmine branch 6940-french-i18n

This will create a remote branch, a local tracking branch and add a note to the ticket with a link to the compare view on Github or Gitorious.

Comment on Redmine by Gitmine

Creating a new branch will register it to the CI server thanks to jenkins-github-autobranch.

Iteration Status

To know where we’re at, we’ve created a dashboard called Alfred.

Lafred Dashboard

It shows the feature branches with their statuses, CI status and links to jump to the ticket, git compare view, CI console outputs and viewcumber output.

When someone feels like doing some code review, he can check out this branch locally running:

gitmine checkout 1234

This feature might involve UI changes. It’s always a pain to checkout, migrate, run a rails server and setup accounts to check what the info box on the screen “Approve a Payment Request with an existing Credit Card when I have access to multiple VersaPay accounts” looks like.

UX Review

To solve this issue, we created Viewcumber. It’s a cucumber formatter that generates a Cappucino app allowing you to browse your application by clicking through Cucumber scenarios.

Viewcumber on VersaPay

The feature is ready to deploy? Just type:

gitmine reviewed 1234

to merge this feature to master and delete the remote branch. Deleting the remote branch will delete the jobs from the CI server and it will disappear from Alfred.

Deploy in a few clicks

End of the week, it’s time to deploy. We want everyone to be able to deploy track the deployment and make sure that we always follow the following flow:

  • double check which tickets are being deployed
  • merge & deploy to staging (both the application and the Chef recipes)
  • merge & deploy to demo (both the application and the Chef recipes)
  • merge & deploy to production (both the application and the Chef recipes)

So we made a tool called Mothership. It’s a very simple ActiveAdmin application were you can define sequences of shell commands you want to run.

Mothership run to deploy VersaPay

It’s now time to celebrate the deployment of the new release and do a quick retrospective.

Conclusion

We are quite happy with the product management & development flows we refined over the past 2 years. Most of the tickets are well organized and we don’t have a lot of non-relevant tickets. The tools we developed to support the development flow makes it seamless and we are confident that we always deploy a fully tested and quality assured application with elegant code.

Comments are closed.