Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £29.99 £19.99. New subscribers only. T&Cs apply

Find out more

DevOps Practices and Habits

.
16.9
Let’s talk about the building blocks of DevOps and get a quick overview of what those might be. Now, let’s start with the seven DevOps practises. And we have configuration management, release management, continuous integration, continuous deployment, application performance monitoring, test automation, and infrastructure as code. Now, these come from a wonderful talk Sam Guckenheimer, also of Microsoft, gave. You can listen to it there in this URL. But I want to very briefly talk about some of these. Configuration management, understanding what we’re deploying, how we’re deploying it, what is the configuration of what’s going into production. Release management, understanding and controlling how we’re building a release pipeline that we can trust.
62.4
Continuous integration, this idea that we should be testing our code, compiling it at every single check-in, every single version control commit. Continuous deployment, getting it out into a test environment, at the very least, and potentially all the way out to production on a very rapid cadence. You’ll see the word “continuous” quite a bit when we’re talking DevOps. Applications performance monitoring is another one that sometimes gets short shrift with DevOps. And here, we’re looking at, in production, monitoring and watching our applications to get not just performance and error information, but usage information– insights onto how we can then evolve our application in the future. Test automation is one of the most difficult of the core DevOps practises.
113.7
And that’s automating your tests– not just unit tests from the developer, but potentially deployment tests, integration tests, user experience tests, or UI tests. All of these are very difficult to get in place in your pipeline, and we’ll be talking about them in other modules as well. And then infrastructure as code. I’m going to talk about this one last. It’s one of my favourites. It’s making sure that when we deploy our code, we’ve got a related infrastructure. And that infrastructure is also checked into version control. So if there’s anything that we need to change in our environment, we should be able to do that in an automated fashion.
154.5
In other words, we want to change the infrastructure, we simply change configuration, which is checked in as code. And that gets pushed up and actually does the changes through something like Chef, or Puppet, or desired state configuration, or any number of tools. Now let’s talk about the seven habits for DevOps. Again, same location. This is Sam Guckenheimer. And these are the things that can help drive the right culture. Because remember, it’s not just about the tools. And team autonomy and enterprise alignment is one of my favourites. And Sam tells it brilliantly, but I want to come back to it. There’s this balance between autonomy and letting teams do what they want to do and alignment.
196.4
And we need to get the business alignment mapped with that enterprise or that team autonomy. Rigorous management of technical debt. Technical debt can come up and bite you and slow down your ability to deliver code effectively and value. And so we want to focus on that and manage it rigorously– take time in our schedule to reduce that technical debt. Another one is focusing on the flow of customer value. This is a mind shift. It’s a strong one for development and operations. Developers need to think not, I got my code checked into version control, now it’s off to be tested and deployed.
236.8
The developer mindset, along with the tester and the IT mindset, needs to be, we get credit when the customer gives us their first piece of feedback from actually using that feature. And that mindset is one that helps drive towards that DevOps culture strongly. Evidence gathered in production is another one that I appreciate. We’re looking at production. We’re going to figure out ways to gather insight from what our customers are doing in production to inform new ways of doing things, and that leads into hypothesis-driven development. Sometimes, even in an agile world, you don’t know exactly what you’re going to build. Instead, you build a hypothesis.
280.2
You think, I believe that if we do this one piece of code, it’s going to result in this type of beneficial behaviour and usage patterns for our end users. And you try it with the smallest possible code that you can put out there, and then you find out did it have the impact. If it didn’t, don’t invest further. Pull it back. There are lots of great examples of hypothesis-driven development and industry. And it’s one of those things, the curiosity and the scientific, method that really drives the culture in DevOps teams. Live site culture, this is a hard one. This is a hard one.
317.9
And it’s this goal, this desire from the entire organisation to say, we need to get to production. It’s getting things to production. It’s pushing the production. It’s this mindset that says, there’s no place like production, there’s no place like production. And to do that, we need to shift a lot of people’s attitudes. You don’t get benefit from any code that’s not in production. If it’s not in production, you’re not able to impact the lives of your end users. Get that focus. Get that desire to go to live site. And the last one is managing infrastructure as a flexible resource. And I love this one. I love that Sam put it in habits.
360.5
Because of all of those, it sounds so technical, but it’s not. It’s this idea that we need to treat our infrastructure as, you might hear it, cats versus cattle. We treat them as cattle, not as pets. We don’t know their names. We’re willing to get rid of an infrastructure and replace it with a brand new infrastructure if necessary. We have a definition of our infrastructure as code, so we should be very happy with throwing away our old infrastructure and spinning up a new one in its place and then just swapping over to that when we go live with our new version. These attitudes, these behaviours, are things which can really drive that DevOps culture.
404
So those are some of the foundational aspects of DevOps.

So far in this activity, we have looked at fast delivery cycles and the DevOps lifecycle. practices. In this step, we will learn about the first building blocks of DevOps.

To be successful in the implementation of DevOps, organisations need to focus on the foundational aspects of DevOps. DevOps is about a culture that drives attitudes and behaviours. These include practices and habits that can be addressed to ensure effective transitioning to DevOps.

Hexagons encasing each of the seven practices listed below Hexagons encasing each of the seven habits listed below

The Seven Key DevOps Practices:

  • Configuration management: Understanding of what you are deploying, how you are deploying it and what the configuration is of items going into production.
  • Release management: Understanding and controlling how you are building a release pipeline that you can trust.
  • Continuous integration: Testing code and compiling it at every check-in and version control commit.
  • Continuous deployment: Getting code into a test environment and into production on a rapid cadence.
  • Infrastructure as Code: Making sure that, when you deploy your code, you have related infrastructure, checked into version control, for deploying changes to your environment in an automated fashion.
  • Test automation: Automating unit, deployment, integration and user experience tests.
  • Application performance monitoring: Monitoring production to get performance information, error information and usage information.

The Seven DevOps Habits

  • Team autonomy and enterprise alignment: Mapping the business alignment with enterprise or team autonomy.
  • Rigorous management of technical debt: Scheduling time to reduce technical debt.
  • Focus on the flow of customer value: Developing an all-encompassing mindset if customer value. Think like a developer, a tester, IT and the customer.
  • Hypothesis-driven development: Developing releases based on hypotheses extracted from customer insights.
  • Evidence gathered in production: Gathering insights from what customers are doing in production.
  • Live-site culture: Fostering a production mindset that encourages the drive to production.
  • Manage infrastructure as a flexible resource: Treating infrastructure as cattle and not as _cats to avoid being too attached to the infrastructure to get rid of it if it does not work for you anymore.

With these attitudes and behaviours, you can really drive a DevOps culture in your organisation.

Join the discussion

Which of these points most appeals to your situation?
Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now