This article will describe some of the development tools that are available from the Java Open Source community and explore how they can help you create high-quality software in a predictable and reproducible fashion, saving you precious time and money. It is taken from chapter three of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259).
Development and Build System with ANT - Continuous Integration (Page 2 of 11 )
One modern software development practice that’s embraced by many methodologies and promoted, particularly by the Extreme Programming (XP) movement, is the practice of continuous integration. This practice might be one of the most important lessons you’ll ever learn from the XP and agile movement. The main idea is that developers working on a project should integrate changes to their code at least on a daily basis. In Chapter 4, the topic of testing is covered in the context of continuous integration. The basic steps to accomplish continuous integration are simple:
Integrate: Changes are checked into a central repository (code that adds new features requires new test cases that must also be checked in).
Test: All tests are performed. A successful integration is bound by a 100-percent success of the testing stage. If any tests fail, the offending code is rolled back and code is refactored until it passes the respective test(s).
Repeat: With the help of automation, you can run this process at well-defined intervals (ideally a minimum of once a day). This ensures that the system’s codebase remains fully tested at all times and that bugs and missing features are addressed as soon as possible.
Continuous Integration, as championed by XP and agile-methodology proponents, is one of those concepts that most developers agree with, but few teams ever implement. You should only build what’s necessary and it should be tested for compliance with the requirements as often as possible. You also should understand that making lots of changes at once leads to hours of “big-bang” integration testing later on.
By never holding on to changes in the code for more than a day, a team can minimize the chances that the code will become fragmented. These “unofficial forks” to a code base (they occur when a developer never integrates changes to the code base and is effectively working on an older version) lead to hard-to-find bugs and countless hours of integration effort.
By adopting a test-driven approach to development (see Chapter 4) in combination with build-process automation, a team can achieve Continuous Integration and build only what’s needed when it’s needed, and build it right. Continuous Integration increases the team’s knowledge about the system being built, thereby boosting its reaction time to feedback from the system and the system’s stakeholders.