DevOps practices

- [Instructor] Having learned the DevOps principles, what are some of the DevOps practices? The first DevOps practice is to have a source of truth for the software code, documentation, device configuration or network state. This usually means a distributed version control system that all team members could refer to. The second DevOps practice is to have automated testing. Because we're trying to put our emphasis on small incremental changes, we should aim to have automated testing that ensures we do not accidentally break things when these changes are made. We should aim to have a system of continuous integration. This means having a system for each developer and operations personnel put their changes into the source control, or the source of truth, as quickly as possible. This change could range from software code, device state, network configuration, and so on. It should also be pointed out the continuous integration means to have the changes make their way to the source of truth or version control system and does not equate to deployment. Once we have continuous integration, we could take the next step for continuous delivery or continuous deployment. What is the difference between the two? Sometimes we do not have control over deployment and just delivery, such as when we have changes in a updated doc or image or when we have a mobile app that is only deployed when the client pulls the changes in. Another DevOps practice is to implement a high trust culture for individuals and between teams. Examples of this practice could be peer review for changes as well as a blameless culture between developers and operators. As mentioned, continuous integration and deployment is a practice where developers integrate the change into a version control repository. Each integration could be verified by an automated testing process that could catch errors. Optionally, the change could be deployed either automatically or with a manual push. The system is crucial to the DevOps practice. In this course, we will use a open source project called GitLab with built-in version control, issue tracking, code review, continuous integration, continuous delivery, and much more. One of the newer job roles as a result of the DevOps movement is the rise of site reliability engineering, or SRE. In the words of Google, SRE is what you get when you treat operations as if it is a software problem. The goal of SRE is to protect, provide for, and monitor the software and system behind services. One of the main concepts of SRE is the idea of the error budgets. It is the uptime of the service as perceived by the user measured in time. As Google is the company that started the SRE movement, feel free to follow the link to find out more about the SRE practices via the link provided. As network engineers continue to adapt DevOps practice, sometimes you will hear the people refer to the job function and role as network DevOps. Please feel free to check out the SRE description from Google or Network Computing's article about the coming together of DevOps into network engineering. There are lots of practical examples of applying DevOps in the real world.