UNIT-I

HISTORY
What is Software: Software is a set of instructions that tell a computer what to do. It’s created using
code written by developers. It is independent of hardware and makes computers programmable. Software
development refers to a set of computer science activities dedicated to the process of creating, designing,
deploying and supporting software.
Types of Software:
• System Software: Operating systems (Windows, Linux).
• Application Software: WhatsApp, YouTube, MS Word.
• Web Software: Flipkart, Gmail, Netflix.
Real-Life Example: When you order from Swiggy:
• UI shows restaurants
• Backend places your order
• Database stores order details
• Server notifies restaurant
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.
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.
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.

1
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. During this stage,
unit testing, integration testing, system testing, acceptance testing is 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.
What are the Software Development Models?
The software development models are the various processes or methodologies that are being selected for
the development of the project depending on the project's aims and goals. There are many development
life cycle models that have been developed in order to achieve different required objectives. The models
specify the various stages of the process and the order in which they are carried out.
There are various Software development models or methodologies. They are as follows:
1. Waterfall model
2. Spiral model
3. V model
4. RAD (Rapid Application Development) model
5. Iterative model
6. Incremental model
7. Prototype model
8. Agile model
Choosing right model for developing of the software product or application is very important. Based on
the model the development and testing processes are carried out. Different companies based on the
software application or product, they select the type of development model whichever suits to their
application.
WATERFALL MODEL
Winston Royce introduced the Waterfall Model in 1970. It is also called as Linear Sequential Model.
The Waterfall model is the oldest and most straightforward model. It follows a step-by-step process
where each phase must be completed before moving to the next one. You cannot go back to change or
fix something in a previous phase.
2
This model has six phases: Requirements analysis, design, implementation, testing, deployment 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.

• Requirement analysis: All possible requirements of the system to be developed are captured in
this phase and documented in a requirement specification document.
• System Design: The requirement specifications from first phase are studied in this phase and the
system design is prepared. This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture.
• Implementation: With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and tested
for its functionality, which is referred to as Unit Testing.
• Integration and Testing: All the units developed in the implementation phase are integrated into
a system after testing of each unit. Post integration the entire system is tested for any faults and
failures.
• Deployment of system: Once the functional and non-functional testing is done; the product is
deployed in the customer environment or released into the market.
• Maintenance: There are some issues which come up in the client environment. To fix those
issues, patches are released. Also, to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
Advantages of Waterfall model
✓ simple to understand and easy to follow.
✓ As it's a top-down approach process, overlapping of the phases is avoided.
✓ Well-documented process.
✓ Works well when requirements are fixed and well understood.
✓ Easy testing and analysis.
✓ Suitable for small-projects
Disadvantages of Waterfall model
✓ No flexibility, you can’t revisit earlier stages.
✓ Late testing, means bugs are found at the end, which is costly to fix.
✓ Not suitable for complex or dynamic projects where requirements change.
✓ The end product is only available at the end of the cycle
3
To summarize, the Waterfall model was only acceptable for projects with stable specifications. By stable,
I mean that over time, requirements will not change. But this is an improbable thing in today's world, as
specifications keep changing from time to time.
SPIRAL MODEL
The Spiral Model is a unique process model in software engineering that combines the iterative nature
of prototyping with the systematic aspects of the Waterfall model. Introduced by Dr. Barry Boehm in
1986, it integrates the iterative nature of software construction with a focus on continuous risk
assessment. This model is ideal for projects where requirements may evolve over time, allowing teams
to adapt and refine their products throughout the development process. The most important feature of
the model is that once the project starts, it has the ability to manage unknown risks.

The Spiral Model is structured around four primary phases:

1. Determine Objectives (Planning Phase): This phase includes requirement gathering and
analysis. Based on the requirements, objectives are defined and different alternate solutions are
proposed. This initial phase focuses on establishing the goals for the current iteration.
2. Identify and resolve risks (Risk Analysis Phase): In this quadrant, all the proposed solutions
are analyzed and any potential risk is identified, analyzed, and resolved. Risks can be assessed
using quantitative and qualitative techniques, allowing teams to prioritize which risks need
addressing. Additionally, alternative solutions are identified in case there is a failure in the
attempted version.
3. Development and Test: Once risks have been analyzed and strategies in place, the development
phase begins. This phase includes the actual implementation of the different features. All the
implemented features are then verified with thorough testing. The actual coding, integration, and
testing take place here.
4. plan of the next iteration: Once the evaluation of the current iteration is complete, the team
prepares for the subsequent spiral. In this phase, the software is evaluated by the customer. It also
includes risk identification and monitoring like cost overrun or schedule slippage and after that
planning of the next phase is started.
4
Advantages of Spiral model:
• Risk Management-Continuous risk assessment throughout the development process allows
teams to address potential challenges before they escalate into critical issues.
• Flexibility-The model's inherent iterative nature supports modifications and enhancements at
every stage of development, facilitating an adaptive approach.
• Customer Involvement-Regular feedback loops with stakeholders ensure that the final software
product meets client expectations and needs effectively.
• Improved Quality-The iterative cycle promotes continuous refinement, leading to a higher-
quality output through regular inspections and adaptations.
• Early Error Detection-The model emphasizes early testing, which enhances the ability to
identify and resolve problems proactively.
Disadvantages of the Spiral Model:
• Cost: The continuous risk analysis and iterative development can make the Spiral model more
expensive than other SDLC methodologies.
• Time-Consuming: The model's cyclic nature can prolong the development process.
• Complexity: The Spiral model can be challenging to manage, especially for smaller teams or
projects with well-defined requirements.
• Lack of Documentation: The focus on iterative development may lead to inadequate
documentation.
V MODEL
V Model stands for Verification and Validation Model. Though inspired by the Waterfall model, where
the testing is done at the end of the project, it differs in that it introduces testing at every stage of
development.

Similar to the Waterfall model, each next stage of the V model begins only when the previous one has
been completed.
Advantages of V model:
• Ability to avoid the downward flow of defects
• An apt fit for small projects with easily understandable requirements
• Higher chances of success
• Offers ease and simplicity
• Proactive tracking of potential defects

5
 • Saves a lot of time as planning and designing related to testing is done before the actual coding
takes place
Disadvantages of V model:
• Even more rigid than the Waterfall model
• No early prototype creation is possible as the software is developed during the implementation
phase
• Requirement and test documents need to be updated if changes are made during the development
PROBLEMS WITH TRADITIONAL MODELS:
1. Developers and Operations Teams are Separate
✓ In traditional models like Waterfall, the development team (who writes the code) and the
operations team (who deploys and manages it) work in isolation.
✓ Developers finish the code and then “throw it over the wall” to the Ops team for
deployment.
2. Code Works on Developer Machine but Fails in Production
✓ Developers build software in their own local environments.
✓ But the production environment (where real users access the software) can be very
different—different OS, settings, versions of libraries, etc.
3. Time-consuming for Manual Testing and Deployment
✓ In traditional models, testing is done manually, often by QA teams after all development
is completed.
✓ Deployment is also manual, involving human steps like uploading files, configuring
servers, restarting services.
4. No Feedback from Users Until Late
✓ In models like Waterfall, the software is shown to the user only at the end—after months
of work.
✓ If something is wrong, it’s too late or expensive to fix.
5. Hard to Respond Quickly to Bugs or Feature Requests
✓ Traditional models require formal change requests and approvals.
✓ Any bug fix or new feature might need to go through a long cycle again:
plan → design → test → deploy.

6
1.1 INTRODUCTION
The word "DevOps" is a combination of the word’s “Development” and “Operations”. DevOps is not
a tool or technology or framework. DevOps is a culture or process or methodology, that implements the
technology in order to promote collaboration between the developer team and the operations team to
deploy code to production faster in an automated and repeatable way. DevOps helps to develop, release
and maintain software Products or projects or applications with higher quality in very faster time.

