Copyright 2015, Robert W. Hasker

Continuous Inspection  Code reviews  Powerful tool  Difficult to ensure meaningful reviews take place  Static analysis tools  Clear win: easy to run, unambiguous results  One of earliest: lint (C)  jlint, pmd  tic_code_analysis to be overwhelmed tic_code_analysis  Demo jlint in TeamCity w/ failure condition

Code Metrics  How to measure amount of code  SLOC  Statements  Useful within developer, style, problem complexity  Why shouldn’t we grade on SLOCs?  Cyclomatic Complexity Number  Number of distinct paths  CCN > 10: high probability of defects

Cyclomatic Complexity  Textbook example: CCN of routine = 114  How to respond?  Check #tests >= 114  Book suggests 114 might be unreasonable. Do you agree?  Refactor  First rule of refactoring: write a test case before you change anything.  Apply extract method technique: write smaller procedures

Duplicated Code  Why a problem?  Increased maintenance costs  Uncertainty: all occurrences fixed?  Testing: additional coverage needed  Real world examples:  Linux kernel in 2002: 15 to 25% duplicated  Sun Java JDK: 21-29% duplicated  Tools: CPD from PMD package, Simian, others

Continuous Inspection  Reducing code complexity  Continuous (procedural) design reviews  Maintain standards  Reduce duplicate code  Assess testing coverage

Continuous Deployment  New model: product always evolving  Continuous deployment – release every night  What do you need to make this work?  CI, obviously  Automated labeling of released versions  Rollback support  Extreme CI  Bare install OS, configure OS, server components, third party tools, custom software  Absolutely all tests run

A middle ground  Three branches:  master: released  stage: validation  dev: target for each sprint  Levels of testing  dev: core testing  stage: acceptance testing by stakeholders  also performance testing?  mutation testing?  A tool!

Improving the process  Automatically build (& test) each pull request  Open VCS Root, show advanced options  Branch specification: +:refs/pull/*/merge  will see build in log as “refs/…master”

Continuous Feedback  What to do if build fails?  Just let someone discover the problem?  Post an alert  Who?  Not everyone!  Project manager, technical lead, developers, testers?  How?  Siren? ? Text Message? Visual signal?

Continuous Feedback  obvious option  Problem: may not be on , spam  Text Message: still have spam issue  Ambient Orb  Small globe, color shows last build status  Problem: no detailed information  Windows task bar  Monitor  Should “last to break build” be on the screen?

Continuous Feedback in TeamCity  Open Build Configuration Settings, General Settings  Open advanced options  Build options: enable status widget  HTML for "  HTML for body:  Usage: open demos\local-ci-status.html

Review  Continuous Inspection  Code metrics, cyclomatic complexity  Identifying code clones  Continuous Deployment  staging branch  build on pull request  mutation testing  Continuous Feedback