Presentation about Continuous Delivery at Scania Connected Services by Anders Lundsgård and Peter Sandberg. The presentation was held in Stockholm the 9th of April on NFI Testfourm 2014.

1. Continuous Delivery
Daily releases to production
Anders Lundsgård
Peter Sandberg
Engineers, Scania Connected Services
Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
from ”the agile manifesto”

2. Continuous Delivery
Deployment
Release
Quality

3. Do you have the guts to deploy
to production 50 times a day!?

4. This is Agile!
© Bestoutcome Ltd 2014

5. This is Agile!
Weeks
Months!
Prod
Last Mile

6. http://www.perforce.com/continuous-delivery-report

7. Why Continuous Delivery?

8. Major measure for Continuous Delivery
CYCLE TIME
”How long would it take your organization to
deploy a change [to production] that involves
just one single line of code? Do you do this on a
repeatable, reliable basis?”
Mary and Tom Poppendieck
Implementing Lean Software Development

9. Smartphone access
to driver/vehicle
data
Scania Connected Services
FMP
Communication
Servers
Web Servers
Monitoring
Report
Email and
SMS
remiders/
alarms
Fleet
Management
Portal
Remote Diagnosis
Current status message
every minute
Web Service
Interface
FMP
MPMP

10. Key koncepts for CD
• Test Driven Development
• Deployment Pipeline
• Continuous Integration
• Configuration Management
• Feature Toggles
• A/B tests
• Always On
• Tear the walls
Cultural
changes
Technical
patterns

11. Technical patterns

12. QA in Continuous Delivery

13. Test Driven Development
Design Code Test
CodeTest
Design
Deploy
Deploy
Code in to VCS Manual work
Prod
Prod

14. Test Pyramid
Unit Tests
Integration Tests
GUI
Tests
Manual
”inspection”

15. Test Ice Cream?
Unit
Tests
Integration Tests
GUI Tests
Manual Regression

16. Test movement
Communication via error reports Communication face to face
Tests executed in desktop
environment
Tests into the Deployment Pipeline
GUI-oriented tests Tests towards service layer
Test specific dev environment Same dev environment as developers
Separated test teams Embedded testers

17. Deployment Pipeline

18. Deployment Pipeline
Commit Stage Acceptance Stage Load Stage Deploy Stage
Compile Unit Test Analysis Packaging Acc.
Deploy
Acc. Tests Exploraty
Tests
Load
Tests
Perf
Tests
Staging
Deploy
Prod
Deploy
...
..
…..

19. Deployment Pipeline
Commit Stage Acceptance Stage Load Stage Deploy Stage
Compile Unit Test Analysis Packaging Acc.
Deploy
Acc. Tests Exploraty
Tests
Load
Tests
Perf
Tests
Staging
Deploy
Prod
Deploy
...
..
…..

20. NO IDE Build, Test or Deploy!!

21. Continuous Integration
• Maintain a Single Source Repository
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits To the Mainline Every Day
• Every Commit Should Build the Mainline on an
Integration Machine
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment

22. Configuration Management
R&D IT
Config file here
and there…
Click here and
there …
First script #1
and then script
#2…
Failover this
and that…
Register key
here and
there …
First alias #1
and then alias
#2…
Release plans
Single source of truth
VCS

23. Feature Branch
Dev Branch #1
Main
Release Branch #1
Dev Branch #2

24. Feature Toggle
Main
GUI
Business
Logic
Database

25. Feature Toggles

26. A/B tests

27. A/B tests
20%
of users

28. Always On

29. DB
Web1 Web2
Load balancer
1. Add new schema
2. Write to both schemas
3. Backfill historical data
4. Read from new schema
5. Remove writes to old schema
6. Remove old schema

30. Cultural change
1. Tear the walls
2. Empower the engineers

31. DevOps
Operations people are rewarded for things
not going wrong.
Developers are rewarded for getting
releases out.
And those two goals are in conflict.
Jez Humble: co-author of the book: Continuous Delivery

33. If I had an idea last night…
…I coded it up this morning…
…I got it on the site this afternoon…
and tomorrow I got data.
In a couple of weeks I’ve learned as
much as I would have in over a year
in a regular system.
http://www.infoq.com/presentations/Facebook-Moving-Fast-at-Scale

36. At the end of the day it is the person
who writes the code who is responsible
for whether or not it works.

41. Are we making
Is Prod
doing well?
Code
metrics

42. Implemented CD i 2 months!
The Software Revolution Behind LinkedIn’s Gushing Profits
- We wanted to be at the point where… as soon as they were checking in
their code… it was qualified and releasable…
- We were able to scale the team to hundreds of developers.
- It was a pretty big risk the business took, to say to its engineering team,
you’re going to run across a bridge and burn it behind you.
2011
Kevin Scott

44. Resources
ISBN-13:978-0321601919
www.continuousdelivery.eu

45. Contact
• Peter Sandberg
– peter.sandberg@scania.com
• Anders Lundsgård
– anders.lundsgard@scania.com