Continuous Integration - Just another buzz word?

that Continuous Integration depends on is automated tests. Many people believe there is no way you can create enough automated tests to make a difference in the quality of the software. Even a small amount of tests can make a difference.

Automated tests can be broken down into several categories: Unit tests, smoke tests, and functional tests. Unit tests are tests typically written by developers to test individual methods, classes and/or groups of classes. Extreme Programming implements a test first approach where the developer must write an automated unit test prior to writing a line of code, then write the code to satisfy the test. Unit tests are excellent for Continuous Integration, however, there are few projects that have already established a test harness full of automated unit tests. For methodologies that are not so test-driven, focus time on automating smoke tests and functional tests.

Smoke tests are very high level tests that exercise the most basic of functionality in the application to determine application quality but with very low confidence. For example, you can start the application, log in, view a record, and close the application gracefully. Even though smoke tests may not verify quality with much confidence, this is usually an excellent place to start if your project has no tests to begin with. Take these smoke tests and integrate them into your integration build process. You may question the value of running smoke tests routinely on the latest code, but it is not uncommon for projects to go for weeks or even months without being able to create a build that can pass even a smoke test. Many times these projects don't know how far they are from having working software.

Once the smoke tests are incorporated into the integration build process, begin adding automated functional tests. When choosing what features to automate, prioritize them based on importance to the application, feature stability, and integration with other features. The highest priority features are those that are important to the application relatively stable and contain interdependencies. Having interdependencies with other features means that changes in somewhat unrelated features could affect the behavior in this feature. An automated test for this particular feature could reap benefits down the road.

The investment involved in creating these automated tests may seem high, but if you hook them up to an integration build that runs 3 times per day, each test will be run against the software at least 60 times per month. Every time they run they're helping to catch integration problems early, when they're easier to fix.

SCM Benefits of Continuous Integration

So the million dollar question is, "Is all this worth it?" Are your formal builds today non-events? Would it be worth the up-front costs to eliminate the late Friday afternoon builds that go well into the weekend because of integration problems? In the end, Continuous Integration produces higher quality software by offering developers appropriate feedback at a time when they can use it to improve the software. Along this same line, it's not uncommon to see a team go through a tedious 3-day release build process and installation into the test environment only to find out that the software release doesn't pass even the most basic smoke test. Continuous Integration catches these problems early and makes release builds much more reliable and predictable.

We can all agree that when implementing changes to software, integration issues must be addressed at some point. Addressing software integration issues at the point when the integration is developed is far less expensive and produces higher quality results than waiting until the formal release