The document discusses continuous delivery (CD) and continuous integration (CI). It defines CD as automatically deploying code changes to a staging environment after builds and tests pass, while CI involves continuous building and testing of code changes. The document outlines benefits of CD like quicker turnaround and less deployment risk. It also discusses requirements for CD like integration with source control management and automated deployments. Additionally, it proposes solutions for complex workflows, database changes, and monolithic applications in a CD pipeline.

1. Continuous Delivery
Michael Neale
@michaelneale
cloudbees.com
Tuesday, 26 November 13

2. Continuous Delivery?
Tuesday, 26 November 13

3. Definitions
Continuous Deployment:
FTP php files to production server.
Done.
Tuesday, 26 November 13

4. Definitions
Continuous Deployment:
Change in SCM -> Build/Test -> Deploy
(deploy to prod, or staging?)
Tuesday, 26 November 13

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

6. Definitions
Continuous Integration:
Change in SCM -> Build/Test -> Feedback cycle
CD requires “CI”
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

10. Continuous Integration
Jenkins-ci.org
Also have to mention Atlassian
Bamboo!
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

12. CloudBees is:
Tuesday, 26 November 13

13. App service
Tuesday, 26 November 13
repos
CI server

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

17. Tuesday, 26 November 13

18. Build slave pools
on commit
Forge/source repos
open source/template
repos
Tuesday, 26 November 13
Jenkins
Apps

19. Dog food eating
Tuesday, 26 November 13

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

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

24. https:/
/github.com/../play2-clickstart
shallow clone
Your code
git.cloudbees.com/your/app
you.ci.cloudbees.com
yourapp.com
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

26. Complex workflows
Tuesday, 26 November 13

27. Jenkins pipeline plugin
https:/
/wiki.jenkins-ci.org/display/JENKINS/Build
+Pipeline+Plugin
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

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

32. Blue Green
http:/
/developer-blog.cloudbees.com/2013/08/bluegreen-deployments-with-jenkins-and.html
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

36. micro-service debugging
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

39. Thank you
Michael Neale
https://twitter.com/michaelneale
https://developer.cloudbees.com
Tuesday, 26 November 13