VictorOps is now Splunk On-Call! Learn More.
Today, developers and operations teams are constantly searching for new ways to apply automation and machine learning to their workflows. But, engineering and IT teams are also looking to improve the way they collaborate and share information. So, it’s impossible to define one single DevOps tutorial that works for everyone. So, we’re taking the approach of writing a DevOps tutorial that’s flexible enough to work for nearly any team.
DevOps isn’t a specific set of tools or techniques, it’s a mindset adopted by engineers and IT practitioners everywhere to automate manual tasks and improve collaboration and visibility – helping teams build out reliable CI/CD pipelines. While different types of software and tools can lead to a better DevOps culture and faster velocity, the root of DevOps comes from the people on the team. And, the value of DevOps implementation doesn’t need to stop at engineering and IT – that value should also flow into the business.
So, let’s take a look at some ways to reduce developer and operations isolation, drive continuous improvement and deliver reliable applications and services faster.
When you start getting into DevOps, you’ll notice a number of job postings for “DevOps engineers”. These are often listings from teams who either don’t really understand the core concepts of DevOps or they’re a smaller company looking for some kind of IT/infrastructure engineer generalist. With the rise of cloud-native businesses and the rising adoption of PaaS and IaaS (Platform and Infrastructure as a Service), the responsibilities for software engineers and sysadmins can become a bit blurred. But, at the end of the day, there’s no such thing as a “DevOps engineer”.
DevOps engineers are made up of frontend experts, backend developers, IT and security analysts, and so much more. DevOps is a mindset adopted by all engineers and IT practitioners at your company – a way to help you think about the types of engineers you should hire. Developers and operations teammates in DevOps will often take on the form of a T-shaped person. A T-shaped individual is someone who builds deep subject matter expertise in one or two areas but also builds a broad range of knowledge in many other aspects of software development and delivery.
But, it’s naive to assume anyone can learn everything about all aspects of development and IT. So, why not focus on how you help people with different skills collaborate cross-functionally at every stage of the software delivery lifecycle? How can developers and IT practitioners better share contextual information in real-time, automate testing and spread accountability for uptime?
Once you realize the value to be gained from DevOps, you need to figure out how to get people excited about adopting it – especially management. Without DevOps buy-in from management teams, it’s hard to justify major automation and changes to CI/CD, testing and incident management. For instance, most developers who haven’t spent time on-call in the past may likely be frustrated at the idea of being put into an on-call rotation. However, if you can prove the value of deeper exposure to production environments from an incident management and development perspective (i.e. better knowledge of both staging and production ecosystems), you can show why the team needs DevOps.
On top of showing the speed and reliability benefits brought by DevOps, managers like to see the business value of it. By tracking key incident management KPIs over time and other important metrics for software delivery, you can show how DevOps reduces downtime and the costs associated with it over time. DevOps adoption won’t happen if it’s only promoted as a top-down motion, it also needs to be bottoms-up. As engineers showcase the value of DevOps, managers will take notice, promote it across the broader leadership teams and then these other leaders can pass down these processes amongst their teams.
Adopting DevOps is often less about tools and general processes than it is about getting people interested in the concept. Every organization is different, so there’s no right approach to getting buy-in for DevOps. But, you can always focus on showing the competitive differentiation in the market brought to the table by DevOps and shed as much light on how it improves business as a whole.
DevOps is the only true CI/CD platform. Tools like Jenkins, Ansible, SaltStack, Chef and Puppet can help you automate continuous integration and delivery in nearly any environment, as well as configuration management, but they can’t facilitate the process in general. So, development and IT teams need to look at DevOps, an organizational mindset and structure, as their real CI/CD platform.
With developers and IT operations teams tightening relationships and shortening feedback loops, they can plan, build, test, deploy and maintain applications and infrastructure better than ever before. Work gets sent backward in the software delivery lifecycle much less often when testing is done in parallel with writing code – leading to greater deployment velocity and fewer reliability concerns. You can use Agile software development practices all day long to write code and build a huge backlog of features and software to be sent live. But, without the ability to actually deploy and maintain these features and services, it doesn’t matter how fast you can write code. Streamlined processes and a tight relationship between developers, IT and security teams is the only true way to encourage a robust CI/CD pipeline.
As engineers, IT and security professionals share more about development, testing, deployment and incident management processes, they’re better equipped with the background knowledge they need to collaborate more effectively. And, armed with improved collaboration and workflow transparency, it’s easier for people to take accountability for certain aspects of the products and services they work with.
DevOps is about sharing accountability across all aspects of engineering. Because, if you really think about it, there’s never one single root cause of a problem. For instance, if an engineer ships code to production that causes some sort of failure or error, it’s not only that person’s fault. Why wasn’t there some sort of test to detect this problem? Could your team make a change to the deployment process to help detect this issue? By simply assigning blame whenever someone doesn’t write perfect code isn’t a scalable, or humanly-possible, way to approach software delivery.
So, any way you can encourage greater transparency and collaboration, the more connected your engineering teams will feel – not only to one another but to the product, as well. Then, you can work automation into these collaborative workflows to make the process even more efficient. But, it’s important to remember that automation should work as a supplement to the way people work together, not a replacement.
Unfortunately, it’s hard to develop one complete tutorial for adopting, implementing and taking advantage of the DevOps methodology. Different businesses are at different stages of their cloud-native journey and no two teams have the exact same setup for engineering, IT and security. So, there isn’t one way to approach DevOps. But, the tips and tricks in the tutorial above should help you build out a basic DevOps framework that will work with any team.
Want to read more about the benefits of DevOps? Learn more about DevOps adoption for efficient incident management and software delivery in our latest, open guide, Why DevOps Matters.