Cd syd

Continuous DeliveryMichael [email protected]

Tuesday, 26 November 13

http://www.cloudbees.com


Continuous Delivery?


Definitions

Continuous Deployment:

FTP php files to production server.

Done.


Definitions

Continuous Deployment:

Change in SCM -> Build/Test -> Deploy (deploy to prod, or staging?)


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


Definitions

Continuous Integration:

Change in SCM -> Build/Test -> Feedback cycle

CD requires “CI”


CD - commit to deploy

Target server


Benefits

Quicker turn aroundHappier usersLess risk per deploymentIdeally deploy “as is” at (almost) any timeFits with “agile” approaches nicely

Lots more - bing it!


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.


Continuous Integration

Jenkins-ci.org

Also have to mention Atlassian Bamboo!


Requirements for CD

Deep SCM integration - commit hooksReliable Production-CI service (not under someones desk)Automated DeploymentMultiple deploy target environmentsEasy rollback


CloudBees is:


CI serverApp service repos


Fiddly

Fiddly to setup by hand - all the hooks, triggers, scripts, automation...

so we came up with “ClickStarts”

Set up all the moving parts


CD quick start - automated

Clone from template to private repoSetup commit hooksSetup buildIssue initial build & run testsSetup runtime container Deploy

All one click, ideally


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



AppsForge/source repos

Jenkins

Build slave pools

open source/template repos

on commit


Dog food eating



CD - dogfoodSome 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.



ExamplePlay Framework:

“Seed project”

Clone into actual project - setup build steps - setup unit/e2e tests - prepare/deploy into a container - setup commit hook


https://github.com/../play2-clickstart

git.cloudbees.com/your/app

you.ci.cloudbees.com

yourapp.com

shallow clone

Your code


https://github.com/angular/angular-seed

https://github.com/angular/angular-seed

But wait, it isn’t that easyMore complex workflowsWarming up environmentsSafe fall-backMonolithic appsDatabase updates

Some solutions...


Complex workflows


Jenkins pipeline plugin

https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin






Warming up environmentsAnd “fail safe” fall back.

BOTH solved by blue-green deployment.

http://martinfowler.com/bliki/BlueGreenDeployment.html







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


Blue GreenNeed 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!


Blue Greenhttp://developer-blog.cloudbees.com/2013/08/blue-

green-deployments-with-jenkins-and.html


http://developer-blog.cloudbees.com/2013/08/blue-green-deployments-with-jenkins-and.html




Blue GreenCan shut down “blue” if needed, to safe resources

Large customers already doing this

Large web companies all do this


Blue GreenWarming up: as simple as a curl script in a loop**

** Works quite well


Monolithic appsSolution: 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.


micro-service debugging


Monolithic appsStill can do CD

Good test suite?

Isolate “risky” changes - more frequent low risk deploys.

Risk of deploy is proportional to the time between deploys


DatabasesOption 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!)


Thank you

Michael Nealehttps://twitter.com/michaelnealehttps://developer.cloudbees.com


https://twitter.com/michaelneale

https://twitter.com/michaelneale



Cd syd

Technology

bluegreen deployment

setup commit

blue green warming

blue green http

blue green need

container setup

safer deployment

denitions continuous