Slide deck for the talk given at Agile Tours in Toronto, Montreal and Ottawa.

1. CONTINUOUS DELIVERY
(IN AN AGILE CONTEXT)
Mike Bowler, Agile & Technical Coach
Tweeting? Use @mike_bowler and #atmtl2013

2. Have a question?!
Don’t wait, ask it!

3. WHAT IS CONTINUOUS
DELIVERY AND WHY
SHOULD I CARE?

4. AGILE PRINCIPLES SAY:
“Our highest priority is to
satisfy the customer
through early and
continuous delivery of
valuable software.”

5. AGILE PRINCIPLES SAY:
“Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.”

6. “Wait a minute! My
company doesn’t want
to deploy that often!”
that
ant is t
port
t’s im deliver fas
Wha CAN
you

7. WHAT IS CONTINUOUS
DELIVERY?

8. , Tivoli, .
Nagios w, etc
PenVie
O
One master branch
Production
Monitoring and
Alerts
Rollbacks on
error
Deploy to
production
udson,
Verify expected
enkins / H
J
istrano,
behaviour
S, Cap e shell
TF
omemad, etc.
H
Compile and
scripts
Package
Pull from
master branch

9. WHAT COULD GO
WRONG?
We could put something new in production that
doesn’t work or we could break something that used
to work!
We could put a half finished feature into production
before it was ready and confuse the users!
We could kick the users off the system in the middle
of doing their work

10. HOW DID WE DEAL WITH
THESE IN THE PAST?
We had long manual test cycles between releases!
We typically deployed off-hours when nobody was
using the system
e’re
e if w utes
easibl 15 min
ot f very
N
ying e
deplo

11. PRE-REQUISITES
ARE HARD
Able to deploy to production at the busiest time of the day
with no visible changes - no unexpected changes, no
downtime!
Have sufficient monitoring to know when something goes
wrong and the ability to rapidly fix it or roll back to a known
good state!
No manual processes after code has been checked in. Every
step is automated.!
Holistic view of the process, from customer request to
production support. Team is bigger than just the devs.

12. DB migration
hip
ns
ma
fts
ra
Continuous integration
One click deploy
Configuration management
One click rollback
Provisioning
Zero downtime deploy
C
Automation
Courage
Pride of work
Common Goal
Agile modeling
Evolutionary design
Design
Cluster immune
system
Feature flags
Comparative testing
Simple design
Whole
Team
Usability
Measurements
Stress testing
Workin
people g with
o
your de utside
v team
Alerts
Engaged people
Monitoring
Sustainable pace
Regular retrospectives
Capacity
Individuals
Compliance
ATDD
Planning
Continuous
Delivery
Scalability
Executable specifications
BDD
TDD
Rapid Feedback
Frequent check-ins
Single codebase
Continuous improvement
Version control
Functional
Configuration management
Exploratory testing
Performance
Dependency management
Cross-functional teams
Incremental development
Co-located teams
Pair programming
High communication
Daily standups
Refactoring
Dev Team
Coding standards
Collective code ownership
Shared understanding
Informational workspace
Simple architecture
Small Stories
hin
it
g w am
kin te
or ur
W yo
© 2013 Gargoyle Software Inc

13. INDIVIDUALS
!
“CRAFTSMANSHIP”

14. COURAGE
Courage to say no to requests that compromise the
teams values!
Courage to say code quality isn’t high enough!
Courage to say these deadlines aren’t realistic!
Courage to escalate issues that nobody wants to
talk about

15. “Take pride in what you do. The kind of
pride I'm talking about is not the arrogant
puffed-up kind; it's just the whole idea of
caring - fiercely caring.”
Arnold Jacob "Red" Auerbach was an American basketball coach of the
Washington Capitols, the Tri-Cities Blackhawks and the Boston Celtics.
http://en.wikipedia.org/wiki/Red_Auerbach

16. EVOLUTIONARY DESIGN &
INCREMENTAL DEVELOPMENT
Design and build only
what you need today!
YAGNI : “You aren’t
going to need it”

