Linuxtag 2012 - continuous delivery - dream to reality

Continuous Delivery

Dream => Reality

Dr. Clement Escoffier, akquinet

This is a work of fiction. Names, characters, places and projects are all products of the author’s

imagination. Any resemblance to actual events, locales or projects is

entirely coincidental

SITUATION

Again, purely imaginary ;-)

• Running for 2 years

• 4-6 developers

• Agile (Scrum)

Quite a big project

As in all big projects,the build is chaotic

Taking forever, Intermittent failures,Inconsistent output,

Non-reproducible builds,Authorization failures

…

Releasing => Stress

Delivery => Error-prone

=> Delays

Delays => Customer

Trust => Pressure

Quality => Technic. Debt

=> Non optimal project situation

“Let’s deliver a version every day”

Output from an escalation meeting

• Web App, JavaEE…• Up and Running

• Mobile App• Downloadable or in a Market

• Desktop App• Installers, Market, Auto-update• Installed on a system

Did you say “deliver” ?

Developers

More Releases =>

Project Managers

More Paperwork =>

Ops

More Changes =>

CONTINUOUS DELIVERY – THE CHALLENGE

Seamless Disruptive Changes

How to introducecontinuous delivery

seamlessly ?

“Let’s all commit to a continuous delivery

model …

… but without changing the way

we work”

CONTINUOUS DELIVERY – PRINCIPLES

Will try to make it not so boring

• Manual software building and deployment

• Deploying in production-like environment only after releasing

• Manual configuration of the environment

Delivery anti-patterns

A set of good practices to

simplify software delivery

AutomationResponsibilityPipeline

Automation

Bootstrap / Configuration

[Insert your own] Tests

Release, Deployment ProcessDatabase Evolution

Commit Stage

Acceptance Tests

UI Tests

Deployment Tests

Capacity Tests

Release

It’s not only source code…

Source

Data

Configuration

Environment

Build tools &

Build processes

Check-in everything

Source Code

Deployment Script

Data

Evolutions

Build ScriptsEnvironmentDescription

Configuration

Traceability

Unique Versioning

Human-readable

Introspectable

Tags

ReproducibleBuild

Notifications

Continuous Integration

Commit Often

Avoid branches

UnderstandableTest Suites

Use ‘branchby abstraction’

Fast feedbackComprehensive

Tests

Automate Tests

Unit Tests

Test Groups

DeploymentTests

IntegrationTests

SystemTests

UI Tests

Automate Deployment

Describe yourenvironment

Always deploy the same way

Manage configurations

AvoidDev vs. Prod

Did I tell you toTEST ?

Do itfrequently

Plan rollbacks

Implement a teststrategy

Promotion / Release<<Prod Ready>>

Capacity Tests

Deployment Tests

UI Tests

Acceptance Tests

Commit StageTest + Package V1 V2 V3

Artifact Repository

Source Repository

CommitStage

V3

AcceptanceTests

Prom. / Rel. Stage

V3

• As fast as possible• < 5 min is good• < 10 min is acceptable

mvn clean install

• Package, Changelog, Scripts…

The Commit Stage

Build only one package:Distribution

This package is reusedby all the test phases

Describe your environment

Reduce the distance betweenDev & Prod

Always deploy using the same way

BACK TO OUR PROJECT

Implementation Time

SCM => SVN, Git, Git-SVN

Build Tool => Maven

continuous-versioning-mp+

maven-release-plugin

CI => Jenkins

Artifact Repo => Nexus

Development

• Maven build• -SNAPSHOT

• Continuous Versioning

A1.0.0-SNAPSHOT

B1.0.0-SNAPSHOT

C1.0.0

• Vagrant• http://vagrantup.com/

Virtual Environment

• Provisioned using• Shell script• Puppet Manifests• Chef Recipes

=> Your deployment script

Virtual Environment

Commit Stage

Artifact Repository

Source Repository

mvn clean install

1.0.0-SNAPSHOT

Commit Stage

mvn clean install

1.0.0-SNAPSHOT

Fast-Release

1.0.0_42

Artifact Repository

Source Repository

tag

All other stages are using the _42 version

Testing Stages

IntegrationTests

DeploymentTests

UITests

Vagrant Box

Initialize a new VM +

Deployment

Testing Stages

DeploymentTests

UITests

Vagrant Box Staging System

DeploymentTests again

Deployment on a staging system

OtherTests

Releasing

Releasing Promoting

Take the current staged version (RC) => Declare it as G.A.

TOOLING

• Builds• Reproducible• Avoid system deps

• Make, Ant, Maven, Gradle, SBT

Build Tools

• Avoid ‘works on my machine’•Dev/ Test / Run on prod-like system

• Vagrant is awesome

Virtualization

• Customizable• Pipeline concepts

• Jenkins, Hudson, Team City, Bamboo• Travis

Continuous Integration

• Describe your environment• Treat your infra as code

• Shell Script, Puppet, Chef

CMS

• Specific CMS to deploy your application

• Go, Deploy-it, Puppet/Mcollective, JMX

Application Deployer

SOME FINAL WORDS

Responsibility

Following the rules

Trust is back

Seeing changes

Always being ready

Track & Visualize everything

Danke !