Prezi

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in the manual

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

From Continuous Integration to Continuous Delivery

Von Continuous Integration zu Continuous Delivery
by Eberhard Wolff on 23 September 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 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
See the full transcript