How I learned to stop worrying and love to deploy

Getting to daily deploys (weekly for apps)

WHY: ITS ALL ABOUT THE FEEDBACK ● Shortening the feedback loop allows us to be responsive● Deploys are a key part of the feedback cycle● If you are deploying daily without fuss, a whole host of other things are going

well: engineering organizational healthcheck

Production metrics & user feedback > Story writing & estimates (IPM) > Compilation > UI test > Unit tests > Pair/Code review >

Show&tell/Demoday > CI > Staging Deploy (CD) > Tester delivering stories > PM accepting stories > Production Deploy > Production metrics

& user feedback

TLDR;1. AUTOMATE ALL THE THINGS (CI - Green builds, CD-automatable canary

deploys, Monitoring and alerting)2. ORGANIZATIONAL ROLE TWEAKS (Product - Developers - Testers -

Infra/Support)3. STANDARDIZATION (Toolsets, frameworks, deployment procedures,

monitoring, logging)4. LOTS OF EFFORT FROM EVERYONE, WITH POWER COMES

RESPONSIBILITY (Ownership of costs, Discipline to process, Ownership of production issues)

FOUNDATIONAL PRINCIPLES1. Config as code2. Confidence through CI/CD3. Incremental unit of work4. Immutable infrastructure, Reversible/Canary deploys5. Shared operational responsibility (monitoring, alerts, pager rotation)

CONFIG AS CODE

1. Shared ownership of configuration between dev and opsa. Dev & ops updating common configs

2. Common configuration between dev, staging, productiona. Vagrant for local developmentb. Common ansible roles c. Config code versioned together with

application3. No local changes on VMs in all

environments4. Ephemeral servers: Servers torn down and

rebuilt from scratch on config push/daily, cheaper

CONFIDENCE THROUGH CI/CD 1. Everyone (Stakeholders,

Product, testers, dev, ops etc) is aware of the state of the builda. CI Monitorsb. CI in the critical path of a daily

workflow

2. Devs+ops make keeping the build green paramount

3. Green build == Deployable builda. Ensure the automated tests cover

critical paths, includes UI testing

INCREMENTAL UNIT OF WORK1. Units of work (stories) that are small and that is understood

across the team (PM, dev, test, ops)2. Constantly merging, testing, deploying > trickle through the

process with no ceremonya. Feature togglesb. In general stories should take between 1-3 days max

IMMUTABLE INFRASTRUCTURE1. Always baking images, no

changes in production on running instances, always replace with latest instance

2. Ansible used as a config management tool to build images - same roles used on dev

3. Canary deploys

SHARED OPERATIONAL RESPONSIBILITY1. Dev and ops on call

schedules2. Shared responsibility

between dev/ops/testers 3. PM updated of operational

overheads, prioritizes stories to improve things

4. Shared pager responsibility