introduction to continuous delivery · 2017-12-06 · continuous delivery frequent releases dev ops...

Continuous Delivery

Graham [email protected]

Twitter: @grahamcbrooksBlog: http://www.grahambrooks.com/blog

Introduction to

Thursday, March 28, 13

mailto:[email protected]


http://www.grahambrooks.com/blog


Agile

Iteration 0 1 2 3 4

Analysis + Design

Development

Testing + Showcase

Integration + QA Release and operation

Customer

Centralized QA IT Operations

"Agile" team

The "last mile"


disrupting traditional businesses

http://code.flickr.com/




Building the right thing

every business idea is a hypothesis until you get user feedback


How often features are used

0 12.5 25 37.5 50

Never

Rarely

Sometimes

Often

Always

Source: Standish Group

45%NEVER USED


releasing frequently

feedback from usersCustomer

developent

Agile productdevelopment

Eric Ries, “The Lean Startup” http://bit.ly/8ZoX5F



feedback from usersreduce risk of release

John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr


http://slidesha.re/dsSZIr

http://slidesha.re/dsSZIr


feedback from usersreduce risk of releasereal project progress


Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software


Production-ready Software

Fast, automated feedback on the production readiness of your applications every time there is a change - to code, infrastructure, or configuration


Continuous Delivery

Customer

Delivery teamConstant flow of new features into production


Software always production ready

Continuous Delivery

Customer



Software always production ready

Releases tied to business needs, not operational constraints

Continuous Delivery

Customer



CD OverviewContinuous Delivery

Dev OpsFrequent Releases

Automated Testing

Test Strategy

TDD/BDD

Product Support

Pipelines

Continuous Integration

Automaation

Lean Operations

Infrastructure as Code

Configuration Management

Monitoring & Metrics

Kanban for Ops

Lean ITIL

Private Cloud


value stream mapping

Product opportunity assessment

Product discovery Development Final testing

and approval ReleaseProduct

planning and estimation

Elapsed time

Value-added time3 days 1 week 10 days 7 weeks 1 week 2

hours

1 week 10 days 3 days 5 days 2 days


deployment pipeline


an automated implementation of your system’s build, deploy, test, release process

deployment pipeline


visibility


deployment pipeline


visibility


feedback

deployment pipeline


visibility


control

feedback

deployment pipeline


deployment pipelineDelivery team Version control Build & unit

testsAutomated

acceptance testsUser acceptance

testsRelease

Check in

Feedback

Trigger

Check in

Feedback

Trigger

Trigger

Check inTrigger

Trigger

ApprovalApproval

Feedback

Feedback

FeedbackFeedback


Commit Stage

Compile

Unit Test

Unit Test

Build Installers

Acceptance Test Stage

Acceptance Test

User Acceptance Stage

Exploritory

Usability

Performance Stage

Performance

Stability Testing

Production

Production Readiness

Production Like


Production Like


Production Like


Production Like

Feedback

Deployment Pipeline


Deployment Pipeline


Principles

• create a repeatable, reliable process for releasing software

• automate almost everything

• keep everything in version control

• if it hurts, do it more often, and bring the pain forward

• build quality in

• done means released

• everybody is responsible for delivery

• continuous improvement


Ask this question:-

• “How long would it take your organization to deploy a change that involved just one single line of code? Do you do this on a repeatable, reliable basis?”

• What gets in the way of getting software out of the door?

Mary and Tom Poppendieck, Implementing Lean Software Development, p59.


Practices


only build your binaries once

Practices



deploy the same way to every environment

Practices


smoke test your deployments



Practices





keep your environments similar

Practices





if anything fails, stop the line

keep your environments similar

Practices


Continuous IntegrationP1 P2

G2 G3G1 G4

P3 P4 P5

G5 G6

B1 B2

G1

G1

P1

P1B1

P2

B1

P1-2

G2

G2

P3

G2

P3

B2

P4

B2

G3

P3G3

G3

P4

P4 P5

P4-5

G4

G4 G5 G6

P2

Professor Plum

Reverend Green

Mainline

Diagram invented by Martin Fowler


everybody checks in to mainline


G2 G3G1 G4

P3 P4 P5

G5 G6

B1 B2

G1

G1

P1

P1B1

P2

B1

P1-2

G2

G2

P3

G2

P3

B2

P4

B2

G3

P3G3

G3

P4

P4 P5

P4-5

G4

G4 G5 G6

P2

Professor Plum

Reverend Green

Mainline




use branch by abstraction for architectural change


G2 G3G1 G4

P3 P4 P5

G5 G6

B1 B2

G1

G1

P1

P1B1

P2

B1

P1-2

G2

G2

P3

G2

P3

B2

P4

B2

G3

P3G3

G3

P4

P4 P5

P4-5

G4

G4 G5 G6

P2

Professor Plum

Reverend Green

Mainline




use branch by abstraction for architectural change

use feature bits to switch off incomplete features


G2 G3G1 G4

P3 P4 P5

G5 G6

B1 B2

G1

G1

P1

P1B1

P2

B1

P1-2

G2

G2

P3

G2

P3

B2

P4

B2

G3

P3G3

G3

P4

P4 P5

P4-5

G4

G4 G5 G6

P2

Professor Plum

Reverend Green

Mainline



different kinds of testing

Functional acceptance tests

ShowcasesUsability testing

Exploratory testing

Unit testsIntegration tests

System tests

Non-functional acceptance tests

(performance, scaling, ...)

Business facing

Technology facing

Critiq

ue p

roje

ct

Support

pro

gra

mm

ing

AUTOMATED

AUTOMATED

MANUAL

MANUAL / AUTOMATED

Diagram invented by Brian Marick


Blue Green Testing

Web Server

Blue Slice

Green Slice

RouterUsers

Application Server

Blue Slice

Green Slice

Database Server

Blue Database

Green Database

1.0

1.0


Blue Green Testing

Web Server

Blue Slice

Green Slice

RouterUsers

Application Server

Blue Slice

Green Slice

Database Server

Blue Database

Green Database

1.0

1.1


Canary Releases


Data Migration


Objections


Visibility and control over locking down

Objections



Compliance - automation over documentation

Objections


Auditing - see who does what



Objections


Auditing - see who does what



Make it easy to remediate outages

Objections


People are the key


Get everyone together at the beginning

People are the key



Keep meeting

People are the key


Make it easy for everyone to see what’s happening


Keep meeting

People are the key


Make it easy for everyone to see what’s happening


Keep meeting

Continuous improvement (kaizen)

People are the key


http://continuousdelivery.com/http://studios.thoughtworks.com/gohttp://thoughtworks.com/http://www.thoughtworks.com/continuous-deliveryhttp://bit.ly/pAkM6B Jeffery Hammond Forrester Consulting

Thank YouGraham Brooks

[email protected]: @grahamcbrooks

Blog: http://www.grahambrooks.com/blog


http://continuousdelivery.com

http://continuousdelivery.com

http://studios.thoughtworks.com/cruise

http://studios.thoughtworks.com/cruise

http://thoughtworks.com

http://thoughtworks.com

http://www.thoughtworks.com/continuous-delivery

http://www.thoughtworks.com/continuous-delivery

http://bit.ly/pAkM6B

http://bit.ly/pAkM6B





introduction to continuous delivery · 2017-12-06 · continuous delivery frequent releases dev ops...

Documents