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.
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:
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:
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.
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:
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.