Continuous deployment

Post on 01-Nov-2014

269 views 1 download

description

When you do Continuous Deployment you can deploy whenever you want: you made it as easy as possible and you have become very good at it. Every engineer knows how to deploy the application to any environment. The Product Department can always see the latest bells and whistles as they are built because you have Stable servers running the latest versions of the application. You implement big changes gradually and show them to Product while keeping the customer's experience stable. When you decide to release, you have made sure all things will work and you know how to react if nevertheless they break, without fires or panic. Continuous Deployment also forces you to do many right things: repeatable builds; the exact same deployment process in all environments, including the developer's machines and a development environment that is as close to Live as possible; backwards-compatible database changes; easy rollbacks; code that is split into components; good tests... In this talk I give an introduction to Continuous Deployment: why you should care, what it means and I propose a few first steps towards introducing this methodology. I presented this talk at DjangoCon EU 2013.

Transcript of Continuous deployment

ContinuousDeployment

Òscar Vilaplana@grimborgdev@oscarvilaplana.cat DjangoCon EU 2013

"""We're hiring!"""from paylogic import (code, highavailability, challenge)from netherlands import (fun, nature, bikes, beer)

def hire(you): email('oscar.vilaplana@paylogic.eu', you.cv) return challenge.accept()

"""We're hiring!"""from paylogic import (code, highavailability, challenge)from netherlands import (fun, nature, bikes, beer)

def hire(you): email('oscar.vilaplana@paylogic.eu', you.cv) return challenge.accept()

intro

deploy

easy

good at it

everyone

Product Owner

Stable

latest versions

big changes

gradually

acceptance

stable

works

Done

breaks

don't panic

forces

Right Things

repeatable

identical

deployment

environments

backwardscompatible

rollback

components

tests

yes it does!

start working

energy

download

setup.py

broken

dependency

pip install

setup.py

nope

docs&

hack

for(;;)

pip uninstall giveafuck

Life life = new Life()

taming a lion1800s

beat into submissionfear

guns & whipsconfusion

taming a lionpresent

understandconditioning

behaviour → signalreward

trust

taming a lion1800s

beat into submissionfear

guns & whipsconfusion

deploy by hand, hackfear

guns & whipsconfusion

deploy by hand, hackbut it works!guns & whips

confusion

deploy by hand, hackbut it works!

hack till it worksconfusion

deploy by hand, hackbut it works!

hack till it worksspecial decisions

taming a lionpresent

understandconditioning

behaviour → signalreward

trust

deploy: hardconditioning

behaviour → signalreward

trust

deploy: hardCI

behaviour → signalreward

trust

deploy: hardCI

push → test → greenreward

trust

deploy: hardCI

push → test → greenhappytrust

deploy: hardCI

push → test → greenhappy

it works in Live

what you needwhat you need

team

working software

repeatable build

deployment

rollback

release

team

committedto

quality

processcan't

compensate

pip installgiveafuck

everyonedeploys

identicalenvironment

everyoneis

responsible

learn

workingsoftware

tests

unit tests

functional tests

acceptance tests

acceptance:

user'sviewpoint

continuousintegration

quickreliable

slow test: fail

no pylint: fail

keep it green

check in often

always ready torollback

responsible:dev + qa

quality

broken:triage

right now

vs

asap

repeatablebuild

automated

used by everyoneeverywhere

no manual changes

deploymentscript

used by everyoneeverywhere

deploy.sh<environment>

<version>

not just code

configurationinfrastructure

always followpipeline

even on emergencies

buggy changesunknown stateirreproducible

what went wrong?

what went wrong?

rollback

blue-greengreen is live

release to bluetest, accept

blue is new green

canary

show new versionto a few

database:keep backwards-

compatible

release

last stepautomatic

small changesfrequent

experience

less risk

maybenot for you

tips

split in components

rehearse releases

get very goodat them!

infrastructure

manage and test

all environments equal

use vagrant

automate everything

(not possible?document)

Questions?Answers?

@grimborgdev@oscarvilaplana.cat Thank you!