Continuous Deployment

Continuous Integration

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Continuous Deployment

Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. Continuous Delivery aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.

-- Martin Fowler, ThoughtWorks - http://www.thoughtworks.com/continuous-delivery

What does this mean in practice?

• Every commit is potentially releasable
• Absolutely everything must be covered by tests
• Requires a skilled team, defined workflow and some technical infrastructure
  • This is our "continuous deployment pipeline"
  • We're building it incrementally and it's not done yet

Our pipeline

• CB system broken into multiple, small services
• Each in its own Github repository
• Each with a rigorous set of tests
• Jenkins CI server whose job is to run those tests on every Github commit
• When "green", a deployable artefact is produced
  • In our case a Docker container
• We have all this already

Our pipeline

• A collection of Docker containers that have passed tests is not sufficient.
• How do we know all the components work together?
• We apply configuration to those artefacts; how do we know it will all work in production?
• How does it actually get deployed?

What we haven't finished yet

• "Non-Functional Testing" environment
  • Load/performance testing, benchmarking, etc.
  • Probably not run on every commit
• "System Integration" environment
  • New "green" artefact is thrown into a production-like environment and run some sanity checks
• "Deployment bot"
  • The midwife for new artefacts

Where are we today?

• Good per-service tests
  • We know our code works. Room for improvement though
• No SI environment
  • We're not sure if everything is configured correctly for production & will work together
• No NF environment
  • Not a big deal in T&L- this is about scale
• Manual deployments; sometimes accidental deployments

What are the benefits of C.D.?

• Detect errors quickly
• Fast turn-around time
• No big "doomsday" of scheduled releases
• Verifiable quality
• This should really be obvious....

What are the benefits of C.D.?

-->

Less this

Moar this

The finished pipeline