Continuous Integration: Finding problems soonest
1 like1,227 views
Continuous integration (CI) aims to find problems early by automatically building and testing code changes. With CI, every code change triggers automated builds, running tests, scans, and deploying to test environments to check if the change breaks anything. The goals are to detect issues immediately, ensure all code is compilable and tests pass, and produce candidate releases quickly. CI requires source control, build servers, automated tests, and developers who fix problems from failed builds. It helps reduce defects but requires resources to implement and maintain.
Continuous Integration: Finding problems soonest
- 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