5 DevOps Best Practices

devops and continuous delivery are important ideas these are the ideas behind what i think of as a genuine engineering approach to software development if you want to sustain our ability to continuously deliver valuable software into the hands of our users then we must take seriously the ideas of devops so here are five of the best practices that evidence shows make devops work in real projects and my guess is that some of these might surprise you [Music] hi i'm dave fardy of continuous delivery welcome to my channel please do hit subscribe and the bell notification icon so that we can keep you informed of new episodes if you find if you find this one interesting as i've said before i believe that the idea of being able to regularly repeatably and sustainably deliver useful software into the hands of our users is a driving force for high performance high quality software development i call this continuous delivery but most people call it devops whatever you call it it's currently the state of the art in software development practice this is true for some very deep and profound reasons this is not just the most recent fad in our industry and it's not going to change in many ways this is a measurably better way of working the state of devops report and the fantastic accelerate book that accompanies it are important things important progress for our industry they provide evidence of a correlative model that allows us to make certain predictions about the behavior of software development teams and their likelihood of success i like the fact that these words are carefully couched the authors don't over claim they don't cut claim that x causes y or that do x and you will get y rather their claim is that the evidence statistically demonstrates that if you practice x then it's related to the outcome of y if you do x you're more likely to get y there's no golden ticket there's no silver bullet that's going to automatically generate great software it's still going to take ingenuity and the cleverness of of people doing great work there are no guarantees it's more complex than that so as we've discussed before some of these predicted outcomes are profoundly important so here are five of the behaviors that predict a high quality of success the five best practices for devops one test automation can we safely release change into production without the need for manual regression testing many organizations use descriptions of tests like this effectively a a script that a human being is forced to follow as though they're some kind of testing robot this is slow it's low quality expensive unreliable error prone fragile it results in hard to understand test cases this is not a high quality process but it's probably one of the most common approaches instead we should be looking at a an exhaustive automated testing strategy we want to be able to test all of the things every behavior of our system that we believe is important we should be able to value that with an automated test of some kind this is important because humans aren't repeatable and reliable we're great at many things but not at being repeatable and reliable so let's employ computers and software for the things that they are good at being repeatable and reliable and let's employ people for the things that they're good at being exploratory and and evaluating mixed messages in complex decision-making processes that's where we shine and where computers don't do so well so let's focus on us doing those things second in my list deployment automation can we deploy to a test or production environment at the push of a single button is this a simple process to be able to get our pro software up and running and available for use wherever it is that we want it deployment automation 2 goes to repeatability and reliability of our process we must control the variables if we want to be able to reliably and repeatably deploy our software wherever we want it we need to be able to understand the state that the environments that we're going to put these things into the environment in which our software operates is a dependency of the software i'd like to know that this particular release candidate will work definitively with this version of the environment configuration we start off with deployment automation and fairly quickly we end up at infrastructure as code and being able to automate all of these things third in my list trunk based development do i merge changes to trunk origin master head whatever you call it at least once per day if you don't your practices are not the most highly correlated with success this is probably one of the most contentious things that i talk about in this context i get into lots of debates and discussions on this topic i do plan to cover this in much more detail in a full episode in future to explain my thinking on this topic but for now here are a few quotes to just kind of pass on the message that i'm trying to deliver the data from the 2015 version of the state of devops report from puppet labs is pretty clear it says trunk based development predicts higher throughput and better stability and even higher job satisfaction and lower rates of burnout we have found that having branches or forks with very short lifetimes less than a day before being merged into trunk and less than three active branches in total are important aspects of continuous delivery and all contribute to higher performance so does merging code into trunk or master on a daily basis the man who invented git linus torvals says this if you merge every day suddenly you never get to the point where you have huge merge conflicts that are hard to resolve so trump-based development is an important idea we'll talk about that in more detail in another day fourth on my list shift left on security is all security testing and validation included as a function of the deployment pipeline while i agree with this how can i not there's data my guess is that this is a symptom of a broader issue first the jargon shift left what do we mean by shift left what that means is that we're trying to shorten the feedback loop we're trying to move the the the the learning that we gain closer to the point of origin and that's for it's rather parochial in that it's based on left left to right readers but it's saying it's moving it to the start so we want to bring security testing right up in earlier in the process shift left so that we can learn more quickly as i said i think that this is a symptom of a broader issue my description of a deployment pipeline is that it goes from commit to releasable outcome and whatever constitutes a releasable outcome is fair game it's within scope of the deployment pipeline and so we should be trying to optimize to get the best feedback that we can on any activity within that scope whatever it determines whatever it is that determines the releasability of our software we're going to evaluate within the deployment pipeline cycle so security is certainly an attribute of this but so is compliance so is scalability so is resilience and so are lots of other features that we might consider important so i think that this is absolutely correct but i think that that when sampling this in the state of devops report this this question then i think that people were focusing on security rather than the general case of all of these things that constitute the releasability of our software last in my list of five things loosely coupled architecture can we make changes in one part of our system and not need to test the whole system before releasing into production again i don't disagree with this i think that's an absolutely valid approach and it's a really nice property of a system to be compartmentalized in the way in which this idea describes the driver for an effective engineering process is fast efficient high quality feedback you can achieve this in two ways you can decompose your system into independently deployable modules that are each easier to to build and test and evaluate because they're smaller and simpler you build test and deploy the pieces independently of one another in this model it's very effective and it goes to this example but there's another perfectly viable alternative that people often miss in their striving for a more decoupled architecture we can also choose to build test and deploy everything together that works too for the second one you need to invest heavily in your deployment pipeline you're probably going to end up with a more sophisticated deployment pipeline in order to give you the speed and quality of feedback that you need on this bigger scale of software but this is actually a remarkably scalable technique going to need feedback enough that you can still get a clear picture of your progress multiple times per day but now for the entire system my guess and i don't have the data to back up this guest so it is only a guess but the real win here is to get a releasable outcome multiple times per day decomposing your architecture into smaller more independent units is really optimizing to achieve that end but so is evaluating your system efficiently enough to be able to evaluate it all together in one step there are trade-offs between these two strategies they are but they are both equally viable if you can manage all of that you're doing well you will have a great picture of your progress and will be able to stay on top of the quality of your system as a result so there are five best practices for devops oh and for continuous delivery thank you very much for watching you

Channel: Continuous Delivery

Views: 9,288

Keywords: devops best practices, what is devops, devops, dev ops, devops engineer, devops tutorial for beginners, devops explained, Continuous Delivery, cicd, Dave Farley, devops training, software engineering, continuous delivery best practices

Id: rcBFpwaB7Qk

Length: 12min 2sec (722 seconds)

Published: Wed Sep 30 2020