DEVOPS MATERIAL (UNIT -1)

UNIT - I

Introduction
History:
Software Development Life Cycle (SDLC) :

A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods required to
make a software product transit through its life cycle stages. It also captures the structure in which
these methods are to be undertaken.

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.

Planning for the quality assurance requirements and identifications of the risks associated with the
projects is also done at this stage.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Business analyst and Project organizer set up a meeting with the client to gather all the data like
what the customer wants to build, who will be the end user, what is the objective of the product.
Before creating a product, a core understanding or knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money transactions. In this
method, the requirement has to be precise like what kind of operations will be done, how it will
be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of the
growth of a product. In case of any ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement Specification) document is
created. The developers should thoroughly follow this document and also should be reviewed by
the customer for future reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and document the
software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

contains all the product requirements to be constructed and developed during the project life
cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and design of
the software project. This phase is the product of the last two, like inputs from the customer and
requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the coding
guidelines described by their management and programming tools like compilers, interpreters,
debuggers, etc. are used to develop and implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to make sure that the products are
solving the needs addressed and gathered during the requirements stage.
PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

During this stage, unit testing, integration testing, system testing, acceptance testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.

This procedure where the care is taken for the developed product is known as maintenance.

Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration and
system testing, and operation and maintenance. The steps always follow in this order and do not
overlap. The developer must complete every phase before the next phase begins. This model is
named "Waterfall Model", because its diagrammatic representation resembles a cascade of
waterfalls.

1. Requirements analysis and specification phase: The aim of this phase is to understand the
exact requirements of the customer and to document them properly. Both the customer and the
software developer work together so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the system to be produced and
not "how."In this phase, a large document called Software Requirement Specification
(SRS) document is created which contained a detailed description of what the system will do in
the common language.

2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language. It defines the overall
software architecture together with high level and detailed design. All this work is documented as
a Software Design Document (SDD).

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

3. Implementation and unit testing: During this phase, design is implemented. If the SDD is
complete, the implementation or coding phase proceeds smoothly, because all the information
needed by software developers is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small modules are tested in
isolation initially. After that these modules are tested by writing some overhead code to check the
interaction between these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end product
is determined by the effectiveness of the testing carried out. The better output will lead to satisfied
customers, lower maintenance costs, and accurate results. Unit testing determines the efficiency
of individual modules. However, in this phase, the modules are tested for their interactions with
each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user once the
software has been delivered to the customer, installed, and operational.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for it is minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the entire
project development.
o The start and end points for each phase is fixed, which makes it easy to cover progress.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

o The release date for the complete product, as well as its final cost, can be determined before
development.
o It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for more significant and
complex projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has now shifted to the
coding phase, and there is a change in requirement, It becomes tough to go back and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and risks in the
earlier phase, so the risk reduction strategy is difficult to prepare.

Agile development model:

An agile methodology is an iterative approach to software development. Each iteration of agile
methodology takes a short time interval of 1 to 4 weeks. The agile development process is aligned
to deliver the changing business requirement. It distributes the software with faster and fewer
changes.

The single-phase software development takes 6 to 18 months. In single-phase development, all

the requirement gathering and risks management factors are predicted initially.

The agile software development process frequently takes the feedback of workable product. The
workable product is delivered within 1 to 4 weeks of iteration.

The Agile development model is an iterative and incremental approach to software development
that emphasizes flexibility, adaptability, and customer collaboration It is an alternative to
traditional "waterfall" development methods that are more linear and sequential.

In the Agile model, the software is developed in short cycles, typically called "sprints," which last
one to four weeks

Each sprint involves planning, designing, coding, testing, and reviewing the software in a
collaborative and iterative manner

The Agile model prioritizes customer satisfaction by frequently releasing working software and
incorporating feedback from the customer in each sprint

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Some key principles of Agile development include:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Advantage Disadvantage
 Difficulty in assessing the effectiveness
and quality of work in the early stages.
 Agile model help businesses adapt more
effectively to customer requirements.
 Agile development team must depend
on customer input. This can derail the
 Increase customer trust.
implementation project.

 Customers can contribute and give opinions

 Require face-to-face communication &
during the implementation process, so the
meetings, which can be difficult for
product is more receptive.
large-scale organizations.

 Able to flexibly change the requirements

 Only a team of senior developers can
and development orientation of the project.
make important and urgent decisions in
the implementation process.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

DevOps Introduction:

The DevOps is the combination of two words, one is Development and other is Operations. It is
a culture to promote the development and operation process collectively.

The DevOps tutorial will help you to learn DevOps basics and provide depth knowledge of
various DevOps tools such as Git, Ansible, Docker, Puppet, Jenkins, Chef, Nagios,
and Kubernetes.

What is DevOps?

DevOps (development and operations) is a set of practices that combines software development
(Dev) and IT operations (Ops) in order to shorten the systems development life cycle and provide
continuous delivery with high software quality DevOps aims to improve collaboration between
development and operations teams, automate and streamline the process of building, testing, and
deploying software, and reduce the time it takes to deliver new features and updates to users
DevOps involves a cultural shift towards increased collaboration and communication between
teams, as well as the adoption of tools and processes that enable automation and continuous

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

