Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1vfO62b. Lisa Van Gelder provides simple tips and tricks for improving delivery without investing lots of time up front creating complex deployment frameworks. Filmed at qconsf.com. Lisa Van Gelder is a Senior Consultant at Cyrus Innovation where she works with companies to build and deliver software solutions, improve their software development process, and speed up delivery.

1. Continuous Delivery
for the rest of us

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/cd-tips-tricks

3. Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon San Francisco
www.qconsf.com

4. About me
• Lisa van Gelder
• Consultant at Cyrus Innovation
• lvangelder@cyrusinnovation.com
• @techbint

5. Continuous Delivery
Is not:!
• Continuous deployment
• Automating all the things
Is:
• Removing the bottlenecks that stop you delivering

17. Ooda loop
• observe, orient, decide, and act
- John Boyd, Father of the F16

19. Continuous Delivery
• Measure the total cycle time
• Reduce your cycle time
• Improve your reaction time

20. How do you choose
where to start?

21. Double the frequency
of releases

22. Benefits of smaller releases
• Code only has value in production - get it there
quicker!
• Less co-ordination required
• Easier to test
• Easier to see if it caused issues in production
• Easier to rollback

23. If you can’t release,
fake it

25. Blockers
• Releases cause problems for users
• Ops team don’t have time to do more releases
• Ops/dev don’t have time to support more releases
• QA don’t have time to test new features
• Takes too long to get a green build

26. Releases cause problems
for users
• data loss
• performance issues
• broken functionality

27. The cms that made journalists
stop work for 20 minutes…
• db changes tied to code changes
• too much state in session

28. Releases cause
performance problems
• play back logs
• soak test
• dark launch
• performance test as soon as you can

29. Releases break existing
functionality
• missing tests
• no env like prod to test on

30. The cdn that broke the
release
• POST /myapp/comment/123/recommend

31. Ops don’t have the time
to perform more releases

34. Ops/dev don’t have time to
watch releases
• Release interrupts normal work
• Team on standby in case of issues

35. Help!

37. Rollbacks
• The risk is much higher when rollback isn’t possible
• Rollbacks should be normal operation, not a failure
• Users don’t care about your new feature if the site
is down
1. It should be possible to rollback
2. It should be quick to rollback

38. Rollbacks

39. A release should be a non-
event
• Done in working hours
• Easy to monitor
• Easy to rollback

40. QA don’t have time to test

42. Cross-functional issues
• release waiting on qa sign off
• release waiting on product manager sign off
• developers waiting on designs
• ux waiting on developers
• front-end developers waiting on back-end

44. Cross functional teams
• don’t start story if all resources aren’t available
• blockers should block
• when work is held up - can someone else perform
that function?

45. Takes too long to get a
green build
• Flaky tests
• Slow-running tests
• Merge hell

46. Flaky tests
• The tests that cry wolf
• Isolate them
• Fix them or delete them

47. Slow running tests
• More than 5 minutes is slow
• Waste of developer time
• Interrupt flow to fix
• People deploy without waiting for tests
• Frequent broken build

48. Slow running tests
• separate unit tests from acceptance tests
• limit the amount of acceptance tests
• mock dependencies - limit calls to db
• run tests in parallel

49. Merge hell
• Continuous Integration is more often than you think!
• Don’t have long lived feature branches
• Check in to master at least once a day
• Feature switches
• Branch by abstraction

51. QA define automated testing
strategy

52. Automate performance tests
What criteria do humans use to evaluate
performance tests?

53. • Have a performance test environment that is a scaled-
down replica of production
• Automate log collection, make sure tests reflect current
traffic patterns.
• Use your application-specific metrics
• Define acceptable ranges for your application

54. Automate release process
What criteria do humans use to evaluate
a successful release?
Use your application-specific metrics
and acceptable ranges

55. Summary
• Measure your cycle time
• Fix your bottlenecks
• Improve your reaction time

56. Questions?
Feedback please!
http://bit.ly/1q3FFIo

57. Suggestions for further
reading
• Continuous Delivery by Jez Humble & David Farley
• The Phoenix Project by Gene Kim, Kevin Behr &
George Spafford
• The Goal by Eliyahu M. Goldratt & Jeff Cox
• Lean Software Development by Mary Poppendieck
& Tom Poppendieck
• Release It! by Michael T. Nygard

58. Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/cd-tips-
tricks