• Development team involves in planning, designing, coding, testing and building. Examples are
Business analyst (BA), System analyst (SA), Design Architect, developers, QA Engineer
(Quality Assurance), Build Engineer.
• Operations team involves in Release, Deployment, Operations and Monitoring. Examples are
Release Engineer, Configure Engineer, System admin, Network admin and Database admin.
• DevOps is the next generation of Agile. In simple it is a set of processes and tools that helps Dev
and Ops teams work faster.
• Our traditional IT had two separate teams in a organization the Development team and the
Operations team. The development team worked on the software, developing it and making sure
that the code worked perfectly, the team releases software to Operations team. The operations
team will be checking the application and its performance and reporting back any bugs, if present.
• The two major teams always had a conflict when it came to execution. To bridge this gap, we
need DevOps. DevOps is a collaboration between Development and IT Operations to make
software production and Deployment in an automated & repeatable way.
• In simple words, DevOps can be defined as an alignment of development and IT operations with
better communication and collaboration.
• DevOps helps to increase the organization's speed, deliver software applications and services.
• Let's make it clear that DevOps is not a technology, tool or any innovative framework. It is more
of a Philosophy and concept. We can also consider it as a culture of an organization where
application lifecycle management is in the center of focus.
• The logo of DevOps is ∞

DevOps life cycle

• The goal of DevOps is to increase an organization’s speed when it comes to delivering
applications and services. Many companies have successfully implemented DevOps to enhance
their user experience including Amazon, Netflix, etc.
7
 • Another core goal of DevOps is automation and Continuous Delivery. Simply, automating
repetitive and tedious tasks leaves more time for human interaction, where true value can be
created.
Where DevOps can help in:
• Increased business agility.
• Reduced time to market cycle.
• Reduced cost of quality and Increased quality and confidence in code.
• Increased Productivity and customer satisfaction
• Reduced cost.
Why DevOps:
Before going further, we need to understand why we need the DevOps over the other methods.
• The development and operation team worked in complete isolation.
• After the design-build, the testing and deployment are performed respectively. That's why they
consumed more time than actual build cycles.
• 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.
• Manual code deployment leads to human errors in production.
• Coding and operation teams have their separate timelines and are not in synch, causing further
delays.
History of DevOps:
• The DevOps movement was originated from the ideas of Agile software development. A group
of individuals have proposed the Agile Manifesto in 2001 to enhance the present state of the
system development. They also suggested ways to discover innovated approaches in the software
development sector. A selected passage from the Agile Manifesto, a well-known and influential
document is given below that can be found on the website, http://agilemanifesto.org/:
• In 2009, the first conference named DevOpsdays was held in Ghent, Belgium. Belgian
consultant and Patrick Debois founded the conference. The term "DevOps Days" was commonly
shortened to "DevOps" in discussions across Twitter and other online forums.
• In 2012, the state of DevOps report was launched and conceived by Alanna Brown at Puppet.
• 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.
• In 2015, Nicole Forsgren, Gene Kim, and Jez Humble founded DORA (DevOps Research and
Assignment).
• In 2017, Nicole Forsgren, Gene Kim, and Jez Humble published "Accelerate: Building and
Scaling High Performing Technology Organizations".
Turnaround Time of DevOps (How fast is fast):
DevOps processes require a quick turnaround. In order to manage this, time must be considered in
broader perspective while tasks considered in smaller perspective. Such context is also considered as
belief of Continuous Delivery Movement.
There exist many principles in DevOps and Continuous Delivery that actually serve as substitute for
some fundamental ideas but with different names. It seems that there is no difference or conflict between
the two ideas. They can be considered as two different aspects of the same thing. DevOps engineers

8
concentrate on streamlining business workflows to enhance speed, efficiency, and reliability. Moreover,
at possible times, frequent manual work is eliminated.
It is quite simple, but people may get distracted with respect to their objectives while managing DevOps
implementations. Dealing with activities that yield no productive outcome at a greater speed has no
benefit for individuals. However, it is essential to continuously monitor and ensure the delivery of the
improved commercial value. For example, improved interaction among various job roles within the
organization is highly valuable. The owners of a specific product are probably interested in knowing
about the development process. Allowing this will help in rapid and efficient delivery of code
advancements in testing. Within the test environments, important people associated with the project,
including product owners and quality assurance teams, can further monitor the advancements in
development process.
DevOps Tools:

DevOps life cycle and tools used by Dev and Ops teams.
Tools Used by Dev Team are:
• Jira: This Software provides planning and roadmap tools so teams can manage stakeholders,
budgets, and feature requirements from day one.
• Git: It is a distributed version control system that tracks changes in any set of computer files,
usually used for coordinating work among programmers collaboratively developing source code
during software development.
• Eclipse: It is a free, Java-based development platform known for its plugins that allow developers
to develop and test code written in other programming languages.
• Maven: This is open-source tool from Apache automates the build process and resolution of
dependencies and is used primarily for Java projects.
• Ant: Ant (Another Neat Tool) is a Java library and a software tool used for automate software
build processes such as compile, run, test and assemble Java application. It is designed and
developed by Apache Software Foundation.
• Gradle: Gradle is a build automation tool known for its flexibility to build software. A build
automation tool is used to automate the creation of applications. The building process includes
compiling, linking, and packaging the code. The process becomes more consistent with the help
of build automation tools.
• Selenium: This open-source tool for automating tests for web applications is used by Google,
IBM, and other big-name companies. It's used only for web applications not desktop or mobile
ones.
• JUnit: It is a unit testing open-source framework for the Java programming language. Java
Developers use this framework to write and execute automated tests.
9
Tools Used by Ops Team are:
• Puppet: It lets you manage and automate software inspection, delivery, and operation. This open-
source tool has a solid track record and thousands of modules and is easily integrated with many
other platforms.
• Chef: This is powerful open-source configuration management tool lets you turn infrastructure
into a code to manage data, attributes, roles, environments, and more.
• Docker: It is a Linux-based open-source platform that focuses on containers, meaning you
package up the software with its dependencies and ship everything together as a unit-no need to
worry about managing dependencies separately.
• Ansible: This is open-source tool for automating software provisioning, configuration
management, and application deployment is easy to use, Plus, it's agentless and uses a simple
syntax written in the YAML language
• Nagios: Its Used to find and correct problems in networks and infrastructure, Nagios is one of
the most popular free and open-source monitoring tools.
• Kubernetes: A relatively new container orchestration platform lets you manage hundreds of
containers.
• Jenkins: It's a CICD tool, It is known for quickly finding issues in code. It's a free, open-source
tool used for automating the delivery pipeline, and lets you test and report changes almost in real-
time.

• Bamboo: It is a continuous integration and deployment tool that ties automated builds, tests and
releases together in a single workflow.
• Sensu: Sensu is one of the top DevOps monitoring tools, it is used for monitoring infrastructure
and applications solutions.
• SaltStack: It is also known as Salt, is a configuration management and orchestration tool. It uses
a central repository to provision new servers and other IT infrastructure, to make changes to
existing ones, and to install software in IT environments, including physical and virtual servers,
as well as the cloud.
• Splunk: It is a popular application monitoring tool to gain real-time visibility into DevOps-
driven application delivery for Continuous Delivery or Continuous Integration to move from
concept to production quickly.
Advantages of DevOps:
The following are the advantages of DevOps
• Faster delivery of software: DevOps teams work together to deliver software more quickly,
using automation and streamlined processes to speed up the development, testing, and
deployment of software.
10
 • Increased agility: DevOps teams are able to respond more quickly to changing market
conditions and customer needs, allowing companies to stay ahead of their competition.
• Improved quality: By integrating testing and quality assurance into the development process,
DevOps teams are able to catch and fix bugs and issues more quickly, resulting in higher quality
software.
• Better collaboration: DevOps teams work together more closely, breaking down silos and
improving communication and collaboration between developers, operations, and other
stakeholders.
• Increased efficiency: By automating manual processes and reducing waste, DevOps teams are
able to work more efficiently and reduce costs.
• Better customer experience: By delivering software more quickly and with higher quality,
DevOps teams are able to improve the customer experience and increase customer satisfaction.
Overall, DevOps can help organizations achieve faster time-to-market, higher quality software,
improved collaboration, and increased efficiency, all of which can contribute to a competitive advantage
in today's fast-paced business environment.
DevOps goals and benefits:
When a team adopts DevOps culture, practices, and tools, they can achieve amazing things:
• Accelerate time to market: Through increased efficiencies, improved team collaboration,
automation tools, and continuous deployment--teams are able to rapidly reduce the time from
product inception to market launch.
• Adapt to the market and competition: A DevOps culture demands teams have a customer-first
focus. By marrying agility, team collaboration, and focus on the customer experience, teams can
continuously deliver value to their customers and increase their competitiveness in the
marketplace.
• Maintain system stability and reliability: By adopting continuous improvement practices,
teams are able to build in increased stability and reliability of the products and services they
deploy. These practices help reduce failures and risk.
• Improve the mean time to recovery: The mean time to recovery metric indicates how long it
takes to recover from a failure or breach. To manage software failures, security breaches, and
continuous improvement plans, teams should measure and work to improve this metric.

