The document introduces DevOps as a combination of practices and tools aimed at enhancing an organization's software delivery speed and efficiency through collaboration between development and operations teams. It discusses the benefits of DevOps, including improved quality, rapid deployment, and security integration, and also outlines the software development life cycle (SDLC) process along with concepts like the minimum viable product (MVP) and lean software development principles. Additional sections cover cross-functional teams, ITIL methodologies, and the evolution of IT service management practices.

1. Introduction to DevOps
Module#1
Ms. Monali Sankhe
1

2. DevOps Definition
• DevOps (a portmanteau of “development” and “operations”)
• is the combination of practices and tools designed to increase an
organization’s ability to deliver applications and services faster than
traditional software development processes.
• This speed enables organizations to better serve their customers and
compete more effectively in the market.
• DevOps is about removing the barriers between traditionally siloed
teams, development and operations.
• Under a DevOps model, development and operations teams work
together across the entire software application life cycle, from
development and test through deployment to operations.
2

3. DevOps Definition
• The word “DevOps” was coined in 2009 by Patrick Debois, who became
one of its gurus.
• DevOps isn’t a process or a technology or a standard.
• Many devotees refer to DevOps as a “culture”—a viewpoint that New Relic
favors.
• “DevOps represents a change in IT culture, focusing on rapid IT service
delivery through the adoption of agile, lean practices in the context of a
system-oriented approach.
• DevOps emphasizes people (and culture),and seeks to improve
collaboration between operations and development teams.
• DevOps implementations utilize technology especially automation tools that
can leverage an increasingly programmable and dynamic infrastructure
from a life cycle perspective.” 3

4. DevOps Benefits
• Speed: Teams that practice DevOps release deliverables more
frequently, with higher quality and stability.
• Improved collaboration: The foundation of DevOps is a culture of
collaboration between developers and operations teams, who share
responsibilities and combine work. This makes teams more efficient and
saves time related to work handoffs and creating code that is designed
for the environment where it runs.
• Rapid deployment: By increasing the frequency and velocity of
releases, DevOps teams improve products rapidly. A competitive
advantage can be gained by quickly releasing new features and
repairing bugs.
4

5. DevOps Benefits
• Quality and Reliability: Practices like continuous integration and
continuous delivery ensure changes are functional and safe, which
improves the quality of a software product. Monitoring helps teams
keep informed of performance in real-time.
• Security : By integrating security into a continuous integration,
continuous delivery, and continuous deployment pipeline, DevSecOps is
an active, integrated part of the development process. Security is built
into the product by integrating active security audits and security testing
into agile development and DevOps workflows.
5

6. Software Development Life Cycle Process
• SDLC is a process that defines the various stages involved in the
development of software for delivering a high-quality product.
• SDLC stages cover the complete life cycle of a software i.e. from
inception to retirement of the product.
6

7. Software Development Life Cycle Process
• 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 (Small and Mid size Industries)
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.
7

8. Software Development Life Cycle Process
• 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.
• 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.
8

9. Software Development Life Cycle Process
• 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.
• 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 are done.
9

10. Software Development Life Cycle Process
• 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.
• 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.
10

11. Minimum Viable Product
(MVP)
11

12. What is a Minimum Viable Product (MVP)?
12
• Minimum viable product (MVP) is a development technique in which a new product or
website is developed with sufficient features to satisfy early adopters.
• The final, complete set of features is only designed and developed after considering
feedback from the product's initial users.
• Eric Ries, defined an MVP as that version of a new product which allows a team to
collect the maximum amount of validated learning about customers with the least effort.
• MVP has three key characteristics
• It demonstrates enough future benefit to retain early adopters.
• It has enough value that people are willing to use it or buy it initially.
• It provides a feedback loop to guide future development.

13. Benefits of an MVP for your Business
• Early testing opportunity
• It is good to find out from the beginning if your idea will work without investing your whole budget.
• User intelligence and gather feedback
• MVP offers the possibility to find out your potential users’ opinion, and how they want to see your final product.
• Allows market analysis
• It helps you understand whether your app is right for your target market.
• Budget friendly
• Creating an MVP is an easy way to enhance the mobile development strategy.
• Attracting Investors
• If your company is dependent on external investments, this is the right time to showcase why your product makes the best solution.
• Investors often avoid ideas that look perfect on paper but miserably fail on implementation.
• Resource Optimization Saves Time and Money
• Investing in a project without considering its risks can result in failure. However, MVP development can help you save your resources.

