Саша Белецкий "continuous delivery в продуктовой...

Why / How / WhenDo I need CONTINUOS DELIVERY?

Product Developer, E-conomic (Ciklum)Trainer, XP Injection

beletsky.net@alexbeletskygithub.com/alexanderbeletsky

WhyHowWhen

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 — REPEATLucky 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

WhyHowWhen

Let's define ourTERMINOLOGY

Deployment != Delivery

Deployment: product IS availbleDelivery: 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 sourcesbuild all product configuration itemsrun unit testsrun functional testsgenerate documentationpackage all artifacts

Deployment is for:update test servers

1. Build and deploy locally with one click2. Define SCM model based3. 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 frameworkRoundhousE database migrationsDropicK application deployment

Meet Chuck Norris Tools

UppercuTEasy to useConfigurable by XMLSupports config for different environment

RoundhousEEasy to useSupports MS SQL, MySQL, PostgressMigration by SQL Scripts

DropkicKDeployment script as C# codeSupport for services and sitesDifferent plans

Available on a Github

> deploy.bat LOCAL> deploy.bat STAGING> deploy.bat PRODUCTION

Step 1 - Build and DeployACCOMPLISHED

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 = 2masterdevelop

Typical branches count >= 2

masterdevelopreleasehotfix

Branch per Environment Layout

Step 2 - Define SCM modelACCOMPLISHED

> 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 continuoslyACCOMPLISHED

Changes are picked up, built, tested and deployed automatically

WhyHowWhen

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@alexbeletskygithub.com/alexanderbeletsky