Configuration Management Systems, Automated Tests, CI, and Complexity

Dean Wampler — Mon, 08 Sep 2008 16:53:00 +0000

I’m working with a client that has a very complex branching structure in their commercial CM system, which will remain nameless. Why is it so complex? Because everyone is afraid to merge to the integration branches.

This is a common symptom in teams that don’t have have good automated test coverage and don’t use continuous integration (CI). Fear is their lot in life. They’ll keep lots of little branches and only merge to integration when they’re ready for the “big bang” integration.

I spoke with a manager at the client site today who expressed frustration that no one really knows which branch they should be committing to and when they should merge to the integration branches.

In contrast, projects with good test coverage and CI do almost all their work on the integration branch. They have little fear, because any problems will get caught and fixed quickly. So, the first point of this post is:

Automated test coverage and CI drastically simplify your use of configuration management.

Here’s something else I’ve noticed, open source CM systems seem to focus on different priorities than commercial systems. Disclaimer: I know I’m generalizing a bit here.

The commercial systems tend to be really good at managing complex branching, with fancy GUI tools to help manage the big trees of branches, facilitate merges, etc. That seems to be their biggest selling feature, GUI’s to manage the complexity.

In contrast, most of the open-source CM systems have lower-tech GUI’s, if any, but the teams using them don’t seem to care that much. Usually, this is because these teams are also practicing TDD and CI, so they just don’t need the wizardry as much.

The open-source CM systems seem to be better at scalability and performance. Some are pioneering distributed CM, e.g., Git and Mercurial. Git, for example, was designed to manage a massive project called Linux. Maybe you’ve heard of it.

Distributed CM is not easy, but it’s a lot easier to do if you don’t need to worry as much about complex branch hierarchies.

Most of the commercial tools I’ve seen don’t scale well and some require way too much administration. My client is apparently the biggest user of their particular tool and the developers complain all the time about performance. This tool is not designed to scale horizontally. The only hope is use faster hardware. In this case, the vendor has focused on managing complexity. To be frank, even their GUI tool is an uninspired and slow Java fat client.

So the second point of this post is:

Avoid CM tools that encourage complexity. Pick the ones that scale.

"Configuration Management Systems, Automated Tests, CI, and Complexity" by Alex

Tue, 23 Sep 2008 21:19:18 +0000

You read my mind:

http://www.accurev.com/press-releases/092308-accurev-47.html

and

http://www.accurev.com/press-releases/030408-accurev-electriccloud.html

Best, Alex

"Configuration Management Systems, Automated Tests, CI, and Complexity" by Tim Ottinger

Tue, 09 Sep 2008 16:16:20 +0000

Preach it, brother!

I’m seeing this in too many places. I think it’s a coping mechanism for systems where the pace of completion is not respected. They don’t want to commit to something unless it’s done, and they define “done” too far out for the development team to keep up.

It is just as bad where the work is not done in short cycles, as far as I can tell. But when the release cycles are shortened the company will go to mad branching instead of shorter units of work.

We know that delayed integration results in errors and cost, and CI solves problems before they get big. We know that unmerged code is like milk outside the fridge, that it rots and eventually should be discarded for safety reasons. We know that delaying pain increases pain.

Yet this seems to be a lot of manager’s first-twitch reaction. And it’s expensive and trouble-causing.

Tim

Object Mentor Blog: Configuration Management Systems, Automated Tests, CI, and Complexity

Configuration Management Systems, Automated Tests, CI, and Complexity

"Configuration Management Systems, Automated Tests, CI, and Complexity" by Alex

"Configuration Management Systems, Automated Tests, CI, and Complexity" by Tim Ottinger