Code Library

Creating an official nightly build of a product has been known as an industry best practice since at least the early 1990s. Well, if a nightly build is a good idea, building a product continuously is an even better one. Continuous integration refers to integrating new or changed code into an application as soon as possible and then testing the application to make sure that nothing has been broken. Rather than checking in code perhaps every few days or even every few weeks, each programmer on a Scrum team running continuous integration is expected to check in code a few times each day—and to run a suite of regression tests over the entire application.

Continuous integration is usually achieved with the help of a tool or script that notices when code has been checked into the version control system. Cruise Control was the first product to gain popularity for automating continuous integration. It could build a product, run as many tests as desired against it, and could then automatically send a notification to the developer who broke the build (or to the entire team). Cruise Control could also send build results to additional feedback devices such as lava lamps, ambient orbs, spare monitors, LED displays, and more.

Some teams opt for a manual approach, in which developers initiate the build and test for each check-in. I strongly recommend against this. Although it is possible to be successful with a manual approach to continuous integration, my experience is that developers will occasionally skip the build and test. It is just too tempting to occasionally think, "I changed only two lines and it worked on my machine." It's also tempting to forgo the build and test when checking in code after your planned quitting time for the day: "Yikes, it's almost six o'clock," a developer may think. "I'm sure this works and I don't want to wait 15 minutes for the tests to finish...." Given the ease with which a continuous integration tool can be configured, it is almost always one of the first things I coach teams to do.

For most developers, the first exposure to automated continuous integration is eye-opening. I know it was for me. I'd become very accustomed to the benefits of a nightly build but had somehow never made the mental leap that if once a day is good, many times a day would be better. After working in a continuously integrated environment for a day, I was hooked. Not only could we eliminate all risk of big integration issues at the end of a project, but also the entire development team would be receiving near-real-time feedback on the status of the product.



" Maintaining a build server and all those tests takes time away from other work ."

A Scrum team will require a suitable automated testing environment regardless of whether it also does continuous integration. So, the only additional overhead is that of setting up and maintaining the build server environment. For most applications this investment will be paid back within the first month by the t i m e saved on integration issues.



" Our system is too complex; it takes hours t o run a full integration test—we can't build continuously ."

These days it is not uncommon to encounter a Scrum team with a test suite that takes hours to run. The solution is normally to partition the test suite rather than abandon the idea of continuous integration. Stephen Marsh and Stelios Pantazopoulos worked on the TransCanada pipeline project and did exactly this.

Several months into the project it became evident that running the full regression test in under fifteen minutes was not possible. As a result the regression test was split into two: a smoke test and a full test. The first ran after every check-in and included all test scripts from the current delivery milestone [sprint] and a subset of scripts from past milestones. The second ran once an hour and included all test scripts from all milestones. The first proved to be complete enough the majority of the time. Only on rare occasions did the second one fail. (2008, 241)



THINGSTO TRY NOW
• An official nightly build is a must for any Scrum team. Getting at least this much in place should be one of the first things you do if you don't have it already. The effort to get a nightly build in place will be paid back within a month at the most, so there's no excuse to be without one. Plan this into your next sprint.

• If you already have a nightly build, take the next step and start building continuously.

• If you have a continuous build, but no tests run as part of it, add some. Getting the first test of each type from this pyramid is a hurdle. But after the first test has been integrated, the rest come much more easily.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010