Search This Blog

Wednesday, February 23, 2011

The Best Continuous Integration Tools

In modern enterprise development, a complex project scope is very common. In this article, I will talk about the latest continuous instigation tools such as Apache's Continuum, Cruise Control (CC), and Hudson; all of them are designed to deal with project complexity, streamline build process, and report issues with the code as soon as they occur. They are perfect for use in an enterprise environment with large to medium size teams, may require a dedicated machine, and provide visual dashboards. These tools also enforce the process of continuous integration and are tightly coupled with a source control system, such as CVS, Subversion, and so forth. They may also simplify code maintenance and reduce the number of the issues that need to be fixed during the QA cycles.

The Continuous Integration Process Defined

The term "continuous integration" refers to a process that builds and tests code on a frequent basis. It was coined by Martin Fowler and Kent Beck, who first wrote about this process near the turn of the millennium.
The continuous integration servers constantly monitor source code repositories and as soon as new changes/commits are detected, they initiate a new build cycle. The build cycle actually involves code compilation and, in addition, may involve various tests and code analysis. If the process encounters errors, it may notify the build master or the culprit who checked in broken/invalid code.
The process can be summarized in these four steps:
  1. Team members check in code artifacts into the source control repository.
  2. The automated build server constantly monitors the repository.
  3. New code is continuously checked out [by this server].
  4. A new project build is continuously integrated and any issues are reported in real time.
There is much more to this concept and to the actual implementation of these automated build servers&mdahs;or continuous integration tools—such as definitions of best practices for the code structure, check-in locations, and so on. For instance, the process specifies that all working code should be in the main branch (trunk) of the code repository, and even though various tools can work with multiple branches, it is not recommended to do that.

No comments:

Post a Comment