Linuxtag 2012  - continuous delivery - dream to reality
Upcoming SlideShare
Loading in...5

Linuxtag 2012 - continuous delivery - dream to reality






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • ----- Meeting Notes (11.05.12 15:03) -----Chances are good that the production deployment does not work… not tested before handsDowntime on production server needs to be reduced
  • ----- Meeting Notes (11.05.12 15:03) -----+ the customer may come with bugs that you can't reproduce one month later => unsatifaction rising
  • ----- Meeting Notes (11.05.12 15:11) -----Indempotent

Linuxtag 2012  - continuous delivery - dream to reality Linuxtag 2012 - continuous delivery - dream to reality Presentation Transcript

  • Continuous Delivery Dream => Reality Dr. Clement Escoffier, akquinet
  • This is a work of fiction. Names,characters, places and projects are all products of the author‟s imagination. Any resemblance to actual events, locales or projects is entirely coincidental
  • SITUATION Again, purely imaginary ;-)
  • Quite a big project• Running for 2 years• 4-6 developers• Agile (Scrum)
  • As in all big projects, the build is chaotic
  • Taking forever, Intermittent failures, Inconsistent output,Non-reproducible builds, Authorization failures …
  • Releasing => Stress => DelaysDelivery => Error-prone
  • Delays => Customer 
  • Trust  => Pressure 
  • Quality  => Technic. Debt => Non optimal project situation
  • “Let‟s delivera version every day” Output from an escalation meeting
  • Did you say “deliver” ?• Web App, JavaEE… • Up and Running• Mobile App • Downloadable or in a Market• Desktop App • Installers, Market, Auto-update • Installed on a system
  • DevelopersMore Releases => 
  • Project ManagersMore Paperwork => 
  • OpsMore Changes => 
  • CONTINUOUS DELIVERY –THE CHALLENGE Seamless Disruptive Changes
  • How to introducecontinuous delivery seamlessly ?
  • “Let‟s all commit to acontinuous delivery model …
  • … but withoutchanging the way we work”
  • CONTINUOUS DELIVERY –PRINCIPLES Will try to make it not so boring
  • Delivery anti-patterns• Manual software building and deployment• Deploying in production-like environment only after releasing• Manual configuration of the environment
  • A set of good practices tosimplify software delivery Automation Responsibility Pipeline
  • Automation
  • Bootstrap / Configuration [Insert your own] TestsRelease, Deployment Process Database Evolution
  • Commit Capacity Stage UI Tests Tests Acceptance Deployment Release Tests Tests
  • It‟s not only source code…
  • SourceEnvironment Data Configuration
  • Build tools &Build processes
  • Source Code Data Deployment Script Evolutions Check-in everythingConfiguration Environment Build Scripts Description
  • Unique Versioning Tags Human-readable Traceability Introspectable Notifications Reproducible Build
  • Commit Often Use „branch by abstraction‟ Avoid branches Continuous Integration Understandable Test Suites Fast feedbackComprehensive Tests
  • Unit Tests Integration Tests Test Groups Automate Tests Deployment Tests UI Tests System Tests
  • Describe your Avoidenvironment Dev vs. Prod Always deploy the same way Automate Deployment Manage configurations Do it Did I tell you to frequently TEST ? Plan rollbacks
  • Implement a test strategy
  • Commit Stage V2 V3 V1 Test + Package Acceptance Tests UI Tests Deployment Tests Capacity TestsPromotion / Release <<Prod Ready>>
  • Source RepositoryCommit Acceptance Prom. / Rel. Stage Tests Stage V3 V3 Artifact Repository
  • The Commit Stage• As fast as possible • < 5 min is good • < 10 min is acceptable mvn clean install• Package, Changelog, Scripts…
  • Build only one package: Distribution
  • This package is reused by all the test phases
  • Describe yourenvironment
  • Reduce the distance between Dev & Prod
  • Always deploy using the same way
  • BACK TO OUR PROJECT Implementation Time
  • SCM => SVN, Git, Git-SVN
  • Build Tool => Maven
  • continuous-versioning-mp+ maven-release-plugin
  • CI => Jenkins
  • Artifact Repo => Nexus
  • Development• Maven build A • -SNAPSHOT 1.0.0-SNAPSHOT• Continuous B 1.0.0-SNAPSHOT Versioning C 1.0.0
  • Virtual Environment• Vagrant •
  • Virtual Environment• Provisioned using • Shell script • Puppet Manifests • Chef Recipes=> Your deployment script
  • Commit Stage Source Repository mvn clean install1.0.0-SNAPSHOT Artifact Repository
  • Commit Stage Source Repository tag mvn clean install Fast-Release1.0.0-SNAPSHOT 1.0.0_42 Artifact Repository
  • All other stages are using the _42 version
  • Testing Stages Initialize a new VM + DeploymentIntegration Deployment UI Tests Tests Tests Vagrant Box
  • Testing Stages Deployment on a staging systemDeployment UI Deployment Other Tests Tests Tests again Tests Vagrant Box Staging System
  • Releasing
  • Releasing Promoting
  • Take the current staged version (RC) => Declare it as G.A.
  • Build Tools• Builds • Reproducible • Avoid system deps• Make, Ant, Maven, Gradle, SB T
  • Virtualization• Avoid „works on my machine‟ • Dev/ Test / Run on prod-like system• Vagrant is awesome
  • Continuous Integration• Customizable • Pipeline concepts• Jenkins, Hudson, Team City, Bamboo• Travis
  • CMS• Describe your environment • Treat your infra as code• Shell Script, Puppet, Chef
  • Application Deployer• Specific CMS to deploy your application• Go, Deploy-it, Puppet/Mcollective, JMX
  • Responsibility
  • Following the rules
  • Trust is back
  • Seeing changes
  • Always being ready
  • Track & Visualize everything
  • Danke !