This is a brief presentation I gave to a DAU class on Continuous Integration in June of 2013.

1. Continuous Integration
Finding problems soonest

2. Your Software Is Your
House
• Except, in a complex software project you have many of the
same type of contractor and they don't communicate well
• For example, if your house were a software project:
• Different masons don't make the foundation connect,
creating fissures
• Different carpenters choose different materials for the
subfloor, leading to weak points
• Different roofers don’t connect joists the same

3. But I did my part right!

4. Some Background
• Source code -> Binary code
• Source code is what people write
• Binary code is what machines run
• Compilers turn source code into binary code
• Developers do this all of the time (It’s not the 1970s)
• Source control holds source code
• It tells you who did what and when (accountability)
• Provides points in time for milestones
• Is key to good Configuration Management
• Build servers detect changes in source control and the turn the
source code into binary code, run tests, perform inspection, etc. and
produce builds

5. Continuous Integration
Goals
• Find the problem when it is introduced
• On every change (continuous):
• Is it intended to meet a requirement (is it gold plating)?
• Can anyone compile it (avoid "magic laptops" or "islands of
knowledge")?
• Did the new code break existing functionality (does it pass
automated testing)?
• Does it contain known bugs (is the foundation bad)?
• Does it contain known security flaws (is it easily hackable)?
• Can others work on the code (does it conform to coding
standards)?
• Does it actually meet the requirement (does it pass functional
testing)?
• Is deployment reproducible? Can it install?

6. Typical CI Process
Source
Control
Management
Requirements
System
Build
System
3. compiles code
4. scans code
5. runs unit tests
6. creates install package
2. verifies requirement
traceability
7. deploys install package to target environment
8. runs integration/regression tests
9. reports progress of each step
1. checks
in code

7. If a Build Fails
• If any of the evaluations fail, mark the build as FAILED!
• No finger pointing! You know who did it!
• Immediately, the developers:
• Fix the code, or
• Roll back the code to a known good state
• If you don’t do either, then developers continue building
on a bad foundation

8. If a Build Succeeds
You may have a candidate for a releasable
product!

9. Requirements for CI
• requirements and architecture are well understood
• target environment is known and available
• an automated deployment mechanism exists
• someone to coordinate and champion process
• automated tests actually exist and are correct
• transaction-based source control system
• developers respond to bad builds quickly
• the systems who support CI can interoperate with one another
• everyone does their job, it’s not a replacement for other good
processes

10. Concerns with CI
• CI requires personnel to maintain and develop
• Sometimes failures are due to the environment
• It takes time and effort to remove these issues
• CI can not perform review tasks which require people:
• User testing
• Documentation review
• Some builds take a long time
• Use a build engineer to help the architect break up the
software into smaller modules
• Run some scans/tests nightly rather than on every change

11. Summary
• CI is all about detecting the problem as it is
inserted into the product
• CI accomplishes this by running tests and scans
code at every change
• CI requires a personnel and hardware
investment
• CI pays off for defect reduction