| DevOps Fundamentals |
IntroductionDevOpsDefinitionDevOps (short for development and operations) is a set of tools and practices, designed to shorten the software developement lifecycle process DevOps is the union of people, processes, and products to enable the continuous delivery of value to our end users. Value is the most important word of that definition. In broad terms, DevOps is an approach based on lean and agile principles in which business owners and the development, operations, and quality assurance departments collaborate to deliver software in a continuous manner that enables the business to more quickly seize market opportunities and reduce the time to include customer feedback. DevOps applies agile and lean principles across the entire software supply chain. It enables a business to maximize the speed of its delivery of a product or service, from initial idea to production release to customer feedback to enhancements based on that feedback. Because DevOps improves the way that a business delivers value to its customers, suppliers, and partners, it’s an essential business process, not just an IT capability. Why DevOps Benefits of DevOpsDevOps provides significant return on investment in three areas:✓ Enhanced customer experience ✓ Increased capacity to innovate ✓ Faster time to value Enhanced customer experienceDelivering an enhanced (that is, differentiated and engaging) customer experience builds customer loyalty and increases market share. To deliver this experience, a business must continuously obtain and respond to customer feedback, which requires mechanisms to get fast feedback from all the stakeholders in the software application that’s being delivered: customers, lines of business, users, suppliers, partners, and so on. In today’s world of systems of engagement, this ability to react and adapt in an agile manner leads to enhanced customer experience and loyalty.Increased capacity to innovateModern organizations use lean thinking approaches to increase their capacity to innovate. Their goals are to reduce waste and rework and to shift resources to higher-value activities.Faster time to valueSpeeding time to value involves developing a culture, practices, and automation that allow for fast, efficient, and reliable software delivery through to production. DevOps, when adopted as a business capability, provides the tools and culture required to facilitate efficient release planning, predictability, and success. The definition of value varies from organization to organization and even from project to project, but the goal of DevOps is to deliver this value faster and more efficiently.Seeing How DevOps WorksThe DevOps movement has produced several principles that have evolved over time and are still evolving. Several solution providers, including IBM, have developed their own variants. All these principles, however, take a holistic approach to DevOps, and organizations of all sizes can adopt them. These principles are ✓ Develop and test against production-like systems✓ Deploy with repeatable, reliable processes ✓ Monitor and validate operational quality ✓ Amplify feedback loops Develop and test against production-like systemsThis principle stems from the DevOps concept shift left, in which operations concerns move earlier in the software delivery life cycle, toward development 
The goal is to allow development and quality assurance (QA) teams to develop and test against systems that behave like the production system, so that they can see how the application behaves and performs well before it’s ready for deployment. The first exposure of the application to a productionlike system should be as early in the life cycle as possible to address two major potential challenges. First, it allows the application to be tested in an environment that’s close to the actual production environment the application will be delivered to; and second, it allows for the application delivery processes themselves to be tested and validated upfront. From an operations perspective, too, this principle has tremendous value. It enables the operations team to see early in the cycle how their environment will behave when it supports the application, thereby allowing them to create a fine-tuned, application-aware environment. Deploy with repeatable, reliable processesAs the name suggests, this principle allows development and operations to support an agile (or at least iterative) software development process all the way through to production. Automation is essential to create processes that are iterative, frequent, repeatable, and reliable, so the organization must create a delivery pipeline that allows for continuous, automated deployment and testing. Monitor and validate operational qualityOrganizations typically are good at monitoring applications and systems in production because they have tools that capture production systems’ metrics in real time. But they monitor in a siloed and disconnected manner. This principle moves monitoring earlier in the life cycle by requiring that automated testing be done early and often in the life cycle to monitor functional and non-functional characteristics of the application. Whenever an application is deployed and tested, quality metrics should be captured and analyzed. Frequent monitoring provides early warning about operational and quality issues that may occur in production. These metrics should be captured in a format that all business stakeholders can understand and use. Amplify feedback loopsOne goal of DevOps is to enable organizations to react and make changes more rapidly. In software delivery, this goal requires an organization to get quick feedback and then learn rapidly from every action it takes. This principle calls for organizations to create communication channels that allow all stakeholders to access and act on feedback. ✓ Development may act by adjusting its project plans or priorities.✓ Production may act by enhancing the production environments. ✓ Business may act by modifying its release plans. Devops Reference ArchitectureA reference architecture provides a template of a proven solution by using a set of preferred methods and capabilities. The DevOps reference architectures help practitioners access and use the guidelines, directives, and other material that they need to architect or design a DevOps platform that accommodates people, processes, and technology A reference architecture provides capabilities through its various components. These capabilities in turn may be provided by a single component or a group of components working together. Therefore, you can view the DevOps reference architecture, from the perspective of the core capabilities that it’s intended to provide. As the abstract architecture evolves to concrete form, these capabilities are provided by a set of effectively enabled people, defined practices, and automation tools. 
The DevOps reference architecture proposes the following four sets of adoption paths: ✓ Plan and measure✓ Develop and test ✓ Release and deploy ✓ Monitor and optimize Getting started with DevOpsThe term DevOps was introduced in 2007-2009 by Patrick Debois, Gene Kim, and John Willis, and it represents the combination of Development (Dev) and Operations (Ops). It has given rise to a movement that advocates bringing developers and operations together within teams. This is to be able to deliver added business value to users more quickly and hence be more competitive in the market. The communication and this link between Dev and Ops does, therefore, allow a better follow-up of end-to-end production deployments and more frequent deployments of a better quality, saving money for the company. To facilitate this collaboration and improve communication between Dev and Ops, there are several key elements in the processes to be put in place, as in the following examples:- More frequent application deployments with integration and continuous delivery (called CI/CD) - The implementation and automation of unitary and integration tests, with a process focused on Behavior-Driven Design (BDD) or Test-Driven Design (TDD) - The implementation of a means of collecting feedback from users Monitoring applications and infrastructure Implementing CI/CD and continuous deploymentWe saw earlier that one of the key DevOps practices is the process of integration and continuous delivery, also called CI/CD. In fact, behind the acronyms of CI/CD, there are three practices: ✔Continuous integration (CI)✔Continuous delivery (CD) ✔Continuous deployment Continuous integration (CI)In the following definition given by Martin Fowler, there are three key things mentioned, members of a team, integrate, and as quickly as possible: "Continuous Integration is a software development practice where members of a team integrate their work frequently... Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible."Continuous delivery (CD)Once continuous integration has been successfully completed, the next step is to deploy the application automatically in one or more non-production environments, which is called staging. This process is called continuous delivery (CD). The tools set up for CI/CD are often completed with others solutions, which are as follows:A package manager: This constitutes the storage space of the packages generated by CI and recovered by CD. These managers must support feeds, versioning, and different types of packages. There are several on the market, such as Nexus, ProGet, Artifactory, and Azure Artifacts. A configuration manager: This allows you to manage configuration changes during CD; most CD tools include a configuration mechanism with a system of variables.
|