1.2 AGILE DEVELOPMENT MODEL

• The meaning of Agile is swift or versatile or speed. Agile model is an iterative model where total
software/project is developed increment by increment.
• Each increment is called “sprint”. Agile methods break tasks into smaller iterations, or parts do
not directly involve long term planning. Each iteration is considered as a short time "frame" in
the Agile process model, which typically takes from 1 to 4 weeks.
• The division of the entire project into smaller parts helps to minimize the project risk and to
reduce the overall project delivery time requirements.
• Each iteration involves a team working through a full software development life cycle including
planning, requirements analysis, design, coding, and testing before a working product is
demonstrated to the client.

11
 • 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.
Phases of Agile Model:

Agile Methodology
• Requirements Gathering-Here is where you define the project’s requirements. This phase
includes explaining business opportunities and planning the time and effort required for the
project. Once you quantify this information, you can evaluate the technical and economic
feasibility of your project
• Design the Requirements- Once you’ve identified the project parameters, work with the
stakeholders to define the requirements.
• Development/Iteration-After the team defines and designs the requirements, the real work
begins. Product, design, and developer teams start working on related projects, ultimately
deploying a product or service that is not static.
• Testing- The quality assurance (QA) team examines and evaluates the product's performance,
looking for bugs and other flaws.
• Deployment- The team deploys the product in a working environment.
• Feedback- Once the product is released, the team receives feedback about the product and
handles any issues that may have arisen.
Advantages of Agile Model: The following are the advantages of Agile model
• Customer satisfaction is high, continuous development and delivery of useful software.
• Customer, Developer and Product Owner interact regularly to emphasize rather than processes
and tools.
12
 • Product is developed fast and frequently delivered.
• A face-to-face conversation is the best form of communication.
• It continuously gave attention to technical excellence and good design.
• Regular adaption to changing circumstances
• Even late change in requirements are welcomed.
Disadvantages of Agile methodology: The following are the disadvantages of Agile Model
• it is not useful for small development projects.
• There is a lack of intensity on necessary designing and documentation.
• It requires on expert project members to take crucial decisions in the meeting.
• Cost of Agile development methodology is slightly mere as compared to other development
methodology
• The project can quickly go out off-track if the project manager is not clear about requirements.
Examples of Agile Development Methods: The following are the Agile Development Methods
• Scrum
• Crystal
• Dynamic Software Development Method (DSDM)
• Feature Driven Development (FDD)
• Lean Software Development (LSD)
• eXtreme Programming (XP)
Agile Wheel of Wheels (Cycles in Agile Development Model):
Agile development encompasses several different cycles, from the Portfolio level through to the Scrum,
Kanban cycles and down to the Continuous Integration cycle.
The focus of cyclic activity varies based on the specific Agile methodology being used.
• Kanban which is often used in operations team, emphasizes the 24-hour time frame.
• Scrum cycles can be between 2 to 4 weeks and are commonly used by development teams using
the Scrum Agile process. Longer cycles are also common and are called Program Increments
under the scaled Agile Framework. These cycles encompass many scrum sprint cycles.

DevOps must be able to support all these cycles. This is quite natural given the central theme of DevOps:
cooperation between disciplines in an Agile organization.
The importance and significant benefits of DevOps lie in the shorter cycles, resulting in increased
efficiency in the longer cycles.
The following are the few instances where DevOps can enhance Agile Cycles.
✓ DevOps engineers enhance the speed and efficiency of deliverables at the final stage of scrum
cycles. Such cycles can occur over a frequency of 2 to 4 weeks. The organizations that mainly

13
 depend on manual deployments, can involve several days to complete a deployment cycle. If
DevOps is implemented in such organizations, they can gain maximum benefits.
✓ Assuming that a Kanban cycle takes 24 hours, it is crucial that the deployment cycle gets
significantly faster than Kanban, in order to achieve success with Kanban.
A well-designed DevOps Continuous Delivery pipeline can deploy code from being committed to the
code repository to production in the order of minutes, depending on the size of the change.

1.3 DEVOPS AND ITIL

• ITIL, which was formerly known as Information Technology Infrastructure Library, is a
practice used by many large and mature organizations.
• 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.
• DevOps is a set of practices for software development and deployment. DevOps is extremely
compatible with various frameworks designed for Agile or lean enterprises. The scaled Agile
Framework (SAFe) is highly compatible with DevOps. It is unlikely to have conflicts among
supporters of various agile approaches and DevOps, as DevOps is emerged from Agile contexts.
However, the situation is quite distinct when it comes to ITIL.
• It is an extensive framework which offers formal structure to several elements within the software
development life cycle. Comparing with DevOps and continuous Delivery which advocate for
14
 frequent and gradual modifications to be made in production, ITIL seems to promote the converse
approach initially. However, it is false.
• Legacy systems usually exhibit a monolithic architecture, which necessitates the implementation
of a process like ITIL to effectively handle the complex modifications frequently associated with
such type of systems.
• For a large organization, the probability is high that system under use is extensive, outdated, and
inflexible legacy system. However, numerous procedures outlined in ITIL can be applied to
related DevOps principles. ITIL incorporates configuration management system and
configuration management database.
The Goal of ITIL: To help businesses for
✓ Deliver high-quality, consistent IT services
✓ Handle problems and incidents in a systematic way
✓ Align IT with business needs
Example: If your school's Wi-Fi stops working, ITIL provides a clear step-by-step method to log,
investigate, fix, and report the issue.
ITIL Service Lifecycle: The ITIL framework consists of five core publications, each covering a
different stage of the IT service management lifecycle:

1. Service Strategy: This publication provides guidance on how to develop and implement IT
service strategies that align with business goals and objectives.
2. Service Design: This publication covers the design of IT services, including how to design
service solutions, architectures, processes, and policies.
3. Service Transition: This publication provides guidance on how to manage the transition of IT
services from development to operations, including how to plan and execute changes, manage
risks, and ensure that new or changed services are ready for deployment.
4. Service Operation: This publication covers the management of IT services in operation,
including how to monitor and manage service performance, resolve incidents and problems,
and manage service requests.
5. Continual Service Improvement: This publication provides guidance on how to continuously
improve the quality and efficiency of IT services, including how to measure and report service
performance, identify areas for improvement, and implement changes.
ITIL and DevOps can work together to improve IT service delivery. ITIL focuses on aligning IT services
with the needs of the business, and DevOps focuses on improving the speed and quality of software
15
delivery. By combining ITIL and DevOps, organizations can create a more efficient and effective IT
service delivery process.
Here are some ways that ITIL can be integrated with DevOps:
• Incident Management: ITIL's incident management process can be used to manage and resolve
incidents that occur in production environments. DevOps can provide real-time monitoring
and alerting, enabling faster detection and resolution of incidents.
• Problem Management: The main goal of this management process is to maintain or manage the
life cycle of all the problems which happen in the services of IT. In the ITIL Framework, the
problem is referred to as “an unknown cause or event of one or more incident”.
• Change Management: ITIL's change management process can be integrated with DevOps to
ensure that changes are tested and approved before they are deployed to production. DevOps can
provide automation and agility to the change management process, enabling faster deployment of
changes while still ensuring compliance with ITIL policies.
• Service Level Management: ITIL's service level management process can be integrated with
DevOps to ensure that service level agreements (SLAs) are met. DevOps can provide continuous
delivery and deployment, enabling faster and more reliable delivery of services.
• Configuration Management: ITIL's configuration management process can be used to manage
and track the configuration of IT assets. DevOps can provide automation and infrastructure-as-
code (IaC) tools, enabling faster and more consistent configuration management.
By integrating ITIL and DevOps, organizations can improve their IT service delivery process, enabling
faster and more reliable delivery of services to the business.
ITIL Key Processes
Process Purpose Example
Incident Management Fix issues quickly Printer not working, Wi-Fi down
Problem Management Find root causes of frequent issues “Why does the same server crash
every week?”
Change Management Control and track system updates Upgrading software without
disrupting users
Service Level Management Handle user needs Password reset, new email account.
Configuration Management Track IT assets and their Know what servers, software, and
relationships hardware are used and how.

