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

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

<modelVersion>4.0.0</modelVersion>

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

<artifactId>my-app</artifactId> <packaging>jar</packaging>

<version>1.0-SNAPSHOT</version>

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

<dependencies>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.8.2</version>

<scope>test</scope>

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

[email protected]

[email protected]

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

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