DevOps Zone is brought to you in partnership with:

Johanna Rothman helps managers and teams solve problems and deliver products. Her most recent book is Manage your Project Portfolio: Increase Your Capacity and Finish More Projects. You can read her blogs and other writings at jrothman.com Johanna is a DZone MVB and is not an employee of DZone and has posted 103 posts at DZone. You can read more from them at their website. View Full User Profile

Is the Cost of Continuous Integration Worth the Value on Your Program?, Part 1

12.23.2011
| 6794 views |
  • submit to reddit

I like continuous integration. A lot. I started being an aficionado of continuous integration back in my senior year of university . It was my very first (and last) team project in my college career. There were three of us. The project manager waited until the night before the project was due to get us all together (argh #1). I had completed much of my code several weeks before (argh #2: who can remember what they’d written several weeks ago?). We wrote code madly for hours, and then tried to make it work, starting about 9pm. It didn’t work. We stayed up all night (argh #3). I finally went back to my dorm about 7am so I could shower and eat breakfast for my 8am class. The other two guys blamed me for leaving, saying I should stay with them. I explained nothing had worked yet, nothing was going to work if I went to my other classes (just about the only smart thing I’d said all night).

That’s the night I realized that if you don’t start putting software together a little bit at a time from the beginning it gets harder the more you have to put it together. I’ve been a fan of continuous integration ever since.

I am sure there are projects where continuous integration might not be the answer, and I have not met them yet. And, I admit, there are times when the cost of continuous integration seems pretty high.

The agilist in me says, “Do it more often. That way you see what the impediments are, so you can see what is so difficult and you can make it easier every time you do it.” The pragmatist in me says, “Not everyone knows how to do it more often. Have pity on these people. Do you want to make them suffer?”

I don’t want to make people suffer. I do want people to realize that continuous integration is often well worth their time, even on a large program. So, here are some steps to help you move to more continuous integration, depending on where you are.

What Does Continuous Integration Mean to You?

The first question is this: What does CI mean to you? To me, it means that the software is Done. That is, it is compiled, tested, and not just demoable, but releaseable.

Now, it doesn’t have to mean that to you, and it certainly doesn’t have to mean that on a program, especially on a large program. But you should know what continuous integration means on your program. And, you should know who decides.

On a program, I recommend that a technical program manager suggest a strawman proposal of what done means, and see if the feature teams can live with it. Then, the feature teams should test that strawman for a limited time, such as an iteration, and see if that proposal makes sense to them. If you’re working in kanban, set a time period, such as one week or two, to make sure you see some features flow through the system and see if the proposal makes sense.

Now, everyone knows what done means for the program, so you know what continuous integration can mean.

Where Are You in Your Journey to Continuous Integration and Agile?

The first step is to know where you are.

The ideal case: Are you finishing features every iteration, as often as every day or so? You are likely doing continuous integration across your program.

Finishing Stories All the End of an Iteration

What I see in many teams practicing agile: Are you finishing features in a hockey stick, with most of the features finishing at the end of the iteration? This is tricky, and leads to staged integration, and makes for staged integration in a program if all the feature teams do this.

What I see in some teams quite new to agile: Do your features span iterations? If your features span iterations, you need to make your features smaller. The reason to make your features smaller has nothing to do with continuous integration yet. Making features smaller is all about seeing your progress and providing feedback to the product owner/customer and making sure you actually complete work inside the iteration. If you are using kanban, this is similar to seeing a board not change for weeks while the same features are still on the board, nothing moving. You are also likely doing staged integration.

If some of your feature teams do one thing, some of your feature teams do something else and you need a way to merge them all together. When I work with program teams, I find the teams doing some of each of these. And, the waterfall teams are doing something else entirely. On a program, we need a way to bring the entire product together on a periodic basis.

Stay tuned for part 2.

Source:  http://www.jrothman.com/blog/mpd/2011/12/is-the-cost-of-continuous-integration-worth-the-value-on-your-program-part-1.html


Published at DZone with permission of Johanna Rothman, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Paul Russel replied on Sun, 2012/06/10 - 8:16am

I’m curious how CI could be expensive to implement? Even back in my waterfall days, we had at least a daily build and test process (this was in the early 90s!). Granted, back then we had a person whose whole job was taking care of that and the version control, but it didn’t seem too costly.

The smaller teams I’ve been on had CI up and running in a day or two with open source tools and a cheap server. I’ve worked at a larger company with 25 teams where a company-wide build ran at least once per day, and most of the small teams also had their own CI.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.