Java Tech & Tools | Continuous Delivery - the Writing is on the Wall | John Stevenson

transcript

©LeanAgileMachineCreative Commons Licence

Continuous Deployment

The writing is on the wall

John StevensonLean Agile Machine

http://creativecommons.org/licenses/by-nc-sa/2.0/uk/

Who is John Stevenson● Lean agile coach

Kanban, system thinking, ToC. ● Atlassian ambassador in UK

Growing communities around JIRA...● Community geek

London Java, Graduate Devs, London Scala, London Clojurians, etc.

● Dabbles with

My Journey

● Started with RUP, UML & XP● Fell for Behaviour Driven

Development & kanban● Learn about a lot of Value &

Systems thinking● Coached teams & individuals● Sharing experiences with

community

So what is Continuous Deployment ?

...its incredibly hard

...even if you are...

...hard plus infinity for everyone else

Continuous deployment example:

Typically:

25 deploys per day

per developer

Forward culture

So why go for continuous

deployment?

http://blog.thehigheredcio.com/2011/08/31/efficiency-vs-effectiveness/

Understanding the business

Table stakes / foundations

SpoilersDifferentiators

Accelerators

Benefits

Where to get started ??

Is your team / company ready ?

A case study in pain and dissapointment!

Change can be expensive

A long journey of discovery

Involving the whole business

Understanding of Value

The right motivation

What is the goal?

Where to start ??

Visualise how you do IT...

Kanban – a wall of Facts

Let the board show issues...

V1.0.1, V1.0.2, V1.0.3, V1.0.4,

Build 1209Build 1221Build 1301

Value stream mapping

The (often wide) path to getting things done

Activities that get things done effectively

Software development

Include the whole process...

Strategy to shiped

Budgeting

Business sign off

Deployment dry run

Improve the foundations

Monitoring your servers

● Nagios / NagVis● The Dude● Microsoft Operations Manager● Outsource IT...

Sever Provisioning

Its all virtual these days...

Virtual Machines

Automate provisioning

Manage sys-admin tasks remotely

Spin up instances into the cloud Using public cloud when your private cloud is maxed out

Off the shelf pre-configured servers

Managing VM's is easy

Automating Virtual Machines

Vagrant – simple to use

● Requirements Ruby Virtualbox Chef / Puppet for other VM systems

Consistent environments

Automated server managementPuppet / Chef / Rex

Disaster recovery for learning

Change freezes

The period of time when the most of the changes happen

When lots of patches are done !

A good time to learn what is important !

Deployment Strategies

If it hurts, do it more often

Segmented deploys

Different customers / different expectations

Timely deployments

Cost of delay ?

When is the software valuable ?

Smaller deployments

Visualise deployment strategies??

Managing your code

It compiles, ship it!!

Compile

Ship It

Automated builds

Design around common patterns for building

Should have valuable reason for doing something different

SBT

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>com.mycompany.app</groupId>

<version>1.0-SNAPSHOT</version>

<name>Maven Quick Start Archetype</name> <url>http://maven.apache.org</url>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency> </dependencies>

</project>

Simple Maven config

Local repositories

Nexus

Artefactory

DVCS

Build tools – continuous feedback

Maven 3 Shell

Simple Build Tool

~Tests

Coding fast feedback

JavaScript

Testable code

● TDD / BDD helped devs have a better appreciation of code that is more testable

● Faster feedback gave devs (and team) better understanding of what is needed

● Resolve issues quickly, prevent many from happening at all

●

Behaviour Driven Developent

Deployable software

● Automated server builds● Automated deployment scripts / tools● Automated tests / specifications● Effective business review

● Faster feedback● Resolve issues quickly● Deploy when valuable

Distributed Versioning

● Smaller repositories Per component / module Simpler architecture

● Manage branching easier with pull requests A pull system is more effective than central push

● Different repos for different purposes Repo for deployment, trunk, CI server

Git Workflow

