This document discusses continuous deployment and what is required to achieve it. Continuous deployment means code is always deployed to production. It requires version control, build/deploy pipelines, infrastructure as code, frequent and safe code updates, separation of rollout and activation, and good observability. Achieving it also requires changes to testing, coding, organization, planning, and learning practices. The document recommends starting with improving deployment frequency metrics and removing impediments through small experiments. It emphasizes improving incrementally based on what teams are passionate about or experiencing pain with.
3. Who We Are
Declan Whelan and Shawn Button
are developers and technical coaches.
Find us at www.leanintuit.com
4. Agenda
• What Continuous Deployment feels like.
• What is necessary for CD.
• What we often see as the missing pieces.
• Aiming for CD.
• Steps to CD success.
5.
6. What Is Continuous Delivery
“Continuous delivery is a software
engineering approach in which teams
produce software in short cycles,
ensuring that the software can be
reliably released at any time.”
- Wikipedia
7. What Is Continuous Deployment
“Continuous deployment is
continuous delivery plus the code
always goes to production.”
- Us
8. Make Continuous Deployment Your Goal
If there’s one thing to take from this today, we hope it be this:
Make Continuous Deployment your goal.
Every time you are faced with a decision ask yourselves:
“Will this take us closer to Continuous Deployment?”
9. What is required for Continuous Deployment?
Version
Control
Build/Deploy
Pipelines
Infrastructure
as Code
Frequent,
safe code
updates
Separation of
rollout and
activation
Good
Observability
10. What is required for Continuous Deployment?
Version
Control
Build/Deploy
Pipelines
Infrastructure
as Code
Frequent,
safe code
updates
Separation of
rollout and
activation
Good
Observability
A Lot of DevOps Initiatives Focus on These
11. What is required for Continuous Deployment?
Version
Control
Build/Deploy
Pipelines
Infrastructure
as Code
Frequent,
safe code
updates
Separation of
rollout and
activation
Good
Observability
A Lot of DevOps Initiatives Focus on These
This is Ignored
12. “A Tool Will Solve Our Problem” - Developers, Always
13. Frequent, Safe, Small Code Updates
Requires changes to how we:
" Test
" Code
" Organize ourselves
" Plan and execute
" Learn
15. Let’s focus on the “dev” loop
build
end to
end test
integration
test
unit
test
code
plan
dev
16. Shift quality left
Move quality checks upstream
build
end to
end test
integration
test
unit
test
codeplan
17.
18. Planning: 3 amigos story writing
Product owner / BA Developer Tester
hmmm …
what edge cases
might there be?
hmmm …
how I simplify this?
hmmm …
how can I make
my customers
more awesome?
19. Story writing is a team effort
From User Story Mapping, by Jeff Patton (O’Reilly, 2014)
21. Code Quality
We see a lot of code from a lot of different contexts.
We consider most of the code we see to be of insufficient quality to be
safe in continuous deployment.
It might have been fine when we were releasing bi-monthly. We had
long manual integration and testing cycles. Not now.
What do we need?
A Tool!
23. Code Quality
You need a broad-based approach to improving code quality:
" Don’t trade quality for short-term delivery speed.
" Pair and mob
" Adopt Test-Driven Development
" Make time for refactoring, and re-design
" Foster team code standards and conventions
" Establish enterprise code standards
" Hold technical training and bring in technical coaches (shameless plug)
" Run coding/testing book/video clubs
" Hold hack-a-thons
" Foster diversity
" Do regular root-cause analysis of failures and bugs
" Use linters and static code analysis tools
" …
27. Code Reviews
Code reviews do improve safety, but slow you down.
" Developers can mob or pair instead:
" Problems are found and fixed immediately.
" Learning is vastly increased. Team members help each other
improve.
" The team develops a shared code style.
" etc.
" (If you can’t mob or pair yet, please STILL DO CODE REVIEWS)
29. Impediments to CD
" existing technical debt
" ineffective development practices
" hand-offs
" schedule pressure
30. Key Metrics
In the book Accelerate by Forsgren, et al., they describe four key
software delivery metrics:
" Lead time for changes
" Time from check-in to production
" Deployment frequency
" How often code is deployed to production
" Time to restore service
" Mean time to recover from failure (MTTR)
" Change failure rate
" How often changes require a fix or rollback
31. Step to CD success
" metrics: we suggest starting with deployment frequency
" empathy: focus on areas where team has passion or pain
" learning: while doing work and focused learning sessions
" have team identify and remove impediments
" start with managers or Scrum Masters helping
" over time teams own this
" small experiments: reflect and adjust
" keep asking “..will this take us closer to Continuous Deployment? ”
32. Improve Incrementally
“If an organization currently delivers to
production every 6 months, it is sadistic to
expect them to release in 2 weeks”
- paraphrased from Mary Poppendieck