integration and delivery (CI/CD) This includes practices such as agile development, continuous
integration, continuous delivery, infrastructure as code, and monitoring and feedback loops
By adopting DevOps practices, organizations can increase the speed of software delivery,
improve the quality of software, and reduce the likelihood of errors or downtime This can lead to
greater customer satisfaction, increased competitiveness, and improved

business outcomes

Why DevOps?

Before going further, we need to understand why we need the DevOps over the other methods.

o The operation and development team worked in complete isolation.

o After the design-build, the testing and deployment are performed respectively. That's why
they consumed more time than actual build cycles.
o Without the use of DevOps, the team members are spending a large amount of time on
designing, testing, and deploying instead of building the project.
o Manual code deployment leads to human errors in production.
o Coding and operation teams have their separate timelines and are not in synch, causing
further delays.
o DevOps History

o In 2009, the first conference named DevOpsdays was held in Ghent Belgium. Belgian
consultant and Patrick Debois founded the conference.
o In 2012, the state of DevOps report was launched and conceived by Alanna Brown at
Puppet.
o In 2014, the annual State of DevOps report was published by Nicole Forsgren, Jez
Humble, Gene Kim, and others. They found DevOps adoption was accelerating in 2014
also.
o In 2015, Nicole Forsgren, Gene Kim, and Jez Humble founded DORA (DevOps Research
and Assignment).
o In 2017, Nicole Forsgren, Gene Kim, and Jez Humble published "Accelerate: Building
and Scaling High Performing Technology Organizations".

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Differences between Waterfall, Agile and DevOps methodologies:

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

ITIL :
ITIL is an abbreviation of Information Technology Infrastructure Library.

It is a framework which helps the IT professionals for delivering the best services of IT. This
framework is a set of best practices to create and improve the process of ITSM (IT Service
Management). It provides a framework within an organization, which helps in planning,
measuring, and implementing the services of IT.

The main motive of this framework is that the resources are used in such a way so that the
customer get the better services and business get the profit.

It is not a standard but a collection of best practices guidelines.

Service Lifecycle in ITIL

1. Service Strategy.
2. Service Design.
3. Service Transition.
4. Service Operation.
5. Continual Service Improvement.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

1) Service Strategy: It is the first and initial stage in the lifecycle of the ITIL framework. The
main aim of this stage is that it offers a strategy on the basis of the current market scenario and
business perspective for the services of IT.

This stage mainly defines the plans, position, patters, and perspective which are required for a
service provider. It establishes the principles and policies which guide the whole lifecycle of IT
service.

Following are the various essential services or processes which come under the Service
Strategy stage:

o Financial Management
o Demand Management
o Service Portfolio Management
o Business Relationship Management
o Strategy Management

2) Service Design: It is the second phase or a stage in the lifecycle of a service in the
framework of ITIL. This stage provides the blueprint for the IT services. The main goal of this
stage is to design the new IT services. We can also change the existing services in this stage.

Following are the various essential services or processes which comes under the Service Design
stage:

o Service Level Management

o Capacity Management
o Availability Management
o Risk Management
o Service Continuity Management
o Service Catalogue Management
o Information Security Management
o Supplier Management
o Compliance Management
o Architecture Management

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

3) Service Transition: Service Transition is the third stage in the lifecycle of ITIL
Management Framework.

The main goal of this stage is to build, test, and develop the new or modified services of IT. This
stage of service lifecycle manages the risks to the existing services. It also certifies that the value
of a business is obtained.

This stage also makes sure that the new and changed IT services meet the expectation of the
business as defined in the previous two stages of service strategy and service design in the
lifecycle.

It can also easily manage or maintains the transition of new or modified IT services from
the Service Design stage to Service Operation stage.

There are following various essential services or processes which comes under the Service
Transition stage:

o Change Management
o Release and Deployment Management
o Service Asset and Configuration Management
o Knowledge Management
o Project Management (Transition Planning and Support)
o Service Validation and Testing
o Change Evaluation

4)Service Operations: Service Operations is the fourth stage in the lifecycle of ITIL. This
stage provides the guidelines about how to maintain and manage the stability in services of IT,
which helps in achieving the agreed level targets of service delivery.

This stage is also responsible for monitoring the services of IT and fulfilling the requests. In this
stage, all the plans of transition and design are measured and executed for the actual efficiency. It
is also responsible for resolving the incidents and carrying out the operational tasks.

There are following various essential services or processes which comes under the stage of
Service Operations:

o Event Management
o Access Management
o Problem Management

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

o Incident Management
o Application Management
o Technical Management

5) Continual Service Improvement: It is the fifth stage in the lifecycle of ITIL

service. This stage helps to identify and implement strategies, which is used for providing better
services in future.

Following are the various objectives or goals under this CSI:

o It improves the quality services by learning from the past failures.

o It also helps in analyzing and reviewing the improvement opportunities in every phase of the
service lifecycle.
o It also evaluates the service level achievement results.
o It also describes the best guidelines to achieve the large-scale improvements in the quality of
service.
o It also helps in describing the concept of KPI, which is a process metrics-driven for evaluating and
reviewing the performance of the services.

There are following various essential services or processes which comes under the stage of CSI:

o Service Review
o Process Evaluation
o Definition of CSI Initiatives
o Monitoring of CSI Initiatives

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Advantages of ITIL

Following are the various advantages or benefits of ITIL:

