1 / 11

Continuous Integration

Continuous Integration. Finding problems soonest. 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:

ingrid
Télécharger la présentation

Continuous Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 checks in code verifies requirement traceability Requirements System Source Control Management compiles code scans code runs unit tests creates install package Build System deploys install package to target environment runs integration/regression tests reports progress of each step

  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

More Related