(Release) Version Control

During my holiday I noticed that Scaled Agile Framework had been updated to version 3.0. I did watch the short update video by Lean Samurai (which was nice and compact), but I haven't really had time to get familiar with most of the contents yet. Some positive first observations include dropping Hardening out of the HIP-sprint (nowadays only Innovation-Planning) and making an attempt to include also strategy into the big picture. Although I like IP more than HIP, I don't really like dropping the shippability from the PSI. I'm glad that separation between development and releasing is still there. Maybe I will learn to like Program Increments.

But the topic I was about to write today is Continuous Integration. It has now been lifted to the big picture to get the attention I think it really deserves. Scrum doesn't offer engineering practices (XP does), so companies should amend their processes with some additional common agreements. Let me now write down some clichés that have some valid points behind them:

• You can't scale crap.
• You can't go fast if you carry a lot of extra.
• Integrate often.

Well, one could consider these also as plain facts. But the first two are more or less related to good coding practices and craftsmanship and staying Lean. Also keeping the technical debt as low as possible helps going faster. The last bullet is related to version control and software production.

We are applying the stable mainline pattern. To get a more thorough explanation on this please check here or here (again I find good stuff and it has Mr. Kniberg's name written on it. That guy is a wizard!) We use a rather well integrated set of Atlassian tools. Atlassian Stash as the basis of our repository management accompanied with Atlassian Bamboo crunching the builds. And they both communicate nicely with JIRA. (While looking for some nice pictures, I bumped into this video about making a demo integration. Maybe worth watching.)

When the code changes are checked in, the builds start automatically. They include running the automated tests (unit and integration), followed by more wider range system level tests if everything went well. Good changes are blessed with a nice green color, but any breaking changes result in an ugly red color.

In Bamboo you can configure the plans to make builds for all new branches automatically. This makes the creation of release branches handy (compared to some other CI frameworks where you need to configure a new build for each new branch.)

Finally, the big dilemma when we make releases. We branch the release from the trunk. This is communicated well in advance to all the teams and developers. But after we make the branching, we don't allow any more changes to the code. Stash offers a handy way to do it from the branch permissions. To be more precise, we do allow changes, but they need to be made via pull-requests and approved by the System Team.

My dilemma here is that I'd like to believe in people. I believe most of the restrictions usually hinder development. But then again, I believe many people are aware of the term feature creep. It's easier to fight it if you don't have a way to make changes. And the obligatory pull-requests have a built-in code review which usually helps improve the general code quality.