Why / How / When Do I need CONTINUOS DELIVERY?

Product Developer, E-conomic (Ciklum) Trainer, XP Injection beletsky.net @alexbeletsky github.com/alexanderbeletsky

Why How When

The story of one project  Very simple GTD web application  .NET technological stack based  VPS hosted  Nothing fancy, seriously

• Prepare release branch and merge all required changes there • Update version in uppercut.config • Commit changes to SCM • Run build.bat • FTP package to deployment server • RDP to deployment server • Unpackage .zip content to temp folder • Manually backup staging database • Stop Stage Web site in IIS manager • Run migration scripts for staging database • Run deployment scripts for staging environment • Run Stage Web site in IIS manager • Test manually that on staging server, that build works fine • If something missed (note it is 60% of all cases) go to 1 • Manually backup production database • Stop Production Web site in IIS manager • Run migration scripts for production database • Run deployment scripts for production environment • Run Production Web site in IIS manager • Test manually that on production server, that build works fine Delivery Script ...

If it FAILS in a MIDDLE — REPEAT Lucky day: 0.5 h Bad day: 2 h

Read those figures as: My customers suffer for 2 hours once in 2 weeks, just becase I do update

And by the way...  It's just takes too much developers time  It's boring  Sooner or later you start to hate deployments

For bussiness people and managers  “Time-to-Market” factor is very low  Feedback cycle is very long  Customer dissatisfaction is very high

Why How When

Let's define our TERMINOLOGY

Deployment != Delivery Deployment: product IS availble Delivery: product IS availble for users

Deployment first Delivery after

All you have to know, the secret formula of Continuous Deployment

(Integration + Deployment) * Continuous = Continuous Deployment

Integration is for: fetching latest sources build all product configuration items run unit tests run functional tests generate documentation package all artifacts Deployment is for: update test servers

1. Build and deploy locally with one click 2. Define SCM model based 3. Run it continuosly Recipe of Success:

 Build and tests execution  Binaries versioning  SCM labeling  Database migration  Web application deployment Step 1 - Build and Deploy

 Build and tests execution  Binaries versioning  SCM labeling  Database migration  Web application deployment Step 1 - Build and Deploy Solved by Chuck Norris tools

UppercuT batch build framework RoundhousE database migrations DropicK application deployment Meet Chuck Norris Tools

UppercuT Easy to use Configurable by XML Supports config for different environment RoundhousE Easy to use Supports MS SQL, MySQL, Postgress Migration by SQL Scripts DropkicK Deployment script as C# code Support for services and sites Different plans

Available on a Github

> deploy.bat LOCAL > deploy.bat STAGING > deploy.bat PRODUCTION Step 1 - Build and Deploy ACCOMPLISHED

 DVCS are simply rule (Git, HG)  TRUNK is production ready  Keep interations in branches  Keep features in branches Step 2 - Define SCM model

Ideal branches count = 2 master develop Typical branches count >= 2 master develop release hotfix

Branch per Environment Layout

Step 2 - Define SCM model ACCOMPLISHED > git checkout develop > git merge --no-ff myfeature > git branch -d myfeature > git push origin develop

 Availability of Build Server  SCM build triggering  Automatically run deployment script  Roll out application to production Step 3 - Run it continuously

 Fork of famous Hudson project  Open source  Java based  Easy start, easy go  Tons of available plugins Say 'Hello' to Jenkins

All configuration could be done in UI

Jenkins Instance is deployed for each environment

Build/Deployment continuosly triggered by SCM

As soon as Staging “Looks Alright”, deploy to production

> git checkout master > git merge develop > git tag -a 1.2 > git push origin master Deployment is nothing more as pushing changes to origin/master

Step 3 - Run it continuosly ACCOMPLISHED Changes are picked up, built, tested and deployed automatically

Why How When

As sooner as better

And?

Results:  Going live time improved 45x  Site down time reduced 300x  No more iterations, Kanban  Staging is updating with every push  Setup and forget

THANK YOU! beletsky.net @alexbeletsky github.com/alexanderbeletsky