An internal discussion around the type of practices an organisation needs to adopt to be able to move to continuous deployments

1. How I
learned to
stop worrying
and love to
deploy
Getting to daily deploys (weekly for apps)

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

3. 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)

4. FOUNDATIONAL PRINCIPLES
1. Config as code
2. Confidence through CI/CD
3. Incremental unit of work
4. Immutable infrastructure, Reversible/Canary deploys
5. Shared operational responsibility (monitoring, alerts, pager rotation)

5. CONFIG AS CODE
1. Shared ownership of configuration between
dev and ops
a. Dev & ops updating common configs
2. Common configuration between dev,
staging, production
a. Vagrant for local development
b. Common ansible roles
c. Config code versioned together with
application
3. No local changes on VMs in all
environments
4. Ephemeral servers: Servers torn down and
rebuilt from scratch on config push/daily, cheaper

6. CONFIDENCE THROUGH CI/CD
1. Everyone (Stakeholders,
Product, testers, dev, ops etc) is
aware of the state of the build
a. CI Monitors
b. CI in the critical path of a daily
workflow
2. Devs+ops make keeping the
build green paramount
3. Green build == Deployable build
a. Ensure the automated tests cover
critical paths, includes UI testing

7. INCREMENTAL UNIT OF WORK
1. 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 ceremony
a. Feature toggles
b. In general stories should take between 1-3 days max

8. IMMUTABLE INFRASTRUCTURE
1. 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

9. SHARED OPERATIONAL RESPONSIBILITY
1. Dev and ops on call
schedules
2. Shared responsibility
between dev/ops/testers
3. PM updated of operational
overheads, prioritizes
stories to improve things
4. Shared pager responsibility