1. One of the best advantages of ITIL is that it helps in increasing the customer satisfaction.
2. It allows managers to improve the decision-making process.
3. It is also used for creating the clear structure of an organization.
4. It also helps managers by controlling the infrastructure services.
5. It improves the interaction between the customers and the service provider.
6. With the help of this framework, service delivery is also improved.
7. It establishes the framework of ITSM for the organization.

DevOps Process :

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

The DevOps process flow:

The DevOps process flow is all about agility and automation. Each phase in the DevOps lifecycle
focuses on closing the loop between development and operations and driving production through
continuous development, integration, testing, monitoring and feedback, delivery, and deployment.

1) Continuous Development:

Continuous development is an umbrella term that describes the iterative process for developing
software to be delivered to customers. It involves continuous integration, continuous testing,
continuous delivery, and continuous deployment.

By implementing a continuous development strategy and its associated sub-strategies, businesses

can achieve faster delivery of new features or products that are of higher quality and lower risk,
without running into significantly bandwidth barriers.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

2)Continuous Integration:

Continuous integration (CI) is a software development practice commonly applied in the DevOps
process flow. Developers regularly merge their code changes into a shared repository where those
updates are automatically tested.

Continuous integration ensures the most up-to-date and validated code is always readily available
to developers. CI helps prevent costly delays in development by allowing multiple developers to
work on the same source code with confidence, rather than waiting to integrate separate sections
of code all at once on release day.

This practice is a crucial component of the DevOps process flow, which aims to combine speed
and agility with reliability and security.

a) Continuous testing:

Continuous testing is a verification process that allows developers to ensure the code actually
works the way it was intended to in a live environment. Testing can surface bugs and particular
aspects of the product that may need fixing or improvement, and can be pushed back to the
development stages for continued improvement.

b) Continuous monitoring and feedback

Throughout the development pipeline, your team should have measures in place for continuous
monitoring and feedback of the products and systems. Again, the majority of the monitoring
process should be automated to provide continuous feedback.

This process allows IT operations to identify issues and notify developers in real time. Continuous
feedback ensures higher security and system reliability as well as more agile responses when
issues do arises.

3) Continuous Delivery:

Continuous delivery (CD) is the next logical step from CI. Code changes are automatically built,
tested, and packaged for release into production. The goal is to release updates to the users rapidly
and sustainably.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

To do this, CD automates the release process (building on the automated testing in CI) so that
new builds can be released at the click of a button.

4) Continuous Deployment:

For the seasoned DevOps organization, continuous deployment may be the better option over CD.
Continuous deployment is the fully automated version of CD with no human (i.e., manual) intervention
necessary.

In a continuous deployment process, every validated change is automatically released to users.

This process eliminates the need for scheduled release days and accelerates the feedback loop.
Smaller, more frequent releases allow developers to get user feedback quickly and address issues
with more agility and accuracy.

Continuous deployment is a great goal for a DevOps team, but it is best applied after the DevOps
process has been ironed out. For continuous deployment to work well, organizations need to have
a rigorous and reliable automated testing environment. If you’re not there yet, starting with CI and
CD will help you get there.

Continuous Delivery:
Continuous delivery is an approach where teams release quality products frequently and
predictably from source code repository to production in an automated fashion.

Some organizations release products manually by handing them off from one team to the next,
which is illustrated in the diagram below. Typically, developers are at the left end of this
spectrum and operations personnel are at the receiving end. This creates delays at every hand-off
that leads to frustrated teams and dissatisfied customers. The product eventually goes live through
a tedious and error-prone process that delays revenue generation.

How does continuous delivery work?

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

A continuous delivery pipeline could have a manual gate right before production. A manual gate
requires human intervention, and there could be scenarios in your organization that require
manual gates in pipelines. Some manual gates might be questionable, whereas some could be
legitimate. One legitimate scenario allows the business team to make a last-minute release
decision. The engineering team keeps a shippable version of the product ready after every sprint,
and the business team makes the final call to release the product to all customers, or a cross-
section of the population, or perhaps to people who live in a certain geographical location.

The architecture of the product that flows through the pipeline is a key factor that determines the
anatomy of the continuous delivery pipeline. Highly coupled product architecture generates a
complicated graphical pipeline pattern where various pipelines could get entangled before
eventually making it to production.

The product architecture also influences the different phases of the pipeline and what artifacts are
produced in each phase. The pipeline first builds components - the smallest distributable and
testable units of the product. For example, a library built by the pipeline can be termed a
component. This is the component phase.

Loosely coupled components make up subsystems - the smallest deployable and runnable units.
For example, a server is a subsystem. A micro service running in a container is also an example of
a subsystem. This is the subsystem phase. As opposed to components, subsystems can be stood up
and tested.

The software delivery pipeline is a product in its own right and should be a priority for
businesses. Otherwise, you should not send revenue-generating products through it. Continuous
delivery adds value in three ways. It improves velocity, productivity, and sustainability of
software development teams.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Velocity:
Velocity means responsible speed and not suicidal speed. Pipelines are meant to ship quality
products to customers. Unless teams are disciplined, pipelines can shoot faulty code to
production, only faster! Automated software delivery pipelines help organizations respond to
market changes better.
Productivity:
A spike in productivity results when tedious tasks, like submitting a change request for every
change that goes to production, can be performed by pipelines instead of humans. This lets scrum
teams focus on products that wow the world, instead of draining their energy on logistics. And
that can make team members happier, more engaged in their work, and want to stay on the team
longer.
Sustainability
Sustainability is key for all businesses, not just tech. “Software is eating the world” is no longer
true — software has already consumed the world! Every company at the end of the day, whether
in healthcare, finance, retail, or some other domain, uses technology to differentiate and
outmaneuver their competition. Automation helps reduce/eliminate manual tasks that are error-
prone and repetitive, thus positioning the business to innovate better and faster to meet their
customers' needs.

