Last week, I spend several days fixing a bug that only surfaced in a distributed environment.I felt pressure to fix it quickly, because our continuous integration build was red, and we treat that as a “stop the line” event. Then I came across a post from Tomasz Nurkiewicz who claims that breaking the build is not a crime. Tomasz argues that a better way to organize software development is to make sure that breaking changes don’t affect your team mates. I agree.
Broken Builds Create Friction
Breaking changes from your co-workers are a form of friction, since they take away time and focus from your job. Tomasz’ setup has less friction than ours. But I feel we
can do better still. In a perfect Frictionless Development Environment (FDE), all friction is removed. So what would that look like with regard to version control? With current version control systems, there is lots of friction. I complained about Perforce before because of that. Git is much better, but even then there are steps that have to be performed that take away focus from the real goal you’re trying to achieve: solving the customer’s problem using software. For instance, you still have to create a new topic branch to work on. And you have to merge it with the main development line. In a perfect world, we wouldn’t have to do that.
Frictionless Version Control
So how would a Frictionless Development Environment do version control for us? Knowing when to create a branch is easy. All work happens on a topic branch, so every time you start to work on something, the FDE could create a new branch. The problem is knowing when to merge. But even this is not as hard as it seems. You’re done with your current work item (user story or whatever you want to call it) when it’s coded, all the tests pass, and the code is clean. So how would the FDE know when you’re done thinking of new tests for the story? Well, if you practice Behavior-Driven Development (BDD), you start out with defining the behavior of the story in automated tests. So the story is functionally complete when there is a BDD test for it, and all scenarios in that test pass. Now we’re left with figuring out when the code is clean. Most teams have a process for deciding this too. For instance, code is clean when static code analysis tools like PMD, CheckStyle, and FindBugs give no warnings.
Some people will argue that we need a minimum amount of code coverage from our tests as well. Or that the code needs to be reviewed by a co-worker. Or that Fortify must not find security vulnerabilities. That’s fine. The basic point is that we can formally define a pipeline of processes that we want to run automatically. At each stage of the pipeline can we reject the work. Only when all stages complete successfully, are we done. And then the FDE can simply merge the branch with the main line, and delete it. Zero friction from version control.
What do you think?
Would you like to lubricate your version control experience? Do you think an automated branching strategy as outlined above would work?
Reference: How To Remove Friction From Your Version Control Experience from our JCG partner Remon Sinnema at the Secure Software Development blog.