14. Elements
• Functionality –
• The features set in the MVP should be clear to the
customers.
• The product set of functions/ features presented to the
customer should deliver clear value to the customer.
• Reliability – Thorough testing should be done to
achieve the quality standard of the product.
• It helps in generating greater customer reliability for
products manufactured in the future.
• Design –
• The MVP design must be unique and should
possess the highest quality standard.
• Usability –
• The usage of the MVP must not be complex,
and it should be intuitive.

15. Steps to building an MVP
• First define the MVP idea
• Define the purpose of the product & the issue it will resolve.
• Product requirements
• List down the feature of the product.
• This will help you understand the product to a better extent.
• Priority product requirements
• List down the requirements that needs to be implemented in the product.
• PPR dependency
• It may happen that one product feature is dependent on another.
• It is important to identify them in advance.
• Build product
• Develop & launch the product with defined product requirements.
• Feedback
• The most important element is the feedback which enables you to know if you are on the correct path or not.

16. MVP Matrix

17. Examples of the Minimum Viable Product
• Airbnb
• With no money to build a business, the founders of Airbnb used their own apartment to validate their idea to create a
market offering short-term, peer-to-peer rental housing online.
• They created a minimalist website, published photos and other details about their property, and found several paying
guests almost immediately.
• Foursquare
• The location-based social network Foursquare started as just a one-feature MVP, offering only check-ins and
gamification rewards.
• The Foursquare development team began adding recommendations, city guides, and other features until they had
validated the idea with an eager and growing user base.

18. Cross-functional teams
• A cross functional team is composed of different members with
different expertise who come together to achieve one main objective.

19. Cross-functional teams

20. Cross-functional teams

21. Cross Functional Teams: Centered Around
the Product

22. Something missing?
● Security
● Compliance and assurance
● Performance testing
● Third-party integrations
● Device management
● Other specialized roles

23. Key Benefits
• Improved speed of delivery
• Reduction in cycle times
• Increase in speed of feedback
• Improved product stability
• Risk reduction
Other Benefits
• More accurate estimates
• Avoiding the “last mile”
• Mainline dev puts product managers in charge
• Better release planning
• True agility
• Expand team skillsets
• Reduce the “bus factor”

24. Drawbacks of Cross-Functional Teams
● More time required for budgeting
● Distractions
● Some team members dislike working in x-functional teams
● Calculating and balancing the time needed for advisors
● Political and departmental resistance

25. Cross-functional teams
• Cross-functional teams do not work in all domains and for all
projects.
• SUCCESS FACTORS ARE:

26. 1. IDENTIFY THE RIGHT PROJECT
●Design and development of new products
●Choosing and implementing new technologies throughout an organization
●Improving the service-profit chain
●Control product costs

27. 2. ASSEMBLE THE RIGHT TEAM
● Product Management
● UX
● Engineering
● Project Management
● Development Management
● Quality Assurance
● Product Design
● Customer Support
● Technical writers
● Production / Shipping
● Design
● Marketing
● Advertising
● Product Marketing
● Marketing Communications
● Field Sales
● Inside Sales
● Sales Engineering
● Professional Services
● Legal
● Accounting

28. 3. EMPOWER THE TEAM
● Team members must be open-minded and highly motivated to learn
and teach
● Team members must come from the all needed functional areas
● A strong team leader with communication skills and a position of
authority is needed
● The team must have the authority and the accountability to
accomplish the mission
● Management must provide resources and support for the team, both
moral and financial
● Greater level of communication across all team members is needed

29. 4. MEASURE [FOR] SUCCESS
● Create real metrics such as estimates vs. real data
● Gather real user feedback and pass on to the entire team
● Improve processes for faster, better customer experience

30. Lean Software Development/Lean IT
• Lean software development means delivering applications efficiently and fast.
• Organizations are under greater pressure than ever to deliver applications faster
and more efficiently.
• Lean software development, focuses on minimizing waste and increasing
efficiency.
• Another approach is DevOps, which bridges the gap between development and
operations in order to deliver software faster, more frequently, and more reliably.
• DevOps is often considered both a philosophy and practice that includes the tools
necessary for application delivery.
• DevOps has been described as an evolution of Agile methodology, an approach
similar in many ways to lean software development.
• DevOps has also been portrayed as a type of lean development system that
merges development and operations into a unified effort.

