Loading presentation...

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 our knowledge base article

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

Continuous Delivery to Continuous Integration

Slides from my talk at Lehmanns in Hamburg. Shows how Continuous Delivery works and what the difference to Continuous Integration is.
by

Eberhard Wolff

on 2 January 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Continuous Delivery to Continuous Integration

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 steps
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
Simplify bringing systems into production
Apply Continuous Integration Principles
Automate
It hurts - do it more often - continuously
Enabled by Cloud / Infrastructure as code
Infrastructure as Code
Script based solutions
Infrastructure as Code - again
Define state a system should have
...and take it there
idempotency built in

Chef Opscode


+
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
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 automated
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
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
Continuous
Integration
Eberhard Wolff
Fellow innoQ
@ewolff
Back in the Dark Ages....
Jenkins
GUI based
Behavior Driven
Selenium
Takes days to release code into production
Lots of stress
Weekends spent on releasing software
Minor difference between production and staging make release fail
Now....
Lightweight virtualization
Shared kernel
Filesystem with diffs
Can be packaged
...and easily automated
+
Simple script for automation
-
Linux only
Cluster enabled runtime?
Szenario: Kunde registriert sich erfolgreich Gegeben ein neuer Kunde mit
E-Mail eberhard.wolff@gmail.com
Vorname Eberhard Name Wolff
Wenn der Kunde sich registriert
Dann sollte ein Kunde mit
der E-Mail eberhard.wolff@gmail.com existieren Und es sollte kein Fehler gemeldet werden
public class
UserRegistrationSteps {
private
RegistrationService registrationService;
private
User kunde;

private boolean
fehler =
false
;

@Given("ein neuer Kunde mit E-Mail $email Vorname $vorname Name $name")

public void
gegebenKunde(String email, String vorname, String name) {
kunde =
new
User(vorname, name, email);
}

@When("der Kunde sich registriert")

public void
registerKunde() {

try
{
registrationService.register(kunde);
}
catch
(IllegalArgumentException ex) {
fehler =
true
;
}
}

...
}

Operate
Measure
Input for new Features
Log analysis with Elasticsearch / Logstash / Kibana
Monitoring with Graphite
Tech Stack
Experiments
https://github.com/
ewolff/user-registration
Optimize
Continuous Delivery
Pipeline
Faster
Feedback
Full transcript