DevOps vs. ITIL

Feature DevOps ITIL
Focus Software delivery IT service management
Goal Deliver features faster, automate everything Deliver stable, reliable services
Approach Agile, flexible, continuous Structured, process-based
Style Rapid development and deployment Standardized operations and support
Users Developers, operations engineers IT support, service managers
Tools Jenkins, Docker, Kubernetes ServiceNow, BMC Remedy

Can DevOps and ITIL Work Together?

Yes! They solve different problems but can complement each other
16
 Situation DevOps Helps ITIL Helps
Build new software Automates building, testing, deploying. Ensures changes are approved and documented.
Deploy updates Makes deployments faster and reliable. Tracks system changes and incidents.
Handle crashes Uses monitoring tools to detect Logs incidents, assigns responsibility, and
problems. reports.

Advantages of ITIL: Following are the various advantages or benefits of ITIL

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

1.4 DEVOPS PROCESS AND CONTINUOUS DELIVERY

The DevOps process is a series of steps followed to develop, test, release, and maintain software
quickly and reliably. It focuses on automation, collaboration, and continuous improvement.
As mentioned earlier, the various phases such as Continuous Planning, Continuous Development,
Continuous Integration, Continuous Testing, Continuous Deployment, Continuous monitoring and
Continuous Feedback constitute DevOps Life cycle.
Continuous delivery (CD) is the process of automating build, test, configuration, and deployment from
a build to a production environment. In DevOps, continuous delivery is also called “Automated
deployment pipeline”. This will include few manual testing’s as well like “User acceptance testing”
which generally will be run by the end user and also few manual approval gates, as the code comes close
to the production environment.
Continuous Delivery (CD) is a DevOps practice where Software is always in a release-ready state. This
means:
• Code is tested automatically.
• It can be released anytime — with the click of a button.
• There is no need for manual, risky deployments.

CD = Code → Test → Ready for Release (automated)

How Continuous Delivery Works:

1. Developers commit code to Git.
2. A CI/CD pipeline:
✓ Builds it automatically.
✓ Tests it automatically.
✓ Packages it for release.
3. The team decides when to release (it’s ready anytime).
4. In Continuous Deployment (the next level), code is automatically released without even
clicking a button.

17
An example of a Continuous Delivery pipeline in a large organization is introduced in the following
image:

While the basic outline of this image holds true surprisingly often, regardless of the organization. There
are, of course, differences, depending on the size of the organization and the complexity of the products
that are being developed.
In general, similarities exist in the initial elements of the pipeline, particularly the developer
environments and the Continuous Integration environment. From organizations point of view, there
exists significant difference in both quantity and variety of testing environments. Moreover, variations
also exist in the production environments.
The various elements of the Continuous Delivery pipeline are as follows:
The Developers:
The developers work on their workstations. They develop code and need many tools to be efficient.
Ideally, they would each have production-like environments available to work with locally on their
workstations or laptops. Depending on the type of software that is being developed, this might actually
be possible, but it's more common to simulate, or rather, mock, the parts of the production environments
that are hard to replicate. One example of this could be constraints related to remote payment systems or
phone hardware.

preference is to use a development environment that is similar to the production environment. If you are
running Windows servers in production, it might also be more convenient to use a Windows development
machine.
This is a sound practice, since otherwise developers might spend a lot of time creating their development
environments. Such a prepackaged environment might, for instance, include a specific version of the
18
Java Development Kit and an integrated development environment, such as Eclipse. If you work with
Python, you might package a specific Python version, and so on.
The preceding developer environment consists of all the development tools we need. These will not be
installed on the test or production systems. This can be a virtual machine provisioned with Vagrant
running on the developer's machine, a cloud instance running on AWS, or a Docker container: there are
many ways to solve this problem.
The revision control system:
The revision control system is often the heart of the development environment. It is the storage area of
organization's software products. It is also common to store the configurations that form the
infrastructure here. If you are working with hardware development, the designs might also be stored in
the revision control system. It is one of the key tools used by successful DevOps teams for reducing
development time and increasing the rate of successful deployments.
The following image shows the systems dealing with code, Continuous Integration, and artifact storage
in the Continuous Delivery pipeline in greater detail:

Regardless of the revision control system you use in your organization, the choice of product is only one
aspect of the larger picture. Moreover, other decisions are also needed to be taken with respect to
directory structure conventions as well as the choice of branching strategy. If there is a large number of
distinctive components, a developer can choose to utilize individual repositories for every one of them.
The build server:
The build server is conceptually simple and easy to understand. A build server is a dedicated server or
computer that is used to automate the process of building software applications. It is also known as a
continuous integration (CI) server.
The build server typically runs a software tool called a build system, which automatically compiles
source code, runs unit tests, and generates binary files or other artifacts that are required to deploy the
software application.
The main benefits of using a build server are that it ensures consistency and repeatability in the software
build process, reduces the risk of errors, and helps to identify and fix issues quickly. By automating the
build process, developers can focus on writing code and testing new features, rather than manually
building and deploying the application each time there is a change in the codebase.
Typically, the build server is programmed to monitor the changes that are implemented inside the
revision control system. Whenever a change is detected, the build server retrieves its locally stored
replica of the source code from the revision control system. Afterwards, it compiles the source code and
executes desired tests to ensure the changes fulfill the required standards. This process is commonly
referred to as Continuous Integration.
19
As there exists Git tool that is used in revision control system, there is no obvious tool that can be
employed in build server field. However, Jenkins has become a popular open source solution for build
servers.
The artifact repository:
When the build server has verified the quality of the code and compiled it into deliverables, it is useful
to store the compiled binary artifacts in a repository. This is normally not the same as the revision control
system. An artifact refers to any file or collection of files that is produced during the software
development lifecycle. This can include source code, compiled binaries, documentation, test results,
configuration files, and other types of files.
An artifact repository is a central location for storing and managing software artifacts such as binary
files, build outputs, and other dependencies used in the software development process. Artifacts are
typically produced during the software development lifecycle, and can include things like compiled or
packaged software components.
By storing artifacts in a repository, developers can easily manage dependencies, share code between
projects and team members, and ensure that everyone is using the same versions of libraries and other
dependencies. This can help to reduce the risk of compatibility issues and make the development process
more efficient and streamlined.
Artifact repositories can be hosted on-premises or in the cloud, and there are a variety of different tools
and platforms available for managing and accessing repositories, such as Nexus, Artifactory, and Maven.
Usually, they include functionalities like searching and organizing data, and even storing metadata, like
different types of IDs and version details related to the artifacts.
In the Java world, a pretty common choice is Sonatype Nexus. Nexus is not limited to Java artifacts,
such as Jars or Ears, but can also store artifacts of the operating system type, such as RPMs, artifacts
suitable for JavaScript development, and so on.
Amazon S3 is an online storage service which is designed for storing binary artifacts using a key-value
structure. An example is the Ceph distributed filesystem, which comes with an object store designed to
be compatible with S3.
Package managers:
A package manager is a tool used in software development to manage the installation, update, and
removal of software packages and their dependencies.
Package managers automate the process of installing and managing software dependencies, making it
easier to install and configure software on different platforms and systems. Instead of manually
downloading and installing each software package and its dependencies, package managers allow
developers to simply specify the packages they need, and the package manager takes care of the rest,
automatically resolving any dependencies and installing the required packages.
Package managers are widely used in many programming languages and development environments.
There are several popular package managers available for Linux, Windows, and Unix systems, including:
For Linux package managers are:
✓ Advanced Packaging Tool (APT) - used by Debian and Ubuntu
✓ Yellowdog Updater, Modified (YUM) - used by Red Hat, CentOS, and Fedora
✓ Pacman - used by Arch Linux
✓ Portage - used by Gentoo Linux
✓ Zypper - used by SUSE Linux