31. Lean Software Development/Lean IT
• The core idea is to maximize customer value while minimizing waste.
• Simply, lean means creating more value for customers with fewer resources.
• The ultimate goal is to provide perfect value to the customer through a perfect value creation process
that has zero waste.
• Lean thinking changes the focus of management from optimizing separate technologies, assets, and
vertical departments to optimizing the flow of products and services through entire value streams that
flow horizontally across technologies, assets, and departments to customers.
• Eliminating waste along entire value streams, instead of at isolated points, creates processes that need
less human effort, less space, less capital, and less time to make products and services at far less costs
and with much fewer defects, compared with traditional business systems.
• Companies are able to respond to changing customer desires with high variety, high quality, low cost,
and with very fast throughput times. Also, information management becomes much simpler and more
accurate.

32. Lean IT principles
• Seven key principles for how to approach lean software
development:
• Eliminate waste
• Empower the team
• Deliver as fast as possible/deliver fast
• Decide as late as possible/defer decision
• Build Quality in
• See the whole/optimize the whole
• Amplify learning/creating knowledge

33. Lean IT principles
• 1. Eliminate waste
• Lean philosophy regards everything not
adding value to the customer as waste. Such
waste may include:
• unnecessary code and functionality
• delay in the software development process
• unclear requirements
• avoidable process repetition (often caused by
insufficient testing)
• Bureaucracy-complex administrative process
• slow internal communication
• In order to eliminate waste, one should be able
to recognize it. If some activity could be
bypassed or the result could be achieved
without it, it is waste.
To maximize value, we must minimize waste

34. Lean IT principles
• Empower the team.
• The development team should be able to make technical decisions about the product without being
bogged down by external approval processes.
• The team needs to be treated with respect and have the freedom to make the choices necessary to
deliver software as fast and effectively as possible.
• Ongoing learning is an essential component of team empowerment.
• Deliver as fast as possible/deliver fast
• Development teams should release software as often as they can, with short deployment cycles that
provide them with continuous feedback.
• Not only does this improve the product faster, but it also provides development teams with more
information for making informed decisions.
• And it helps eliminate waste.

35. Lean IT principles
• Decide as late as possible/defer the decision
• Software development requires a flexible mindset that encourages team members to keep their options open until they’ve
gathered the data necessary to make proper decisions.
• And the longer they wait, the more informed those decisions.
• Deciding late also makes it easier to accommodate new and evolving circumstances.
• Build integrity in
• Accelerated application delivery should not come at the expense of the application’s integrity or quality.
• Fast does not mean sloppy.
• Customers should get an application that’s easy to use, works as it’s supposed to work, and includes the features they
expect.
• The right tools can help ensure integrity by automating repetitive tasks, implementing comprehensive testing, and
providing ongoing monitoring and feedback.

36. Lean IT principles
• See the whole/optimize the whole
• Software development is immersed in endless detail.
• Development teams should also understand the big picture.
• They should be familiar with the project’s goals, the application’s users, the value that the application provides, and
any other information that offers insights into what they’re trying to achieve as a team and organization.
• Amplify learning:
• Software development should be treated as an ongoing learning process that’s available to all team members.
• Learning can take many forms, such as training, code reviews, project documentation, pair programming,
or knowledge sharing.

37. ITIL
• ITIL is stands for Information Technology Infrastructure Library.
• ITIL is a set of guidelines for IT service management.
• The guidelines cover best practices and tried-and-true processes for everything from incident
management to problem management to change management.
• ITIL is a highly structured methodology designed to increase efficiency and provide statistics for IT
operations.
• ITIL is so highly structured, there are many specific terms and concepts that must be learned in order to
utilize it effectively.
• ITIL has been the intellectual property of AXELOS, who license ITIL materials, offer certifications
and update the ITIL framework.
• ITIL is a proprietary system governed by a private, for-profit company, rather than the amorphous,
ownerless philosophy of DevOps.

38. History of ITIL

