Continuous Integration: Begin Again

We’ve been using CruiseControl productively for a number of years. First as a stop gap in ensuring build success on multiple operating systems, later as a quick check of tests. More recently we’ve added reporting, and tests as part of a larger memory analysis platform.

But, being a bunch of software developers means we are continuously craving something different, like switching to Haskell and using Ruby on Rails. Joking aside (and nobody panic) it is more that we look at areas of our build processes to identify the pain points, and what can be done to improve them. I mean, that’s how we provide value right? By continuously improving processes and features.

This time we took a look at things we don’t change often, but end up injecting a lot of pain into the process each time they are done. And these pain points become more obvious as we increase our agile usage, as they occur more frequently than they did in the past.

How often do you go through your “official” release process? In my past life it used to be this occurred every six months at best, a year or so on a bad year and a long time ago (in a far far away land) I had the opportunity to work on a project that lasted 7 years. Now granted I certainly wasn’t on it for seven years, people tended to drift on and off the project but it took seven years to ship. That was a long time ago.

Today we are looking at monthly cycles, or in the case of very specific changes even two week cycles. Those painful processes that were blotted out with 6 months between them now happen pretty frequently. We used to not bother with the problems, just moan a little and trudge through it. But agile changes that. Continuous Integration changes that. These processes should work, be easy to change, and adapt quickly. Anything that doesn’t adapt you want to drop as quickly as possible.

To do that we’ve started looking at new tools for our processes. Because new tools solve all your problems right? As soon as you started compiling in C++ from C all your problems went away right? Okay not really. Tools are nice, tools make a good impetus for change, but change solves your problems. Yes moving to C++ provides you with access to new functionality, but only until you actually implement and use exception handling in a structured manner do you really get value out of the tool.

Sometimes it’s felt that the tool is enough. I mean when you switched SCM products you kept your old processes. Sure, maybe they didn’t quite fit the new tool and you had to write a lot of scripts, but it was what you were used to. You may even be nodding your head right now. Nothing like shoe horning a process you created 5 years ago into a tool adopted last year. If you didn’t change your process how did the new tool provide value? Performance and scalability may get you some value, but new features and usage patterns get you a lot farther.

As part of examining our build and integration tools, we looked at processes. What areas of our process are not formal? Is there a specific person who knows the incantations to make it work? What happens when machines fail, do we have alternative machines that can take up the slack? Can we run multiple builds on the same machine? Multiple tests? How do we get and review our results? What are the top 3 pain points for each person involved?

Not only does asking these questions help us understand the process better, but it identifies the areas of change. And with these changes we can leverage both our existing tools as well as the new tools we’ve chosen to acquire. It helps our existing team, and it helps those who join us in the future. They’ll be more productive faster. We’ll have time to work on the features our customers want, and instead of just getting by we’ll be able to use forward looking technologies.