• Resources
• Case Studies
• Derivatives WIKI
• Derivatives Articles
• Derivatives Regulations
  • Derivatives and Hedging
  • Fair Value Measurements
  • Disclosures
  • Employee Stock Options
  • Basel II and Sarbanes-Oxley
• Expert Interviews
• Finance Survey
• Glossary
• Product Documents
• Webinars
• White Papers
• Login

Home > Resources > Articles > 2008

Continuous Integration - Software Engineering Best Practices

Overview

Continuous Integration is a software practise where each member of the software development team integrates their code changes on a frequent basis. This can result in many integrations per day. Each code change causes a new build to be automatically executed and unit tested. This gives very quick feedback to each developer about any code change that they make. Errors are discovered quickly, allowing the developer to fix any problems when the code change is fresh in his or her mind.

» Click to evaluate the lastest trial version of FINCAD Analytics.

Aspects of Continuous Integration

A good Continuous Integration system has several important aspects. They are:

1. Automate Builds

Continuous Integration requires frequent builds. This is especially true for large, complex software systems which are extremely vulnerable to integration problems. Many of these systems can take hours (or more) to build from beginning to end. It is simply not feasible to have one or more team members dedicated to performing regular builds. The knowledge of how to build the system must reside in one place: an automated build script.

Build scripts can take many forms. For simple systems, they could be a batch file, shell script, or makefile. More complicated systems generally require a more sophisticated build system1. Regardless of the tool in use, the build must be easy to run from a single mouse click or simple command line. Thus, a new build can be started by anyone or an automated, scheduled process.

2. Code in a Single Source Code Management Repository

Source code management (SCM) system is a vital component to any software company. In Continuous Integration, it is important that all code for a particular system is kept in the same SCM, ideally under the same repository. This allows for a single point of integration. Without a single point of integration, different repositories need to be synchronized periodically. This results in significant delays in the integration efforts. In extreme cases this can result in weeks, even months between the time a developer commits a change to SCM system and sees it integrated into the live product.

In cases where a single repository is either not possible or not desirable, synchronization between repositories should be automated and fast. All shared information should be small enough to be quickly and easily replicated across repositories. Any delays in replication can result in longer builds, delaying valuable feedback to developers.

3. Make Your Builds Self-Testing

In order to receive accurate feedback from a build, the build system must be able to test the results automatically. This usually means running the unit tests created by the developers. This ensures any change to the source code that breaks existing behaviour will result in a quick failure of the build. Failures can then be investigated and fixed before they are shipped to customers.

If the system has regression tests as well as unit tests, they can also be run as part of the build system. In some cases though, regression tests can take a very long time to execute, thus delaying feedback to developers. If this is the case, regression tests should be run less frequently, such as overnight, or once weekly.

4. Commit Source Code Changes Frequently

Developers should commit their changes to SCM on a frequent basis, at least once per day. Commits are a form of communication between the different developers through the code base. By committing often, developers are communicating their changes more often. This will result in any problems being discovered much sooner than if commits are held off until the very end of a development phase.

5. Keep the Build Fast

The most important aspect of Continuous Integration is constant feedback early on in the build process. Key to this is a fast build system. If a minor change in the code base requires a 7 hour build, a developer must wait a full business day before finding out if their changes are compatible with the other developers within the team.

In order to achieve a fast build, the build system must be able to do incremental builds in addition to a "clean" build. Incremental builds will only build what has been changed and that depends on what has changed. It will re-use the build artefacts from the unchanged code. This can introduce dramatic speed increases in a very complicated build process. Clean builds, which could run for hours, can then be used for release candidate (RC) builds, where it is advisable to be certain of what artefacts are included in a final customer facing software release.

6. Visible Build Status

Continuous Integration is not of much use if there is not a way for every team member to determine the current state of the most recent builds. Constant feedback isn’t very useful if it is hard to find. It is important to have an easy, accessible method for every interested party (QA, developer, manager, CEO, etc.) for finding out the current build status. This could be an email list (although this can be disruptive and therefore ignored), website, or something physical such as a red/green light or even a lava lamp3. Some methods are more effective than others, but the result is the same: wide reaching, public communication.

Example: Swap Portfolio Peak Exposure Profile

Continuous Integration is about increased communication between developers. By increasing the frequency and timeliness of communication, as well as automating testing, far fewer bugs are introduced into the product, resulting in more stable releases and ultimately, happier customers.

________________________________________

References

Fowler, M. (2006, May 1). Continuous Integration. Retrieved May 26, 2008, from martinfowler.com: http://www.martinfowler.com/articles/continuousIntegration.html

Disclaimer

Your use of the information in this article is at your own risk. The information in this article is provided on an "as is" basis and without any representation, obligation, or warranty from FINCAD of any kind, whether express or implied. We hope that such information will assist you, but it should not be used or relied upon as a substitute for your own independent research.

For more information or a customized demonstration of the software, contact a FINCAD Representative.