39. Benefits of ITIL
• Better reliability
• Improves the decision making
• Better return on investment
• Better quality of service
• Cost-efficient

40. Types of ITIL
• ITIL V1-In 1989, ITIL's goal was to standardize IT service management (ITSM). This initial iteration gave
organizations an overview of how to streamline services and helped admins start thinking about best practices.
• Available management- This ensures that IT services( Infrastructure, Tools,
Processes, roles etc.)available based on the business requirements.
• Capacity Management-It focuses and manages any performance based issues
related to both services and resources
• Contingency Management-It helps in finding vulnerabilities and helps in
preventing such incidents
• Cost management- It helps in delivering and managing cost effective IT assets and
resources.

41. Types of ITIL
• ITIL V2-ITIL v2 offered admins a more applicable and uniform structure for service
support and delivery, and it included actual processes for organizations to follow.
• Service support- it delivers processes for controlling service interruptions.
• Service delivery- IT has a set of principles, policies and constraints which can be
utilized for designing, building and deploying of services delivered by service
providers.
• Version 2 doesn’t have an organized service lifecycle, unlike version 3.

42. Types of ITIL
• ITIL V3-
• Service strategy-It is the process of understanding client requirements
• Service design-It aims in designing IT services efficiently and effectively
• Service transition-It plans, builds, test and deploy the services into
customer environment
• Service operation- it ensures to maintain access to IT services for authorized users
and minimizes the issues of service failure
• Continual Service Improvement (CSI)- it ensures the IT services are continuously
aligned to business needs

43. Types of ITIL
• ITIL 2011 V3
• Service strategy-ITIL 2011 V3 proposed a new service called as service manager for people who creates and implements IT strategy
that align with requirements
• Service design-It coordinates activities across all the designs and implement technical standards to the service design process
• Service transition-It introduces effective change management which minimizes the risk of service failure
• Service operation-the latest update of service operation provides and maintain the processes for effective and efficient handling of
service requests
• Continual Service Improvement (CSI)- It introduces improvement process into a clear and concise seven step model.
• Identify the strategy for improvement
• Define what you will measure
• Gather the data
• Process the data
• Analyze the information
• Present the information
• Implement improvement

44. Types of ITIL
• ITIL 2011 V4
• The four dimension model
• Organization and people-people in organization should understand their roles and responsibilities towards creating a value to the
organization.
• Infromation and technology -this includes information, knowledge and techniques that are required for managing services.
• Partners and supplier-it incorporates contracts and other agreements between organizations and their partners.
• Value streams and processes: A value stream is a series of steps that organization uses to create and deliver products service to a
consumer, whereas a well –defined process can improve productivity within or across organization
• An organization should address all the four dimentions in order to maintain the service quality.
• ITIL service value system-The service value system is set of activity performed by an organization to deliver a valuable output
to the end user
• SVS includes several elements:
• Guiding principles: It has a set of principles that guide by creating value for your customers and your organization.
• Governance: It controls and monitors the performance of the organization
• Service value chain: It is set of activities that business performs in order to deliver a valuable product or service to its customer
• Continual improvement: it is an iterative approach which ensures that an organizations performance meets the customer's expectations
• Practices: It has 34 management practices which are designed for accomplishing organization goals

45. Agile development methodologies
• A small history of Software development processes

46. Agile
• Not a process, it's a philosophy or set of values
• Agile is a time boxed, iterative approach to software delivery that builds
software incrementally from the start of the project, instead of trying to
deliver it all at once near the end.
• It works by breaking projects down into little bits of user functionality
called user stories, prioritizing them, and then continuously delivering
them in short two week cycles called iterations.

47. Agile Manifesto
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

48. Agile Manifesto
• Principles that need to be followed to make a process agile
• Customer satisfaction
• Welcome change
• Deliver Frequently
• Work together
• Motivated team
• Face to face
• Working software
• Constant pace
• Good design
• Simplicity
• Self organization
• Reflect and adjust

49. Advantages of agile methodology
• Large amount of interaction between the client and the project team
• Improved transparency to clients in every phase of project
• The delivery of the output is predictable and can sometimes be earlier than expected
• The cost of the project are predictable and follow rigid schedule
• It allows for changes to refine and re-prioritize the product backlog
• The client can provide priority features allowing the team to ensure maximum project value
• By focusing on the users , the team can deliver value to the customers
• The project is broken into smaller units, with high quality development, testing and
collaboration.

