Continuous Delivery for Agile Teams

CONTINUOUS DELIVERY (IN AN AGILE CONTEXT)

Mike Bowler, Agile & Technical CoachTweeting? Use @mike_bowler and #atmtl2013

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

WHAT IS CONTINUOUS DELIVERY AND WHY

SHOULD I CARE?

“Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.”

AGILE PRINCIPLES SAY:

“Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the

shorter timescale.”

AGILE PRINCIPLES SAY:

“Wait a minute! My company doesn’t want to deploy that often!”

What’s important is that

you CAN deliver fast

WHAT IS CONTINUOUS DELIVERY?

Pull from master branch

Compile and Package

Verify expected behaviour

Deploy to production

Monitoring and Alerts

Rollbacks on error

Production

One master branch

Jenkins / Hudson, TFS, Capistrano, Homemade shell

scripts, etc.

Nagios, Tivoli, OPenView, etc.

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

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

Not feasible if we’re

deploying every 15 minutes

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.

Continuous

Delivery

Individuals

Courage

Pride of work

Design

Agile modeling

Evolutionary design

Simple design

Usability

Engaged people

Continuous improvement

Sustainable pace

Regular retrospectives

Executable specifications

ATDD

BDD

TDD

Exploratory testing

Functional

Performance

Incremental development

Pair programming

Refactoring

Dev Team

Configuration management

Version control

Frequent check-ins

Single codebase

Dependency managementCross-functional teams

High communication

Co-located teams

Daily standups

Shared understanding

Coding standards

Collective code ownership

Informational workspace

Simple architectureSmall Stories

Whole

Team

Automation

Continuous integrationDB migration

One click deploy

One click rollback

Zero downtime deploy


Provisioning

Cluster immune

system

Common Goal

Feature flags

Measurements

Comparative testing

Stress testing

MonitoringAlerts

Planning

Capacity

Compliance

Scalability

Rapid Feedback

© 2013 Gargoyle Software Inc

Craftsmansh

ip

Working within

your team

Working with people outside your dev team

INDIVIDUALS !

“CRAFTSMANSHIP”

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

“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

http://en.wikipedia.org/wiki/Red_Auerbach

EVOLUTIONARY DESIGN & INCREMENTAL DEVELOPMENT

Design and build only what you need today!

YAGNI : “You aren’t going to need it”

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

ENGAGED PEOPLE

Continuous improvement (Sharpening the saw)!

Sustainable Pace!


AUTOMATED TESTS

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?

Executable Specifications

AUTOMATED TESTS

Techniques!

ATDD (Acceptance Test Driven Development)!

BDD (Behaviour Driven Development)!

TDD (Test Driven Development)!

All write specifications first. Why is this important?

Executable Specifications

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 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

“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

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!

Freedom to make any change, anywhere in the code base

HIGH COMMUNICATION

Informational Workspace

CROSS FUNCTIONAL TEAMS

Everyone should know a little of everything!

Should everyone be able to take a vacation? Even the specialists?

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


Compile and Package




Rollbacks on error

ProductionThis model assumes one !branch. !!Avoid feature branches.

Pull from Amy’s branch

Compile and Package




Rollbacks on error

Production

Merge with master branch

Compile and package


One branch !per developer

Merge with local copy of master

Pull from Bob’s branch

Compile and Package



Pull from Carol’s branch

Compile and Package



DEVELOPMENT TEAM WORKING WITH EVERYONE ELSE

RAPID FEEDBACK

PLANNING & MEASUREMENT

Plan for production usage!

Capacity planning!

Compliance!

Scalability!

!

Stress testing!

Comparative measurements

MONITORING & ALERTSMonitor all production usage and trigger alerts for abnormal conditions.!

How do operations know what conditions are abnormal?

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 helping or hurting the overall goal?

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 machine already running!

Cluster immune system!

Automated rollbacks if the new deploy doesn’t meet defined acceptable thresholds


Compile and Package




Rollbacks on error

Production

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.

Continuous

Delivery

Individuals

Courage

Pride of work

Design

Agile modeling

Evolutionary design

Simple design

Usability

Engaged people


Sustainable pace



ATDD

BDD

TDD

Exploratory testing

Functional

Performance


Pair programming

Refactoring

Dev Team


Version control

Frequent check-ins

Single codebase


High communication

Co-located teams

Daily standups


Coding standards




Whole

Team

Automation


One click deploy

One click rollback



Provisioning

Cluster immune

system

Common Goal

Feature flags

Measurements

Comparative testing

Stress testing

MonitoringAlerts

Planning

Capacity

Compliance

Scalability

Rapid Feedback


Craftsmansh

ip

Working within

your team


“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

http://en.wikipedia.org/wiki/Bjarne_Stroustrup

Continuous Delivery for Agile Teams

Technology

Transcript of Continuous Delivery for Agile Teams