In my current role at cpap.com, I’m working on improving the workflow of our small development team. We made the switch from SVN to git a couple of years ago, but the tools we had available at the time didn’t really support us well, so we had to fight to stop using git like we used SVN.

As the developers got more comfortable with git (and as we brought in new blood to the company), the workflow has organically changed to be closer to the original plan. Now only the lead developers push changes into master, and developers pull off feature branches when they get a new ticket.

It’s working well, but still our tools weren’t supporting us like they should, so a few months ago I embarked on a journey to bring our tools up to scratch. Unfortunately, the best tools that I could find refuse to support (or acknowledge) anything other than gitflow. I have beaten them into shape, supporting how we work, but it hasn’t been easy, and it hasn’t been the promised land.

While normally it would be naive to assume that our precious snowflake workflow would work out of the box, our workflow isn’t actually that unique, and is the one that best supports both our team and how our business operates.

The Workflow That Was

Before discussing how we came to our current model, let’s quickly discuss what we had before the change to git.

Our core systems were started almost 15 years ago (and there’s still a surprising amount of original code) with a small team - one man, in fact. Over the years, as the company grew, more developers joined on, and subversion started to show its weaknesses.

Merge conflicts were frequent; there was little access control to ensure that a developer didn’t accidentally (or maliciously, for that matter) commit unfinished code into trunk; the lead developers were just as swamped with tickets as everyone else; code quality suffered, despite the best efforts of the team. Suffice it to say that mistakes were made because there wasn’t sufficient ability to control what happened.

The Workflow That Became

Out of the madness came git. It was a hard sell to begin with - everyone had to learn new skills, I had to write stupid amounts of documentation, and we were limited by the tools we could get. We spent a long time figuring out a workflow that we thought could achieve our goals and generally make life better. We almost got there, too.

We ended up with a workflow that very closely resembled the Open Source workflow that is seen all over github. We didn’t just have a master branch, we had a "mainline" repository, and only the lead developers could commit to that. All work by other developers was done through their own clones of the project, and fed back to the upstream with merge requests.

We had deficiencies with this. Our chosen repository server couldn’t automatically keep developer’s clones up to date (again, this isn’t uncommon in the Open Source world), so we had to introduce everyone to remote repositories. We had to pull from mainline to get upstream changes, and so help us if we accidentally pushed changes to our own master branch. Our plans for a CI server fell through - we couldn’t get merge request hooks to fire reliably, and when they did, we couldn’t get the results of a build back in a meaningful way. It was a vast improvement, but we still weren’t where we wanted to be.

The Workflow To Come

So that’s how we got to where we are today. We’re revamping our tools with BitBucket and Bamboo from Atlassian. I cannot heap enough praise on these tools - they work really well for our team, and they work really well in general.

But...

They don’t support our workflow - at least not out-of-the-box. You see, they are tools designed for big companies whose software works on ‘release cycles’ and ‘milestones’. We’re not that company. Someday we may be, but the day-to-day business in a competitive e-retail marketplace simple doesn’t work like that. Too many feature requests have to be dealt with like hot fixes - we have to react to what our competitors do, as well as working on long-term goals, and general code-base reform projects. We have a mixture of jobs, very few of which would fit neatly into gitflow, or any "release" based workflow.

So here we are, with a workflow that does work surprisingly well for a team of our size. We follow the Open Source model (and also contribute to Open Source projects when we can). But again, we’re being let down by our tools.

In BitBucket, you have to install a plugin to notify your build server of a pull request - something which should be baked in to the software. On Bamboo, you have to manually find and check out the commits from the pull request before you can build them - again, something that should be easy (we accomplished it with a couple of minor custom scripts).

Bamboo 5.10 has introduced native build status notifications to BitBucket, but they only work with true branches. If you run your build against a pull request, the build will get attached to the commit you are attempting to merge to instead of the commit that you’re trying to merge from. In the 5.9.* family of Bamboo, you can set up post-build commands which notify BitBucket through the build status API, but again, this is non-supported behaviour which should be baked in.

Again, it’s been worth the upgrade - we have CI services which actually work now. We have developer forks which keep up with upstream. We have a pull request model that’s actually enjoyable to work with. We have diffs which show us what will actually change, even on large commits.

Gitflow isn’t the be-all and end-all of workflows. For many teams (especially small teams like ours), it would actually be detrimental to the business. I long for the day where our workflow is enabled natively in tools outside of github and Travis CI. Hopefully we will soon see that day, but for now I’ll Frankenstein it together and keep our team moving forwards.