50. Agile methodologies
• Extreme programming(XP)
• It is a framework that enables teams to create high quality software
and improves their quality of life
• It enables software development with the appropriate engineering
practices
• When is it applicable?
• Changing s/w requirements
• To handle risks caused due to new technology
• Working with small development teams

51. Agile methodologies
• Kanban
• This method is used to design, manage and improve flow of system
• Organizations can visualize their flow of work and limiting their work
in progress
• When is it applicable?
• It can be used in situations where work arrives in an unpredictable
fashion
• It also used to deploy work immediately, without waiting for other
work items

52. Agile methodologies
• Lean
• Lean is set of tools and principles that aim to identify and remove
waste to increase the speed of process development
• Maximizing value to client ensuring waste is minimized
• When is it applicable?
• Apply to any sector where there is waste of any form

53. Agile methodologies
• Scrum
• Framework –used by teams to establish a hypothesis ,try it out, reflect
on experience and adjust
• When is it applicable?
• Used when cross functional teams are working on product
development when work is split into more than one 2-4 iterations

54. Agile methodologies
• Crystal
• Is approach to s/w development that focuses on people and their
interactions, rather than tools and processes
• It aimed to steam line processes and improve optimization

55. History of DevOps
• Patrick Debois is often referred to as the father of DevOps.
• Debois wanted to learn IT from all possible perspectives.
• 2007:
• It all started in 2007 when he started working on a robust data center migration where he was
responsible for testing.
• it wasn’t possible to bridge the significantly wide gap between the two worlds i.e. development and
operations
• 2008:
• It was in 2008 at an Agile conference conducted in Toronto, Canada, when a man named Andrew Shafer
attempted to arrange a meetup session that was called “Agile Infrastructure.”
• 2009:
• The first conference named DevOpsDays was held in Ghent Belgium. Belgian consultant and Patrick
Debois founded the conference.
• With the significant amount of attention that this event gathered from experts in both fields, there are
lively debates held over Twitter where users used the hashtag #DevOps.

56. History of DevOps
• 2011:
• It was in March 2011 when Cameron Haight of Gartner offered his predictions for DevOps to take a course in the
following few years.
• With his positive outlook, many other members and users came and began implementing DevOps with wide ideas.
• Soon enough, enterprises regardless of how small or big scale they are started adopting DevOps.
• DevOps is one of the most internal frameworks in the workspace and were beginning to adopt these new practices. With
DevOps earning more and more fame, it is a thing similar to Agile.
• 2015:
• DevOps incorporated into SAFe. SAFe is rapidly gaining traction in the enterprise arena, where DevOps is adopted and
scaled across.
• 2016:
• DevOps is the new norm for high-performing companies “Clearly, what was state of-the-art three years ago is just not
good enough for today’s business environment.”
• 2018:
• State of DevOps report defines 5- stage approach From level 0 to 5, a descriptive, pragmatic approach is introduced to
guide teams and mature DevOps initiatives, a report sponsored by Deloitte
• 2019:
• Enterprises embed more IT functions in their teams next to ‘Dev’ and ‘Ops’ “organizations are embedding security
(DevSecOps), privacy, policy, data (DataOps) and controls into their DevOps culture and processes.”

57. DevOps stakeholders
• “A STAKEHOLDER IS EITHER AN INDIVIDUAL, GROUP OR ORGANIZATION WHO IS IMPACTED BY THE
OUTCOME OF A PROJECT. THEY HAVE AN INTEREST IN THE SUCCESS OF THE PROJECT, AND CAN BE
WITHIN OR OUTSIDE THE ORGANIZATION THAT IS SPONSORING THE PROJECT.”
• One way to consider the stakeholders for DevOps:
• Dev Includes all people involved in developing software products and services including but not
exclusive to:
• Architects
• business representatives
• Customers
• product owners
• project managers
• quality assurance (QA)
• testers
• Analysts
• suppliers

58. DevOps stakeholders
• Ops Includes all people involved in delivering and managing software products
and services including but not exclusive to:
• Information security professional
• systems engineers
• system administrators
• IT operations engineers
• release engineers
• database administrators (DBAs)
• network engineers
• support professionals
• third party vendors
• supplier