Release Management:

Release management is the process of overseeing the planning, scheduling, and controlling of
software builds throughout each stage of development and across various environments. Release
management typically included the testing and deployment of software releases as well.

Release management is an important component of the DevOps process that focuses on planning,
scheduling, coordinating, and deploying software releases to production. It ensures that software
releases are delivered in a controlled and efficient manner, with minimal disruption to users or the
business.

In DevOps, release management typically involves automating the software release process as
much as possible, to reduce manual effort and increase the speed and accuracy of releases. This
PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

can involve using tools such as Continuous Integration/Continuous Delivery (CI/CD) pipelines,
version control systems, and deployment automation scripts.

Release management has had an important role in the software development lifecycle since before
it was known as release management. Deciding when and how to release updates was its own
unique problem even when software saw physical disc releases with updates occurring as seldom
as every few years.

The release management process in DevOps typically includes the following steps:

Planning and scheduling: The release schedule is planned and coordinated with stakeholders,
including development teams, testing teams, and business users.

Build and testing: The software is built and tested in a continuous integration environment to
ensure that it meets quality standards.

Staging and approval: The software is deployed to a staging environment for further testing and
validation, and is approved for release.

Deployment and monitoring: The software is deployed to the production environment, and is
closely monitored to ensure that it is functioning correctly and that any issues are quickly
identified and resolved.

Post-release review: A review of the release is conducted to identify any issues or areas for
improvement, and to incorporate feedback into future releases.

By using a structured and automated release management process, DevOps teams can achieve
faster and more reliable delivery of software releases while reducing the risk of errors or
downtime. This can lead to greater customer satisfaction, increased competitiveness, and
improved business outcomes.

Advantages of Release Management for DevOps:

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

With the transition to DevOps practices, deployment duties have shifted onto the shoulders of the
DevOps teams. This doesn’t remove the need for release management; instead, it modifies the
data points that matter most to the new role release management performs .

Release management acts as a method for filling the data gap in DevOps. The planning of
implementation and rollback safety nets is part of the DevOps world, but release management still
needs to keep tabs on applications, its components, and the promotion schedule as part of change
orders. The key to managing software releases in a way that keeps pace with DevOps deployment
schedules is through automated management tools.

Aligning business & IT goals

Release management provides a critical bridge between these two gaps in perspective. It
coordinates between IT work and business goals to maximize the success of each release. Release
management balances customer desires with development work to deliver the greatest value to
users.

Minimizes organizational risk

Release management minimizes the risk of failure by employing various strategies. Testing and
governance can catch critical faulty sections of code before they reach the customer. Deployment
plans ensure there are enough team members and resources to address any potential issues before
affecting users. All dependencies between the millions of interconnected parts are recognized and
understood.

Direct accelerating change

Release management is foundational to the discipline and skill of continuously producing

enterprise-quality software. The rate of software delivery continues to accelerate and is unlikely to
slow down anytime soon. The speed of changes makes release management more necessary than
ever.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Release management best practices

As DevOps increases and changes accelerate, it is critical to have best practices in place to ensure
that it moves as quickly as possible. Well-refined processes enable DevOps teams to more
effectively and efficiently. Some best practices to improve your processes include:

Define clear criteria for success:

Well-defined requirements in releases and testing will create more dependable releases. Everyone
should clearly understand when things are actually ready to ship.

Well-defined means that the criteria cannot be subjective. Any subjective criteria will keep you
from learning from mistakes and refining your release management process to identify what
works best. It also needs to be defined for every team member. Release managers, quality
supervisors, product vendors, and product owners must all have an agreed-upon set of criteria
before starting a project.

Minimize downtime:

DevOps is about creating an ideal customer experience. Likewise, the goal of release management
is to minimize the amount of disruption that customers feel with updates.

Strive to consistently reduce customer impact and downtime with active monitoring, proactive
testing, and real-time collaborative alerts that enable you to quickly notify you of issues during a
release. A good release manager will be able to identify any problems before the customer.

The team can resolve incidents quickly and experience a successful release when proactive efforts
are combined with a collaborative response plan.
Optimize your staging environment:
The staging environment requires constant upkeep. Maintaining an environment that is as close as
possible to your production one ensures smoother and more successful releases. From QA
to product owners, the whole team must maintain the staging environment by running tests and
combing through staging to find potential issues with deployment. Identifying problems in staging
before deploying to production is only possible with the right staging environment.
Maintaining a staging environment that is as close as possible to production will enable DevOps
teams to confirm that all releases will meet acceptance criteria more quickly.

Strive for immutable:

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Whenever possible, aim to create new updates as opposed to modifying new ones. Immutable
programming drives teams to build entirely new configurations instead of changing existing
structures.

Keep detailed records:

Good records management on any release/deployment artifacts is critical. From release notes to
binaries to compilation of known errors, records are vital for reproducing entire sets of assets. In
most cases, tacit knowledge is required.

