The Next Generation of Continuous Delivery
Upcoming SlideShare
Loading in...5
×
 

The Next Generation of Continuous Delivery

on

  • 2,613 views

The build pipeline model of continuous delivery works great for simple projects, but can be challenging for applications with many pieces and parts. In this deck, we look at two approaches for ...

The build pipeline model of continuous delivery works great for simple projects, but can be challenging for applications with many pieces and parts. In this deck, we look at two approaches for reconciling CD and these applications. In one approach, we force the applications into a simple pipeline, in the other, the pipeline is reimagined.

Statistics

Views

Total Views
2,613
Views on SlideShare
2,613
Embed Views
0

Actions

Likes
0
Downloads
133
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    The Next Generation of Continuous Delivery The Next Generation of Continuous Delivery Presentation Transcript

    • Next Gen Continuous Delivery From Build delivery to Value delivery1
    • Eric’s Bio I’m a Lead Consultant at Urbancode where I helps customers get the most out of their build, deploy and release processes. I have 9 years of automation experience throughoutEric Minick the application life-cycle in roles aseric@urbancode.com a developer, test automation engineer, and support engineer. I’ve been at the forefront of CI & CD for 7+ years 2
    • Agenda• Introduction to Continuous Delivery• Continuous Delivery & Complex Apps• Adapting apps to CD• Adapting CD to complex apps• Q&A3
    • What is CD?• An automated flow from build to “ready to deploy to production”• Push-button deployment to production• The execution of many types of tests• Cultural emphasis on constant shipability4
    • “Normal” CD• Expanding the CI emphasis on quality and automation downstream dev system build UAT sign-off staging prod test test5
    • The Build Pipeline (Build > ? > Prod)• Perform a build – and execute unit tests• Promote build to a test environment & test – Repeat N times• Release dev system build UAT sign-off staging prod test test6
    • We even have a maturity model for it7
    • Why are we doing it?• Small batch sizes: – Reduce risk – Lower the “waste” of unreleased features• Natural extension of the “test your builds” mentality of CI• Address the deployment bottleneck in Operations.8
    • Continuous Delivery is a “DevOps” Strategy• Successful implementation requires assistance from developers, operations, and others• Cooperation and coordination between developers and operations must improve9
    • Agenda• Introduction to Continuous Delivery• Continuous Delivery & Complex Apps• Adapting apps to CD• Adapting CD to complex apps• Q&A10
    • The Hard Part is Coordination Image from wisc.edu11
    • Complex apps have related builds• Builds of one part of the app depend on another• A change in one “pipeline” could impact another pipeline• Tests cross-cut builds pipelines12
    • Multiple tier apps• Different tiers, different JPetStore Application teams, different builds Apache SIT WEB• How do align the Tomcat MID changes? DB JPetStore Content PROD WEB JPetStore WAR MID DB JPetStore DB13
    • Modern architectures make it worse • Dozens of inter-related components • The promise of “change only one piece” is rarely realized in practice Image from ischool.tv14
    • Prod deployments aren’t of one build15
    • Build pipelines in coupled systems dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test16
    • Some pieces aren’t built• Databases dev system build UAT sign-off staging prod test test• Infrastructure build dev test system test UAT sign-off staging prod dev system build UAT sign-off staging prod test test dev system build UAT sign-off staging prod test test• Content build dev test system test UAT sign-off staging prod dev system build UAT sign-off staging prod test test• Reports / ETL17
    • CD’s Build Pipeline isn’t Perfect• It fails to: – Account for deployment time dependencies – Model things that aren’t built – Deal with incremental updates18
    • Now what? Work hard to salvage build pipelines Or Use a different model19
    • Agenda• Introduction to Continuous Delivery• Continuous Delivery & Complex Apps• Adapting apps to CD• Adapting CD to complex apps• Q&A20
    • Adapting apps to CD: Principals• Principals – Everything is a “build” – Builds are promoted independent of other builds• Example techniques – Release build of builds – Enforce backwards compatibility – Expand / Contact pattern for databases21
    • A Build of Builds• Create a mini-release process for each component, and combine them into a big build.• Mega build contains the binaries from the others Comp. dev Build test Comp. dev Mega system UAT sign-off staging prod Build test Build test Comp. dev Build test22
    • A Build of Builds• Create a mini-release process for each component, and combine them into a big build.• Mega build contains the binaries from the others Comp. dev Build test Comp. dev Mega system UAT sign-off staging prod Build test Build test Comp. dev Build test• Challenges: My “mega build” is big, and is always fully deployed. My components don’t know if they went to Prod.23
    • Enforce Backwards Compatibility• Build and immediately deploy to integration testing• If integration tests fail, the build is rejected and the old build of that component is redeployed to integration testing24
    • Enforce Backwards Compatibility• Build and immediately deploy to integration testing• If integration tests fail, the build is rejected and the old build of that component is redeployed to integration testing• Challenges: Good integration tests, extra engineering to support new and old versions, etc.25
    • Database Expand / Contract• Goal: Backwards compatible, zero downtime database deployments.• Never remove objects old / active users of the database need. Only add new objects. Once all clients are using the new objects, remove the old.26 See: http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime- database-deployment/
    • Database Expand / Contract• Goal: Backwards compatible, zero downtime database deployments.• Never remove objects old / active users of the database need. Only add new objects. Once all clients are using the new objects, remove the old.• Challenges: a significant and not always easy change to how organizations develop DB updates.27 See: http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime- database-deployment/
    • Agenda• Introduction to Continuous Delivery• Continuous Delivery & Complex Apps• Adapting apps to CD• Adapting CD to complex apps• Q&A28
    • Adapting CD to our Apps• Account for deployment time dependencies• Model things that aren’t built• Deal with incremental updates29
    • Use the “Build of Builds” model as a start Comp. dev Build test Comp. dev Mega system UAT sign-off staging prod Build test Build test Comp. dev Build test30
    • Shift to “Release Sets” or “Snapshots”• We don’t need a new build, we need a name for a collection of builds.• Delay the creation of these until integration tests pass, and create based on the successful integration tests Snapshots at “Application” or dev system build test test “System” level. dev system Sign- build test test UAT Staging Prod off dev system build test test31
    • Don’t require “build”• Extracts from existing systems, artifact repos, or source control are OK to get deployable version. dev system Build test test Snapshots at “Application” or “System” level. Config dev system Extract test test Sign- UAT Staging Prod off Fetch from dev system SCM test test32
    • Support multiple incremental moves• Incremental requires: – Multiple versions of a component in snapshots – Awareness when tracking what is where – Order awareness when performing rollbacks.33
    • Pipeline with Snapshots Fetch from dev system Web SCM test test dev system Mid. Code Build test test Sign- UAT Stage Prod off Config dev systemMid. Config Extract test test Fetch from dev system DB SCM test test 34
    • In story form• A change to a component, creates a new version (often by doing a build).35
    • In story form• A change to a component, creates a new version (often by doing a build).• The new version is vetted, and then tested in an integration environment.36
    • In story form• A change to a component, creates a new version (often by doing a build).• The new version is vetted, and then tested in an integration environment.• When the integrated system passes tests, a snapshot of all the component versions in the system is created.37
    • In story form• A change to a component, creates a new version (often by doing a build).• The new version is vetted, and then tested in an integration environment.• When the integrated system passes tests, a snapshot of all the component versions in the system is created.• Snapshot deployments don’t redeploy unchanged components38
    • In story form• A change to a component, creates a new version (often by doing a build).• The new version is vetted, and then tested in an integration environment.• When the integrated system passes tests, a snapshot of all the component versions in the system is created.• Snapshot deployments don’t redeploy unchanged components• The component version is promoted & released39
    • In Summary• Today, continuous delivery on complex systems is hard to coordinate.• Two options 1. Strict development standards to force our systems into the build promotion model 2. A shift towards snapshot deployments that accommodate projects “as they are”40
    • References http://urbancode.com/resources• Enterprise CD Maturity Model• Death to Manual Deployments!• Build & Deployment Automation for the Lean Economy• ITIL Release Management and AutomationUrbancode.com/blogs/Twitter.com/UrbanCodeSoftFacbebook.com/UrbanCodeSoftSlideshare.net/Urbancode41
    • Yes, we sell products for this• AnthillPro – Build automation and build promotion• uDeploy – Deployment and release managementUpcoming AnthillPro + uDeploy demo:http://web.urbancode.com/using-anthillpro-with-udeploy42
    • Questions? eric@urbancode.com @EricMinick43