Introduction and Basics of DevOps( Development and Operations). pptx

Introduction to DevOps

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 e nough 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. Fundamentals of MVP 13 Build:  Build the product that will cover must have features to solve the priority problem your product intends to solve Measure:    Measure the success of your product with limited features .  Take user feedback , do user testing , and discover if people are willing to use (and pay for) . Learn : After feedback for your product either receiving the fix/improve the feature or add on another feature that continues to solve the problem and add value.

14. 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.

15. 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.

16. 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 .

17. MVP Matrix

18. 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.

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

20. Cross -functional teams

21. Cross-functional teams

22. Cross Functional Teams: Centered Around the Product

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

24.  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”

25. 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

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

27. 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 

28. 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 

29.  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 

30. 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

31. 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.

32. 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.

33. 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

34. 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

35. 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.

36. 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.

37. 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.

38. 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.

39. History of ITIL

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

41. 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.

42. 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.

43. 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

44. 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

45. 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

46. Agile development methodologies

47. Agile development methodologies A small history of Software development processes

48. Waterfall  development  process You complete one phase (e.g. design) before moving on to the next phase (e.g. development) You rarely aim to re-visit a ‘phase’ once it’s completed . That means, you better get whatever you’re doing right the first time ! You don’t realize any value until the end of the project You leave the testing until the end. You don’t seek approval from the stakeholders until late in the day This approach is highly risky, often more costly and generally less efficient than Agile approaches

49. 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.

50. 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 

51. 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

52. 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.

53. 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

54. 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

55. 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

56. 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

57. 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

58. 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. 

59. 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.” 

60. 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

61. 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

62. 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.

63. 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.

64. 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.

65. 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.

66. 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.

67. 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.

68. 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.

69. 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.

70. 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.

71. Agile Vs. DevOps