ALWAYS READY FOR RELEASE

PRACTICE MAKES PERFECT

@bogdancostea

WHO IS THIS GUY?

developer and lead10+ years experienceJava, .Net, rubydesktop, rich client, web, backendinfrastructure and test automationmulti-language, multi-region deploymentsagile and lean methodsI learning and I trek in weird places

“ a distributed software and product development company focused on delivering outstanding value to our customers using remote teams and cutting edge technologies

Join us at http://www.xogito.com/careers

SO, DOCKER IS…

justkidding, Idothatallthetime, ignoreme

we’re here because we’re in the software business

that usually means that the result of our work is a piece

of softwaredelivering it usually means

deploying it as well

the phase that begins when you start working on something and ends with the customer getting to use it in production…

that’s called cycle timeand shorter is better

if you have 2 week sprints but only deploy a new version after integrating everything into a 6 month release plan, your cycle time is 6

months

if you deploy every sprint your cycle time is2 weeks

if you deploy 5 times a day, your cycle time is roughly 5 hours

bear with me

Amazon deploys every 11.6 secondshttps://www.youtube.com/watch?v=dxk8b9rSKOo

SO, HOW DO WE DECREASE CYCLE TIME?

we can just do lesswe can release without testing

we can automate as much as possible, from version control to

having it deployed to production*

continuousas in all the time

deploymentas in deploying it somewherepipelineas in series of flowing steps

CONTINUOUS DEPLOYMENT PIPELINE

WHAT IS IT?

An evolution over:• version control• automated builds• automated

testing• continuous

integration• continuous

delivery

CD VS CONTINUOUS DELIVERY

continuous delivery usually stops before deploying it to any environment.

continuous deployment automates the deployment process as well.

OK, IT’S BETTER THIS WAY… BUT WHY?

the more frequent the deployment the less riskier

it becomes a known and stable processit forces you to think about your environmenthelps you identify and eliminate bottlenecks

leads to a decoupled architecture, favors micro services

by continuously rehearsing the release process, the organization becomes more competent at doing it, so that releasing becomes autonomic, like breathing, rather than traumatic, like giving birth

- Kief Morris

YOU ALSO GET

more timemore sleepmore trust

happier customers

CD IN PRODUCTION

you don’t need to deploy to production 50 times per

day like Flickr or every 11.6 seconds like Amazon

CD makes you ready to deploy at any time

doesn’t force you do deploy to production every time

PIPELINESThe simple, I’m writing a website, I don’t care pipeline

git - > web hook -> script -> live

The enterprise OMG(TM) pipeline

git -> ci -> automated testing -> create test infrastructure -> populate test db -> deploy to test -

>run automated acceptance tests -> teardown test environment -> branch for stage -> create stage

infrastructure -> populate stage db -> deploy to stage -> send email -> manual acceptance tests(pass/fail) ->

teardown stage infrastructure -> if passed create production infrastructure replica, populate and deploy

-> point load balancer to new infra

HEADS UP

there is no one-size-fits all pipeline

start small, evolve, keep it simpleyou should never skip the

pipelinealways have engineer-driven QA

ALWAYS have a rollback plan

DISSECTING CD

it’s a process, it has one or more steps and one or more process gates, or decision points

gates can be automated or manualmanual gates are limited to push-buttons, think:

Deploy to production

VERSION CONTROL

I mean come on, this slide is redundant, reallyeverything goes in version control

except credentials, that’s baddon’t do that

small, atomic commitstrunk development makes things easier

YOUR ARCHITECTURE AND CODE

micro services win, although not required

decoupled components, isolated, easily deployable

dependencies force larger and more complex pipelines

SOLID at the component level makes life easier

BUILD AUTOMATION AND DEP. MGMT.

… no build automation, no CI, no CI, no CD

you need reproducible builds on any env

build dependencies you can depend on

TEST AUTOMATIONunit tests

integration testsload tests

UI automation testsare great automated process gates, or decision points

you need QA engineers for front-end exploratory

though

CONTINUOUS INTEGRATION

small atomic commits + continuous integration = win

trunk development simplifies things

this can be your CD driver

think Jenkins or Go as CD engines

first things first - you need to separate your environmentsyour toolchain, whatever that may be, must:

know your different environments dev, stage, prod

run build processes based on environment definitions

there's no place like home and no environment like production

ENVIRONMENTS

WHAT ABOUT DATABASES?

setup and tear-down scripts - SQL, dirty

migrations - code, better

database version control with rollback

always aim for production replica environments

WHAT ABOUT INTEGRATIONS

mock or sandbox any external dependencies

use dedicated accounts for every environment for SaaS endpoints

INFRASTRUCTURE AUTOMATION

utility computinginfrastructure as code

containerisation, packs, slugseasy to start over

BE READY TO FAIL

you need a rollback strategy

that you put thought into

that works

you actually tried it at least once

LET’S TALK ABOUT SOME OF YOUR STACKS

CONFERENCE SPONSORS

GOLD

SILVER

BRONZE

MEDIA PARTNERS

www.agile.ba

THANK YOU!@bogdancostea

ifyou’readeveloper interested inremoteworkandchallengingprojects findmearound, messagemeonTwitterorjustgoto

http://www.xogito.com/careers