More and more companies worldwide are excited about DevOps and the many potential benefits of embarking on a DevOps transformation. The challenge many of them are having, however, is figuring out where to begin and how to scale DevOps practices over time. These challenges can be especially daunting in large enterprises. In this webinar we will discuss a maturity model for framing your transformation, then focus on analyzing your deployment pipeline and identify existing inefficiencies in software development and deployment.
6. Software changes
continuously
deployed to live
production
Continuous
Deployment
Software changes
continuously delivered to
stakeholders in any
environment
Continuous
DeliveryContinuous Integration
Automated commit, build and testing of
code in the development environment
User FeedbackRapid Changes
Discipline
AGILE
An incremental
approach to
identifying,
prioritizing, and
coordinating feature
development
Development Production / Prod-like Live Production
Env.Stage
Release Deploy Monitor
Upstream (left) Downstream (right)
Define Plan Code Commit Build Non-Func Test Scan Integrate Int. Test Package Deploy Acct. Test Load Test
Change Mgt. Production Bugs
Agile, CI, Continuous Delivery and DevOps
6
DevOps → Culture approach, supported by practices
14. Y-Axis: Levels of adoption
14
Agile
Upstream 33%
Agile
Downstream 13%
Enterprise
Agile Upstream 22%
Enterprise
DevOps 10%
TeamWorkgroupEnterprise
Define Plan Code Build Integrate Test Release Deploy Operate
15. The Destination
15
Agile
Upstream 33%
Agile
Downstream 13%
Enterprise
Agile Upstream 22%
Enterprise
DevOps
• Innovate faster
• Respond to market
• Gain competitive advantage
• Increased productivity
• Employee satisfaction and retention
TeamWorkgroupEnterprise
Define Plan Code Build Integrate Test Release Deploy Operate
16. The DevOps Trinity and the Chasms
16
Upstream Downstream
People &
Culture
Process &
Practices
Tools &
Technology
Agile, Scrum, Kanban PMBOK, ITIL, Waterfall
Point Tools,
Grassroots, Rapid
Change
Move Fast, Innovate Maintain Quality Stability, Uptime
Enterprise Class, Corp.
Procurement, Stable
Define Plan Code Build Integrate Test Release Deploy Operate
17. CloudBees 4Qs of DevOps maturity
17
Quadrant 1:
Team-level
Agile
Quadrant 2:
Team-level
CD
Quadrant 3:
Enterprise
Agile
Quadrant 4:
Enterprise
DevOps
TeamWorkgroupEnterprise
Define Plan Code Build Integrate Test Release Deploy Operate
18. The Path To DevOps
Q1: Team-level Agile
Q3: Enterprise Agile Q4: Enterprise CD
Q2: Team-level CD
• Mature CI practices for some teams
• Some tools federation and standardization
• Development disconnected from delivery
• Often Water-scrum-fall approach
• Mature CD for some teams
• Improved tools standardization
• Development connected to delivery
• Some teams release in weeks, days or hours
• Mature CI practices for most-to-all teams
• Elastic CI-as-a-service
• Tools centralization and standardization
• Increased developer productivity
• Mature CD on most-to-all teams
• Elastic, Internally-Managed CD-as-a-Service
• Development and delivery tools centralization
and standardization
• Most teams release in weeks, days or hours
CloudBees 4Qs of DevOps maturityTeamWorkgroupEnterprise
Define Plan Code Build Integrate Test Release Deploy Operate
19. The Trinity and the Chasms
19
Upstream Downstream
People &
Culture
Process &
Practices
Tools &
Technology
Agile, Scrum, Kanban PMBOK, ITIL, Waterfall
Point Tools,
Grassroots, Rapid
Change
Move Fast, Innovate Maintain Quality Stability, Uptime
Enterprise Class, Corp.
Procurement, Stable
Define Plan Code Build Integrate Test Release Deploy Operate
20. Poll Question
Which quadrant is your organization in?
• Quadrant 1 – Team-Level Agile
• Quadrant 2 – Team-Level CD
• Quadrant 3 – Enterprise Agile
• Quadrant 4 – Enterprise CD or DevOps
• Quadrant 0 – None (Legacy, Waterfall)
Introduction
Always introduce this way because I truly believe this is the potential impact
This is going to require eliminating waste and improving efficiencies
Types of work: New/Unique, repetitive, triage
Getting everyone on the same page & where to start DP
Agenda 12Min
Basic DP 1 Dev
Metrics for aligning starting point and progress
Scaling to a Dev team
DevOps appr. for small teams
DevOps appr. large tightly coupled teams
Close with impacts of changes
Build 1: (Software Delivery Cycle)
Regardless of how your company approaches software development and delivery, it includes fundamental tasks from defining requirements, to coding to managing builds, to integration testing, to packaging distributions, deploying to testing or production, monitoring and re-iterating all over again. Whatever specific steps you take, these are the sequential tasks of software delivery. Typically each stage is deployed to defined development, staging and productions environments. The tasks we focus on throughout are referred to upstream, and sometime “left” in the delivery flow or downstream, or “right” based on where the typically occur in the process.
Build 2: (Rapid Changes driven by Use Feedback)
The biggest driver for a need for faster delivery is the ever-increasing demand from users and consumers (depending on our business type), who are placing demands on the business to innovate and compete to provide better experiences and services. Not only do these changes need to be implemented quickly, they have to be delivered with levels of quality that assure continuous user satisfaction. Methods to collect detailed feedback downstream must be continually fed back into upstream development
Build 3: (Agile)
Agile delivery and processes have become a standard incremental approach to building software faster, specifically targeting user needs . Whether you are in a highly regulated insurance or financial industry, or a fast moving start up, you have likely adopted some agile approach. But while agile is a predominant approach to software delivery, it comes with a fair set of challenges associated with many, fast moving tasks that must span teams and stages.
Build 4: (Continuous Integration)
10 years ago, Continuous Integration entered the scene when our CTO, Kohsuke Kawaguchi, created Jenkins to address the speed problem with automation. This allowed code that individuals and small teams were developing to be put into a framework to compresses repetitive and mundane tasks like commits, builds & unit tests. Without question, Jenkins is the defacto standard for continuous integration, with millions of users and projects across the world.
Build 5: (Continuous Delivery)
Today, Continuous Delivery is the next step to maturing the software delivery process, encompassing Continuous Integration to move the discrete tasks that were automated for developers and moving further down the delivery chain. Teams are able to confidently take the software coming out of development and have it ready deploy and run state for any stakeholder across the your organization. This doesn't always mean going as far as deployment into live production – that is decision based on your business needs - but you can confidently assure that the code is continuously delivered in a pipeline – ready for QA – whether internal or with third party partner – usability and acceptance testers - or to beta users release - and yes it may even deployed into live production.
Build 6: (Continuous Deployment)
Continuous delivery is NOT ALWAYS about delivering to live users, but if you do have continuous deployment needs - as many online retails and internet-only businesses like Google and Netflix do - then Continuous Delivery is THE necessary path to get to that objective.
Build 6: (DevOps)
When all this comes together, what it enables is a set a processes and technologies that allow you to realize DevOps – which makes continuous “everything” a reality for your business.
DevOps is associated with a number of tools technologies, and practices
Most are important to apply or at least understand
Frequently organizations get mired in the details
Frequently teams lean wrongly on a specific dogmatic practice
This results in losing site of the “best fit” goal
Can inhibit progress and result in “overload”, or analysis paralysis
This results in losing site of the “best fit” goal
Can inhibit progress and result in “overload”, or analysis paralysis
I have discovered, in practice that…
If you simplify the problem space, you reduced noise, and accelerate progress
To this end, when approaching a DevOps transformation it is best to simplify…
Consider the transformation a journey you plan to take.
Befor you do ask 3 simple questions.
Where are we?
What is our current state, problems, stregnths, etc.
Your starting point
Where are we going?
Your destinations
What to you seek to achieve
what is practical to achieve?
How do we get there?
What are the major steps (or roads) we will take to get there?
In what order?
First we will establish the X-axis for the matrix composed of our Quadrants
The X-Axis is:
Focused on the SDLC
Can represent a agile or non-agile team
All development has some form of Define, Plan, Code, Build, Integrate, Release, Deploy (or install), and Operate
But separated into to halves, Agile Upstream
Practice of agile definition, planning and development methods such as Scrum, Kanban, Continuous Integration etc.
Greater than 33% of organizations claim to have implemented Agile Upstream Processes
Benefits include…faster feedback, less code defects, better management of work
The other half is Agile Downstream
Covers the integrate test, release, deploy part of the process
Include practices such as automated testing, continuous delivery, and continuous deployment
Only 13% of organizations practice this
Next slides will look into why this is an issue
First we will establish the X-axis for the matrix composed of our Quadrants
The X-Axis is:
Focused on the SDLC
Can represent a agile or non-agile team
All development has some form of Define, Plan, Code, Build, Integrate, Release, Deploy (or install), and Operate
But separated into to halves, Agile Upstream
Practice of agile definition, planning and development methods such as Scrum, Kanban, Continuous Integration etc.
Greater than 33% of organizations claim to have implemented Agile Upstream Processes
Benefits include…faster feedback, less code defects, better management of work
The other half is Agile Downstream
Covers the integrate test, release, deploy part of the process
Include practices such as automated testing, continuous delivery, and continuous deployment
Only 13% of organizations practice this
Next slides will look into why this is an issue
The Y-axis:
Represents adoption of agile-upstream and downstream across the enterprise or at scale
Broken down into team->work group adoption and workgroup to enterprise.
Definition of a “workgroup” or even a team may differ by organization
Only a subset of those that have implemented agile-upstream have scaled it.
When considered with those that implemented downstream…..
As studies show only a select few organizations of implemented enterprise devops, practiciing agile-upstream and downstream at scal
For organizations that connect upstream and downstream, and scale that to the enterprise:
Can achieve DevOps and its benefits:
Innovate faster
Respond to market
Gain competitive advantage
Increased productivity
Employee satisfaction and retention
Often overlooked, but privately cited by many customers
Leads to many of the other benefits
For those interested in the bottom-line, all of these can lead to reduced-cost and/or increase revenue
So why hasn’t everybody done this?
[next slide]
Implementing DevOps requires connecting multiple stake holders, often across organizations other boundaries…
On th planes of
People or Culture
Praces and practices
Tools and technology
However this present what we call the Chasms, seperations between upstream and downstream, and between teams and the enterprise.
Examples are: [see slide](TBC)
These chasms, and the areas of each axis which they separate, which are supported by real data and experience, represent the Quadrants of maturity.
Quadrant 1, Team-Level Agile
Quadrant 2, Team-Level Continuous Delivery
Quadrant 3, Enterprise Agile Upstream
Quadrant 4, Enterprise DevOps
I often consider this just DevOps. CD can be implemented and team-level, but DevOps requires organization wide implementation
Each of the quadrants can be described, by a set of characteristics found in companies in each of the Quadrants.
[next slide]
Implementing DevOps requires connecting multiple stake holders, often across organizations other boundaries…
On th planes of
People or Culture
Praces and practices
Tools and technology
However this present what we call the Chasms, seperations between upstream and downstream, and between teams and the enterprise.
Examples are: [see slide](TBC)
1st order effect
DevOps
100s vs 10s
Lack of alignment
Right way first
Marketing faster execution
Dev Push into production Millennial
Release Everything under version control
Ops feature toggles working closely with Dev on scripts
Exec stock price and bonus
Aligned top to bottom, Everyone excited what could possible go wrong 10 Min
All the right parts BUT
Doesn’t look or work like and elephant
DevOps face plant
This is going to require eliminating waste and improving efficiencies
Types of work: New/Unique, repetitive, triage
Getting everyone on the same page & where to start DP
Agenda 12Min
Basic DP 1 Dev
Metrics for aligning starting point and progress
Scaling to a Dev team
DevOps appr. for small teams
DevOps appr. large tightly coupled teams
Close with impacts of changes
Basic flow
Simple process what could go wrong
What can go wrong at each step
Business Idea
Waterfall planning
too much inventory
Lean
JIT (20 to 5%)
Env (250 day story)
Consistency
SE, SD, automation, cloud
Testing stage
Cycle time
repeatability
branch time
Approval times (approval time story)
Prod
deploy time and effort (launch calls story)
Monitoring
New issues (IE8 short story)
What can go wrong at each step
Business Idea
Waterfall planning
too much inventory
Lean
JIT
Env (250 day story)
Consistency
SE, SD, automation, cloud
Testing stage
Cycle time
repeatability
branch time
Approval times (approval time story)
Prod
deploy time and effort (launch calls story)
Monitoring
New issues (IE8 short story)
What can go wrong at each step
Business Idea
Waterfall planning
too much inventory
Lean
JIT
Env (250 day story)
Consistency
SE, SD, automation, cloud
Testing stage
Cycle time
repeatability
branch time
Approval times (approval time story)
Prod
deploy time and effort (launch calls story)
Monitoring
New issues (IE8 short story)
Where to start
All about change management and personal ownership
Smaller for simplicity
Stuff that matters
Loosely coupled
Tightly coupled
40 Mins
DevOps more important with more people
Teams of 10 people diff from teams 100s
Common view more important
Start with biggest issues to create + momentum
Design DP to help minimize triage waste
Build Freq, BAT, SV
Break it down into stable subsystems
Then build it up releasable
Need to start build up you subsystem deployment pipelines with gates and stage
Stages localize feedback (triage)
Gates for cultural changes and block instability
Define the system DP
Complex system have more stages for localizing triage and gating instabilities
Multiple stages have more opportunities for waste with repetitive tasks
Define the system DP
Complex system have more stages for localizing triage and gating instabilities
Multiple stages have more opportunities for waste with repetitive tasks
Minimizes rework with fast feedback and enables efficient triage
Focus on long legs
Separate new work issues from repetitive
Issues with repetitive tasks and cycle time for repetitive work will be used to prioritize automation
Start with Env and Test before CI
Possible Results
Complex Benefits are more pronounced
10s versus 100s
Jez and David DP
Engaged executives