Continuous Integration Support
When more than one developer is working on a software project, from time to time
the team members need to integrate their changes to the project’s codebase
and then run a build to see if the renewed code can be built and, if the build succeeds,
and if it works without errors. These builds (they indicate the “health”
status of the entire project) are called integrated builds. Normally, they
are performed occasionally (e.g. right before the deadline) or regularly (for instance,
weekly or daily). It is hard to locate errors that arise in integrated builds that
are performed rarely, since the number of changes introduced between the previous
and current builds may be tremendous. To reduce the number of errors revealed in
integrated builds and to make it is easier to find errors, you should perform these
builds as often as possible. Ideally, builds should be performed right after the
source code of your project has been modified. This will help you continuously maintain
the integrity of your codebase - it will be much easier to find errors that appeared
after modifying the source code, because you will always know which source files
were changed for this build. It is also recommended that each build be tested and
reported appropriately. By following this strategy, you will always be able to provide
developers and users with a working build compiled using the latest versions of
the source files. The strategy is called continuous integration (http://www.extremeprogramming.org/rules/integrateoften.html).
It works well if:
Your code is stored in a central location, preferably a source code control product
like Visual SourceSafe. Build Studio macros can access different source control
repositories. See
Supported Tools.
You have automated your build process, say, by writing an appropriate Build Studio
macro.
You have included tests (unit, functional, regression, etc.) in the codebase as
part of the project (optional). These tests can be run as part of the build macro.
See
Automation of Testing and
Profiling Cycles.
Notifications about the build and test results are sent to respective users automatically.
You can do this by including the appropriate operations in your macro. See
Automatic Notifications.
As you can see, Automated Build Studio supports all of the prerequisites of continuous
integration. In addition, it includes facilities that allow you to practice continuous
integration of your projects in full. The main facility is a dedicated Windows NT
service called Automated Build Studio Service.You can configure this service
via Build Studio’s user interface to track all the changes in files of the
specified project under source control systems such as Visual SourceSafe, Subversion,
CVS or Perforce. To reduce the amount of time spent on interaction between the service
and source control system and to lower the use of resources, the service does not
poll the source control repository constantly, it does this at certain time intervals.
Thus, using Automated Build Studio as a continuous integration solution lets you
get reliable up-to-date automatic builds of your software at any time.