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