Focus on the team:

Well-defined and implemented DevOps procedures will usually create a more effective release
management structure. They enable best practices for testing and cooperation during the complete
delivery lifecycle.

Scrum
Scrum is a framework used by teams to manage work and solve problems collaboratively in short
cycles. Scrum implements the principles of Agile as a concrete set of artifacts, practices, and
roles.

Scrum is an Agile framework for managing and completing complex projects, particularly in
software development. It emphasizes collaboration, flexibility, and iterative development, with a
focus on delivering value to the customer.

In Scrum, a team works in sprints of two to four weeks, during which time they plan, design,
develop, test, and deliver a potentially shippable product increment. The team meets regularly to
discuss progress, review work, and plan for the next sprint.

The Scrum lifecycle

The diagram below details the iterative Scrum lifecycle. The entire lifecycle is completed in fixed time
periods called sprints. A sprint is typically one-to-four weeks long

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Scrum roles:

There are three key roles in Scrum: the product owner, the Scrum master, and the Scrum team.

1) Product owner:

The product owner is responsible for what the team builds, and why they build it. The product
owner is responsible for keeping the backlog of work up to date and in priority order. Represents
the interests of the customer and is responsible for defining and prioritizing the product backlog.

2) Scrum master:

The Scrum master ensures that the Scrum process is followed by the team. Scrum masters are
continually on the lookout for how the team can improve, while also resolving impediments and
other blocking issues that arise during the sprint. Scrum masters are part coach, part team
member, and part cheerleader. Facilitates the Scrum process and helps the team to work
effectively and efficiently.

3) Scrum team (Development Team):

The members of the Scrum team actually build the product. The team owns the engineering of the
product, and the quality that goes with it. A self-organizing and cross-functional group of
individuals who deliver the product increment during each sprint.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Some key Scrum artifacts include:

Product backlog
The product backlog is a prioritized list of work the team can deliver. The product owner is
responsible for adding, changing, and reprioritizing the backlog as needed. The items at the top of
the backlog should always be ready for the team to execute on. A prioritized list of requirements for
the product.

Plan the sprint

In sprint planning, the team chooses backlog items to work on in the upcoming sprint. The team
chooses backlog items based on priority and what they believe they can complete in the sprint.
The sprint backlog is the list of items the team plans to deliver in the sprint. Often, each item on
the sprint backlog is broken down into tasks. Once all members agree the sprint backlog is
achievable, the sprint starts.

Execute the sprint

Once the sprint starts, the team executes on the sprint backlog. Scrum does not specify how the
team should execute. The team decides how to manage its own work.

Scrum defines a practice called a daily Scrum, often called the daily standup. The daily Scrum is a
daily meeting limited to fifteen minutes. Team members often stand during the meeting to ensure
it stays brief. Each team member briefly reports their progress since yesterday, the plans for
today, and anything impeding their progress.

To aid the daily Scrum, teams often review two artifacts:

Task board

The task board lists each backlog item the team is working on, broken down into the tasks
required to complete it. Tasks are placed in To do, In progress, and Done columns based on their
status. The board provides a visual way to track the progress of each backlog item.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Sprint burndown chart

The sprint burndown is a graph that plots the daily total of remaining work, typically shown in
hours. The burndown chart provides a visual way of showing whether the team is on track to
complete all the work by the end of the sprint.

Sprint review and sprint retrospective

At the end of the sprint, the team performs two practices:

Sprint review

The team demonstrates what they've accomplished to stakeholders. They demo the software and
show its value.

Sprint retrospective

The team takes time to reflect on what went well and which areas need improvement. The
outcome of the retrospective are actions for the next sprint.

Increment

The product of a sprint is called the increment or potentially shippable increment. Regardless of
the term, a sprint's output should be of shippable quality, even if it's part of something bigger and
can't ship by itself. It should meet all the quality criteria set by the team and product owner.

Repeat, learn, improve

The entire cycle is repeated for the next sprint. Sprint planning selects the next items on the
product backlog and the cycle repeats. While the team executes the sprint, the product owner
ensures the items at the top of the backlog are ready to execute in the following sprint.

This shorter, iterative cycle provides the team with lots of opportunities to learn and improve. A
traditional project often has a long lifecycle, say 6-12 months. While a team can learn from a
traditional project, the opportunities are far less than a team who executes in two-week sprints, for
example.

This iterative cycle is, in many ways, the essence of Agile.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Scrum is very popular because it provides just enough framework to guide teams while giving
them flexibility in how they execute. Its concepts are simple and easy to learn. Teams can get
started quickly and learn as they go. All of this makes Scrum a great choice for teams just starting
to implement Agile principles.

Scrum emphasizes transparency, inspection, and adaptation. The team regularly inspects and
adapts its process and progress, based on feedback and data from previous sprints. Scrum is
widely used in software development, but it can be applied to a wide range of complex projects.
Scrum is designed to be flexible and adaptable, allowing teams to tailor the process to their
specific needs and context.

Kanban
Kanban is a Japanese term that means signboard or billboard. An industrial engineer named
Taiichi Ohno developed Kanban at Toyota Motor Corporation to improve manufacturing
efficiency.

Although Kanban was created for manufacturing, software development shares many of the same
goals, such as increasing flow and throughput. Software development teams can improve their
efficiency and deliver value to users faster by using Kanban guiding principles and methods.