59. Key Goals of DevOps
• Ensures effective collaboration between teams
• Effective collaboration in any process relies on shared ownership.
• During the development process, all those involved should embrace the fact that everyone is equally responsible for the entire
development process.
• Whether it is development, testing, or deployment, each team member should be involved.
• They should understand that they have an equal stake in the final outcome.
• In the DevOps paradigm, passing of work from one team to another is completely defined and broken down.
• This accelerates the entire process of development since collaboration between all the teams involved is streamlined.
• Creates scalable infrastructure platforms
• The primary focus of DevOps is to create a sustainable infrastructure for applications that make them highly scalable.
• According to the demands of the modern-day business world, scalable apps have become an absolute necessity.
• In an ideal situation, he process of scaling should be reliable and fully automated.
• As a result, the app will have the ability to adapt to any situation when a marketing effort goes viral.
• With the app being scalable, it can adjust itself to large traffic volumes and provide an immaculate user experience.

60. Key Goals of DevOps
• Builds on-demand release capabilities
• Companies must focus on keeping their software in a ‘releasable’ state.
• Continuous delivery will allow the software to add new features and go live at any stage.
• DevOps aims to automate the process of release management because it has a plethora of advantages.
• Automated release management is predictable, fast, and very consistent. Moreover, through automation,
companies can release new versions as per their requirements.
• Automated release management also has complete and thorough audit trials, as these are essential for compliance
purposes.
• Provides faster feedback
• Automating monotonous tasks such as testing and reporting will accelerate the process of rapid feedback.
• Since the development team will know what has to change, it can roll out the updated version faster.
• In addition, the team can better understand the impact of the changes that it has done in the software lifecycle.
• A concrete understanding of changes will assist team members in working efficiently in tandem.
• With rapid feedback, the operations team and developers can make better decisions collectively and enhance the
app’s performance.

61. DevOps Terminology
• Agent: An Agent is a program residing on particular physical servers to execute multiple
processes on that very server.
• Agile Software Development: A philosophy and methodology for software development,
with an emphasis on user feedback, the quality of software, and the capability of fast
response to new product requirements and other changes.
• Application Release Automation (ARA): The deployment of software releases to
several different environments and their configurations, but with minimal human
involvement.
• Behavior-Driven Development (BDD): An Agile software development methodology
that encourages collaboration and teamwork between software developers, Quality
Assurance, and business participants in any given software project.
• Build Agent :An agent used in continuous integration that can be installed locally or
remotely, depending on the server. The agent sends and receives messages relating to the
creation of software builds.

62. DevOps Terminology
• Canary Release: Referencing how canaries were brought into coal mines to test the air, this is a go-live strategy where
a new application version gets released to a small batch of production servers, then monitored closely to determine if it
runs as it’s supposed to. If the version proves to be stable, it’s rolled out to all of the production environment.
• Capacity Test: This test determines the user capacity that a computer, server, or application can support right before
failing.
• Commit: A means of recording changes to a repository, then adding a log message, is outlining the selfsame changes.
• Configuration Drift: When uncommitted hotfixes and manual changes are applied to software and hardware
configurations, the latter becomes inconsistent with the master version. This is often a common reason for technical
debt.
• Configuration Management: An engineering process for creating consistent system settings, including physical
attributes, performance, and function, as well as keeping them that way. This is meant to keep a system aligned with its
initial design, requirements, and operational information.
• Containerization: An operating system (OS) level method of virtualization employed for the deployment and running
of distributed applications without having to launch an entire virtual machine for every use.
• Containers: A software package is a standardized unit that includes everything needed to run the software, including
code and dependencies. Containers enable an application to run in a fast and reliable manner when it’s moved from one
computing environment to another.

