This document discusses moving from a traditional development and operations model to a DevOps model using continuous delivery. It outlines some anti-patterns to avoid when adopting DevOps, such as treating configuration management as DevOps or creating separate DevOps teams. The traditional model has development and operations teams with different goals and tools working independently. Continuous delivery is presented as an Agile approach where development, testing, deployment, and monitoring are automated and continuous. This allows for faster and more reliable software releases.

1. DevOps – Moving from Agile Dev to
Agile Ops using Continuous Delivery
Kalyan Kumar
VP-CFS & Chief Technology Architect
Email: kalyank@hcl.com
Twitter: @kklive

4. Anti Pattern #1 - Config Mgmt = DevOps
4
Tools
Process
Culture

5. Anti-Pattern #2- Rebranding Ops as the DevOps team or Creating separate team
5
(Yet Another Silo)
Act as a change agent

6. Anti-Pattern #3 - Sell it as a buzzword
6

7. 7
Anti-Pattern #4 – Deploy Software Manually

8. 8
Anti-Pattern #5 - Manual Configuration of Production Environments

9. 9
Anti-Pattern #6 - Believe chef/puppet will solve all your problems 

10. Anti-Pattern #7 - Deploy to production after testing in Dev without testing in Production-Like

12. Traditional Dev and Ops Model
12
They don’t have common goals.
They don’t use the same tools
No visibility into one others’ processes
Characteristics of traditional Dev and Ops teams:
Development Teams
• Driven by change
• Focus is to deliver value
executing projects on
time and within budget
• Measured by improved
business capability and
agility
• Higher frequency of
releases
• Rapid pace of innovation
in tools and technologies Different implementation methodologies
Operations Teams
• Driven by stability
• Focus is to keep the
enterprise running with
less to zero downtime
• Measured by uptime and
stability of the production
system
• Encourage fewer releases
• Typically small teams
consumed by fire-fighting

13. Symptoms and causes
13
The project was kicked off last week. The dev environment isn’t ready
yet.
There are multiple tracks in the project. Build is broken more often than
not. Takes a lot of time to identify the issue.
Application is deployed to QA environment successfully. But I can’t login
to the application.
Tedious testing cycle. Takes too much time to setup test bed, execute test
cases, report results and even more time to repeat this cycle.
Takes too much time to follow the release notes and deploy the
application.
No easy way to
spawn
environments
Continuous
Integration
Lack of release
management
process
Continuous
Testing
Deployment
automation
Program
Manager
Development
Manager/Lead
QA Lead/team
Program
manager
Ops/Deployme
nt teams
CauseSymptomImpacted party

14. Agile is needed in all the phases of SDLC. Not just in development.
14
Continuous Build
and Integration
• Key part of Agile
development
• Integrate code from
multiple tracks/modules
as early as possible
• Unit tested build delivered
• Assign build version before
deploying to QA
Continuous
Testing
• QA the code for functional
and non-functional
aspects in a prod-like
environment
• QA reports defects on a
specific build version
• Dev fixes the defects and
delivers another build.
This loop continues till QA
certifies the build
• Improves confidence in
the entire team if code is
being tested regularly
Continuous
Deployment
• Objective is to get the
system to the users’ hands
as often as possible
• Deploy the QA certified
build in prod
• Build tools to automate
the deployment
• Opportunity for Ops to
provide feedback to Dev
on the structure of the
build early in the life cycle
• Continually deploying
code will improve the
quality of tools and make
the deployment seamless
Continuous
Monitoring
• Use monitoring tools to
measure system and
application health
• Opportunities to identify
bottlenecks and issues
early
• Communicate
performance/scalability
issues to dev early
Continuous Delivery

15. DevOps – Move beyond Continuous Integration to Continuous Delivery
15
Provisioning
•Provisioning of
servers with pre-
requisites
•Automation
Deployment
Automation
•Continuous
Integration
•Continuous Testing
•Build dependencies
•Config files
Deployment
Architecture
•Caching
•Load balancing
•Content Delivery
Networks
Release
Management
•Continuous release
•Code promotions
•Code rollbacks
Environment
Management
•Inventory
management
•Auto scaling based
on policies
•Approvals
Application
Performance and
Monitoring
•System health
monitoring
•Application health
monitoring
•Root cause analysis
Project Initiation
Project
Implementation
Project Rollout Feedback
Dev
Ops
Continuous Delivery
Culture Process Tools

16. Version
Management
User Interface/API
Have a Platform to Deliver DevOps Vision
Environment Management
Environment
Baselines
Orchestration & Collaboration
Configuration Management
Build
Build
Repository
QA Performance
Test
UAT Production
Env
Config
Application
Files
Process Management
Culture
Application Performance Management
Programmable Infrastructure

17. Traditional
Transition
Agile
Transition
Leaving
Dev
Come Back Soon!
Welcome To
Ops
Drive Safe!
Leaving
Dev
Come Back Soon!
Welcome To
Ops
Drive Safe!
Agile Dev meets Agile Ops
Release Management is Too Slow
Streamlined Release Management

18. 18
Be the Iron Man and not the Robot
Be the Automator and NOT the Automated 

19. Thank You
* All logos, trademarks, copyrights referred in this deck belong to the respective
companies or Creative Commons License