20
For Windows package managers are:
✓ Chocolatey
✓ Scoop
✓ NuGet
✓ Windows Package Manager (winget)
Other package managers are:
✓ NPM for Node.js,
✓ pip for Python,
✓ RubyGems for Ruby,
✓ Maven for Java,
✓ Homebrew for macOS.
The great benefit of these package management systems is that it is easy to install and upgrade a package;
dependencies are installed automatically.
In case of a common system in place that does not offer sophisticated features, then it is needed to
remotely login into each server and execute the "yum upgrade" command. As a result, the most recent
packages will be retrieved and installed from the binary repository. In many sophisticated deployment
systems manual upgrades are not required.
Test environments:
After build server has stored the artifacts successfully in the binary repository, they can be installed from
there into test environments.
Test environments are separate environments that are created to test software applications before they
are deployed to production environments. These environments can be physical or virtual and are
designed to simulate the production environment as closely as possible.
Test environments should normally attempt to be as production-like as is feasible. Therefore, it is
desirable that the they be installed and configured with the same methods as production servers.
The following figure shows the test systems in greater detail:

There are different types of test environments, including:

1. Development environment: This environment is used by developers to write and test code
before it is checked into version control. It is usually a local environment on the developer's
machine.
2. Staging environment: This environment is used to test the software after it has been built and
before it is deployed to the production environment. It is designed to be as close to the production
environment as possible.
21
 3. Production-like environment: This environment is used to test the software in an environment
that is similar to the production environment. It is useful for identifying issues that may only
occur in a production-like environment.
4. Performance testing environment: This environment is used to test the performance and
scalability of the software application under different loads.
Overall, test environments are an important part of the software development process, as they help to
ensure that software applications are reliable, stable, and perform as expected in production
environments.
Staging / production:
The final stage in testing environments is referred to as the staging environments. Staging environments
are the last line of test environments. They are interchangeable with production environments. You install
your new releases on the staging servers, check that everything works, and then swap out your old
production servers and replace them with the staging servers, which will then become the new production
servers. This is sometimes called the blue-green deployment strategy.
The following detail from the larger Continuous Delivery image shows the final systems and roles
involved:

It is used to test the software application after it has been built and before it is deployed to the production
environment. The staging environment is used to identify & fix any issues that may arise before the
software application is deployed to the production environment.
This helps to ensure that the software application performs as expected in the production environment.
A few organizations possess the resources required to uphold staging servers with production quality as
it is advantageous and secure approach to managing updates. However, many organizations lack such
resources.
Benefits of The Continues Delivery:
• Increases the number of deliveries.
• Minimizes the risk of failure in production.
• Reduces manual work.
• Increases confidence in the team.
• Enables the team to automate everything.
• Enables faster feedback.
Tools for Continuous Delivery:
Tool Purpose
Jenkins, GitLab CI Automate builds and tests
Docker Package apps into containers for deployment
Kubernetes Run and manage those containers
Spinnaker, ArgoCD Control deployment pipelines
22
1.5 RELEASE MANAGEMENT
Release management is a software development process that involves managing the planning,
scheduling, coordinating, and controlling of software releases. Release management typically included
the testing and deployment of software releases as well. It is a key aspect of software development and
involves a set of activities that ensure the smooth and efficient release of software products.
The main objectives of release management are to:
• Ensure the quality and reliability of software releases.
• Ensure that software releases are delivered on time and within budget.
• Minimize the risks associated with software releases.
• Maximize the value of software releases to the business.
Release management has had an important role in the software development lifecycle since before it was
known as release management. This Release management is a challenge to achieve in the real world.
• One reason for this is that it is usually hard to reach the level of test automation needed in order
to have complete confidence in automated deploys.
• Another reason is simply that the cadence of business development doesn't always the match
cadence of technical development. Therefore, it is necessary to enable human intervention in the
release process.

The release management process typically includes the following activities:

1. Release planning: This involves defining the scope of the release, determining the release
timeline, and identifying the resources required for the release.
2. Release coordination: This involves coordinating the activities of various teams involved in the
release, such as development, testing, and deployment teams.
3. Release testing: This involves testing the software release to ensure that it meets the quality and
reliability standards.
4. Release deployment: This involves deploying the software release to the production
environment.
5. Release monitoring: This involves monitoring the software release in the production
environment to ensure that it is performing as expected.
6. Release feedback: This involves collecting feedback from end-users and stakeholders to identify
areas for improvement and inform future releases.
Overall, release management is critical for software development and helps to ensure that software
releases are delivered on time, within budget, and with the required quality and reliability.
Advantages of Release Management for DevOps:
• 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.
23
 • 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.
Different Types of Release Management:
• ITIL Release Management: ITIL is a specific type of process for IT operations. For release
management, you schedule and maintain the integrity of new deployments, from planning to
release. The IT operations team receives code from the software developers and decides how or
when to deliver the service. This is done while maintaining uptime for existing services.
• DevOps Release Management: DevOps has a prominent role in many of the duties once under
release management roles but doesn’t diminish the importance of release management. In fact,
release management acts as a method for filling the data gap in DevOps, being a constant process
that works alongside development. Since DevOps streamlines the flow between delivery and
operations, release management keeps tabs on apps and their components.
• Agile Release Management: In agile release management, also known as agile release planning,
you don’t focus on major releases. Instead, you break staged releases down into several iterations
or sprints. You can have several sprints running simultaneously, depending on their complexity
or your team structure. A sprint ends with a new product increment, but that doesn’t necessarily
mean a product release happens. You’ll only release the big ones.
Goal of Release Management: To ensure
• Software is released smoothly and on time.
• It works correctly in the live environment
• It causes no disruption to users or services.
Tools Used in Release Management:
Tool Purpose
Jira Track release planning and tasks
Git Version control for code
Jenkins / GitLab CI Automate build, test, and deployment
ServiceNow / BMC Remedy ITIL-style release tracking and approvals
Docker / Kubernetes Containerized releases for easy rollouts
Monitoring Tools Watch for post-release issues
(e.g., Datadog, Prometheus)

1.6 SCRUM
SCRUM is an Agile methodology that is used for iterative and incremental software development. Scrum
is focused primarily on ways to manage tasks in team-based development conditions. Scrum is a
framework used by teams comes together to manage work and solve problems collaboratively to move
the product forward in short cycles. Scrum is lightweight, simple to understand, but powerful when
used well.
Scrum implements the principles of Agile as a concrete set of artifacts, practices, and roles. Scrum
provides just enough structure for people and teams to integrate into how they work, while adding the

24
right practices to optimize for their specific needs. The entire lifecycle is completed in fixed time periods
(breaking down the development process into small iterations) called Sprints. A sprint is typically one-
to-four weeks long.
The team works on a set of features during each sprint, and at the end of each sprint, a potentially
shippable product increment is delivered. The Scrum framework consists of roles (Product Owner,
Scrum Master, and Development Team), events (Sprint Planning, Daily Scrum, Sprint Review, and
Sprint Retrospective), and artifacts (Product Backlog, Sprint Backlog, and Increment).

The iterative Scrum lifecycle

