Introduction
If you have been involved in any sort of software delivery over the past few years, you have probably heard about DevOps. It's a common term that means many different things to many different people. This article covers 6 key aspects of a successful DevOps strategy and is written to shed some light on what DevOps really means for modern software development.
What Is DevOps
Donovan Brown, one of Microsoft’s Cloud Developer Advocates, coined a popular definition for DevOps back in 2015:
"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."
He kept it broad, but that was intentional. DevOps is not tied to any particular tool or process; you can't install it on a server, and no book is going to explain it in its entirety. It is simply a shift in priorities, mindset and the types of tools that you use to get the job done.
The 6 sections listed below are written to expand this definition and elaborate on what this might involve. It’s not guaranteed to be a definitive list, but to initiate the thought process on what is involved.
6 Key Pillars of a Successful DevOps Strategy
Collaborate
DevOps is founded on the idea of development and operations teams working together and helping each other out. But it goes beyond just those two teams, everyone involved in software delivery need to be talking, working together, and have a strong understanding of each other’s motives. If tensions and distrust exist among team members, the blame games start, and product quality suffers.
Team leaders need to be responsible for ensuring that teams are getting along and communicating, this could be through frequent team building events, daily status meetings, team-wide wikis, or even moving desks around so people can sit together.
But take note: DevOps is not about making everyone responsible for everything – because then nobody is responsible for anything. Instead, the idea is to create a culture that, when something goes wrong it doesn't matter who caused it, it's everyone's problem.
Focus on the End User
To deliver software that benefits users, every team member – developers, analysts, designers, operations, management – needs to keep the user front of mind.
There are many tactics for keeping everyone focused on the customer, such as:
- Immersing everyone in customer environments, observing people using the products that the team is building.
- Putting every team member on the on-call roster at different times, so everyone has an idea of what happens and who is affected when things go wrong.
- Having all team members respond to customer feedback.
- Get team members to use the products that they're building on a daily basis.
These tasks are often given to a small subset of the team (who usually don't make the key decisions about the product). Involving everyone brings the end user to the centre of everyone’s mind, and people are more likely to make decisions that deliver value to the end user.
Automate
Humans are excellent at providing creative solutions to problems, but we're also excellent at making mistakes. When people are involved in the release of a piece of software, you're greatly increasing your chance of something going wrong.
If you want to be successful in delivering any software, you need to invest in automating any repeatable manual task. The benefits are too good to pass up:
- Eliminate the chance of anyone making mistakes.
- Reduce the time taken to complete the tasks.
- Enable more frequent deployment of features to users.
- Boost morale by keeping people on new, creative tasks rather than repeating things they've already done.
- Free up your infrastructure experts to make improvements to deployment processes, security, and quality of the environment.
Automation takes a significant time investment, and you're always going to be finding more to do, but with every task you automate things become faster and more consistent. It's a never-ending journey, you just have to start somewhere.
Build in the Cloud
To be successful when delivering modern software, you need to be able to respond to market and user demand quickly and make drastic changes at any time. This is not possible if you're running your own datacentres; you're always going to be hamstrung by time required order, receive and install the necessary hardware – then you're locked into that decision for years.
If you're running in the cloud, you can do things you could never do when running your own datacentre. You can:
- Get started with the latest services and hardware in an afternoon.
- Change direction at any time – you're never bound by previous hardware purchases.
- Pay for exactly what you need by only scaling up your hardware during peak times.
- Get instant access to datacentres where your end users are.
If you want to keep up with the best in the industry, you have to be running in the cloud. After all, unless you're a cloud provider, your data centre infrastructure is never going to differentiate you from your competitors, so it's not worth doing it yourself.
Monitor Everything
In a world with perfect developers, perfect testing practices, and perfect infrastructure, you would never get any issues in production. In the real world, that's not going to be the case.
No matter how good you are, you're going to run into problems in production. Be it unhandled exceptions, performance issues, user experience bugs, or infrastructure problems, the only thing worse than them making it to production is not knowing that they're there.
Monitoring of your applications is essential. If there are any issues in production, you need to know that they're happening before your users do, and you need to know why. If you're not monitoring, you're flying blind.
Microsoft's Visual Studio Team Services team recently posted a stunning post-mortem of a recent production issue, and how their monitoring was essential in working out what happened and how to prevent it in the future.
Metrics, Metrics, Metrics
As you begin to make changes to your product, tools, and processes, you’re going to want to know if these changes are helping – and metrics are the only good way to do this. Without any concrete data to back up your decisions and assumptions, you’re flying blind.
Some examples of the types of data you'll want to track are:
| Usage metrics | Keep track of how your users are using your product, using that to guide the investments that you make |
| Team process metrics | How many bugs are found per release? How often are features being completed on time? How long does it take to fix a bug? |
| Release metrics | How many releases are being performed per week? What outage time is required for each release? How often are releases failing? What is most likely to fail in a release? |
| User satisfaction | Are users happy with your product? What recent changes have affected user satisfaction? |
| Team morale surveys | Is the team currently enjoying the work that they are doing? What recent changes have affected morale? How many people are having to work overtime? |
These can be gathered from a variety of sources, such as production monitoring tools, project management tools, user surveys, and other purpose-built metrics gathering services.
But be cautious: metrics are only of any value if they're real. If you set hard targets that teams must meet, everyone will quickly work out how to fake the numbers. Instead, when the metrics are looking bad, reflect on what recent changes may have caused them to change, and make team-wide adjustments to get back on track.
Summary
At this point, it probably feels like there is so much to think about before you can even start to scratch the surface. But rest assured that the journey to DevOps is a marathon. You and your team will always be learning, and always finding things to improve.
The most important thing is that you understand where you are in the journey, learn from where you have struggled in the past, start working to where you want to be.
In Platform Engineering, we have experts that live DevOps every day and know the ins-and-outs of tools like Visual Studio Team Services, Confluence, Team City, and Octopus Deploy, and methodologies like Agile and Scrum. There plenty of different ways that we can help out:
- DevOps assessments: If you are not sure where to start, we can come and have a chat with you and your team, find out what is going well, what isn't going well, and work out where to start your DevOps journey.
- Help with tooling: If you have already started with some of the tooling that is available, but know you are not getting the most out of it, we can help out and get you up to speed.
- Learn from us: The best way to learn what DevOps is about and understand the benefits is to see it on a real project. If we are ever doing a project with you and your team, we would love you to sit in on the process and see us in action.