Definitions and Terms

• Deployment Pipeline - (pg 3) - an automated implementation of your application's build, deploy, test, and release process
• Integration - (pg 24) - Exercising code to see if it achieves desired outcomes
• Continuous Integration - (pg 24) - the practice of building and testing your application on every check-in
• Cycle Time - (pg xxiii) - The time from deciding that you need to make a change to having it in production

The Problem: How do we deliver quality software as quickly as possible

• Every change to any part of the application triggers release
• Push button deployments
• To any environment

Antipatterns

Manual deployment/Manual environment setup

• Human error
• Human time is expensive
• Bus factor
• Documentation is burdensome/out of date

Deployment as an event/Deployment first time in prod

• Human communication is expensive/time consuming
• Manual configuration of test environment is problematic -- unforeseen production issues
• All bugs block the rest of the release
• Processes are subverted with shoddy fixes

Feedback

Automated feedback acted upon for EVERY CHANGE to

• code
• env
• conf
• data

Feedback types

• unit tests
• quality indicators (code coverage)
• functional test (acceptance tests)
• non-functional tests (performance, security)
• exploratory

Feedback - additional notes

• Must be recieved quickly
• Critical CI runs first, then automated functional tests, then exploratory tests[fn:4]

Release Candidate

• If the result of a change is software that meets release criteria, it can be a release candidate
• Each change should be a potential release

Deployment Pipeline

Aims

1. visibility - makes build, deploy, test, release visible to everyone involved
2. feedback - problems ID ASAP so they can be resolved
3. Fully automated deployment of any version to any environment

Benefits

• Encourage collaboration (no deployment experts)
• Empowers teams
• No documentation!
  • On pg 6 it's mentioned that an automated system is self documenting to some degree
  • I would beg to differ with this.
• reliable and repeatable/reduces errors
• reduces stress

  • this may be the real benefit of reducing errors

    The problem here is that releases into production are big events. As long as this is true they will be surrounded with a lot of ceremony and nervousness

• Flexibility
  • ???

• Practice

  In essence the final deployment into production is being rehearsed every single time the software is deployed to any target

Principals of Software Delivery

Reliable process for Releasing

Automated setup of environment and deployment of application

Automate almost everything

Keep everything in version control

• Everything in version control needed to
  • Build
  • Test
  • Deploy
  • Release
• Single command to build and deploy to any env (including dev)

If it hurts do it more

Build quality in

• cf: fast feedback
• testing is not a phase
• testing is not the exclusive domain of testers

Done means released

Everyone is involved

Continuous improvement