Share →
Buffer
Andrew Clear (Mug Shot)

If you haven’t heard, the future of software development is in continuous value delivery. We can easily envision a world in 5 years where if your product doesn’t have at least a monthly release cycle, you probably don’t have a product. A cornerstone of the continuous value delivery model is the Continuous Integration (CI) builds. A lot of ink, both real and virtual, has been dedicated to discussing why we should all be using CI build. Indeed, you could stock a moderately sized book shelf with nothing but tomes on the subject. And once you’ve fully stocked that bookshelf, you could purchase another and fill it with volumes instructing you on the how. Modern tools have made the process of setting up basic CI builds incredibly pain free (In Visual Studio 2012 you can set up a basic automated build with a custom trigger in about five minutes).

So the question becomes, why aren’t we?

For a lot of people, if the first taste is bad, the item is removed from the menu forever. While this may be a great idea for some things (they say what happens in Vegas stays in Vegas, but I’ll still never drink tequila again…) for our software practices the age old adage of “if at first we don’t succeed, try try again” might be more applicable (just don’t commit Einstein’s insanity). There are two major reasons why you might fall into this category: your build (or test suite) takes too long to run, or your team didn’t fully commit to continuous integration. The first is a technical hurdle, and the previously alluded to libraries of knowledge address the area completely. My colleague has a great rule of thumb when it comes to CI build times; they need to be shorter than the time it takes for the developer to get to her car. The second is a more fundamental issue, the heart of which lies with the simple observation that continuous integration is not a tool, it is a mind set. This is an important distinction. If your team is committed to continuous integration, but your process is giving you headache, consider changing your tool.

For others, the idea of “best practices” remains some fuzzy ideal on the shelf, forever crammed behind the need to put out today’s emergency fix. The greatest impetus to change comes from pain, and the lack of a CI build causes the greatest amount of pain at the time of the “Great Integration”. Unfortunately, this is the exact same period when you’re already working 60 hour weeks, and every necessary fix is an emergency fix. Not exactly the time you want to be designing and implementing a new process. It is however a great time to remind the holders of the purse strings about that crazy CI build idea you tried to sell them on six months ago.

For still others, your project started small and you thought there was no need for a CI build. Then it grew a bit, and then a bit more. You were beginning to think that maybe you should think about how your current processes would scale, but there were so many interesting new features to implement. Now you have a snarling monstrosity with no manners that takes a team of build engineers a couple months to corral into production. You know there is a better way, but the current way works. Well, kind of. Sometimes. As long as somebody doesn’t screw it up that is…

We understand all of these reasons. One of my colleagues worked on a team that attempted to implement a CI build with their entire existing automated (but not optimized) test suite. They eventually ended up with a gated check-in CI build that took almost 2 hours to run. That’s a lot of developer downtime, eventually leading to the abandonment of the whole thing (they’ve since got it worked out, and are enjoying CI utopia).

Maybe you’ve experienced one, or more of these scenarios, maybe you haven’t. The bottom line is that we know CI builds are supposed to make our lives easier, and our code cleaner, but sometimes the path from here to there isn’t all that obvious.

The Path to CI Utopia

Step 1: Team commitment

Notice that I said “team commitment”. Not company commitment, or IT commitment or anyone else. Get your team together, and if you are ready to drink the continuous integration Kool-Aid, then that is all you need. Sure, its easier to pull off CI with a build server and build agents that queue up automatically when you check in, but it isn’t necessary. Don’t believe me? Check out this post from James Shore. Remember, continuous integration is a mind set, not a tool. Of course, the further into your organization the tendrils of continuous integration can reach, the more benefit you will reap. There is a flip side to this coin. One or two  team members who refuse to drink the Kool-Aid can grind your CI machine to a halt; everybody on your team at least needs to be on the same page.

Step 2: Figure out where you are

Step back and take some stock of your current situation. You need to spend some time thinking about where you currently are before you zip off to the horizon. A quick sampling of some of the issues your going to want to consider: Do you have a build server? Can you set one up? Do you want to use a CI tool? Do you have automated tests? How long does it take to run the entire suite? Can you improve that? How committed are your developers? Are they willing to change their daily habits? Self-examination is a difficult skill to master, especially if you have little experience in this area, but getting a good snapshot of your current situation will smooth out the next few steps.

Step 3: Define where you want to go

This is an important, and often overlooked step. Continuous integration is an umbrella that covers quite a few different implementations, and some of those are better launching pads than others for the rest of your journey towards continuous value delivery. Maybe all you need is a simple automated build that triggers on check in and doesn’t run any automated tests. Perhaps you would rather have a gated check in that will only accept alterations to the source code with a successful build. Or maybe you need a fully automated pipeline, with multi-staged builds that run your complete suite of automated tests, including your automated UI tests (What’s that? You don’t have automated UI tests? Check out this video from Channel 9). Each of these scenarios, and this by no means is intended to be an exhaustive list, will require different bits, and varying degrees of acceptance penetration into your organization. Defining your goal now can eliminate a lot of headaches later. When in doubt, start smaller so your team can begin to see the benefits of CI builds faster.

Step 4: Map your route

And now we come to it. Hopefully you have someone available to your team who is experienced in this area and can give some much needed advice. If not, there is always that library of information you can slog your way through. Or you could seek some outside assistance to give your team some guidance in the right direction, and help you get off to a good start. I won’t make a feeble attempt to sum up the plethora of information already available, just be ready to put in a little effort before you start implementing.

Step 5: Implementation

Collect the bits, install the bits, and most importantly, train your team to use the bits. The most perfectly architectured continuous integration system in the world will fall flat on its face if your team doesn’t understand it and know how to use it properly. This stage will obviously vary depending on your map; just remember to keep everyone in the loop and fully trained.

Repeat as necessary

What? You thought you would get it perfect the first time? Our new software paradigm is all about feedback loops and iterations, and the implementation of a new software development practice is no different. Once you’re up and running, give it some time and then discuss it with your team. Identify the pain points and cycle through again. Someday you too can be just like Flikr.

Interested in getting some of that outside help I mentioned earlier? Northwest Cadence is offering a Builds Practices Health Check that can help you figure out where you currently are and begin the process of creating the map to where you want to be. Please contact Rick Flath for details.

Print Friendly
Tagged with →