From Continuous Integration to Continuous Delivery

From Continuous Integration to Continuous Delivery Continuous Integration Takes weeks to integrate changes from teams Lots of stress Getting everything to compile is already hard One day of consulting to solve a technical issue: Wasted almost entirely on getting system to compile... 1999 Continuous Integration: First approaches Includes tests Unit Integration Tools Shell skripts Home grown Today Tools like Hudson, Jenkins CI is universal Projects can easily provide latest integrated build Problem solved! Principles Don’t Use Manual Procedures If it hurts - do it more often - and bring the pain forward! Current Problems Bringing Software into Production is hard Takes a lot of time Error prone Infrastructure can be created by calling an API Easy to create new servers Cloud Continuous Delivery Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual / Exploratory Testing Release Need automated Installers Simplify bringing systems into production Apply Continous Integration Principles Automate It hurts - do it more often - continuously Enabled by Cloud / Infrastructure as code Infrastructure as Code Package Managers & Automated Installers Script based solutions + Well established & integrated Easy to learn - Not portable Configurations? Standard way to install systems deb / apt-get rpm / yum ... Infrastructure as Code - again Define state a system should have ...and take it there idempotency built in Chef Opscode Puppet https://github.com/ewolff/JavaChefVagrantEC2 + Portable Collections of predefined recipes Configurations can be easily added - Recipes usually need to be customized Compile Unit tests Static Code Analysis (optional) Result: binaries Might be more than a deployable artifact i.e. installer GUI-based (e.g. Selenium) or Behavior-driven: Given <initial context> When <event occurs> Then <some outcome> Realistic scenario and data Through UI Service or public API Lower-level API (Scaled-down) production-like system Exploratory i.e. no strict test plan ...by domain experts Focus on new features / unforeseen behavior Not everything should be automized But: Automation frees resources for manual testing Automated! No manual change to any system Blue-green Two environments Install system on second environment in the background Canary Release Deploy to subset of servers Pipeline - Builds are promoted Numerous other options Deploy to running server (only partial solution) Extensions to home grown solutions Much like initial Continuous Integration affords Quite a lot established solutions for software distribution The Lean Principle Anything not released is waste ...like surplus stock in a warehouse Reduce waste Optimize pipeline throughput Higher Reliability Deployment automated ...and therefore reproducible Pipeline executed more frequently Faster Time to Market Pipeline executed faster Therefore: Code faster in production Lower Risk Deploying seldom to production increases risk ...because more changes pile up Need to deal with databases Schema migration Update data Managing test data NoSQL database are more flexible Tools like Flyway or Liquibase Continuous Integration Need to deal with configuration Push changes to lots of servers Chef Server Puppet Apache ZooKeeper Eberhard Wolff Architecture and Technology Manager adesso AG About me Eberhard Wolff Architecture & Technology Manager at adesso adesso is a leading IT consultancy in Germany Speaker Author (e.g. first German Spring book) Blog: http://ewolff.com Twitter: @ewolff http://slideshare.com/ewolff eberhard.wolff@adesso.de Back in the Dark Ages.... Decouple releases and features Restrain feature branches Otherwise: too many parallel version of code Which one should is the basis for the pipeline? Therefore: Features can be toggled on and off i.e. new features can be introduced silently ...and activated on demand Thoughtworks Go Etsy Deployinator Dreadnot coordination of stages i.e. skripts, Ruby commands etc Pipeline Management Tools