17. SIMPLE DESIGN
“A complex system that works is
invariably found to have evolved from a
simple system that worked. The inverse
proposition also appears to be true: A
complex system designed from scratch
never works and cannot be made to
work. You have to start over, beginning
with a working simple system.”
-- Gall's Law

18. ENGAGED PEOPLE
Continuous
improvement
(Sharpening the saw)!
Sustainable Pace!
Regular retrospectives

19. AUTOMATED TESTS
ations
ecific
ble Sp
ecuta
Ex
A section of executable code that can be run
repeatedly to ensure that our production code does
what it is supposed to do!
Why is it important to automate these?

20. AUTOMATED TESTS
ations
ecific
ble Sp
ecuta
Ex
Techniques!
ATDD (Acceptance Test Driven Development)!
BDD (Behaviour Driven Development)!
TDD (Test Driven Development)!
All write specifications first. Why is this important?

21. EXPLORATORY TESTING
Looking for issues!
Done earlier in the
process

22. PAIR PROGRAMMING

23. REFACTORING
Code refactoring is a “disciplined technique for
restructuring an existing body of code, altering its internal
structure without changing its external behaviour”,
undertaken in order to improve some of the nonfunctional
attributes of the software. !
!
Advantages include improved code readability and
reduced complexity to improve the maintainability of the
source code, as well as a more expressive internal
architecture or object model to improve extensibility.!
!
-- Wikipedia entry on Refactoring

24. “The trouble with quick and dirty
is that dirty remains long after
quick has been forgotten.”
Steven C. McConnell is an author of many software engineering textbooks
including Code Complete, Rapid Development, and Software Estimation.
http://en.wikipedia.org/wiki/Steve_McConnell

25. DEVELOPMENT TEAM
WORKING TOGETHER

26. SMALL STORIES

27. SHARED
UNDERSTANDING
Agreed standards!
Coding conventions!
Shared design!
Simple architecture

28. COLLECTIVE CODE
OWNERSHIP
We all own the code!
We all keep it clean!
Clean up the garbage, no matter who left it like that!
Freedom to make any change, anywhere in the code
base

29. HIGH COMMUNICATION

30. Informational Workspace

31. CROSS FUNCTIONAL
TEAMS
Everyone should know
a little of everything!
Should everyone be able
to take a vacation? Even
the specialists?

32. CONFIGURATION
MANAGEMENT
Use version control!
Check in everything that can’t be regenerated!
Check in frequently

33. BRANCHING
Avoid feature branches!
Avoid anything that requires manual merging

34. This model assumes one !
branch. !
!
Avoid feature branches.
Production
Monitoring and
Alerts
Rollbacks on
error
Deploy to
production
Verify expected
behaviour
Compile and
Package
Pull from
master branch

35. One branch !
per developer
Production
Monitoring and
Alerts
Deploy to production
Verify expected behaviour
Rollbacks on
error
Compile and package
Merge with master branch
Verify expected
behaviour
Verify expected
behaviour
Verify expected
behaviour
Compile and
Package
Compile and
Package
Compile and
Package
Merge with local
copy of master
Merge with local
copy of master
Merge with local
copy of master
Pull from
Amy’s branch
Pull from
Bob’s branch
Pull from
Carol’s branch

36. DEVELOPMENT TEAM
WORKING WITH
EVERYONE ELSE

37. RAPID FEEDBACK

38. PLANNING &
MEASUREMENT
Plan for production
usage!
Capacity planning!
Compliance!
Scalability!
!
Stress testing!
Comparative
measurements

39. MONITORING & ALERTS
Monitor all production usage and trigger alerts for
abnormal conditions.!
How do operations know what conditions are abnormal?

40. FEATURE FLAGS
A/B testing!
Hiding incomplete features!
Enabling features based on permissions

41. COMMON GOAL
How does each group get measured?!
Developers!
Testers!
DBA’s!
Operations staff!
Are those measurements helping or hurting the
overall goal?

42. AUTOMATION
No more manual
processes!
Full automation of
deploy and rollback,
including database
changes

