The document outlines a comprehensive guide for implementing DevOps within an organization, emphasizing the need for a cultural transformation alongside technical practices. It describes a phased approach (crawl, walk, run, fly) focusing on standardizing tools, automating processes, and enhancing collaboration between development and operations. Key initiatives include transitioning to cloud environments, implementing automated testing, and establishing a Center of Excellence to oversee DevOps adoption.

1. Preparing for DevOps
GROUND WORK
EKLOVE MOHAN

2. DevOps Introduction
• A combination of "development" (and
QA) along with "Operations".
• DevOps emphasis on developing a culture
within the organization for the
transformation.
• To build the culture, first step is to build
maturity among developers and
operations.
• DevOps cannot be implemented by any
organization overnight or even in a
fortnight. It requires a lot of groundwork,
dedication, and in some cases
enforcement as well.

3. Crawl-Walk-Run-Fly
Crawl
• Standardize Source
Control
• Define branching
strategy
• Define Defect Tracking
tool
• Automate System test
cases
• Plan for Synthetic
Transactions
• Enable Quality Checks
• Enable Automated
Unit Test cases
• Expose to cloud
• Build Knowledge base
Walk
• Build Continuous
Integration pipeline
• Build an Artifact
repository
• Build Continuous
Delivery pipeline for
Dev
• Enable Synthetic
transaction
Run
• Build Continuous
Delivery pipeline for
QA and production
• Enable Build
Promotion
• Setup Infrastructure
and application
monitoring tools
Fly
• Enable Blue Green
environments
• Enable Infrastructure
as code
• Enable Metric based
alerts
• Enable Continuous
Deployment
• Build pipelines of
pipelines
• Progress towards
DevSecOps

4. Crawl Stage - Roles and Responsibilities
• Organization
• Form a group of thought leaders
(Project Managers, Architects and
Product owners).
• Source Control Standardization
• Define branching strategy
• Define defect tracking tools
• Monitor progress on a daily basis
• Quality Assurance (QA)
• Implement system test cases
automation
• Plan for Synthetic Transactions
• Developers
• Enable Quality checks
• Automated unit testing
• Exposure to cloud
• Operations
• Understand the product
• Enable configuration management
tool
• Exposure to cloud
• Monitor the infrastructure and
application

5. Form a Centre of Excellence
CTO
Project
Managers
Architects
Product
Managers
Transformation
Head
• Identify a group of Project managers, architects and
product managers who can run this CoE.
• Generally, this group is termed as “DevOps CoE”. As
of now, call it “Transformation CoE” since the focus
is on transforming the organization to be able to
adopt DevOps one day.
• Group focuses on standardization of tools and
processes across all the projects within the
organization than for a single project.
• Work on Continuous Improvement through
feedbacks and retrospections at regular intervals.

6. Standardize Source Control
• Identify a list of all the source control management tools
that are being used in the organization.
• Filter to one. Compare features of all the source controls
(cost, on-prem vs cloud etc) or pick the one that is common
across most projects (may not be the best choice).
• For each project to be migrated, identify whether we need
all the history or can live with, say 6 months of history.
• Use Git command to clone from original source control
along with history. E.g. if original source control is TFS, use
• Don’t discontinue the original source control as yet. Create a
sync job between the old and new source control system.
Developers continue to checkin/commit to old but the sync
job moves the updated code into new. No one directly
commits into new.
• Plan training for developers and operations on the new
source control system.
git tfs -d quick-clone --changeset=567716 <tfsUrl> “<folder to clone>" "C:/B1“
git tfs pull

7. Branching Strategy
• Use a standard branching strategy. Big no to long
running branches.
• Pick between “Single Trunk” or “Feature based”
branches.
• “Single Trunk” has no or minimum merge conflicts,
since we develop of the same “trunk” and branch
only when a release is required. Hotfixes are also
developed on trunk and then “cherry – picked” into
release branch.
• “Feature based” – create a code branch for each
feature. Merge from trunk to “feature” branch on a
regular basis to avoid merge conflicts later. Feature
branch are short lived branches and should be
merged back into the trunk as soon as the feature is
complete.

8. Defect Tracking Tool
• Similar to Source Control systems that may exist in
plenty within the organization, compare all the tools
but filter to one.
• Most of the modern tools have similar features
therefore compare based on on-premise vs cloud,
cost, testing team comfort, reporting capabilities etc.
• The tracking tool should have provision of
integrating with the Continuous Integration tools.
We would need that when we start the DevOps
process.
• Define training plan for the entire team on effective
usage of the tool.

9. System Test case Automation
• Move towards automated test cases. Manual Test
cases may have greater test coverage but is not
automated and are time consuming.
• Target coverage percentage (Functional coverage) for
each sprint.
• Start with converting regression test cases to
automated. New feature development continue to be
manual.
• Run the automated test cases on a daily basis (run it
nightly every day once the test case suite is stable).
• Develop competencies on Behaviour Driven
Development (BDD) and then opt for tools like
Cucumber.

