Video: Continous Delivery Sounds Great - Jez Humble

Continous Delivery Sounds Great - Jez Humble ( https://www.youtube.com/watch?v=SjVV3xuYKJs )

Model: software = design + delivery

design= unpredictable delivery = predictable

lean 6 sigma doesn’t fit on software ; because software is 2 things

6 sigma tries to get all variability out of a system great for delivery, not great for design

xp lean software development unix

inventor of unix pipe

(2) = microservices (3) = deliver early & often (4) = automate, tool based

not new ideas

-–

1. “We’re regulated”

1a amazon 2011 amazon is heavily regulated - credit cards - public trading company

1b) US government: 8-14 months from code complete to live

got cloud.gov certified, only 55 security controls left

fully reproduce system from version control

all info needed for auditing is there: - which tests were run - who authorised a run

2 throughput metrics 2 stability metrics high performers do better on both no tradeoff between stability and throughput

all different domains all company sized (startup to mega corps)

-–

2. “We’re not building websites”

anecdote: hp team was going really slowly they were critical path for all new releases this is really bad, but typical in the industry

anecdote: airline needed more time to change a booking system for new seats than to change the seats in the planes

allows single

“how do you do automated tests?” “we build a simulator” “you did WHAT?”

into trunc only after automated tests overnight regression test

not deploying anyway why would we do continuous delivery? it changes the dynamics

lean is not about cutting costs lean is about investing to remove waste in medium and long term, drives down transaction cost of making changes, so that you can move faster

continuous delivery NOT about releasing multiple times/day IS about changing the economics of the software delivery process to work in small batches

• faster feedback
  • build quality in
    • reduce cost
    • increase quality
    • reduce time to market

-–

3. “Too much legacy”

anecdote / demo “gui tests” test harness

too much legacy == too much complexity

reduce complexity => allows us to go faster

complexity is everywhere

it took amazon 4 years to go to architecture that allowed … in that time they did not deliver much new stuff

pattern: strangler application drive incremental evolutionary architecture change through building new stuff - don’t rebuild the old stuff

evolutionary architecture is never done goal = reducing complexity

complexity of your operational environment makes it hard to add new features

[ ] Steve Yegge’s Platform Rant he worked at amazon during the 4 year transition to SOA memo from CEO ‘Bezos’

enables:

-– 4) our people are too stupid anecdote: Adrian Cocraft cloud architect for netflix netflix were biggest users of internet, took 6-7 years to go to cloud CIO of a random stodgy company comes up to him and asks “Adrian where do you get all these amazing people from?” Adrian replied: “I get them from you”

It’s not the people that are the problem someone is being stupid, but not the people you think

anecdote: famous story about lean NUMMI (new united motor manufacturing incorporated) Tesla factory was recent, used to be GM factory, the worst factory, shut down the plant NUMMI joint venture GM + Toyota - Toyota wants plant in US (trade barriers) - GM wanted to learn to build small cars profitably

union leaders convinced Toyota to rehire the employees training course in Japan within a year, higher quality cars than any GM plants

the problem are not the people the system of work, system of leadership and management

lines on ground = timing anecdote: toyota non-toyota: try to put a seat in, bolt it down, don’t make it in time, whatever, next ends up at quality control: “nobody can drive that, rejected”

toyota: you get 3/4 of the way and notice you won’t make it pull Andon cord, manager comes, helps you still don’t make it? pull Andon cord again, assembly line stops fix the problem, assembly line continues later on, reflect how to improve workers make suggestions, and you get to implement it you have the power to change your own system of work to make it better Support engineer group to make / change tools for you

build quality in as a worker your responsibility is to make sure that when the work product leaves you, everything is great and you have the tools, the power and the responsibility to build quality in

[ ] this americal life episode about that anecdote [ ]

machine are in charge of finding problems humans are in charge of solving problems

exact analogy in software delivery: continuous integration something goes wrong -> notify

continuous integration certification - all developers check in to trunc at least daily - when your tests fail, you get them fixed within 10 minutes

devops research less rework (proxy metric for quality)

-–

continuous delivery = continuous improvement

high performing companies always working to get better, they never stop it’s part of everyone’s daily work

How can I make things more awesome for the people around me.