Kanban is an Agile methodology that focuses on visualizing work, limiting work in progress, and
maximizing efficiency and flow. It originated in the manufacturing industry and has since been
adapted for use in software development, project management, and other areas.

In Kanban, work is visualized on a board, typically with columns that represent the various stages
of work, such as "To Do," "In Progress," and "Done." Each piece of work is represented by a card
or sticky note that moves across the board as it progresses through the stages.

Some key principles of Kanban include:

1) Visualize work: Make the work visible by using a board or other visual tool. Visualization of
work is a key principle that Kanban addresses primarily through Kanban boards. These boards use
cards organized by progress to communicate overall status. Visualizing work as cards in different
states on a board helps to easily see the big picture of where a project currently stands, as well as
identify potential bottlenecks that could affect productivity.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

2) Use a pull model: Historically, stakeholders requested functionality by pushing work onto
development teams, often with tight deadlines. Quality suffered if teams had to take shortcuts to
deliver the functionality within the timeframe.

Kanban focuses on maintaining an agreed-upon level of quality that must be met before
considering work done. To support this model, stakeholders don't push work on teams that are
already working at capacity. Instead, stakeholders add requests to a backlog that a team pulls into
their workflow as capacity becomes available.

3. Limit work in progress: Set limits on the amount of work that can be in progress at any one
time to avoid overloading the team. Teams that try to work on too many things at once can suffer
from reduced productivity due to frequent and costly context switching. The team is busy, but
work doesn't get done, resulting in unacceptably high lead times. Limiting the number of backlog
items a team can work on at a time helps increase focus while reducing context switching. The
items the team is currently working on are called work in progress (WIP).

Teams decide on a WIP limit, or maximum number of items they can work on at one time. A
well-disciplined team makes sure not to exceed their WIP limit. If teams exceed their WIP limits,
they investigate the reason and work to address the root cause.

4. Manage flow: Monitor and improve the flow of work across the board to optimize efficiency
and minimize waste.

5. Make process policies explicit: Define the policies and rules that govern the flow of work, and
make them explicit to the team.

6. Continuously improve: Regularly review and improve the process to optimize efficiency and
flow. To practice continuous improvement, development teams need a way to measure
effectiveness and throughput. Kanban boards provide a dynamic view of the states of work in a
workflow, so teams can experiment with processes and more easily evaluate impact on
workflows. Teams that embrace Kanban for continuous improvement use measurements like lead
time and cycle time.

Kanban is designed to be flexible and adaptable, allowing teams to tailor the process to their
specific needs and context. It emphasizes continuous improvement and encourages teams to
experiment and evolve their process over time.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Kanban is often used in conjunction with other Agile methodologies, such as Scrum, to provide
additional benefits such as improved visibility and efficiency.

Kanban boards

The Kanban board is one of the tools teams use to implement Kanban practices. A Kanban board
can be a physical board or a software application that shows cards arranged into columns. Typical
column names are To-do, Doing, and Done, but teams can customize the names to match their
workflow states. For example, a team might prefer to use New, Development, Testing, UAT,
and Done.

Software development-based Kanban boards display cards that correspond to product backlog
items. The cards include links to other items, such as tasks and test cases. Teams can customize
the cards to include information relevant to their process.

On a Kanban board, the WIP limit applies to all in-progress columns. WIP limits don't apply to
the first and last columns, because those columns represent work that hasn't started or is
completed. Kanban boards help teams stay within WIP limits by drawing attention to columns
that exceed the limits. Teams can then determine a course of action to remove the bottleneck.

Cumulative flow diagrams

A common addition to software development-based Kanban boards is a chart called a cumulative

flow diagram (CFD). The CFD illustrates the number of items in each state over time, typically
across several weeks. The horizontal axis shows the timeline, while the vertical axis shows the
number of product backlog items. Colored areas indicate the states or columns the cards are
currently in.

The CFD is particularly useful for identifying trends over time, including bottlenecks and other
disruptions to progress velocity. A good CFD shows a consistent upward trend while a team is
working on a project. The colored areas across the chart should be roughly parallel if the team is
working within their WIP limits.

A bulge in one or more of the colored areas usually indicates a bottleneck or impediment in the
team's flow. In the following CFD, the completed work in green is flat, while the testing state in
blue is growing, probably due to a bottleneck.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Kanban and Scrum in Agile development

While broadly fitting under the umbrella of Agile development, Scrum and Kanban are quite
different.

● Scrum focuses on fixed length sprints, while Kanban is a continuous flow model.
● Scrum has defined roles, while Kanban doesn't define any team roles.
● Scrum uses velocity as a key metric, while Kanban uses cycle time.

Teams commonly adopt aspects of both Scrum and Kanban to help them work most effectively.
Regardless of which characteristics they choose, teams can always review and adapt until they
find the best fit. Teams should start simple and not lose sight of the importance of delivering
value regularly to users.

Kanban with GitHub

GitHub offers a Kanban experience through project boards (classic). These boards help
you organize and prioritize work for specific feature development, comprehensive roadmaps, or
release checklists. You can automate project boards (classic) to sync card status with associated
issues and pull requests.

Kanban with Azure Boards

