info@burnssheehan.co.uk020 3206 1900

Continuous Delivery

Ifor Evans

Head of Platform Development, Betfair

Continuous Delivery

First published by Jez Humble and David Farley from ThoughtWorks in 2010

Where did CD come from?

Based on Agile principles

• Iterative Development

• Cross functional teams

• Automated unit (TDD) & functional testing (QA Testing)

• Continuous Integration

Based on Agile principles

What is CD?“A set of practices, principles and tools aimed at building, testing and releasing high quality software faster and more frequently.” – Betfair CD Definition

“A way of reducing the cycle time – i.e. how long it takes to get a simple code change to get to production”

“Automating everything!”

QA1 QA2 Pre-Prod ProdC.I.Change

SubmittedProduction

What is CD?

Principles of CD

Build artefacts only ONCE

Use the same automated mechanism to deploy to EVERY environment

Smoke test your deployment

If anything fails, STOP the lineEVERYBODY has responsibility for the

release process

- Code, DB, Config & System config changes

Principles of CD

Why Continuous Delivery?

If we do this there are NO surprises.

Until the code we’ve just written is running in production, we’ve

merely wasted time.

Bring the pain forward – Deployments are traditionally hard and fail often.

Get real feedback on the progress of projects based on the only useful definition of “DONE”—working software in a real production environment

delivering value to users.

By releasing small increments regularly, it reduces the risk of each individual release.

Why Continuous Delivery?

Continuous Delivery vs Continuous Deployment

Continuous Deployment means that every build that passes all automated tests will be deployed to Production.

Scary?

Continuous Delivery allows managed deployments and release windows.

Bit less scary?Giving control of releases

to the business.

Continuous Delivery vs Continuous Deployment

Prerequisites

Automated Builds

Automated Static Code Analysis

Automated Unit Tests (code & db)

Automated Functional Tests (code & db)

Automated Security Tests

Automated Performance Tests

Automated System Integration tests

Automated Sanity/Smoke Tests

Automated Deployments & Configuration

Automated VM ProvisioningAutomated Network Provisioning

Prerequisites

What might a typical CD pipeline look like?

Functional Testing Functional Testing

Continuous Integration

Continuous Integration QA1 QA1 QA2QA2 SecuritySecurity PerformancePerformance Pre-ProdPre-Prod

Short-lived

1 2 3 4 5 6

ProdProd

Changes

Long-lived Pre-Prod

7

TYPES OF TESTING PERFORMED1.Continuous Integration Build Server (Long-lived)

1. Build/Compilation 2. Unit Tests3. Fortify, Sonar & other Static Code Analysis

2.QA1 (Short-lived)Tests against mocks and stubs

3.QA2 (Short-lived)Tests against mock endpoints and DB

4.Security (Long-lived)Security tests against cutting edge services and components

5.Performance (Long-lived)Performance testing against near as live services and components

6.Pre-Prod (Long-lived)Full integration tests in a production replica environment

7.Prod (Long-lived)

Fail early

Heavyweight environments later in the pipeline

Non-functional testing

What might a typical CD pipeline look like?

Tool options• Roll your own

• ThoughtWorks Studios Go

• Jenkins CI

• Microsoft Team Foundation Server

• Lots of other possible options

What don’t they have? Automated VM Provisioning, Network Provisioning, Deployment Configuration..

Tool Options

Cultural Changes• Requires full Agile Adoption

• Requires teams to embrace responsibility for automating their end-to-end pipeline.

• Software needs to be in a potentially releasable state every build.

• Heavy focus on testing deployability

Cultural Changes

SummaryA set of tools and services that allow us to construct an automated build pipeline that extends from Development all the way to Production.

Automated testing of our deployment, configuration, NFR requirements as well as functionality.

Summary

END

020 3206 1900 info@burnssheehan.co.uk