Adopting continuous delivery

Post on 28-Jan-2015

112 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

A recording is available here: http://www.youtube.com/watch?v=2jt-up0a4JY While keeping software production ready throughout its lifecycle and optimizing your delivery process for shorter cycle times might seem like a good idea to you, the rest of your organization might not share your excitement. In this talk, Jez Humble shares stories from companies who have attempted to adopt continuous delivery and discusses the organizational, architectural and process factors that led to the success - or failure - of these initiatives.

Transcript

adoptingcontinuous delivery

@jezhumblendc oslo, 13 june 2013

Friday, July 5, 13

“adopting”

organizational, architectural, process

-NOT-

tools, code, infrastructure

Friday, July 5, 13

start with continuous integration

understand why you want to change

get measurable change fast, even if reaching your goal takes years

create culture of continuous improvement

focus on organization and architecture

takeaways

Friday, July 5, 13

what is continuous delivery?

reduce the cost, time, and risk

of delivering incremental changes

to users

Friday, July 5, 13

Friday, July 5, 13

Friday, July 5, 13

why continuous delivery?

1. build the right thing

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

Customerdevelopment

Agile productdevelopment

Friday, July 5, 13

do less

“Evaluating well-designed and executed experiments that were designed to improve a key metric, only about 1/3 were successful at improving the key metric!”

“Online Experimentation at Microsoft”, Kohavi et al http://stanford.io/130uW6X

Friday, July 5, 13

@jezhumble

We believe that

[building this feature]

[for these people]

will achieve [this outcome].

We will know we are successful when we see [this signal from the market].

hypothesis-driven delivery

Je! Gothelf “Better product de"nition with Lean UX and Design” http://bit.ly/TylT6A

Friday, July 5, 13

Friday, July 5, 13

http://bit.ly/19Z5izI

Friday, July 5, 13

http://bit.ly/19Z5izI

Friday, July 5, 13

scienti"c method

create hypothesis

deliver minimum

viable product

get feedback

(repeat)

Friday, July 5, 13

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?”

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

Friday, July 5, 13

releasing frequently

1. build the right thing2. reduce risk of release

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

Friday, July 5, 13

optimize for mtrs

Friday, July 5, 13

optimize for mtrs

MTBF MTRS

John Allspaw: “Building Resilience in Web Dev & Ops” http://bit.ly/Pa0DBq

Friday, July 5, 13

http://bit.ly/19Z5izIFriday, July 5, 13

deployment pipeline

Delivery team Version control Build & unit tests

Automated acceptance tests

User acceptance tests

Release

Check in

Feedback

Trigger

Check in

Feedback

Trigger

Trigger

Check inTrigger

Trigger

ApprovalApproval

Feedback

Feedback

FeedbackFeedback

Friday, July 5, 13

why continuous delivery?

1. build the right thing2. reduce risk of release3. real project progress

Friday, July 5, 13

so#ware is always releasable on demand

prioritize keeping system releasable over delivery

anybody can get fast, automated feedback on the e!ect of a change

how do i know i’m doing it?

Friday, July 5, 13

skills & responsibilities

plan for continuous delivery

architect for continuous delivery

business wants to scale back release frequency

project launched early

green"eld project

Friday, July 5, 13

devops

http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

Friday, July 5, 13

hiring a devop

http://gun.io/blog/how-to-hire-devops/

Friday, July 5, 13

the devops role

If you add a “devops” function to your existing dev, testing and ops functions, you just missed the whole point.

Friday, July 5, 13

the path of continuous delivery

http://www.flickr.com/photos/jezand_rani/455116092/Friday, July 5, 13

hp laserjet "rmware team

~5% - innovation

15% - manual testing

25% - current product support

25% - porting code

20% - detailed planning

10% - code integration

2008

Friday, July 5, 13

deployment pipeline

Friday, July 5, 13

hp laserjet "rmware team

~5% - innovation

15% - manual testing

25% - current product support

25% - porting code

20% - detailed planning

10% - code integration

2008

~40% - innovation

5% - most testing automated

10% - one branch cpe

15% - one main branch

5% - agile planning

2% - continuous integration

2011

The remaining 23% on RHS is spent on managing automated tests.

Friday, July 5, 13

the economics

2008 to 2011

• overall development costs reduced by ~40%

• programs under development increased by ~140%

• development costs per program down 78%

• resources now driving innovation increased by 5X

A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum

Friday, July 5, 13

improvement kata

Friday, July 5, 13

test automation

architecture

continuous integration

planning process

what changed?

Friday, July 5, 13

organizational transformation

aim to achieve measurable change as soon as possible - no more than a few months

Friday, July 5, 13

top down or bottom up?

fetch me 100 of your finest CSMs!

no! we will deliver crappy software late through self-

organization!

Friday, July 5, 13

start with continuous integration

Is the system working?

If you broke it, you "x it.

Friday, July 5, 13

Mainline Server

Develop

Build

Build

pull

Local Workstation

Buildpush

✔Done!

Friday, July 5, 13

branch-by-abstraction - bit.ly/kAUbEw

“feature branching is a poor man’s modular architecture” - Dan Bodart

micro-services - build a platform - bit.ly/shHR!

strangler application - bit.ly/R4ZiJZ

architecture

Friday, July 5, 13

acceptance testing in non-integrated environment

design for phoenixes - bit.ly/PFtDQy

stand up system in dev environment

create test doubles for integration

design for test and deploy

Friday, July 5, 13

program-level co-ordination

1 -> 2 releases per month; 40% cycle time reduction

low-hanging fruit: reduce branching, run tests, standardize environments, decrease build time

director of continuous delivery managing initiative

what can we do in a year?

Friday, July 5, 13

slack time

excitement

existing capability (“nokia test”)

can demonstrate measurable change

"nding the right team

Friday, July 5, 13

Are you doing iterative development?

Iterations must be time-boxed to less than four weeks

Software features must be tested and working at the end of each iteration.

The iteration must start before the specification is complete.

the nokia test

bas voddeFriday, July 5, 13

Are you doing Scrum?

Do you know who the product owner is?

Is the product backlog prioritized by business value?

Does the product backlog have estimates created by the team?

Are there project managers (or others) disrupting the work of the team?

the nokia test

bas voddeFriday, July 5, 13

monolithic architecture, water-scrum-fall

architecture didn’t consider test and deployment

“They don't need a deployment pipeline, they need to talk to each other much more”

expected magic CD fairy to make things better

how not to do it

Friday, July 5, 13

start with continuous integration

understand why you want to change

get measurable change fast, even if reaching your goal takes years

create culture of continuous improvement

focus on organization and architecture

takeaways

Friday, July 5, 13

jesse’s rule

“don’t fight stupid,make more awesome”

Jesse Robbins, Co-founder, Opscode @jesserobbinsFriday, July 5, 13

questions@jezhumble | jez@thoughtworks.comhttp://continuousdelivery.com/

ThoughtWorks is hiring!http://join.thoughtworks.com/

Australia | Brazil | Canada | ChinaGermany | India | Singapore | South AfricaUganda | UK | USA

© 2013 ThoughtWorks, Inc.

Friday, July 5, 13

top related