Git architecure (logical)

Change-set history

Code reviews

DVCS push requests

Central or

Distributed Version control

Centralised team

Centralised issues

Fear of breaking the build

unnecessary branching

delayed commits

Off-line support?

Any redundancy in versioning server?

Managed Distributed team

Continuous Integration

What

When

How long

Run specifications / unit tests

Reports

Actions to initiate

CI Server basics

BOfH CI Server

Kicks out checked in code if it fails

Wires up build bunnies to stop you hiding from broken builds

Wall of shame for breaking builds

Top ten worst programmers

CI Server lights

Ultimate Wallboards

Issue ticker

Stream of issues flowing

Highlight new features, overdue items, critical issues, time related news, etc

UltimateWallboard.com

More than compiling code...

conf/tomcat-users.xml<user username=”bamboo” password=”bamboo” roles=”manager-script,manager-gui”/>

One click deploy

Architect for deployment

Modular systems

Simple interfaces

Supported by acceptance tests (specifications)

Automate low value tasks

Final thoughts

Predictability / Cadence

Smaller tasks

Understanding you capacity

Communicate effectively

Feedback

How will you make a change ?

● Automated deployments● Distributed version control● Refactoring architecture, design & code● Modularity in design● Migrating from technical debt

● Shouting...

Benefits

Thank you

Feedback & Refs

@JR0cket

JStevenson@atlassian.com

John@jr0cket.com

Please note: Very few bulletpoints were hurt during the making of this presentation

The big-ish picture

SummaryAdaptable practices

TDD/BDD, DDD, kanban, ToC, system thinking

Good understanding of supporting tools Cucumber, CI build jobs, DVCS, ...

Strong DevOps capability

Understand business value

A tool to collaborate

Visualising the workload

Pull system

Experditing

● Visualisation for a high priority task Big red sticker Experditing lane Record other tasks being blocked

● Review why you get high priority task Consider it a constraint / bottleneck

Experditing lane

DevOps Goal keeper

● Team rotates people around role ● Goalkeeper fields all issues● Rest of team allowed to

focus on a (bigger) task● Use visual indicator to show

who is the Goalie

Visually represent these points ??

Drop the Backlog

● The backlog is a omnipresent sign of overload

Useful for pushing back to the management

Bad for team moral Hide it away (eg. JIRA)

● When team are in tune with value, tasks flow more naturally – opportunities are not drowned out

Data dashboard effect

● Manager can instantly see what you are working on

● Manager can evaluate priorities easily Or go back and ask for clarification with business

● Gives data on issues Recording task swapping, time to work on tasks Data to review at retrospective on current

approach

Washing line

RSPB

Royal Society for the protection of Bulletpoints

Change at speed of deployment

Be as creative as needed

Managing the change

Subtle ”Theory of Constraints”

● What is stopping you achieve your goals ? Identify all the current challenges

● Find how to work effectively With respect to the biggest challenge

● Incrementally improve around biggest challenge

● Review the challenges

Change at the speed of acceptance

● Effective change cannot be pushed

● kanban estoles pull, change should be pulled

● Odd that some many agile projects start and end with a big bang

Lean Startup

● Business canvas model● Real options● Last responsible moment● Least responsible change

Lessons from Service Desk

● Variation of personal kanban Sticky notes at the side of the keyboard One priority at once Need business reason to change priorities

Record reason and number of times you had to revisit the task

DevOps overload

● Lots of last minute patches

● Deployment like buses, nothing for a few days then three come at once for the same night

● DevOps have no time to script deployments

● Have to deal with long, boring deployment documents

● Repeatedly swiched from infrastructure work, vastly increasing time taken.

Summary of Kanban

● Visualse work● Manage WIP● Engage with business

Shared ownership● Encourage realistic

priorities

● Helps you stay sane

● Show you are productive

● Deal with micro-management

Java Tech & Tools | Continuous Delivery - the Writing is on the Wall | John Stevenson

Technology