CONTINUOUS DELIVERY
(IN AN AGILE CONTEXT)

Mike Bowler, Agile & Technical Coach
Tweeting? Use @mike_bowler and #atmtl2013
Have a question?!
Don’t wait, ask it!
WHAT IS CONTINUOUS
DELIVERY AND WHY
SHOULD I CARE?
AGILE PRINCIPLES SAY:

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

“Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preferen...
“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
WHAT IS CONTINUOUS
DELIVERY?
, Tivoli, .
Nagios w, etc
PenVie
O

One master branch

Production

Monitoring and
Alerts
Rollbacks on
error

Deploy to	

p...
WHAT COULD GO
WRONG?
We could put something new in production that
doesn’t work or we could break something that used
to w...
HOW DID WE DEAL WITH
THESE IN THE PAST?
We had long manual test cycles between releases!
We typically deployed off-hours w...
PRE-REQUISITES
ARE HARD
Able to deploy to production at the busiest time of the day
with no visible changes - no unexpecte...
DB migration

hip
ns

ma
fts
ra

Continuous integration

One click deploy

Configuration management

One click rollback

P...
INDIVIDUALS
!

“CRAFTSMANSHIP”
COURAGE
Courage to say no to requests that compromise the
teams values!
Courage to say code quality isn’t high enough!
Cou...
“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 id...
EVOLUTIONARY DESIGN &
INCREMENTAL DEVELOPMENT

Design and build only
what you need today!
YAGNI : “You aren’t
going to nee...
SIMPLE DESIGN
“A complex system that works is
invariably found to have evolved from a
simple system that worked. The inver...
ENGAGED PEOPLE

Continuous
improvement
(Sharpening the saw)!
Sustainable Pace!
Regular retrospectives
AUTOMATED TESTS

ations
ecific
ble Sp
ecuta
Ex

A section of executable code that can be run
repeatedly to ensure that our...
AUTOMATED TESTS

ations
ecific
ble Sp
ecuta
Ex
Techniques!