Azure Boards provides a comprehensive Kanban solution for DevOps planning. Azure Boards has
deep integration across Azure DevOps, and can also be part of Azure Boards-GitHub integration.

● For more information, see Reasons to use Azure Boards to plan and track your work.
● The Learn module Choose an Agile approach to software development provides hands-on Kanban
experience in Azure Boards.

Delivery Pipeline:

A DevOps pipeline is a set of automated processes and tools that allows both developers and
operations professionals to work cohesively to build and deploy code to a production
environment.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

In DevOps, a delivery pipeline is a process that enables the continuous delivery of software
applications, from development to production. The pipeline is a series of stages or steps that
automate the build, test, and deployment of software, as well as any necessary quality checks and
security scans.

Components of a DevOps pipeline:

Continuous integration/continuous delivery/deployment (CI/CD):

Continuous integration is the practice of making frequent commits to a common source code
repository. It’s continuously integrating code changes into existing code base so that any conflicts
between different developer’s code changes are quickly identified and relatively easy to
remediate. This practice is critically important to increasing deployment efficiency.
We believe that trunk-based development is a requirement of continuous integration. If you are
not making frequent commits to a common branch in a shared source code repository, you are not
doing continuous integration. If your build and test processes are automated but your developers
are working on isolated, long-living feature branches that are infrequently integrated into a shared
branch, you are also not doing continuous integration.

Continuous delivery ensures that the “main” or “trunk” branch of an application's source code is
always in a releasable state. In other words, if management came to your desk at 4:30 PM on a
Friday and said, “We need the latest version released right now,” that version could be deployed
with the push of a button and without fear of failure.
This means having a pre-production environment that is as close to identical to the production
environment as possible and ensuring that automated tests are executed, so that every variable that
might cause a failure is identified before code is merged into the main or trunk branch.

Continuous deployment entails having a level of continuous testing and operations that is so
robust, new versions of software are validated and deployed into a production environment
without requiring any human intervention.
This is rare and in most cases unnecessary. It is typically only the unicorn businesses who have
hundreds or thousands of developers and have many releases each day that require, or even want
to have, this level of automation.

To simplify the difference between continuous delivery and continuous deployment, think of
delivery as the FedEx person handing you a box, and deployment as you opening that box and
using what’s inside. If a change to the product is required between the time you receive the box
and when you open it, the manufacturer is in trouble!

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Continuous feedback: The single biggest pain point of the old waterfall method of software
development — and consequently why agile methodologies were designed — was the lack of timely
feedback. When new features took months or years to go from idea to implementation, it was almost
guaranteed that the end result would be something other than what the customer expected or wanted. Agile
succeeded in ensuring that developers received faster feedback from stakeholders. Now with DevOps,
developers receive continuous feedback not not only from stakeholders, but from systematic testing and
monitoring of their code in the pipeline.
Continuous testing is a critical component of every DevOps pipeline and one of the primary
enablers of continuous feedback. In a DevOps process, changes move continuously from
development to testing to deployment, which leads not only to faster releases, but a higher quality
product. This means having automated tests throughout your pipeline, including unit tests that run
on every build change, smoke tests, functional tests, and end-to-end tests.
Continuous monitoring is another important component of continuous feedback. A DevOps
approach entails using continuous monitoring in the staging, testing, and even development
environments. It is sometimes useful to monitor pre-production environments for anomalous
behavior, but in general this is an approach used to continuously assess the health and
performance of applications in production.
Numerous tools and services exist to provide this functionality, and this may involve anything
from monitoring your on-premise or cloud infrastructure such as server resources, networking,
etc. or the performance of your application or its API interfaces.

Continuous operations is a relatively new and less common term, and definitions vary. One way
to interpret it is as “continuous uptime”. For example in the case of a blue/green deployment
strategy in which you have two separate production environments, one that is “blue” (publicly
accessible) and one that is “green” (not publicly accessible). In this situation, new code would be
deployed to the green environment, and when it was confirmed to be functional then a switch
would be flipped (usually on a load-balancer) and traffic would switch from the “blue” system to
the “green” system. The result is no downtime for the end-users.
Another way to think of Continuous operations is as continuous alerting. This is the notion that
engineering staff is on-call and notified if any performance anomalies in the application or
infrastructure occur. In most cases, continuous alerting goes hand in hand with continuous
monitoring.

One of the main goals of DevOps is to improve the overall workflow in the software development
life cycle (SDLC). The flow of work is often described as WIP or work in progress. Improving
WIP can be accomplished by a variety of means. In order to effectively remove bottlenecks that
decrease the flow of WIP, one must first analyze the people, process, and technology aspects of
the entire SDLC.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

The delivery pipeline begins with the development of code and moves through various stages
until it reaches the production environment. The pipeline typically includes the following stages:

1. Code building: Developers create and modify code, which is then compiled into an executable
format. 2. Code testing: Automated testing is performed on the code to ensure that it meets the
required quality standards.
3. Code analysis: Static code analysis tools scan the code for security vulnerabilities, coding
errors, and other issues.

4. Artifact creation: The compiled code and any other required artifacts, such as configuration
files and dependencies, are packaged into an artifact for deployment.
5. Deployment: The artifact is deployed to the target environment, either manually or through
automation.
6. Testing in the target environment: Automated testing is performed in the target environment
to ensure that the application works as expected.

