Video: Continous Delivery Sounds Great - Jez Humble
Continous Delivery Sounds Great - Jez Humble
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.
