This document discusses introducing continuous delivery practices at an organization. It provides four stories from different companies about their continuous delivery journeys. The first story describes challenges at Nokia with complicated dependencies and integration problems that were addressed by implementing delivery pipelines and consumer driven contracts. The second story focuses on delivering value and achieving a higher release frequency, shorter cycle times, and higher release success rates at another unnamed company. The third story discusses the architecture at eBay and improvements achieved by moving to more modular code and weekly releases. The final story cautions against skipping testing phases when moving to continuous delivery. Common themes that helped organizations were taking baby steps, establishing cross-functional teams, test automation, and focusing on delivering value.

1. HOW TO INTRODUCE
CONTINUOUS DELIVERY?
Alexander Schwartz
Nokia Location & Commerce

2. Which delivery style you have?
“Big ship” “Kaiten Sushi”
www.flickr.com/photos/burtonandy/4702810536/ www.flickr.com/photos/mc_masterchef/178245348/
How to do the transition?

3. What
helps?

4. 4 Stories:
What helps? What not?
Story #1 Story #2 Story #3 Story #4
context #1 context #2
NOKIA another company

5. Context: Nokia L&C Places
Story #1 RESTful services to show Place
information on maps
applications.

6. Story #1: The Initial Challenges
•complicated
dependencies
•integration problems
•production bugs
•big bang releases
Approach: Ask for smart people for help.
-> Delivery Pipelines
-> CDCs (Consumer Driven Contracts)

7. From Services Dependencies to Pipelines
City Pages
<<webapp>>
Places
Registry Maps app for
<<REST>>
Windows 7
<<device app>>
Account
Service Search
Places
<<REST>> <<REST>>
Backend Maps Web
<<webapp>>
API
Recommendations
<<REST>>
PBAPI client
API
<<client API>>
Upstream Downstream
Build Pipeline Order

8. The Result After 1 Year
Dev QA Shipping
SNAPSHOTS
Component
Pipeline
Integration
Component
Build
Component
Mgmt.
Releases
Pipeline
Component Deploy Test Deploy Deploy
Build
Manual
Component
Mgmt. Test
Test
Co Co Co
Dev Team
builds
Co Co Co
Ops
Co Co
QA Rel. Mg.
Dev

9. The Result After 1 Year
Developer buy-in
fair
in the ideas
Developer buy-in
0 %
in implementation
Improvement of
none
Cycle Time

10. Learnings
Bad: Good:
• It was build by another • it established a
team. “we should do...”
• It was build beside the - CDCs
teams builds. - pipelines
• Big Bang Rollout - deliver faster
• no shared responsibility • it fixed other
• no proof that it works problems: server
config, etc.

11. Context: Nokia L&C Places
Story #2 RESTful services to show Place
information on maps
applications.
Focus on Delivering

12. What we achieved?
1 year
#Releases 5 in 6 month >110 in 6 month
Cycle Time av. approx. 35 days 11 days
Cycle Time min. 1 week 2 hours
Release Success 10 % 97 %
Unplanned Work 80 % 20 %

13. What helped....
DevQA
DevOps TDD
Trust
Test Automation
Kanban
Pairing
Baby
People Steps

14. Build one team
Dev
QA Rel.Mgt
Dev
OPS
Build Mgmt
Dev
Dev
Dev +
Dev

15. DevOps + DevQA
Dev QA Ship
Dev QA Ops
Dev QA Ops

16. Focus process: Kanban

17. Focus process: Kanban
Avatar

18. BFocus
on the
value stream
Main Metric:
Release Cycle Time

19. BBAutomation
“
Automating the
wrong thing to
early is
dangerous
• Automate
everything you do
twice.
• Automation will
be your rescue.
www.flickr.com/photos/gibbisons/5538845069/

20. Automation
Our Automation:
Full E2E pipeline in one
tool, from commit to
prod

21. Eat your Own Dog Food
You understand the value of
Continuous Delivery?
Use the same principle for your
Improvement Process.
Baby Steps, Baby Steps, Baby Steps, Baby Steps….
www.flickr.com/photos/mshades/2132689629/

22. Why we should care
about fast delivery?

23. How to find the
balance + rhythm?
Firefighting
Deliver
Improve
…

24. Context: eBay company
Story #3 biggest e-commerce market
place for vehicles in Germany

25. The Architecture
web app for a single
use case, e.g. “search” – eBay “pillar architecture”
(every major use case is separate)
– a lot of shared code
– big domain model
– typical change:
shared • impacts one component
code
• the domain model
• full rollout
DB – big bang rollouts, no downtime
– deployment army

26. What we achieved?
2 years
#Releases every 2-3 weeks every week
Cycle Time av. 10-30 days 30 days
Cycle Time min. 30 days 10 days
room for room for
External quality
improvement improvement

27. Context: eBay company
Story #4 biggest e-commerce market
place for vehicles in Germany
Why don’t just skip
the hardening phase?

28. What we achieved?
3 years
#Releases every 2-3 weeks 4-8 per week
Cycle Time av. 10-30 days 1-5 days
Cycle Time min. 30 days 2 hours
room for
External quality pretty good
improvement

29. What helped....
Kanban
Baby
Test Automation
Steps
A huge step
- make the right thing easy
- share responsibility
- cross-functional teams

30. 4 Stories:
What helps? What not?
Story #1 Story #2 Story #3 Story #4
Huge Step Baby Steps Baby Steps Huge Step
Continuous Disruptive
Improvement Change

31. Questions?
Alexander Schwartz
twitter: @alexschwartzbln
e-mail: alexander.schwartz@nokia.com