Continuous Integration - Just another buzz word?

is created and fails.

Continuous Integration helps to establish a "team" mindset for the build, whereby if the build breaks, it is a team-wide priority to get it fixed. Traditionally, the release build oftentimes integrates code changes for the first time, causing build problems that are left up to the build engineer to deal with. Many times the build engineer ends up removing features from the build to get it to work. By incorporating these integration activities earlier in the process, more features end up in the build and the effort typically ends up being more of a team effort.

Recap

Incorporating Continuous Integration into your project may seem like a daunting task, but it's not all that bad. You likely already have a fully automated build environment, so the biggest task will likely be incorporating automated tests. Don't be afraid to put the integration build in place with no tests to start with and add them as you go. Just verifying periodically that the latest code in your repository actually compiles adds value. Most good things are implemented and improved upon incrementally, so start small and build onto it. Your developers will become more productive. Your software will be of higher quality and release builds will become non-events. It won't be long before you wonder how you survived without it!

SCM Specific Concerns with Continuous Integration

Who owns the build?

Now that we're recommending adding a new build type to the development process, the question is, "who owns the build?" As discussed earlier in this article, this build is owned by both the developers and the SCM group. However, it's also important for this build to be an exact replica of the formal release build that the SCM group is responsible for, so we've found that a team effort between developers and the SCM group is very important. The SCM group is there to provide support for the automated build process and the build is initiated as well as the results interrogated by the developers. Development takes responsibility for the build and SCM takes responsibility for the build process, and the two must work together as a team.

How should we track Integration Builds?

Integration builds are not intended to be tracked beyond the latest "successful" build results. Therefore, no label is applied to the SCM repository to track integration builds. The only important item to store for these builds is the last successful applicable targets, in case the development group should want to install and test the latest. This implies that the prior successful build results be temporarily stored off during the integration build so that they're not overwritten, just in case the latest integration build turns out to be unsuccessful.

How should we handle multiple concurrent releases?

The Continuous Integration process is set up for each codeline. Some codelines will choose not to leverage Continuous Integration, and others will. You may have multiple concurrent active development codelines, each having their own Continuous Integration build process implemented. There are several situations that can occur when doing parallel development where we need to propagate a change from one codeline to another. This should be done in a workspace first and the developer should verify the integration of that code prior to committing it to the SCM repository. The receiving codeline's Continuous Integration process will ensure proper integration. Code integration is not a magic event. It involves bringing changes together from two areas that were unaware of each other and testing to see that they play nice together. Therefore, in environments that implement Continuous Integration, it is not recommended to