Scrum roles:
There are three key roles in Scrum: the product owner, the Scrum master, and the Scrum team.
• 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 product backlog of work up to date,
prioritizes the delay and is responsible for the distribution of functionality on each repetition.
• 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.
• Scrum 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. The team manages its work and
organizes the work to complete the sprint or cycle.
Scrum Artifacts & Tools:
✓ Scrum has several artifacts and tools. The primary artifact is, of course, the product itself.
✓ Product backlog: The product backlog is another tool. 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.
✓ Sprint backlog: 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, the team needs to perform in
order to deliver the functionality it committed to deliver during the sprint. Once all members
agree the sprint backlog is achievable, the sprint starts.
✓ 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.
25
Scrum Events:
✓ Plan the sprint: On the first day of a sprint and during the planning meeting, team members
create the sprint backlog. 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.
✓ Daily Scrum: A Daily Scrum, also known as a daily stand-up, is a short, time-boxed meeting
held daily by the Scrum team to synchronize their work and identify any impediments. Typically
lasting 15 minutes, it's a crucial event for maintaining alignment, fostering collaboration, and
ensuring progress toward the Sprint Goal. If the Product Owner or Scrum Master are actively
working on items in the Sprint Backlog, they participate as Developers.
✓ 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.
✓ Sprint review: A sprint review is a collaborative meeting that is typically held at the end of every
sprint. This is when the team runs through work items they completed during the sprint or
iteration. The team demonstrates what they've accomplished to stakeholders. They demo the
software and show its value. At the end of each sprint review, the product owner or the team lead
uses this feedback to create necessary work items in the product backlog.
✓ Sprint Retrospective: A sprint retrospective is a review conducted after a sprint that plays a key
role in the Agile methodology. The sprint retrospective meeting takes place immediately after the
sprint review. A sprint retrospective aims to determine what went well and which areas need
improvement. The outcome of the retrospective are actions for the next sprint.
Unlike the sprint backlog, the product backlog is a list of features to be built over many sprints. During
the sprint, most teams use a task board (virtual or physical) to visually represent the flow of sprint
backlog work as it moves from To Do, to Doing, to Done.
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.

26
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.
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.
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 Activities:
• Each sprint begins with a sprint planning meeting, where the product owner presents the top
items on the product backlog to the team, and team members figure out how much work they can
commit to during the coming sprint.
• During each sprint, the team takes a small set of features from idea to fully implemented and
tested functionality. At the end, these features are done and could potentially be released to
customers.
• On each day of the sprint, all team members attend a daily scrum meeting. Daily scrums are a
way for team members to synchronize their work and collaborate to move that work to done. The
daily meetings last no more than 15 minutes and are intended to give the team a time to share
what they worked on the prior day, will work on that day, and identify any impediments to
progress.
• At the end of a sprint, the team conducts a sprint review during which the team demonstrates the
new functionality to the product owner or any other stakeholder who wishes to provide feedback
that could influence the next sprint.
• This feedback loop may result in changes to the freshly delivered functionality, but it may just
as likely result in revising or adding items to the work planned for the future.
• Another inspect-and-adapt activity is the sprint retrospective at the end of each sprint. The whole
team participates in this meeting. The meeting is an opportunity to reflect on the sprint that has
ended and to identify what changes or improvements the team may wish to make to the process
itself.
Advantages of Scrum: The following are the advantages of scrum
• Faster delivery - Working features delivered regularly
• Flexibility - Easy to adapt to changes
• Team collaboration - Everyone communicates daily
• Transparency - Everyone knows what’s going on
• Continuous improvement - Team gets better over time
Simple Example: Let’s say your class is building a school website:

27
Product Backlog:
✓ Create homepage
✓ Add photo gallery
✓ Add timetable section
✓ Contact form
Sprint 1 (2 weeks):
✓ Build homepage
✓ Add photo gallery
Sprint 2:
✓ Add timetable section
✓ Add contact form
➡️ Every day the team checks progress.
➡️ At the end of each Sprint, you review what was built.
➡️ Then you improve the process and plan the next Sprint.

1.7 KANBAN
Kanban is another Agile methodology that is used for continuous delivery. It involves visualizing the
flow of work, limiting work in progress, and optimizing the flow of work to improve efficiency and
quality. The Kanban framework consists of visual boards, work items, work in progress limits, delivery
cadence, and continuous improvement. Kanban which is often used in operations team, emphasizes the
24-hour time frame.
Kanban is a popular framework used to implement Agile and DevOps software development. It allows
project managers to successfully manage and keep track of their projects. Unlike some other popular
frameworks, Kanban believes in introducing little but meaningful changes in the continuing setup.
Kanban is used to optimize workflow and increase efficiency in various industries including software
development, manufacturing, shopping malls, etc.
Kanban is a Japanese term that means Visual board or signboard or billboard. An industrial engineer
named Taiichi Ohno developed Kanban at Toyota Motor Corporation to improve manufacturing
efficiency. Work items are represented visually on a board called Kanban-board, that allowing team
members to see the state of every piece of work at any time. Kanban is a work flow management method
for Defining, Managing, Improving the services, delivering the knowledge/work. It is used for
visualizing the work, Maximizing the efficiency and Improve continually.
Purpose of Kanban: Kanban helps to teams
✓ Visualize their work ✓ Identify bottlenecks
✓ Limit how much work is in progress ✓ Improve efficiency over time
It’s not just a tool — it’s a method for managing flow and improving continuously.
Components of Kanban:
1. Kanban Board: A Kanban board is the main workspace. It has columns that represent different
stages of work. Common columns are
Column Name Meaning
To Do Tasks that are ready to be worked on
In Progress Tasks that are currently being worked on
Done Finished tasks
28
 2. Kanban Cards: Each task is a card that moves from left to right across the board. Each card
includes:
1. Task name 2. Person responsible 3. Due date (optional)
4. Description 5. Priority 6. Checklist (optional)
These cards are moved across the board as progress happens.
3. Work-In-Progress (WIP) Limits: One of the most powerful parts of Kanban. You limit how
many tasks can be in each column at once. Because
✓ It prevents people from starting too many tasks at once.
✓ It forces the team to focus and finish before starting new things.
4. Continuous Delivery / Flow: Kanban is not based on time (like Scrum’s Sprints). It’s based on
flow-the goal is to keep work moving smoothly. New work can be added anytime, and finished
work can be released anytime. There’s no “start” or “end” of a Sprint-work just flows
continuously.
5. Metrics & Improvement: Teams often use flow-based metrics to improve performance:
Metric Meaning
Lead Time Time from task added to task done
Cycle Time Time from task started to task done
Throughput Number of tasks completed per day/week
Kanban Process:
• The main idea of Kanban is that the flow of work is displayed on a large board with different
columns.
• Work is represented by a card on the board, and the board is divided into different columns. Each
column on the board displays a different state of the work process, and as the work continues,
the card is shifted from one column to the next to the next to track progress and possible
completion.
• The Kanban method uses something like a bulletin board put in the work area. Traditional
Kanban boards are divided into three columns named something like:
✓ To accomplish/ To do : To do-prioritized, To do-unprioritized.
✓ In progress/ Working/ Doing : Plan, Develop-Test-Launch
✓ Finished/ Done : Done, Approval Pending.

Traditional Kanban board

• Various workplaces may use different numbers or names for the columns, but the idea of shifting
the Kanban card from column to column as work is completed remains unchanged.
Kanban delivers four pivotal practices (Kanban Principles):
• Visualize work: We visualize all work and look for triggers such as cards turning red when the
work they represent is blocked or has been dormant for more than two days.
• Limit work in progress: We agree on and enforce (soft) work-in-progress limits to encourage
reduced batch sizes and manage queue lengths.
29
 • Focus on flow: We pull not push work, which helps us to defer commitment until we meet our