10. Plan for Synthetic Transactions
• A system consist of multiple applications. Each application may run on its own set of servers. Each may
work as an individual unit but validating that they are working as a group is important.
• Generally the first request coming on these servers may timeout or fail due to warm up or network error.
Synthetic transaction provides early feedback if any of these issues exist, even before even the business
starts.
• Consider Synthetic transaction as a void submission to the system that will create dummy records in the
database, initiate a transaction, hit the third parties, store the updated values and then perform a clean up
of the entire dummy transaction.
• Identify one most critical scenario based on the business needs. This transaction should ideally touch all
the discrete systems for that application.
• This will not be used right now in the “crawl” stage, but is going to be used when we start “running”. Plan
for Synthetic transaction now and build during the “walk” stage.

11. Enable Quality Checks in the code
• Write code that follows industry standards best
practices. Every programming language has defined
guidelines that the developers should follow.
• Manual code review are too dependant on the
individuals. Bring in automation. E.g. enable FxCop
for .NET, PMD for Java etc. on each developer
machine.
• Use a centralized tools or platform that can show
quality scores and deduce code quality on the basis
of design, architecture and test quality for the
project.
• Compete with your project and not with others. The
quality score of today should either be the same or
improve tomorrow but should not deteriorate.
• Consider code quality issues same as functional
issues and fix them on priority.

12. Implement Automated Unit Test Cases
• Build sense of responsibility. The code developer
writes, first needs to be tested by the developer.
• Write automated unit test cases. For legacy
applications, don’t worry about Test Driven
Development (TDD) as yet but do understand the
concept.
• Refactor the code to loose couple. Use Interfaces or
abstract classes to inject the dependencies.
• Monitor the unit test code coverage. Define goals for
each sprint. Be cognizant of the fact that the
coverage will be higher when you start writing the
automated test cases, but it will stabilize and
difficult to increase after a point of time.
• Ensure that there is atleast one assertion for each test
case. Don’t write test cases for the sake of coverage.
Ensure that the test cases do fail when code is
updated and the testcase is not.

13. Exposure to Cloud
• Consider cloud as a catalyst to DevOps. At some point of
time in your organization, they will go hand-in-hand.
• Developers are responsible for coding new features and are
generally not aware about deployments or about basic
networking concepts like subnets, ports, private and public
IPs, load balancers etc. DevOps require developers to know
all this.
• Learn by reading the books/watching tutorials or by doing
the things practically on cloud. Learning curve is much
shorter when done practically.
• Get a sense of building and deploying the code on cloud.
Observe each settings. Understand securing the instances.
Play with servers, create and destroy at will.
• For Operations, move to cloud and understand the shared
responsibility model. Do look at serverless. Change mindset
from procurement to on-demand services.
• Build atleast one non production environment in
collaboration with the development team on cloud.

14. Understand the Product
• Operations, confined to deployment and monitoring of the infrastructure. With DevOps in mind, it is
important to build understanding of the application you are building and supporting.
• Operations to be part of the daily scrum meetings to understand what is coming up in near future.
• Collaborate with developers to understand the changes in the functionality. Do raise concerns if you think
something can create issue when deployed to production. E.g. increasing the application log volume on the
file server due to change in verbose level etc
• Special attention to all third party integration. Ports, security credentials, certificates and the protocol used
to send and receive the information is critical.
• Analyse configuration management tools like puppet or Chef. This will be the next level of automation that
we would target so start preparing. Knowing about the product would greatly help in preparing the scripts.
• Going for IaaS, PaaS or SaaS would be easier to determine since operations not only knows about the server
configuration but also about the application needs.

15. Monitor Infrastructure and application
• Monitor not only Infrastructure but applications as well.
Change mindset to not only look at CPU utilization,
memory utilization, disk space, I/O writes etc but also at
application component interaction.
• Evaluate tools which run both on on-premise as well as
cloud even if you don’t have any plan for cloud. Some day
you will move to cloud, so be prepared.
• Get away from custom dashboard tools build by your team
few years back. They wont work on cloud.
• Build skills on Infrastructure automation. Practise on cloud.

16. Closing words
• There are four stages of maturity defined in this deck (Crawl, walk, run
and fly) but only “Crawl” has been detailed out.
• Let the “Crawl” phase run for 2-3 months. Gather feedback, conduct
retrospection. Identify the challenges and work towards remediation.
• Move to the “Walk” stage. Don’t go for a big bang approach. Start the
stage only for 2-3 projects and monitor the progress.

17. Coming up next
Details on how to work during the “Walk” stage.

18. Thank you