7. Monitoring: The application is monitored in the target environment to ensure that it performs
correctly and to detect any issues that may arise.
The delivery pipeline is often implemented using a continuous integration and continuous
delivery (CI/CD) platform, which automates the entire process and enables developers to focus on
coding and innovation rather than on managing infrastructure and deployments.

BottleNecks
DevOps is a philosophy that emphasizes collaboration, automation, and continuous
improvement, with the goal of delivering software applications faster, more reliably, and with
higher quality. However, like any process, there can be bottlenecks in the DevOps pipeline that
slow down the delivery of software. Here are some common bottlenecks in DevOps:

1. Manual processes: Manual processes, such as code reviews, testing, and deployments, can be
time-consuming and error-prone, which can slow down the DevOps pipeline.
2. Lack of automation: A lack of automation can lead to delays in the pipeline, especially in
areas such as testing and deployment.

3. Resource constraints: Limited resources, such as hardware or staffing, can create bottlenecks
in the DevOps pipeline.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

4. Poor communication: Communication breakdowns between team members, such as

developers, testers, and operations staff, can slow down the pipeline and result in errors.

5. Poorly designed systems: Complex or poorly designed systems can create bottlenecks in the
pipeline, especially if they are difficult to deploy or test.
6. Inadequate tooling: Inadequate or outdated tooling can slow down the pipeline and create
inefficiencies.

To address these bottlenecks, organizations can implement various strategies, such as increasing
automation, improving communication, redesigning systems, and investing in better tooling.
DevOps teams can also conduct regular retrospectives and identify areas for improvement, as well
as monitor and measure key metrics, such as cycle time, lead time, and deployment frequency, to
identify bottlenecks and optimize the pipeline.

Lead Time Lead time is a key metric used in DevOps to measure the time it takes to deliver a
feature or a change from the point it is requested to the point it is available to the end-user. This
metric is also sometimes referred to as "cycle time," "development lead time," or "time-to-
market."
Lead time includes all the steps involved in the delivery process, such as requirements gathering,
development, testing, deployment, and release. By measuring lead time, DevOps teams can gain
insight into how long it takes to deliver new features and identify areas for improvement.
Lead time is typically measured in days or weeks, and it includes the following stages:

1. Ideation: The initial idea or request for a new feature or change.

2. Planning: The feature is planned and added to the development backlog.

3. Development: The feature is developed, which may include coding, testing, and integration
with other systems.
4. Testing: The feature is tested to ensure that it works as expected and meets the required quality
standards.

5. Deployment: The feature is deployed to the production environment, which may include
testing in the production environment.
6. Release: The feature is released to the end-users, who can start using it.

By measuring lead time, DevOps teams can identify bottlenecks and inefficiencies in the delivery
process and work to improve them. This can help organizations deliver features faster, with
higher quality, and at a lower cost.

Examples:
PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

DevOps is a philosophy that emphasizes collaboration, automation, and continuous improvement

in software development and delivery. Here are some examples of DevOps in practice:

1. Continuous integration and continuous delivery (CI/CD): CI/CD is a DevOps practice that
involves automating the building, testing, and deployment of software applications. This approach
helps teams to identify and fix issues quickly, resulting in faster and more frequent releases.

2. Infrastructure as code (IaC): IaC is a practice that involves managing infrastructure

resources, such as servers, networks, and storage, using code. This approach enables teams to
automate the provisioning and management of infrastructure, which can reduce errors and
improve consistency.

3. Monitoring and logging: DevOps teams use monitoring and logging tools to track the
performance of applications and infrastructure. This enables them to identify issues and improve
the reliability of applications.

4. Agile development: Agile development is a software development methodology that

emphasizes collaboration, flexibility, and continuous improvement. DevOps teams often use agile
practices, such as sprints and standup meetings, to manage their work and deliver software
quickly.

5. ChatOps: ChatOps is a practice that involves using chat tools, such as Slack or Microsoft
Teams, to automate and streamline communication between teams. This approach enables teams
to collaborate more effectively and reduces the need for time-consuming meetings and emails.

6. Shift-left testing: Shift-left testing is a practice that involves testing applications earlier in the
development process. This approach helps to identify and fix issues more quickly, which can
reduce costs and improve the quality of applications.

These are just a few examples of DevOps practices. DevOps is a flexible approach that can be
customized to meet the needs of different organizations and teams.

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.
 DEVOPS MATERIAL (UNIT -1)

Sample questions : UNIT –I:

Introduction, Agile development model, DevOps, and ITIL. DevOps process and Continuous
Delivery, Release management, Scrum, Kanban, delivery pipeline, bottlenecks, examples.

PART A:
1) Explain briefly about Sdlc?
2) What is waterfall model?
3) What is agile model?
4) Why Devops ?
5) What is Devops?
6) What is ITIL?
7) What is continuous development?
8) What is continuous Integration?
9) What is continuous Testing?
10) What is continuous delivery?
11) What is continuous deployment?
12) What is Scrum?
13) What is Kanban?
14) What is bottleneck?
PART B:
1) What is the difference between agile and Devops?
2) What are the differences between agile and waterfall model?
3) What is ITIL? Explan about its service life cycle?
4) Explain DevOps process flow in detail?
5) What is continuous delivery and how it works?
6) Explain components of delivery pipeline?

PREPARED BY
G.SATISH KUMAR (M.Tech)
VEC-KHAMMAM.