Defining Enterprise Continuous Integration

Enterprise Continuous Integration (ECI) is an extension of Continuous Integration (CI) to multiple projects. This short article gives you a brief overview of ECI, its characteristics, benefit and current limitations. As we progress in developing this practice, I will continue to provide additional links and information.

CI is inherently a Single Code Base Practice

Continuous Integration is a software development practice where a project team rebuilds, tests and often deploys their software system with every change to that system -- often several times per day. CI is inherently a single-application practice, in that it is generally implemented by a single project team working on a shared source code base.

ECI Extends CI

ECI extends the concept of Continuous Integration to account for multiple applications that need to be integrated at a higher level, or otherwise need to coordinate their CI activity (e.g. central administration). As such, it is inherently a multi-application practice.

Key ECI Characteristics

  • ECI is aimed at coordinating multiple application builds, or multiple builds across a large project.
  • ECI can include multiple levels of integration
  • ECI accounts for central administration of builds.

ECI Benefits

  • Earlier detection of integration issues among projects/code bases
  • Better regression testing for production systems with multiple applications
  • Increased confidence that changes by one group will not negatively impact others
  • Increased discipline and flexibility in the enterprise change management process
  • Clearer definition of the enterprise�s approach to environment changes
  • Shifts IT focus from policing procedures to defining expectations as a method of ensuring quality (which scales better)
  • Accurate and frequent feedback to interested parties, even at a distance.
  • Increased sophistication of testing. Testing groups can focus on more difficult quality problems, instead of just ensuring integration was successful.

ECI Risks and limitations

  • Handling External dependencies:
    • Databases
    • Mainframes
    • Third-Party apps
    • Other applications
  • Emerging Tool Support
    • Build tools are only now supporting multiple projects
    • Testing tools are weak on enabling the kind of in-build testing needed at this level (just now maturing for individual project-level builds).
    • Limited integration with other enterprise code and change management tools

  • Requires Cultural Shift to adopt

    • Can�t be slapped down and enforced
    • Requires buy-in
    • Enables (but does not require) adoption of agile process at the project level, but agile project will reap the most benefits of implementing this practice

  • Requires skilled testing
    • Both at the individual project level (i.e. can�t dump testing onto other groups)
    • And at the integration level (but working more closely with each project than typical integration level testing groups do.
    • Techniques are needed that are different from traditional QA testing � including increased use of automation.


ECI seeks to take the benefits of CI to larger projects and the coordination of many interrelated smaller projects. As tools and techniques become more mainstream, the challenges of adoption will decrease, but the adoption of ECI does mean changing some IT practices, in order to gain the benefits of Agile at the enterprise level.