ATDD (Acceptance Test Driven Development)!
BDD (Behaviour Driv...
EXPLORATORY TESTING

Looking for issues!
Done earlier in the
process
PAIR PROGRAMMING
REFACTORING
Code refactoring is a “disciplined technique for
restructuring an existing body of code, altering its internal...
“The trouble with quick and dirty
is that dirty remains long after
quick has been forgotten.”

Steven C. McConnell is an a...
DEVELOPMENT TEAM
WORKING TOGETHER
SMALL STORIES
SHARED
UNDERSTANDING
Agreed standards!
Coding conventions!
Shared design!
Simple architecture
COLLECTIVE CODE
OWNERSHIP
We all own the code!
We all keep it clean!
Clean up the garbage, no matter who left it like that...
HIGH COMMUNICATION
Informational Workspace
CROSS FUNCTIONAL
TEAMS

Everyone should know
a little of everything!
Should everyone be able
to take a vacation? Even
the ...
CONFIGURATION
MANAGEMENT

Use version control!
Check in everything that can’t be regenerated!
Check in frequently
BRANCHING

Avoid feature branches!
Avoid anything that requires manual merging
This model assumes one !
branch. !
!
Avoid feature branches.

Production

Monitoring and
Alerts
Rollbacks on
error

Deploy...
One branch !
per developer

Production

Monitoring and
Alerts

Deploy to production
Verify expected behaviour

Rollbacks o...
DEVELOPMENT TEAM
WORKING WITH
EVERYONE ELSE
RAPID FEEDBACK
PLANNING &
MEASUREMENT
Plan for production
usage!
Capacity planning!
Compliance!
Scalability!
!

Stress testing!
Comparati...
MONITORING & ALERTS
Monitor all production usage and trigger alerts for
abnormal conditions.!
How do operations know what ...
FEATURE FLAGS

A/B testing!
Hiding incomplete features!
Enabling features based on permissions
COMMON GOAL
How does each group get measured?!
Developers!
Testers!
DBA’s!
Operations staff!
Are those measurements helpin...
AUTOMATION

No more manual
processes!
Full automation of
deploy and rollback,
including database
changes
MORE ADVANCED
AUTOMATION
Provisioning!
Getting a new machine up and running !
Configuration management!
Making changes to a...
RECAP
Production

Monitoring and
Alerts
Rollbacks on
error

Deploy to	

production
Verify expected	

behaviour
Compile and	

Pac...
PRE-REQUISITES
Able to deploy to production at the busiest time of the day
with no visible changes - no unexpected changes...
DB migration

hip
ns

ma
fts
ra

Continuous integration

One click deploy

Configuration management

One click rollback

P...
“Design and programming are human
activities; forget that and all is lost.”

Bjarne Stroustrup is a Danish computer scient...
MORE READING
CONTACTING ME
Mike Bowler!
Agile & Technical Coach !
!

mbowler@GargoyleSoftware.com!
Cell: 905 409-7052!
Twitter: @mike_b...
HANDOUTS
DB migration

hip
ns

ma
fts
ra

Continuous integration

One click deploy

Configuration management

One click rollback

P...
Production

Monitoring and
Alerts
Rollbacks on
error

Deploy to	

production
Verify expected	

behaviour
Compile and	

Pac...
Upcoming SlideShare
Loading in …5
×

Continuous Delivery for Agile Teams

898 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
898
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Continuous Delivery for Agile Teams

  1. 1. CONTINUOUS DELIVERY (IN AN AGILE CONTEXT) Mike Bowler, Agile & Technical Coach Tweeting? Use @mike_bowler and #atmtl2013
  2. 2. Have a question?! Don’t wait, ask it!
  3. 3. WHAT IS CONTINUOUS DELIVERY AND WHY SHOULD I CARE?
  4. 4. AGILE PRINCIPLES SAY: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
  5. 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. 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. 7. WHAT IS CONTINUOUS DELIVERY?
  8. 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. 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. 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. 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. 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. 13. INDIVIDUALS ! “CRAFTSMANSHIP”
  14. 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. 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. 16. EVOLUTIONARY DESIGN & INCREMENTAL DEVELOPMENT Design and build only what you need today! YAGNI : “You aren’t going to need it”
  17. 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. 18. ENGAGED PEOPLE Continuous improvement (Sharpening the saw)! Sustainable Pace! Regular retrospectives
  19. 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. 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. 21. EXPLORATORY TESTING Looking for issues! Done earlier in the process
  22. 22. PAIR PROGRAMMING
  23. 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. 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. 25. DEVELOPMENT TEAM WORKING TOGETHER
  26. 26. SMALL STORIES
  27. 27. SHARED UNDERSTANDING Agreed standards! Coding conventions! Shared design! Simple architecture
  28. 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. 29. HIGH COMMUNICATION
  30. 30. Informational Workspace
  31. 31. CROSS FUNCTIONAL TEAMS Everyone should know a little of everything! Should everyone be able to take a vacation? Even the specialists?
  32. 32. CONFIGURATION MANAGEMENT Use version control! Check in everything that can’t be regenerated! Check in frequently
  33. 33. BRANCHING Avoid feature branches! Avoid anything that requires manual merging
  34. 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. 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. 36. DEVELOPMENT TEAM WORKING WITH EVERYONE ELSE
  37. 37. RAPID FEEDBACK
  38. 38. PLANNING & MEASUREMENT Plan for production usage! Capacity planning! Compliance! Scalability! ! Stress testing! Comparative measurements
  39. 39. MONITORING & ALERTS Monitor all production usage and trigger alerts for abnormal conditions.! How do operations know what conditions are abnormal?
  40. 40. FEATURE FLAGS A/B testing! Hiding incomplete features! Enabling features based on permissions
  41. 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. 42. AUTOMATION No more manual processes! Full automation of deploy and rollback, including database changes
  43. 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. 44. RECAP
  45. 45. Production Monitoring and Alerts Rollbacks on error Deploy to production Verify expected behaviour Compile and Package Pull from master branch
  46. 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. 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. 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. 49. MORE READING
  50. 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. 51. HANDOUTS
  52. 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. 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

×