Continuous Integration

CI (Continuous Integration) is the process of taking features from the Program Backlog and developing, testing, integrating and validating them in a staging environment where they are ready for deployment and release, often requiring a three tier approach of Story integration, System integration and Solution integration.




Story Integration

Since Features are too abstract to be coded directly, they must be converted to Stories during PI Planning. Each story is defined, coded, tested and integrated into the baseline.


Team members integrate their work frequently and apply automated continuous integration environments.


To ensure new features work compatibly with all existing functionality, the system must be continually tested as well, so the team apply automated testing and test-first development (aka TDD).




Automate Story Tests


Developing incrementally means that the system must be continually tested as well, otherwise there is no way to assure that the new stories work compatibly with all existing functionality.


Teams therefore apply test-first development (/TDD), which includes creating unit and acceptance tested for each story that gets implemented.


To avoid building 'technical debt', Agile teams develop and apply these tests in the same iteration in which they implement the  story.


This figure illustrates Passing Vs Not (yet) Passing and broken tests are the real indicators of progress:




System Integration


To fully tested the features, system level integration and testing are required. With support of the System Team, the work of all the teams on the ART must be frequently integrated to assure that the system is evolving as anticipated:


  • Teams continuously integrate assets - leaving as little as possible to the System Team
  • Integrate every vertical slice of a user story
  • Avoid physical branching for software
  • Frequently integrate hardware branches
  • Use development by intention inc case of inter-team dependencies
    • define interface and integrate first
    • then add functionality


System level testing should be carried out as frequently as possible during the iteration, ideally daily. However, whatever the circumstances, full system integration must be carried out at least once per iteration.


All this work comes together in the system demo, which demonstrates the accumulated features and is the true indicator of ART progress.


Automate Feature Tests


As with user stories, features must be continuously tested against their acceptance criteria to ensure new functionality is developed. Again the test-first approach is applied, in this case by automating as many of the feature tests as possible.


  • Test First: Automate now!
    • Else, velocity is bottle-necked, quality is speculative and scaling is impossible
  • Automated tests are implemented in the same iteration as the functionality
  • The team builds functionality that also automates the tests
  • Created an isolated test environment
  • Actively maintain test data under version control
  • Passing vs not-yet-passing and broken automated tests are the real iteration progress indicator



Solution Integration


Building Large Solutions (i.e. those that require multiple ARTs and suppliers to develop them) requires an additional level of integration to pull all the work together.


Full or partial integration occurs over the course of a PI, with full solution integration being carried out at least once per PI, as per:



Solution Demo


  • Features are functionally complete or "toggled" so as not to disrupt demonstrable functionality
  • New features work together and with existing functionality
  • Takes place after the teams' demo
  • Carried out from the Staging environment, which should resemble Production as closely as possible




Enabling Continuous Integration

  • Integrate often
    • The more frequently teams integrate, the quicker they find problems. The harder it is to do, the more frequent the need to do it
    • Eliminate impediments and add automation along the way -> lead to faster learning cycles and less re-work
  • Make integration results visible
    • When integration processes break, everybody should know how and why it broke
    • When it's fixed, new tests should be developed to detect the problem earlier and prevent it from happening again
  • Fixing failed integrations is a top priority
    • If teams just keep working during an integration failure, it doesn't create the right sense of urgency and importance to fix the problem
    • To highlight the problem, teams often use flashing lights to draw attention to a broken build and visible indicators display the percentage of the time the system remains broken
  • Establish common cadence
    • Integration points are easier when all the teams are moving at the same constant rhythm
    • If full CI can't be accomplished during the course of an iteration, teams can make near term trade-offs on what can be integrated, while continuously improving their techniques and infrastructure toward this goal
  • Develop and maintain proper infrastructure
    • Effective continuous integration depends on the availability of test and staging environments
    • Infrastructure is an investment
    • Lean-Agile leaders take the long view and make investments today to increase velocity for the marathon ahead
  • Apply supportive engineering practices
    • Continuous integration is easier when the system is deigned with those concerns in mind
    • Test-First Development / TDD and designing for testability call for better solution modularity and separation of concerns, as well as the use of primary interfaces and physical test points.


Start Now! - it may be challenging, at first, but resistance will fade as a result of better deliveries!