22 October, 2014

…asks Paul Hammant
We have a team of 6 developers and 1 release/QA Engineer; we practice Scrum and have 4 week long sprints and we’re a subversion shop. We hold a demo at the end of the 3rd week and as we don’t have dedicated testers everybody is involved with testing during the final week. Every Monday is our regular bug-fixing day.

We have a standard product and we do trunk-based development for that; new stuff and bug fixes committed to trunk. We have a nice system of Feature Toggles (more another day) and so far have had little need for Branch by Abstraction.

When testing is complete and bugs that need fixing are fixed, we redeploy Head to the server and our release engineer runs some final tests (typically he runs some manual sanity tests and validates the corrected bugs). If all is good the version is tagged.

For this final test we don’t bother creating a release branch, we’re small enough team to say no commits allowed until further notice, although the release engineer may commit one or two minor corrections. This usually takes half a day.

Alongside the standard product we have many client-specific versions. These are maintained by a separate ‘services’ team (2 or 3 developers). Their release schedule is much less onerous than ours – clients don’t like change. Each non-standard client has their own branch and when they want to update to the latest standard, they merge from our tag.

We’ve had this system in place for at least 18 months now. Up until then we had two (large) releases per year. For each release we would make a new (permanent) release branch. To this day we have a few branches of this type but they are being phased out as clients are upgraded and now it’s very rare that we bug fix on these. For clients that are still on these versions, we bug-fix on the corresponding standard branch. Our release engineer manually merges these fixes up to the next version whenever necessary. The service team tends to cherry pick fixes from these branches merging them to their client branch.

The move from 2 to 12 releases per year has significantly improved the quality of our releases and the near absence of the need to maintain old versions has made things much simpler. We’re still not satisfied with the quality of our software although it’s evident that there is no comparison when there were at most two large releases per year. I put this mainly down to the absence of having ‘real testers’ in the team. So far we’ve found it difficult to convince management to recruit people with this profile.