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!
VersaPay development flow features:
- 2 week iterations
- planning poker
- feature branches
- CI against all branches
- code & UX review
- deploy at the end of each iteration
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:
- redmine – A ticket management system.
- redmine backlogs plugin – UI to sort and group features per iteration.
- jenkins-ci – Continuous Integration server.
- gitorious – Open source Github like.
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.
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.
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.
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.
Creating a new branch will register it to the CI server thanks to jenkins-github-autobranch.
To know where we’re at, we’ve created a dashboard called Alfred.
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.
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.
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)
It’s now time to celebrate the deployment of the new release and do a quick retrospective.
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.