Continuous integration: The value of CI

Learn about the value of continuous integration and get reasons why continuous integration can benefit the enterprise in this free sample chapter download.

The following is an excerpt from Continuous integration: Improving software quality and reducing risk, by Paul Duvall, Steve Matyas and Andrew Glover. Read the complete chapter about the value of continuous integration for free.

continuous integration


This chapter attempts to answer the questions that you may have when making the decision to implement the practices of continuous integration (CI) on a project. It provides an overview of the advantages and disadvantages of continuous integration, and covers how continous integration complements other software development practices.

At a high level, the value of continuous integration is to:

  • Reduce risks
  • Reduce repetitive manual processes
  • Generate deployable software at any time and at any place
  • Enable better project visibility
  • Establish greater confidence in the software product from the development team

Let's review what these principles mean and what value they offer.

Continuous integration reduces risks

By integrating many times a day, you can reduce risks on your project. Doing so facilitates the detection of defects, the measurement of software health, and a reduction of assumptions. 

  • Defects are detected and fixed sooner—Because CI integrates and runs tests and inspections several times a day, there is a greater chance that defects are discovered when they are introduced (i.e., when the code is checked into the version control repository) instead of during late-cycle testing.
  • Health of software is measurable—By incorporating continuous testing and inspection into the automated integration process, the software product's health attributes, such as complexity, can be tracked over time.
  • Reduce assumptions—By rebuilding and testing software in a clean environment using the same process and scripts on a continual basis, you can reduce assumptions (e.g., whether you are accounting for third-party libraries or environment variables).

CI provides a safety net to reduce the risk that defects will be introduced into the code base. The following are some of the risks that CI helps to mitigate. We discuss these and other risks in the next chapter.

  • Lack of cohesive, deployable software
  • Late defect discovery
  • Low-quality software
  • Lack of project visibility

Continuous integration reduces repetitive processes

Reducing repetitive across all project activities, including code compilation, database integration, testing, inspection, deployment, and feedback. By automating CI, you have a greater ability to ensure all of the following.

  • The process runs the same way every time.
  • An ordered process is followed. For example, you may run inspections (static analysis) before you run tests—in your build scripts.
  • The processes will run every time a commit occurs in the version control repository.
  • This facilitates
  • The reduction of labor on repetitive processes, freeing people to do more thought-provoking, higher-value work
  • The capability to overcome resistance (from other team members) to implement improvements by using automated mechanisms for important processes such as testing and database integration

Continuous integration generates deployable software

CI can enable you to release deployable software at any point in time. From an outside perspective, this is the most obvious benefit of CI. We could talk endlessly about improved software quality and reduced risks, but deployable software is the most tangible asset to "outsiders" such as clients or users. The importance of this point cannot be overstated. With CI, you make small changes to the source code and integrate these changes with the rest of the code base on a regular basis. If there are any problems, the project members are informed and the fixes are applied to the software immediately. Projects that do not embrace this practice may wait until immediately prior to delivery to integrate and test the software. This can delay a release, delay or prevent fixing certain defects, cause new defects as you rush to complete, and can ultimately spell the end of the project.

Continuous integration enables better project visibility

CI provides the ability to notice trends and make effective decisions, and it helps provide the courage to innovate new improvements. Projects suffer when there is no real or recent data to support decisions, so everyone offers their best guesses. Typically, project members collect this information manually, making the effort burdensome and untimely. The result is that often the information is never gathered. CI has the following positive effects.

  • Effective decisions -- A CI system can provide just-in-time information on the recent build status and quality metrics. Some CI systems can also show defect rates and feature completion statuses.
  • Noticing trends -- Since integrations occur frequently with a CI system, the ability to notice trends in build success or failure, overall quality, and other pertinent project information becomes possible.

Continuous integration establishes greater product confidence

Overall, effective application of CI practices can provide greater confidence in producing a software product. With every build, your team knows that tests are run against the software to verify behavior, that project coding and design standards are met, and that the result is a functionally testable product.

Without frequent integrations, some teams may feel stifled because they don't know the impacts of their code changes. Since a CI system can inform you when something goes wrong, developers and other team members have more confidence in making changes. Because CI encourages a single-source point from which all software assets are built, there is greater confidence in its accuracy.

Continuous integration: Terms of the trade
  • Automated: A "hands-off" process. Once a fully automated process begins, no user intervention is required. Systems administrators call this a "headless" process.
  • Build: A set of activities performed to generate, test, inspect, and deploy software.
  • Continuous: Technically, continuous means something that, once started, never stops. This would mean the build runs all the time; however, this isn't the case. Continuous, in the context of CI, is more like continual, and in the case of CI servers, a process continually runs, polling for changes to the version control repository. If the CI server discovers changes, it executes a build script.
  • Continuous integration: "A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily—leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."
  • Development environment: The environment in which software is written. This can include the IDE, build scripts, tools, third-party libraries, servers, and configuration files.
  • Inspection: Analysis of source code/bytecode for the internal quality attributes. In the context of this book, we refer to the automated aspects (static and runtime analysis) as software inspection.
  • Integration: The act of combining separate source code artifacts together to determine how they work as a whole.
  • Integration build: An integration build is the act of combining software components (programs and files) into a software system. This build includes multiple components on bigger projects or only low-level compiled source files on smaller projects. In our everyday life, we tend to use the terms build and integration build interchangeably, but for the purposes of this book we make the distinction that an integration build is performed by a separate integration build machine.
  • Private (system) build: Running a build locally on your workstation before committing your changes to the version control repository, to lessen the chances that your recent changes break the integration build.
  • Quality: The Free On-Line Dictionary of Computing defines quality as "an essential and distinguishing attribute of something..." and "superior grade." The term quality is often overused, and some seem to think it is based on perception. In this book, we take the stance that quality is a measurable specification just like any other. This means you can identify specific metrics of quality, such as maintainability, extensibility, security, performance, and readability.
  • Release build: Readies the software for release to users. It may occur at the end of an iteration or some other milestone, and it must include any acceptance tests and may include more extensive performance and load tests.
  • Risk: The potential for a problem to occur. A risk that has been realized is known as a problem. We focus on the higher-priority risks (damage to our interests and goals) that have the highest likelihood of occurring.
  • Testing: The general process of verifying that software works as designed. Furthermore, we define developer tests into multiple categories, such as unit tests, component tests, and system tests, all of which verify that objects, packages, modules, and the software system work as designed. There are many other types of tests, such as functional and load tests, but from a CI perspective, all unit tests written by developers, at a minimum, are executed as a part of a build (although builds may be staged to run fast tests first followed by slower tests).

Next Steps

Continue reading this free chapter about continuous integration

Read other excerpts from data management books in the chapter download library

Dig Deeper on Data integration

Business Analytics
Content Management