The document discusses continuous application delivery (CAD) and how DevOps principles enable it. It describes breaking down silos, automating processes, and collaborating as a unified team. The CAD maturity model scores organizations on agile delivery practices like continuous integration, automated testing, and self-service tools. Highly mature organizations implement patterns like trunk-based development, automated testing and deployment, and decoupling database changes.

1. CONTINUOUS APPLICATION DELIVERY(CAD)
- How DevOps Culture Enables CAD
- DevOps & OpsDev
- CAD Maturity Model

2. Continuous App Delivery – Follows DevOps Principles
Break Silos
Agility only work when we work as
ONE TEAM
Fail Fast, Learn Fast!
Reward Failures & Encourage to Fail Fast
- Be Agile NOT FRAGILE
Automation is the Key Transparency
enables Collaboration
DevOps
Principles
Automation enables Self-Service which
provides Empowerment which brings
Innovation
Quantitative (DATA driven) approach for
publishing inputs & resolutions
FAIL- First Attempt In LearningTEAM- Together Everyone Achieves More
Lower the overall Operational CostsMaximize Business Outcomes
1 2
3 4

3. DEVOps
OpsDev
CUSTOMER FOCUSSED SOLUTION
Increase Agility & Predictability
Standardization of Application
Development Process & Delivery
Zero Touch, Self-Serviceable
Automated Build & Deployment of
Apps from Dev to Prod
Collaborate on the Operational
Efficiency to be injected in the App
Architecture
Standardization of Infrastructure
Provisioning Process & Delivery
Zero Touch, Self-Serviceable
Automated Provisioning & Monitoring
of Machines from Dev to Prod
Collaborate on the Application
efficiency to be injected in the System
Architecture
Increase Operational Efficiency
Standardization of
Processes
Automated Tools
& Frameworks
Collaboration &
Sharing
ONE TEAM
Feedback loop
DevOps & OpsDev
AGILITY IS KEY

4. Continuous Application Delivery - Application Maturity Scorecard
AD-HOC MANAGED DEFINED OPTIMIZED
AGILE DELIVERY
 Teams rely mainly on manual
testing after development is
complete to find defects.
 System integration is painful and
happens after development on a
module is completed.
 Provisioning production-like
integrated testing environments
is expensive and manual.
 Deployment process is manual
 Developers, testers, operations,
and management have goals
that bring them into conflict.
 Change management is ad hoc
or heavyweight and often
circumvented or ignored.
 Clear product ownership and
chain of responsibility are in
place.
 Change management controls
are implemented, including a
process to detect unauthorized
changes with consequences
defined.
 Business participates fully and
regularly in development
activities and decisions related
to delivery.
 There is some automated
acceptance testing.
 Production-like testing
environments are available for
projects early on.
 There is some scripting to
reliably and repeatedly configure
environments and build
packages from version control.
 Teams practice trunk-based
development with continuous
integration of all changes.
 There are enough automated
tests that critical defects are
detected and prevented fast and
automatically.
 Provisioning of environments is
fast and automated.
 No work is considered done until
it has passed automated unit
and acceptance tests associated
with the Job
 Testers are not primarily
focused on regression testing.
 Database changes are bundled
with versioned releases
 History of release is art-factored
and seamless rollback’s
 Self-Serviceable tools &
frameworks are provided to
Development Teams for
seamless App Lifecycle
management (incl. Build &
Deployment)
 All new requirements describe
how the value of the feature will
be measured.
 Product teams are responsible
for implementing metrics to
gather this data through
techniques.
 Systems are architected with
continuous deployment in mind,
supporting patterns such as dark
launching to decouple
deployment from release.
 Database changes are
decoupled from application
deployments.

5. Articles to Read
• http://www.slideshare.net/Urbancode/how-to-build-a-devops-toolchain
• http://www.slideshare.net/thekua/devops-from-the-ground-up?related=1
• http://www.slideshare.net/nishanthnow/introducing-devops?related=2
• http://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/
• http://blog.devopsguys.com/2013/02/20/twelve-devops-anti-patterns/