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.

1. Continuous Delivery in the Enterprise

2. Why Waterfall Fails
Idea
Requirements
Development
Test
Release
Validate code
Matches Reqs
Learn if idea & requirements
Match the market need

3. Learning Faster

4. 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 Minick
eminick@us.ibm.com
@EricMinick

5. Agenda
 Introduction to Continuous Delivery
 Continuous Delivery meets the Enterprise
 People Changes
 Adapting CD to Complex Apps
 Q&A

6. What is Continuous Delivery?
Automated flow
from Build to
“ready for prod”
Push button
release to prod
Lots of feedback
Emphasis on
always shippable
Themes

7. “Classic” CD
build
dev
test
system
test
UAT sign-off staging prod

8. The Build Pipeline
build
dev
test
system
test
UAT sign-off staging prod
for (env in testEnvironments) {
deploy( build, env );
runTests (env.testType, env);
}

9. Continuous Delivery is a DevOps Strategy
 Successful implementation requires assistance from
developers, operations, and others
 Cooperation and coordination between developers and
operations must improve

10. Agenda
 Introduction to Continuous Delivery
 Continuous Delivery & The Enterprise
 People Changes
 Adapting CD to complex apps
 Q&A

11. Enterprise Challenges
Complex, interconnected systems
Silos that need to work together.
?

12. The Hard Part is Coordination
Image from wisc.edu

13. Composite apps: many tiers & components

14. Composite apps: many tiers & components
An Application might have
dozens of components

15. Composite apps: many tiers & components
An Application might have
dozens of components
Delivered by Different Teams

16. Composite apps: many tiers & components
Which build does “Login” test?

17. These people
deploy one build
at a time to prod
88% Deploy More than one
build to production a time
√
√
√

18. Build pipelines in composite applications
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod

19. Some pieces aren‟t built
Databases
Infrastructure
Content
Reports / ETL
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod
build
dev
test
system
test
UAT sign-off staging prod

20. The Build Pipeline fails to:
Account for deployment time dependencies
Model things that aren‟t built
Deal with incremental updates
X
X
X

21. Agenda
 Introduction to Continuous Delivery
 Continuous Delivery & Complex Apps
 People Changes
 Adapting CD to complex apps
 Q&A

22. Delivery Spans Silos
A DevOps Culture Helps

23. 23
• Common Business Objectives
• Vision Statement
• Common measures of Success
Product
Owner
Team
Member
Team Lead
Team
Member
Team
Member
Senior
Executives
Users
Domain
Experts
Auditors
Gold Owner
Support Staff
External
System Team
Operations
Staff
Adopting DevOps in the Enterprise: People/Culture

24. 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. 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
Users
Domain
Experts
Auditors
Gold Owner
Support Staff
External
System Team
Operations
Staff
Adopting DevOps in the Enterprise: People/Culture

26. Agenda
 Introduction to Continuous Delivery
 Continuous Delivery & The Enterprise
 People Changes
 Adapting CD to complex apps
 Q&A

27. Adapting CD to our Apps
 Account for deployment time dependencies
 Model things that aren‟t built
 Deal with incremental updates

28. Use the “Build of Builds” model as a start
Mega
Build
system
test
UAT sign-off staging prod
dev
test
Comp.
Build
dev
test
Comp.
Build
dev
test
Comp.
Build

29. 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
build
dev
test
system
test
build
dev
test
system
test
build
dev
test
system
test
UAT
Sign-
off
Stagin
g
Prod
Snapshots at “Application”
or “System” level.

30. Don‟t require “build”
 Extracts from existing systems, artifact repos, or source
control are OK to get deployable version.
Build
dev
test
system
test
Config
Extract
dev
test
system
test
Fetch from
SCM
dev
test
system
test
UAT
Sign-
off
Stagin
g
Prod
Snapshots at “Application”
or “System” level.

31. Support multiple incremental moves
Incremental requires:
–Multiple versions of a component in snapshots
–Awareness when tracking what is where
–Order awareness when performing rollbacks.
Creating a Snapshot
Component Versions / Builds
1
1
2
2
3
3
321Web
Mid. Code
DB
Snapshot
3
2
1
Mid. Config 1 2 3 3
2

32. Snapshot
3
2
1
3
2
Pipeline with Snapshots
Fetch from
SCM
dev
test
system
test
Config
Extract
dev
test
system
test
Fetch from
SCM
dev
test
system
test
UAT
Sign-
off
Stage Prod
Build
dev
test
system
test
Web
Mid.
Code
Mid. Config
DB

33. In story form
A change to a component, creates a new version (often by
doing a build).

34. 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.

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. When the integrated system passes
tests, a snapshot of all the component versions in the system
is created.

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. Snapshot deployments don‟t redeploy unchanged
components

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
components. The snapshot is promoted & released. Yay.

38. 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

39. Yes, we sell products that help
 IBM UrbanCode Deploy
–Application Deployment Automation
 IBM UrbanCode Release
–Coordination across many applications

40. 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

41. Questions?
IBMDW.net/urbancode
eminick@us.ibm.com
@EricMinick