Chapter 4: Technical Practices
Context: Technical Practices Are Not Optional
XP (Extreme Programming) prescribed technical practices like TDD and CI. Many Agile adoptions treated these as secondary, emphasizing management/team practices (Scrum). Research shows technical practices play a vital role — they can’t be skipped.
What is Continuous Delivery?
Continuous delivery (CD) = a set of capabilities to get changes of all kinds (features, config changes, bug fixes, experiments) into production or into users’ hands safely, quickly, and sustainably.
Five Key Principles of CD
- Build quality in — detect issues quickly rather than relying on inspection. Deming: “Cease dependence on inspection to achieve quality.”
- Work in small batches — decompose work into chunks with measurable outcomes. Get feedback before you’ve committed to the wrong direction.
- Computers perform repetitive tasks; people solve problems — automate regression testing and deployments; free people for higher-value work.
- Relentlessly pursue continuous improvement — improvement is everybody’s daily work, not a separate initiative.
- Everyone is responsible — system-level outcomes (throughput, quality, stability) require collaboration across all functions. Not dev’s job vs. ops’ job.
Three Foundations of CD
- Comprehensive configuration management — everything needed to build, test, and deploy must be in version control. Fully automated provisioning from version control.
- Continuous integration (CI) — short-lived branches (< 1 day), integrated into trunk/master frequently. Each change triggers build + unit tests. Failures fixed immediately.
- Continuous testing — automated tests run on every commit. Developers can run all tests locally. Testers do exploratory testing continuously against latest builds.
Capabilities Studied (2014–2016)
- Version control for app code, system config, app config, build/config scripts
- Comprehensive test automation (reliable, easy to fix, run regularly)
- Deployment automation
- Continuous integration
- Shift left on security
- Trunk-based development (not long-lived feature branches)
- Test data management
In 2017, two new capabilities added:
- Loosely coupled, well-encapsulated architecture (see Ch. 5)
- Teams that can choose their own tools
Impact of CD
CD drives improvements across multiple dimensions:
Performance:
- Higher software delivery performance (lead time, deploy frequency, MTTR)
- Lower change fail rates
Culture:
- Generative, performance-oriented culture
- Strong organizational identity
People:
- Lower deployment pain
- Reduced team burnout
“Improvements in CD brought payoffs in the way that work felt. Investments in technology are also investments in people.”
CD and Quality
Quality is measured by:
- Perceived quality/performance of applications
- % time spent on rework or unplanned work
- % time spent on defects identified by end users
Key finding: CD predicts lower levels of unplanned work and rework (statistically significant).
Time breakdown:
- High performers: 49% new work, 21% unplanned/rework
- Low performers: 38% new work, 27% unplanned/rework
Unplanned work = failure demand (John Seddon’s term) — demand caused by failure to do the right thing the first time.
Specific Practice Nuances
Version Control
- Keeping system and application configuration in VCS is more highly correlated with performance than keeping application code — configuration is often undervalued.
Test Automation
What predicts IT performance:
- Reliable tests — when they pass, teams are confident it’s releasable. Failures indicate real defects. Flaky tests undermine this; quarantine or delete them.
- Developers primarily create and maintain acceptance tests — not QA or outsourced parties. Why: (1) makes code more testable, (2) developers care more about tests they own.
- Run tests frequently — every commit triggers build + fast tests; daily comprehensive suite; current builds available for exploratory testing.
Note: Testers still have an essential role in manual/exploratory/usability testing and helping evolve automated suites.
Test Data Management
Successful teams had:
- Adequate test data to run fully automated suites
- Ability to acquire test data on demand
- Test data was not a limiting factor
Trunk-Based Development
- Fewer than 3 active branches at any time
- Branches live less than 1 day before merging to trunk
- No “code freeze” or stabilization periods
- Results are independent of team size, org size, or industry
GitHub Flow: suitable for open source contributors not working full-time. For product teams, short-lived branches merged daily is the right model.
Information Security
High performers integrate infosec throughout:
- Security reviews for all major features without slowing development
- Infosec experts contribute to design, attend demos, test security in automated suites
- Easy-to-consume preapproved security libraries, packages, toolchains available to devs
This contributes to software delivery performance AND reduces security remediation time.