Over the course of 15+ years in software development, I've learned quite a bit about automating software delivery. Looking back, I realized that I've been performing Continuous Delivery in one form, or another, for most of that time. Let's take a few minutes to talk about how Continuous Delivery can help teams of all sizes get software into customers' hands faster for tighter, more effective feedback loops. It's all about the automation!

1. Crawl, Walk, and Run to
Continuous Delivery
David Batten
DevOps Specialist and Author @ Pluralsight
djb@battenworks.com
@battenworks

2. Continuous Delivery is the ability to get changes
of all types – including new features,
configuration changes, bug fixes, and
experiments – into production, or into the hands
of users, safely and quickly in a sustainable way.
(continuousdelivery.com)
What is
Continuous
Delivery ?

3. Why Do
Continuous
Delivery ?
● Reduce mistakes
● Manage risk
● Get customer feedback into the system
sooner
● Get customer value into the system sooner
● Because you can

4. Attempt 1
Super fast
Super simple
Instant feedback

5. Attempt 1
Drawbacks
No source control
No tests
No integration
No automated
configuration
management

6. Attempt 2
Source control
Continuous integration
Quick feedback
Automated app
configuration
management

7. Attempt 2
Drawbacks
No tests
No automated system
configuration
management
Branching/merging
complexity
Only automated in Lab
environment

8. Testing Pyramid
Integration
Unit
Acceptance
Slow
$
$$$
Fast

9. Attempt 3
Unit tests
Separate tool to manage
releases (security and
auditing)

10. Attempt 3
Drawbacks
No automated integration
or acceptance tests
No automated system
configuration
management

11. Attempt 4
Automated integration
tests
Automated acceptance
tests
Automated system
configuration
management

12. ● Immutable infrastructure
● Auto scaling
● Fine tuning the system
What’s next ?

13. ● It's about managing risk
● It's about automating the pieces that make
sense, not necessarily the entire thing
● It's about complexity trade-offs
● It's about culture
● Build binaries once, deploy them n times
General
Considerations

14. Thank You
David Batten
DevOps Specialist and Author @ Pluralsight
djb@battenworks.com
@battenworks