definition of done (DoD) and we have the capacity to commit to the next activity.
• Continuous improvement: It is important to measure work from when it enters our backlog,
how long it takes to get through the process (lead time), and how efficient we are working
(cycle/lead time). This enables us to continuously inspect and improve how we work and track
progress.
• Take Feedback: The most important entity for any business is the consumer, and implementing
an effective feedback system is very important. On the Kanban boards, a column can be made
for feedback from either an external evaluator or the consumers themselves. In this way, the
quality of the delivered work can be maintained constantly. With the help of Kanban, you have
feedback loops of different kinds, including:
✓ Service delivery reports
✓ Policy reviews
✓ Operations reviews
✓ Risk evaluation meetings
✓ Daily stand up sessions
Advantages of Kanban: With Kanban, you can improve not only in your task planning but also in the
output produced by your teams, some of the benefits are as follow.
1. Identifying issues: An important practice of Kanban is to limit work-in-progress. It is a basic
aspect in organizations to multitask. However, multitasking has been seen to be problematic,
specifically in terms of efficiency. The need to switch regularly between tasks and work can
influence your task's completion. Setting work-in-progress lets you and your team highlight any
barriers in your improvement process, which could be because of a lack of focus, resources, or
techniques.
2. Flexibility: Unlike other frameworks. Kanban isn't restrictive. There are no definite phase
durations and preferences are based on the most recent data. This makes it fit for teams in any
organization to use a Kanban board to collaborate, document work, and track their work progress.
The column structure of a Kanban board is an excellent way to organize information.
3. It can Save Time: As part of the Agile practice, implementing a Kanban board will allow your
team to improve throughout the development process. By using. shared visual management tool,
each team member can see all activity involved in the project process, and should any issues
appear, the transparency will allow them to be fixed quickly in the process. This inevitably allows
enough time and resources for your team to continue providing a high-quality product or service.
4. It Empowers Teams: As every team member involved in a project can access the Kanban board,
everyone shares the responsibility for ensuring work gets moved along the board properly and
eventually to the "Done" column. Having this kind of responsibility within your team members
can foster communication and collaboration skills.
5. Balance Productivity: By sticking to the basic practices of Kanban, limiting the amount of
work-in-progress will keep workers from consuming time on menial tasks. This limits the risk of
work excess and the productivity flow being slowed down. The visualization of workflow can
ensure even streams of productivity. This also helps to predict the service delivery time.
Disadvantages of Kanban:
1. Less Effective in Shared-Resource Situations: Irregular orders may render the Kanban process
unproductive.

30
 2. Product Mix or Demand Changes May Cause Problems: Changes in demand and products
may impact the functioning of the Kanban system. Thus, the system is less suitable for enterprises
where product volumes and mixes fluctuate.
3. The Kanban System Doesn't Eliminate Variability: The Kanban method may deliver poor-
quality items that need to be updated or scrapped if production is disrupted with long and
unpredictable downtimes. Any variability or unpredictability will impact the functioning of the
system, making it send confusing, mixed, and incorrect signals with respect to the optimal
production levels.
4. Quality Miscues: The Kanban approach brings quality levels of inventory close to zero. In cases
of high uncertainty and troubles in the transportation network, inventory buffers are required to
guard low-grade quality from the internal operations and also from the suppliers. This slows your
production process.
Tools for Kanban:
1. Trello - Most popular, simple drag-and-drop
2. Jira (Kanban board) - Used in software development
3. Asana, ClickUp, Notion - General project management tools
4. Miro - Whiteboard with Kanban templates.
Difference Between Scrum and Kanban:
Kanban and scrum share some of the same concepts but have very different approaches. Scrum focuses
on sprint cycles, which can occur biweekly or monthly. Kanban can be said to focus more on shorter
cycles, which can occur daily. The philosophical differences between Scrum and Kanban are a bit deeper,
although not mutually exclusive. Many organizations use both Kanban and Scrum together. From a
software-deployment viewpoint, both Scrum and Kanban are similar. Both require frequent hassle-free
deployments. From a DevOps perspective, a change starts propagating through the Continuous Delivery
pipeline toward test systems and beyond when it is deemed ready enough to start that journey.
KEY ITEM SCRUM KENBAN
Framework Scram is a framework that defines Kanban is a visual framework that focus
specific roles, events & artifacts on continuous delivery and optimizing
workflows.
Planning Scrum uses fixed length sprints typically Kanban emphasizes continuous work flow
2-4 weeks with preplanned work. and delivery with no pre-defined iteration.
Release At the end of each sprint if approved by Continuous delivery or at the team's
methodology the product owner. discretion.
Prioritization Scram uses a product owner and refined Kanban uses a backlog or queue that is
by the team continuously re-prioritized based on
customer needs and team capacity.
Roles Scrum has mainly 3 roles: Product owner, Kanban has no predefined roles.
Scrum master and Development team
Estimation Scrum uses relative estimation techniques Kanban doesn't require explicit estimation,
such as Planning Pokers to estimate work.

31
 Metrics Scrum uses velocity, burn-down charts, Kanban uses lead-lime, cycle-time. and
etc. metrics to track work progress and other metrices to measure flow and
forecast future. work. identify the bottlenecks.
Change Teams should strive to not make changes Change can happen at any time
philosophy to the sprint forecast during the sprint.
Doing so compromises learnings around
estimation
Time-Based Fixed time periods (Sprints) No fixed time (flow-based)
Flexibility More structured Very flexible
Meetings Daily stand-ups, Sprint Planning, etc. No required meetings
Delivery At end of Sprint Continuous

1.8 DELIVERY PIPELINE

The primary focus of Scrum is on sprint cycles occurring once every two weeks or once in a month. In
contrast, the primary focus of Kanban is on shorter cycles, occurring on a daily basis. However, it is
important to note that these distinctions do not make the two methodologies mutually exclusive. It is
typical for firms to employ both techniques simultaneously.
In terms of software deployment, both Scrum and Kanban are similar emphasizing the importance of
frequent and seamless deployments. From a DevOps viewpoint, the journey of a change progresses
through the Continuous Delivery pipeline, fest systems and so on. This happens when the change is
ready to be implemented.
A Delivery Pipeline is the automated process of moving software from development to production
safely and quickly. It ensures that every code change goes through building, testing, and releasing in a
controlled, repeatable way. The delivery pipeline is the process used to build, test, and deploy software.
It involves a series of stages, such as development, testing, staging, and production, that are connected
through an automated process. The delivery pipeline is designed to ensure that software is delivered
quickly, reliably, and with high quality.
Our pipeline can manage both the following types of scenarios:
• The build server supports the generation of the objective code quality metrics that we need in
order to make decisions. These decisions can either be made automatically or be the basis for
manual decisions.
• The deployment pipeline can also be directed manually. This can be handled with an issue
management system, via configuration code commits, or both.
• So, again, from a DevOps perspective, it doesn't really matter if we use Scrum, Scaled Agile
Framework (Safe), Kanban, or another method within the lean or Agile frameworks. Even a
traditional Waterfall process can be successfully managed— DevOps serves all!
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. While a DevOps
pipeline can differ by organization, it typically includes build automation/continuous
integration, automation testing, validation, and reporting.
Why is it Important?
Before pipelines, teams would
➢ Write code for weeks/months
32
 ➢ Do manual testing
➢ Deploy manually (which was slow and error-prone).
With a Delivery Pipeline, teams can:
➢ Release faster
➢ Catch bugs early
➢ Automate repetitive work
➢ Deliver higher-quality software
Stages in a Typical Delivery Pipeline: Here’s a step-by-step breakdown:
1. Source Code Management (SCM):
Developers write and commit code into a version control system like Git (e.g., GitHub, GitLab).
This is the starting point. Tool used: Git, GitHub, Bitbucket.
2. Build Stage:
The code is compiled and packaged into a working product. If something is broken in the code,
the build fails. Example: Turning source code into an .exe file or .apk file. Tools used: Maven,
Gradle, MSBuild, Jenkins, Azure Pipelines.
3. Automated Testing Stage:
Verifies that the new code works and hasn’t broken anything. Run unit tests, integration tests,
etc. If tests pass, the code moves forward. If tests fail, it stops so bad code isn’t released. Tools
used: JUnit, Selenium, PyTest, TestNG.
4. Staging/Pre-production:
The software is deployed to a test environment. It looks like the real production system but is
safe for testing. Real users may test here (User Acceptance Testing – UAT). Tools used: Docker,
Kubernetes, Ansible.
5. Deployment (Release Stage):
The final, tested version is automatically deployed to the production environment. Users can
now access the latest version. This step is usually done with:
• Continuous Delivery (CD) – manual trigger to release
• Continuous Deployment – automatic release if everything passes
Tools used: Jenkins, GitLab CI/CD, Azure DevOps, CircleCI
6. Monitoring and Feedback (Optional):
After deployment, monitor for Performance issues, Errors, User feedback. Tools used:
Prometheus, Grafana, New Relic, Sentry
Continuous Integration vs Continuous Delivery vs Deployment:
✓ CI (Continuous Integration) Code is automatically tested and merged daily.
✓ CD (Continuous Delivery) Code is always ready to be deployed (manually).
✓ CD (Continuous Deployment) Code is deployed automatically when all tests pass
Benefits of Delivery Pipeline:
• Faster delivery-Ship updates quickly.
• Automated testing-Catch bugs early.
• Repeatable-Reduces human error.
• Transparent-Everyone can see what's happening.
• Reduces risk-Small changes are safer than big ones.

