21CS019 Fundamentals of DevOps (Elective VIII)
Unit - I
By
Mr. Ganesh Dev
Assistant Professor – Dept. of CSE
GMR Institute of Technology
INTRODUCTION TO DEVOPS
DevOps is a software development methodology that
emphasizes collaboration, automation, and continuous delivery.
It brings together the development (Dev) and
operations (Ops) teams to work together throughout the entire
software development lifecycle, from planning and development
to testing, deployment, and operations.
The key principles of DevOps:
1. Culture of collaboration: DevOps emphasizes the importance of
cross-functional collaboration and communication between
development, operations, and other teams involved in the
software delivery process.
2. Automation: DevOps emphasizes the use of automation tools
and processes to speed up the delivery of software and reduce
the risk of human error.
3. Continuous delivery: DevOps emphasizes the importance of
delivering software in small, frequent increments, enabling faster
feedback and rapid response to changing customer needs.
4. Monitoring and feedback: DevOps emphasizes the use of
monitoring tools and feedback loops to gather data on the
performance of the software and the delivery process, enabling
teams to identify and address issues quickly.
The benefits of DevOps:
1. Faster time-to-market: By adopting DevOps, organizations can deliver
software faster and more frequently, enabling them to respond to
changing customer needs and market demands more quickly.
2. Improved quality: DevOps emphasizes automation and collaboration,
which can reduce the risk of human error and improve the quality of
the software being delivered.
3. Greater agility: DevOps enables organizations to respond to changing
market conditions and customer needs more quickly and effectively.
4. Increased efficiency: DevOps emphasizes the use of automation tools
and processes, which can improve the efficiency of the software
delivery process and reduce waste.
5. Better collaboration and communication: DevOps emphasize cross-
functional collaboration and communication, which can improve
teamwork and foster a culture of continuous improvement
How does DevOps differ from traditional
software development methodologies
DevOps differs from traditional software development methodologies in
several keyways:
1.Approach to software development: Traditional software development
methodologies like Waterfall or Agile follow a linear approach to software
development, where each phase of the software development lifecycle is
completed sequentially before moving on to the next phase. In contrast,
DevOps follows an iterative and incremental approach, where software is
developed, tested, and delivered in small, frequent increments.
2. Collaboration: Traditional software development methodologies typically
involve siloed teams with separate roles and responsibilities, whereas DevOps
emphasizes cross-functional collaboration and communication between
development, operations, and other teams involved in the software delivery
process.
3. Automation: DevOps emphasizes the use of automation tools and processes
to speed up the delivery of software and reduce the risk of human error,
whereas traditional software development methodologies rely more on
manual processes.
How does DevOps differ from traditional
software development methodologies
4. Feedback and Continuous Improvement: DevOps emphasizes the
importance of monitoring and feedback loops to gather data on the
performance of the software and the delivery process, enabling
teams to identify and address issues quickly. In contrast, traditional
software development methodologies may not emphasize
feedback loops until the end of the development cycle.
5. Deployment Frequency: Traditional software development
methodologies typically involve infrequent, large-scale releases,
while DevOps emphasizes smaller, more frequent releases to
enable faster feedback and continuous improvement.
6. Customer Focus: DevOps puts a strong emphasis on delivering
value to customers through continuous feedback and collaboration,
whereas traditional software development methodologies may not
prioritize customer feedback until later in the development cycle.
How does DevOps differ from traditional
software development methodologies
In summary, DevOps differs from traditional software
development methodologies in its approach to software
development, collaboration, automation, feedback and
continuous improvement, deployment frequency, and customer
focus. DevOps emphasizes an iterative and incremental
approach, cross-functional collaboration, automation, frequent
feedback, and customer value, while traditional software
development methodologies rely on a linear approach, siloed
teams, manual processes, infrequent feedback, and delayed
customer involvement.
What are some common tools and technologies used in
DevOps, and how do they support the DevOps process?
There are a variety of tools and technologies used in DevOps to
support the software delivery pipeline. Here are some common
tools and technologies used in DevOps:
1.Version control systems: Version control systems like Git and
SVN allow teams to collaborate on code changes, track changes
over time, and manage different versions of the software.
2. Continuous Integration and Continuous Delivery (CI/CD) tools:
CI/CD tools like Jenkins, CircleCI, and Travis CI automate the
build, test, and deployment process, allowing teams to rapidly
test and deliver changes to production.
3. Infrastructure as code (IaC) tools: IaC tools like Terraform and
CloudFormation allow teams to automate the provisioning and
configuration of infrastructure, reducing the risk of errors and
enabling faster deployment times.
What are some common tools and technologies used in
DevOps, and how do they support the DevOps process?
4. Containerization technologies: Containerization technologies
like Docker and Kubernetes allow teams to package and deploy
applications in a portable and scalable way, enabling faster and
more efficient deployment.
5. Monitoring and Logging tools: Monitoring and Logging tools
like Prometheus, Grafana, and ELK stack allow teams to monitor
the performance and health of the software, detect issues and
anomalies, and troubleshoot problems in real-time.
6. Collaboration and Communication tools: Collaboration and
Communication tools like Slack, Microsoft Teams, and Zoom
allow teams to communicate and collaborate in real-time,
facilitating cross-functional collaboration and knowledge
sharing.
What are some common DevOps metrics used to measure
performance and identify areas for improvement?
There are several common DevOps metrics that can be used to
measure performance and identify areas for improvement, including:
1. Lead time: The time it takes to go from code commit to
production deployment. A shorter lead time indicates faster
development and deployment cycles.
2. Deployment frequency: The frequency of code deployments to
production. A higher deployment frequency indicates faster and
more frequent releases of new features and bug fixes.
3. Mean time to recovery (MTTR): The average time it takes to
recover from a failure or outage. A shorter MTTR indicates faster
incident response and resolution times.
4. Change failure rate: The percentage of deployments that result in
failures or incidents. A lower change failure rate indicates higher
code quality and fewer production incidents.
What are some common DevOps metrics used to measure
performance and identify areas for improvement?
5. Customer satisfaction: The level of satisfaction among users and
customers. This metric can be measured through surveys, feedback, or
other customer satisfaction metrics.
6. Infrastructure utilization: The amount of resources used by the
application infrastructure. A high utilization rate can indicate a need
for scaling or optimization.
7. Code quality: Metrics such as code coverage, code complexity, and
code maintainability can be used to measure the quality of the
codebase.
8. Team productivity: Metrics such as sprint velocity and team
throughput can be used to measure the productivity of the
development team.
By measuring these and other DevOps metrics, teams can identify
areas for improvement and optimize their development and delivery
processes for greater efficiency, reliability, and customer satisfaction.
What is continuous integration (CI),
and how does it support DevOps?
• Continuous Integration (CI) is a software development practice
that involves automatically building, testing, and integrating
code changes into a shared repository multiple times a day.
The goal of CI is to detect and address code integration issues
early in the development process, improving the overall
quality of the code and reducing the risk of errors and delays
during the later stages of development. I
• n a typical CI workflow, developers commit code changes to a
shared repository, triggering an automated build and test
process. The CI tool checks out the latest version of the code,
builds the software, runs automated tests, and reports the
results back to the team. If the build or tests fail, the team is
notified, and the developer responsible for the failed changes
can quickly address the issue.
What is continuous integration (CI),
and how does it support DevOps?
• CI is a crucial component of DevOps because it enables faster
feedback and continuous integration of code changes, allowing
teams to detect and address integration issues early in the
development process. By identifying and addressing issues earlier,
teams can avoid costly delays and reduce the risk of errors and
downtime in production.
• CI also helps teams to maintain a high level of code quality and
consistency by enforcing code standards and providing automated
testing and feedback. By automating the build, test, and integration
process, teams can reduce the burden of manual testing and enable
developers to focus on writing high-quality code
• Continuous Integration (CI) is a software development practice that
supports DevOps by enabling faster feedback and continuous
integration of code changes, improving code quality, and reducing
the risk of errors and downtime in production.
What is continuous delivery (CD), and
how does it support DevOps?
• Continuous Delivery (CD) is a software development practice that involves
automating the entire software delivery pipeline, from code changes to
deployment, in order to enable rapid, reliable, and frequent releases of
high-quality software.
• CD builds on the foundation of Continuous Integration (CI) by automating
the deployment and delivery process, enabling teams to quickly and
reliably release code changes to production. With CD, code changes that
pass the CI process are automatically deployed to a staging environment
where they undergo further testing and validation.
• Once the code changes are approved in the staging environment, they
are automatically deployed to production, with minimal human
intervention. CD supports DevOps by enabling teams to deliver code
changes more frequently and reliably, reducing the time it takes to get
new features and bug fixes into the hands of users.
• By automating the delivery process, CD also reduces the risk of errors and
downtime, as well as the manual effort required to release code changes.
What is continuous delivery (CD), and
how does it support DevOps?
• In addition, CD provides teams with greater visibility and control over the
software delivery process, enabling them to identify and address issues
more quickly and efficiently.
• CD also supports collaboration and communication between teams involved
in the software delivery process, enabling cross-functional teams to work
together more effectively and deliver software faster.
• Continuous Delivery (CD) is a software development practice that supports
DevOps by automating the entire software delivery pipeline, enabling teams
to deliver code changes more frequently and reliably, reducing the risk of
errors and downtime, and improving collaboration and communication
between teams.
• Value stream mapping is a critical component of DevOps because it allows
organizations to identify inefficiencies and bottlenecks in their software
delivery process.
• By understanding the flow of work from ideation to deployment, DevOps
teams can optimize their processes, reduce waste, and improve the speed
and quality of software delivery
What is value stream mapping?
• Value stream mapping (sometimes called VSM) is a lean
manufacturing technique to analyze, design, and manage the
flow of materials and information required to bring a product
to a customer.
• Also known as "material and information-flow mapping", it
uses a system of standard symbols to depict various work
streams and information flows.
• Items are mapped as adding value or not adding value from
the customer’s standpoint, with the purpose of rooting out
items that don’t add value.
What is value stream mapping?
why value stream mapping is important
for DevOps:
1.Identifying waste and inefficiencies: Value stream mapping helps
organizations identify areas of waste and inefficiency in their software
delivery process, such as excessive wait times, handoffs, and rework.
By reducing or eliminating these areas of waste, organizations can
improve their software delivery speed and quality.
2. Improving collaboration: Value stream mapping provides a common
language for DevOps teams to communicate and collaborate. By
mapping out the entire software delivery process, DevOps teams can
better understand each other's roles and responsibilities, and identify
areas where collaboration can be improved.
3. Increasing transparency: Value stream mapping provides a clear
view of the software delivery process, making it easier for DevOps
teams to identify and track progress. This increased transparency
helps to improve accountability and make it easier to identify and
address issues as they arise
why value stream mapping is important
for DevOps:
4. Continuous improvement: Value stream mapping is a
continuous process that allows organizations to identify areas
for improvement and implement changes on an ongoing basis.
By continually optimizing their software delivery process,
DevOps teams can deliver higher quality software faster and
more efficiently.
In summary, value stream mapping is critical for DevOps
because it helps organizations optimize their software delivery
process, reduce waste and inefficiencies, improve collaboration
and transparency, and continuously improve their processes. By
focusing on the value stream, organizations can deliver higher
quality software faster and more efficiently, ultimately providing
more value to customers
Analyzing the technology value stream:
• Analyzing the technology value stream involves identifying the various steps
involved in delivering value to customers through technology and optimizing
these steps to improve efficiency and effectiveness. The value stream can
include processes related to software development, infrastructure
management, and customer support.
1. Identify the value stream: The first step is to identify the value stream and
map out the various processes involved in delivering value to customers. This
can include processes related to software development, infrastructure
management, and customer support.
2. Analyze each process: Once the value stream is identified, each process
should be analyzed to identify inefficiencies and areas for improvement. This
can involve using process mapping tools, such as flowcharts, to identify
bottlenecks and areas where work is duplicated.
3. Prioritize improvements: After identifying areas for improvement, prioritize
them based on the potential impact on the value stream. Some improvements
may have a higher impact than others, so it is important to focus on the most
critical improvements first
Analyzing the technology value stream:
4. Implement improvements: Once improvements are identified
and prioritized, it is important to implement them in a systematic
way. This can involve using agile methodologies to implement
changes in small iterations and continuously monitoring and
adjusting the process.
5. Measure results: Finally, it is important to measure the impact of
the improvements on the value stream. This can involve collecting
data on key performance indicators, such as cycle time, lead time,
and customer satisfaction, to ensure that improvements are having
the desired impact.
By analyzing the technology value stream and implementing
improvements, organizations can deliver value to customers more
efficiently and effectively. This can help to reduce costs, increase
customer satisfaction, and stay competitive in today's fast-paced
market.
The History of DevOps
As Agile development gained popularity, a new
term emerged to describe the practices and
principles used to streamline the development and
deployment process: DevOps.
To share the history of DevOps, below is a detailed
history of DevOps timeline, listing all the defining
moments and summarizing the contributions of key
influential people from 2007 to 2019.
2007
DevOps started in 2007 when Patrick Debois — an
IT consultant, recognized that development (Dev)
and operations (Ops) teams were not working well
together.
While the gaps and conflicts between Dev
and Ops have always been unsettling to him, the
constant switching and back and forth on a large
data center migration project where he was
responsible for testing particularly frustrated him.
One day he was deep in the rhythm of Agile
development. Next day he was firefighting and
living the unpredictability of traditional operations.
He knew there had to be a better way.
2008
The following year, at the 2008 Agile Conference,
Andrew Shafer created a birds of a feather meeting
(BoF) to discuss “Agile Infrastructure”.
Andrew didn't think anybody would come, so
he himself didn’t show up to his own meeting.
Patrick Debois showed up, and went looking
for Andrew because he wanted to talk about Agile
infrastructure being the solution to get operations
to be as Agile like the developers were. This was
where DevOps got started.
2009
In 2009, at the Velocity conference, John Allspaw
and Paul Hammond talked about “
10+ deploys per day - Dev and Ops Cooperation at
Flickr
,” and the idea started gaining traction.
This talk made people notice what was
possible by adopting these early DevOps practices.
Also, in October 2009, Patrick, held the first
DevOpsDays conference in Ghent, Belgium. It was
described as “The conference that brings
development and operations together.” This is
where the term "DevOps" was first used.
DevOpsDays is now a local conference held
internationally several times a year in different
cities.
2010
In 2010, Jez Humble and David Farley wrote a
groundbreaking book called Continuous Delivery
that sets out the principles and technical practices
that enable rapid, incremental delivery of high-
quality, valuable new functionality to users using a
technique called Continuous Delivery.
Through automation of the build, deploy, and
test processes, along with improved collaboration
between developers, testers, and operations,
delivery teams can release changes in a matter of
hours—sometimes even minutes—no matter the
size of a project or the complexity.
The book is over 13 years old, but it still has a lot
of great concepts that helped changed a lot of
people's thinking about how to perform software
delivery in a continuous fashion.
2013
Two years later, in 2013, Gene Kim, Kevin Behr, and
George Spafford published The Phoenix Project,
based on Eliyahu Goldratt’s book, The Goal.
The Goal is about a manufacturing plant
about to go under and what they had to do to bring
it back to life. It is a story about lean manufacturing
principles.
The Phoenix Project is about an information
technology (IT) shop in a company about to go
under and what it took to bring it back to life.
This story is about applying lean
manufacturing principles to software development
and delivery.
2015
In 2015, Dr. Nicole Forsgren, Gene Kim, and Jez Humble
founded a startup called DORA (DevOps Research and
Assessment) that produced what are now the largest
DevOps studies to date called the
State of DevOps Reports. Nicole was the CEO and is an
incredible statistician.
Through this research, she found that taking an
experimental approach to product development can
improve your IT and organizational performance and that
high-performing organizations are decisively
outperforming their lower-performing peers in terms of
throughput.
The research shows that undertaking a technology
transformation initiative can produce sizeable cost
savings in any organization. If you haven't read the most
recent State of DevOps report, I strongly urge you to do
so.
2016
The DevOps Handbook was published in 2016. It
was written by Gene Kim, Jez Humble, Patrick
Debois, and John Willis as a follow-on to The
Phoenix Project and serves as a practical guide on
implementing the concepts introduced in that book.
John Willis, by the way, worked at Docker and Chef
back then, and is a DevOpsDays coordinator after
being at the original DevOpsDays in Ghent 2009
with Patrick Debois.
If you only read one DevOps book, this is the
book to read. They looked at companies that have
adopted DevOps and document what did work and
what did not work. It's a great read.
2019 — 10 years of DevOpsDays
Come 2019, 10 years after the first DevOpsDays in
Ghent, Belgium, 60+ DevOpsDays events were held
in 21 countries.
Patrick Debois led DevOpsDays from its
inception in 2009 until 2014, and then Bridget
Kromhout became the lead in 2015. She is also the
co-host on the very popular podcast,
Arrested DevOps. If you don't listen to it, you
should.
She stepped down in 2020 but stayed on the
advisory board of DevOpsDays with Patrick.
The individuals mentioned above are some of the
major influential people in the early DevOps
movement. They weren’t the only ones, but they
went out and made a difference. They showed us
Why is the DevOps History Important?
Knowing the DevOps History is important because
DevOps was a grassroots effort started by people
like Patrick Debois and Andrew Shafer, who just
wanted to eliminate the roadblocks in software
delivery and figure out how can development and
operations work better together.
And as Damon Edwards, who co-hosted a podcast
with John Willis called the 'DevOps Cafe', said it
best in his talk on “The (Short) History of DevOps”:
• DevOps is from the practitioners, by practitioners.
• It’s not a product, a specification, or job title.
• It is an experience-based movement that is
decentralized and open to all.
The ways of DevOps
• Flow
• Feedback Loops
• Culture of Continual Experimentation and
Learning
Flow
• The First Way is mostly concerned with accelerating the “flow” of
work throughout a process. Whether you’re calling it Flow or Systems
Thinking, the principles underpinning the First Way are working
toward the same end: viewing the flow of work as one continuous
system (unsiloed) that can be continually refined and optimized.
Some of the key principles of the First Way are:
• Making work “visible”. Unlike manufacturing processes, which are
easily observable on a plant floor, the flow of software through its
development lifecycle is not easily seen. Using methods such as
Kanban boards can surface the activities going on behind the scenes,
by showing the left-to-right movement of a user story through the
development phases.
Flow
• Limiting work-in-progress (WIP). Keeping work-in-progress to a minimum
has also been shown to accelerate work flow, because it minimizes multi-
tasking and context-switching.
• Reducing batch sizes. “Chunking” work into smaller pieces like a two-
week sprint can also help deliver features (albeit smaller ones) and bug
fixes to the customer faster. Issues are often caught earlier when those
updates and additions are released sooner.
• Reducing hand-offs between teams. The risk of “dropping the baton”
increases as the hand-offs do. Although hand-offs can’t be completely
minimized, the key is to keep the teams in tight communication with one
another so that the hand-off itself is almost a non-event rather than a
large ordeal with the potential for communication missteps along the way.
• Identifying and removing constraints and waste. Constraints might be
bottlenecks in the process, such as environments, test setup, and overly
tight architecture, while waste includes things like manual work, heroics,
and context-switching.
Feedback Loops
The Second Way works to enable fast and constant feedback cycles
throughout all stages of a development cycle.
Some of the key principles of the Second Way are:
• Swarming and solving problems to build new knowledge. This principle
fits into the “fail fast” mentality, so that teams can find issues with an
implementation as soon as possible and address them early and often as
iterations continue.
• Pushing quality closer to source. This principle is at the core of the
DevSecOps movement, which is concerned with addressing security
concerns during the development cycle, instead of at the end, when
rework to remediate is more difficult and costly.
• Optimizing for downstream work centers. This principle works against
the “throw it over the wall” mentality, by underscoring that development
should be just as invested in their application being deployable, working
with operations to bridge that gap (and vice versa).
Culture of Continual Experimentation and
Learning
The culture of continual experimentation and learning is a key aspect of
DevOps that emphasizes the importance of trying new things, learning from
failures, and continuously improving processes. Here are some ways this
culture is fostered in DevOps:
1. Embracing failure as a learning opportunity: In DevOps, failure is not seen
as a negative outcome, but rather as an opportunity to learn and improve.
Teams are encouraged to take risks and try new things, knowing that
failure is an inevitable part of the learning process.
2. Building a blameless culture: In a blameless culture, individuals are not
blamed for failures, but rather the focus is on identifying the root cause of
the failure and improving processes to prevent similar failures from
occurring in the future. This encourages individuals to take risks and
experiment without fear of reprisal.
3. Encouraging experimentation and innovation: DevOps teams are
encouraged to experiment with new technologies, processes, and
approaches to continuously improve their work. This can involve setting
aside time for innovation and experimentation, creating an environment
that fosters creativity, and providing resources and support to pursue new
ideas.
Culture of Continual Experimentation and
Learning
4. Providing opportunities for learning and growth: DevOps teams
are provided with opportunities for continuous learning and growth,
such as attending conferences, participating in training programs, and
collaborating with other teams. This helps to ensure that individuals
stay up-to-date with the latest trends and technologies and are
continuously improving their skills.
5. Celebrating successes and learning from failures: Finally, DevOps
teams celebrate successes and learn from failures by recognizing
individuals and teams who have made significant contributions,
sharing lessons learned from failures, and using successes and failures
as opportunities to reflect on and improve processes.
By fostering a culture of continual experimentation and learning,
DevOps teams can stay agile, adapt to change, and continuously
improve their work. This can lead to better outcomes for customers,
increased efficiency, and a competitive advantage in the marketplace
