5. Definitions
Continuous Delivery:
Change in SCM -> Build/Test -> Be able to deploy at
will (keep it clean, ready to deploy)
Typically always deployed to a staging environment
Tuesday, 26 November 13
7. CD - commit to deploy
Target server
Tuesday, 26 November 13
8. Benefits
Quicker turn around
Happier users
Less risk per deployment
Ideally deploy “as is” at (almost) any time
Fits with “agile” approaches nicely
Lots more - bing it!
Tuesday, 26 November 13
9. Necessity
Risk of deployment proportional to time since last
deployment
We are all deploying services now, not so much apps
in a box (other than app store!) - world has changed.
Tuesday, 26 November 13
11. Requirements for CD
Deep SCM integration - commit hooks
Reliable Production-CI service (not under someones
desk)
Automated Deployment
Multiple deploy target environments
Easy rollback
Tuesday, 26 November 13
14. Fiddly
Fiddly to setup by hand - all the hooks, triggers,
scripts, automation...
so we came up with “ClickStarts”
Set up all the moving parts
Tuesday, 26 November 13
15. CD quick start - automated
Clone from template to private repo
Setup commit hooks
Setup build
Issue initial build & run tests
Setup runtime container
Deploy
All one click, ideally
Tuesday, 26 November 13
16. Tedium
Lots of one off steps to get going with CD
You won’t ever remember how to setup commit
hooks each time you need to
Tuesday, 26 November 13
21. CD - dogfood
Some projects are direct to production on tests pass
Some are direct to “staging” until merged into master
branch (git branches to control deployment is
common)
Easily, and often, roll back.
Tuesday, 26 November 13
23. Example
Play Framework:
“Seed project”
Clone into actual project
- setup build steps
- setup unit/e2e tests
- prepare/deploy into a container
- setup commit hook
Tuesday, 26 November 13
25. But wait, it isn’t that easy
More complex workflows
Warming up environments
Safe fall-back
Monolithic apps
Database updates
Some solutions...
Tuesday, 26 November 13
28. Warming up environments
And “fail safe” fall back.
BOTH solved by blue-green deployment.
http:/
/martinfowler.com/bliki/
BlueGreenDeployment.html
Tuesday, 26 November 13
30. Blue Green
2 clones of production environment
Always deploy to “blue”
When ready - flip switch (router) from green to blue.
If bad - flip back - no redeployments, no other
changes
Tuesday, 26 November 13
31. Blue Green
Need to be both production grade environments!
Safer deployment
Can warm up “blue” before flipping switch (prime
caches, run final smoke testing)
Deploying to prod is NOT deploying - just changing
what you call production!
Tuesday, 26 November 13
33. Blue Green
Can shut down “blue” if needed, to safe resources
Large customers already doing this
Large web companies all do this
Tuesday, 26 November 13
34. Blue Green
Warming up: as simple as a curl script in a loop**
** Works quite well
Tuesday, 26 November 13
35. Monolithic apps
Solution: avoid if you can!
Microservices (a whole other topic I love to talk
about)
CD then applies to each service, individually. Each
service has radically different release cadences.
Releases are massively low risk.
Tuesday, 26 November 13
37. Monolithic apps
Still can do CD
Good test suite?
Isolate “risky” changes - more frequent low risk
deploys.
Risk of deploy is proportional to the time between
deploys
Tuesday, 26 November 13
38. Databases
Option 1: Snapshot and then deploy (for rollback)
Option 2: Separate out “destructive” deploys
(schema change, data change) from CD deploys not one size fits all
Daily deploys: DB/data scheme doesn’t change daily
(I hope!)
Tuesday, 26 November 13