33
1.9 IDENTIFYING BOTTLENECKS
When engaging in agile work, keep track of what you are doing, and try to identify problem areas. When
everything is working as it should, a commit to the code repository should result in the change being
deployed to integration test servers within a 15-minute time span. When things are not working well, a
deploy can take days of unexpected hassles.
Here are some possible causes:
• Database schema changes.
• Test data doesn't match expectations.
• Deploys are person dependent, and the person wasn't available.
• There is unnecessary red tape associated with propagating changes.
• Your changes aren't small and therefore require a lot of work to deploy safely. This might be
because your architecture is basically a monolith.
some more examples of bottlenecks: These are the 11 bottlenecks that have the biggest impact on the
flow of work.
1. Inconsistent Environments: In almost every company I have worked for or consulted with, a
huge amount of waste exists because the various environments (dev, test, stage, prod) are
configured differently. I call this “environment hell”. How many times have you heard a
developer say “it worked on my laptop”? As code moves from one environment to the next,
software breaks because of the different configurations within each environment.
I have seen teams waste days and even weeks fixing bugs that are due to environmental issues
and are not due to errors within the code. Inconsistent environments are the number one killer of
agility.
Create standard infrastructure blueprints and implement continuous delivery to ensure all
environments are identical.
2. Manual Intervention: Manual intervention leads to human error and non-repeatable processes.
Two areas where manual intervention can disrupt agility the most are in testing and deployments.
If testing is performed manually, it is impossible to implement continuous integration and
continuous delivery in an agile manner (if at all). Also, manual testing increases the chance of
producing defects, creating unplanned work. When deployments are performed fully or partially
manual, the risk of deployment failure increases significantly which lowers quality and reliability
and increases unplanned work.
Automate the build and deployment processes and implement a test automation
methodology like test driven development (TDD)
3. SDLC Maturity: The maturity of a team’s software development lifecycle (SDLC) has a direct
impact on their ability to deliver software. There is nothing new here; SDLC maturity has plagued
IT for decades. In the age of DevOps, where we strive to deliver software in shorter increments
with a high degree of reliability and quality, it is even more critical for a team to have a mature
process.
Some companies I visit are still practicing waterfall methodologies. These companies struggle
with DevOps because they don’t have any experience with agile. But not all companies that
practice agile do it well. Some are early in their agile journey, while others have implemented
what I call “Wagile”: waterfall tendencies with agile terminology sprinkled in. I have seen teams

34
 who have implemented Kanban but struggle with the prioritization and control of WIP. I have
seen scrum teams struggle to complete the story points that they promised. It takes time to get
really good at agile.
Invest in training and hold blameless post mortems to continuously solicit feedback and
improve.
4. Legacy Change Management Processes: Many companies have had their change management
processes in place for years and are comfortable with it. The problem is that these processes were
created back when companies were deploying and updating back office solutions or
infrastructure changes that happened infrequently. Fast forward to today’s environments where
applications are made of many small components or micro services that can be changed and
deployed quickly, now all of a sudden, the process gets in the way.
Many large companies with well-established ITIL processes struggle with DevOps. In these
environments I have seen development teams implement highly automated CI/CD processes only
to stop and wait for weekly manual review gates. Sometimes these teams have to go through
multiple reviews (security, operations, code, and change control).
Companies with legacy processes need to look at how they can modernize processes to be
more agile instead of being the reason why their company can’t move fast enough.
5. Lack of Operational Maturity: Moving to a DevOps model often requires a different approach
to operations. Some companies accustomed to supporting back office applications that change
infrequently. It requires a different mindset to support software delivered as a service that is
always on, and deployed frequently. With DevOps, operations is no longer just something Ops
does. Developers now must have tools so they can support applications. Often I encounter
companies that only monitor infrastructure. In the DevOps model developers need access to
logging solutions, application performance monitoring (APM) tools, web and mobile analytics,
advanced alerting and notification solutions.
Assess your operational processes, tools, and organization and modernize to increase agility
and transparency.
6. Outdated testing practices: Too often I see clients who have a separate QA department that is
not fully integrated with the development team. The code is thrown over the wall and then testing
begins. Bugs are detected and sent back to developers who then have to quickly fix, build, and
redeploy. This process is repeated until there is no time remaining and teams are left to agree on
what defects they can tolerate and promote to production. This is a death spiral in action. With
every release, they introduce more technical debt into the system lowering its quality and
reliability, and increasing unplanned work. There is a better way.
The better way is to block bugs from moving forward in the development process. Testing must
be part of the development process, not a handoff that is performed after development.
Developers need to play a bigger part in testing and testers need to play a bigger part in
development. This strikes fear in some testers and not all testers can make the transition.
Quality is everyone’s responsibility, not just the QA team.
7. Automating waste: A very common pattern I run into is the automation of waste. This occurs
when a team declares itself a DevOps team or a person declares themselves a DevOps engineer
and immediately starts writing hundreds or thousands of lines of Chef or Puppet scripts to
automate their existing processes. The problem is that many of the existing processes are

35
 bottlenecks and need to be changed. Automating waste is like pouring concrete around
unbalanced support beams. It makes bad design permanent.
Automate processes after the bottlenecks are removed.
8. Competing or Misaligned Incentives and Lack of Shared Ownership: This bottleneck has
plagued IT for years but is more profound when attempting to be agile. In fact, this issue is at the
heart of why DevOps came to be in the first place. Developers are incented for speed to market
and operations is incented to ensure security, reliability, availability, and governance. The
incentives are conflicting. Instead, everyone should be incented for customer satisfaction, with a
high degree of agility, reliability, and quality (which is what DevOps is all about). If all teams’
goals are in support of the goals I mentioned above, and everyone is measured in a way that
enforces those incentives, then everyone wins --- especially the customer.
Work with HR to help change the reward and incentives to foster the desired behaviors.
9. Dependence on Heroic Efforts: When heroic efforts are necessary to succeed, then a team is in
a dark place. This often means working insane hours, being reactive instead of proactive, and
being highly reliant on luck and chance. The biggest causes of this are a lack of automation, too
much tribal knowledge, immature operational processes, and even poor management.
If your organization relies on heroes, find out what the root causes are that creates these
dependencies and fix them fast.
10. Governance as an Afterthought: When DevOps starts as a grassroots initiative there is typically
little attention paid to the question “how does this scale?” It is much easier to show some success
in a small isolated team and for an initial project. But once the DevOps initiative starts scaling to
larger projects running on way more infrastructures or once it starts spreading to other teams, it
can come crashing down without proper governance in place. They all have different versions of
third party products and libraries on them. Suddenly, it is not so easy anymore.
With DevOps, the same thing can happen without the appropriate controls in place. Many
companies start their DevOps journey with a team of innovators and are able to score some major
wins. But when they take that model to other teams it all falls down. There are numerous reasons
that this happens. Is the organization ready to manage infrastructure and operations across
multiple teams? Are there common shared services available like central logging and monitoring
solutions or is each team rolling their own? Is there a common security architecture that everyone
can adhere to? Can the teams provision their own infrastructure from a self-service portal or are
they all dependent on a single queue ticketing system? I could go on but you get the point.
Assign an owner and start building a plan for scaling DevOps across the organization.
11. Limited to No Executive Sponsorship: The most successful companies have top level support
for their DevOps initiative. One of my clients is making a heavy investment in DevOps training
and it will run a large number of employees through the program. Companies with top level
support make DevOps a priority. They break down barriers, drive organizational change, improve
incentive plans, communicate “Why” they are doing Devops, and fund the initiative. When there
is no top level support, DevOps becomes much more challenging and often becomes a new silo.
Don’t let this stop you from starting a grass roots initiative. These grassroots teams measured
their success and pitched their executives.
If running a grassroots effort, gather before and after metrics and be prepared to sell and
evangelize DevOps upward.

36