continuous delivery in the enterprise
DESCRIPTION
Continuous delivery in larger shops can run into people and technological roadblocks related to complex systems and organizational structures. This presentation looks at some of those challenges and how to overcome them.TRANSCRIPT
Continuous Delivery in the Enterprise
Why Waterfall Fails
Idea
Requirements
Development
Test
Release
Validate codeMatches Reqs
Learn if idea & requirementsMatch the market need
Learning Faster
Presenting Today
Eric is a DevOps Evangelist with IBM where he helps customers get the most out of their build, deploy and release processes.
Today he works with customers and industry leaders to find the best ways of adopting continuous delivery and DevOps.
Eric [email protected]@EricMinick
Agenda
Introduction to Continuous Delivery
Continuous Delivery meets the Enterprise
People Changes
Adapting CD to Complex Apps
Q&A
What is Continuous Delivery?
Automated flow from Build to
“ready for prod”
Push button release to prod
Lots of feedbackEmphasis on
always shippable
Themes
“Classic” CD
builddev
test
system
testUAT sign-off staging prod
The Build Pipeline
builddev
test
system
testUAT sign-off staging prod
for (env in testEnvironments) { deploy( build, env ); runTests (env.testType, env);}
Continuous Delivery is a DevOps Strategy
Successful implementation requires assistance from developers, operations, and others
Cooperation and coordination between developers and operations must improve
Agenda
Introduction to Continuous Delivery
Continuous Delivery & The Enterprise
People Changes
Adapting CD to complex apps
Q&A
Enterprise Challenges
Complex, interconnected systems
Silos that need to work together.
The Hard Part is Coordination
Image from wisc.edu
Composite apps: many tiers & components
Composite apps: many tiers & components
An Application might havedozens of components
Composite apps: many tiers & components
An Application might havedozens of components
Delivered by Different Teams
Composite apps: many tiers & components
Which build does “Login” test?
These peopledeploy one buildat a time to prod
88% Deploy More than one build to production a time
√
√√
Build pipelines in composite applications
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
Some pieces aren’t built
Databases
Infrastructure
Content
Reports / ETL
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
builddev
test
system
testUAT sign-off staging prod
The Build Pipeline fails to:
Account for deployment time dependencies
Model things that aren’t built
Deal with incremental updates
X
X
X
Agenda
Introduction to Continuous Delivery
Continuous Delivery & Complex Apps
People Changes
Adapting CD to complex apps
Q&A
Delivery Spans Silos
A DevOps Culture Helps
23
• Common Business Objectives • Vision Statement
• Common measures of Success
Product Owner
Team Member
Team Lead
Team Member
Team Member
Senior Executives
UsersDomain Experts
Auditors
Gold Owner
Support Staff
External System Team
OperationsStaff
Adopting DevOps in the Enterprise: People/Culture
24
• The case for and against ‘DevOps Team’• The DevOps Liaison Team
• No overlay layer of bureaucracy
Adopting DevOps in the Enterprise: People/Culture
25
• Building a DevOps Culture• There is no Silver Bullet
• Right People are needed
Product Owner
Team Member
Team Lead
Team Member
Team Member
Senior Executives
UsersDomain Experts
Auditors
Gold Owner
Support Staff
External System Team
OperationsStaff
Adopting DevOps in the Enterprise: People/Culture
Agenda
Introduction to Continuous Delivery
Continuous Delivery & The Enterprise
People Changes
Adapting CD to complex apps
Q&A
Adapting CD to our Apps
Account for deployment time dependencies
Model things that aren’t built
Deal with incremental updates
Use the “Build of Builds” model as a start
Mega Build
system
testUAT sign-off staging prod
dev
test
Comp.
Build
dev
test
Comp.
Build
dev
test
Comp.
Build
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
builddev
test
system
test
builddev
test
system
test
builddev
test
system
test
UATSign-
offStagin
g Prod
Snapshots at “Application” or “System” level.
Don’t require “build”
Extracts from existing systems, artifact repos, or source control are OK to get deployable version.
Builddev
test
system
test
Config Extract
dev
test
system
test
Fetch from SCM
dev
test
system
test
UATSign-
offStagin
g Prod
Snapshots at “Application” or “System” level.
Support multiple incremental moves
Incremental requires:
–Multiple versions of a component in snapshots
–Awareness when tracking what is where
–Order awareness when performing rollbacks.
Pipeline with Snapshots
Fetch from SCM
dev
test
system
test
Config Extract
dev
test
system
test
Fetch from SCM
dev
test
system
test
UATSign-
offStage Prod
Builddev
test
system
test
Web
Mid. Code
Mid. Config
DB
In story form
A change to a component, creates a new version (often by doing a build).
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.
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.
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
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 snapshot is promoted & released. Yay.
In Summary
Continuous Delivery can be Hard in the Enterprise
–People are trained not to work together
–Simple build pipelines don’t work for composite applications
Plan of Attack
–Embrace a DevOps culture. Collaborate like crazy.
–Use release sets to promote components that are tested together
Yes, we sell products that help
IBM UrbanCode Deploy
–Application Deployment Automation
IBM UrbanCode Release
–Coordination across many applications
Learn more
Ibmdw.net/urbancode Enterprise CD Maturity Model
Death to Manual Deployments!
Build & Deployment Automation for the Lean Economy
ITIL Release Management and Automation