43. MORE ADVANCED
AUTOMATION
Provisioning!
Getting a new machine up and running !
Configuration management!
Making changes to a machine already running!
Cluster immune system!
Automated rollbacks if the new deploy doesn’t
meet defined acceptable thresholds

44. RECAP

45. Production
Monitoring and
Alerts
Rollbacks on
error
Deploy to
production
Verify expected
behaviour
Compile and
Package
Pull from
master branch

46. PRE-REQUISITES
Able to deploy to production at the busiest time of the day
with no visible changes - no unexpected changes, no
downtime!
Have sufficient monitoring to know when something goes
wrong and the ability to rapidly fix it or roll back to a known
good state!
No manual processes after code has been checked in. Every
step is automated.!
Holistic view of the process, from customer request to
production support. Team is bigger than just the devs.

47. DB migration
hip
ns
ma
fts
ra
Continuous integration
One click deploy
Configuration management
One click rollback
Provisioning
Zero downtime deploy
C
Automation
Courage
Pride of work
Common Goal
Agile modeling
Evolutionary design
Design
Cluster immune
system
Feature flags
Comparative testing
Simple design
Whole
Team
Usability
Measurements
Stress testing
Workin
people g with
o
your de utside
v team
Alerts
Engaged people
Monitoring
Sustainable pace
Regular retrospectives
Capacity
Individuals
Compliance
ATDD
Planning
Continuous
Delivery
Scalability
Executable specifications
BDD
TDD
Rapid Feedback
Frequent check-ins
Single codebase
Continuous improvement
Version control
Functional
Configuration management
Exploratory testing
Performance
Dependency management
Cross-functional teams
Incremental development
Co-located teams
Pair programming
High communication
Daily standups
Refactoring
Dev Team
Coding standards
Collective code ownership
Shared understanding
Informational workspace
Simple architecture
Small Stories
hin
it
g w am
kin te
or ur
W yo
© 2013 Gargoyle Software Inc

48. “Design and programming are human
activities; forget that and all is lost.”
Bjarne Stroustrup is a Danish computer scientist, most notable for the
creation and the development of the widely used C++ programming language.
http://en.wikipedia.org/wiki/Bjarne_Stroustrup

49. MORE READING

50. CONTACTING ME
Mike Bowler!
Agile & Technical Coach !
!
mbowler@GargoyleSoftware.com!
Cell: 905 409-7052!
Twitter: @mike_bowler!
!
Other links for me on Facebook, Google+ etc at!
http://www.GargoyleSoftware.com/mike_bowler

51. HANDOUTS

52. DB migration
hip
ns
ma
fts
ra
Continuous integration
One click deploy
Configuration management
One click rollback
Provisioning
Zero downtime deploy
C
Automation
Courage
Pride of work
Common Goal
Agile modeling
Evolutionary design
Design
Cluster immune
system
Feature flags
Comparative testing
Simple design
Whole
Team
Usability
Measurements
Stress testing
Workin
people g with
o
your de utside
v team
Alerts
Engaged people
Monitoring
Sustainable pace
Regular retrospectives
Capacity
Individuals
Compliance
ATDD
Planning
Continuous
Delivery
Scalability
Executable specifications
BDD
TDD
Rapid Feedback
Frequent check-ins
Single codebase
Continuous improvement
Version control
Functional
Configuration management
Exploratory testing
Performance
Dependency management
Cross-functional teams
Incremental development
Co-located teams
Pair programming
High communication
Daily standups
Refactoring
Dev Team
Coding standards
Collective code ownership
Shared understanding
Informational workspace
Simple architecture
Small Stories
Mike Bowler
hin
it
Agile & Technical Coach
© 2013 Gargoyle Software Inc
g w am
(905) 409-7052
kin te
r r
mbowler@GargoyleSoftware.com
Woyou
@mike_bowler

53. Production
Monitoring and
Alerts
Rollbacks on
error
Deploy to
production
Verify expected
behaviour
Compile and
Package
Pull from
master branch
Mike Bowler
Agile & Technical Coach
(905) 409-7052
mbowler@GargoyleSoftware.com
@mike_bowler