63. DevOps Terminology
• Continuous Delivery: An approach to software engineering in which integration, automated testing, and automated
deployment capabilities continuously allow new software to be repeatedly developed and deployed swiftly and with
a high degree of reliability, but with little human intervention.
• Continuous Deployment: A development practice for software releases in which every code commit that passes
through automated testing is sent to the production environment, which results in a large number of daily production
deployments. It accomplishes the same tasks as Continuous Delivery does, but the former is fully automated,
completely removing the human element.
• Continuous Integration: A software development practice where developers merge all of their working copies of
code into a shared repository often, ideally several times a day.
• Continuous Quality: A systemic process that involves finding and fixing any software glitches and bugs during
every part of the software development cycle. It is considered a part of both the continuous integration and
continuous delivery processes.
• Continuous Testing: The process of running automated tests as part of the software delivery pipeline across all
environments to obtain immediate feedback on the code build quality.

64. DevOps Terminology
• Dark Launch :A development strategy in which a new version of the code, one that implements new features, is
released to your team or a subset of the organization’s users, but is either not visibly activated or is only partially so. This
process is similar to a Canary Release.
• Deployment: The bringing together of all the processes necessary to that make hardware or a software program
available for use, which includes all installations, configuring, testing, and moving that program to its home
environment.
• Deployment Pipeline: An automated multi-step process that takes software from version control to making it available
to an organization’s users.
• DevOps: A fusion of the words “development” and “operations,” describing a design philosophy where development
and operations teams collaborate on software development and deployment. The goal of this new process is to increase
software production agility while achieving business goals.
• DevSecOps : The process of bringing security into DevOps methodology and giving it a significant role.
• Event-Driven Architecture: A software architecture pattern where the system both produces messages or events, and is
built to react to, consume, and detect other events.
• Exploratory Testing: A testing process where human testers are given free rein to test areas that may potentially have
issues that automated testing couldn’t detect.
• Fail Fast: A design strategy characterized by a rapid turnaround, where an attempt fails, is reported on time, feedback is
quickly returned, the changes are made, and a new attempt is made.

65. DevOps Terminology
• Gemba : This term means "the real place" in Japanese, and in the context of the business world, it often means
“where value is created.”
• Issue Tracking: A process where programmers and quality assurance experts can track the flow of both defects and
new features, starting at identification and concluding with resolution.
• Lead Time: In the world of manufacturing, this is the time involved in moving a work in progress (WIP) to a finished
state. In the world of DevOps, the context changes to moving code changes to production.
• Mean Time Between Failures (MTBF): A calculation of the average amount of system downtime resulting from
failures, it measures the reliability of a given system or components.
• Mean Time to Recovery (MTTR): The average amount of time needed for a system or component to recovering from
failure and be returned to production status.
• Microservices: A pattern of architectural design wherein complex applications is composed of a suite of smaller
modular services or components that communicate with each other using language-agnostic APIs.
• Production: The last stage in the software deployment pipeline, where the target audience will finally use the
application.

66. DevOps Terminology
• Regression Testing: The testing of a software application to confirm that any recent changes made to an application
haven’t adversely affected any features that were already in place.
• Release Orchestration: Using tools such as XL Release to manage software releases, taking them from the
development stage to the actual software release. This includes the definition, automation, security, monitoring, and
control of the manual and automated tasks
• Rollback: Returning a database or program to a previous state, either manually or automatically.
• Source Control: Also called revision control or version control, this is a process for storing, tracking, and managing
changes to code, documents, websites, and other pieces of information. This is usually achieved by generating branches
off of the software’s stable master version, then merging the stable feature branches back into the latter.
• Staging Environment: An almost replica of a production environment for software testing. It’s used to test the newest
software iteration before it goes live, using an environment that mimics live production as close as possible.
• Technical debt: The extra development work that results when an easily implemented code is used in the short run,
rather than the application of the best overall solution. In other words, the cost of a short-cut.
• Test Automation: Using specialized software (apart from the software being tested) to control the execution of tests
and compare actual outcomes against predicted outcomes.
• Unit Testing: A testing strategy that involves isolating the smallest unit of testable code is separated apart from the rest
of the software and running tests on it to see if it functions as it’s supposed to.

67. DevOps vs Agile
• What is DevOps?
• DevOps is a software development method which focuses on
communication, integration, and collaboration among IT
professionals to enables rapid deployment of products.
• What is Agile?
• Agile Methodology involves continuous iteration of development
and testing in the SDLC process. This software development
method emphasizes on iterative, incremental, and evolutionary
development.

68. Agile Vs. DevOps

69. Agile Vs. DevOps

70. Agile Vs. DevOps

71. Agile Vs. DevOps