DevOps is not just one thing, but rather a set of tools and practices that, well, everyone is following, or should be. But, for all of its ever-increasing popularity, few can really explain what DevOps is about without tangling themselves up in jargon. With this guide, we’ll help you navigate the DevOps maze in a way that’s easy, fun, and will hopefully get you going in the quest for more—and better—implementation. Without further ado, here’s DevOps explained!
And hey, we know even a seasoned DevOps engineer will stumble and bumble when it comes to explaining what it’s all about. Here’s something we had to say about it in our blog about 10 DevOps Tips, all the way back in the simpler times of 2018:
“Get everyone on the same DevOps page. Given that there are so many different definitions of DevOps, with some of them focused solely on increased automation, there’s a need to share what DevOps will mean for your organization across all stakeholders”
And that’s why the first order of the day is finding an easy definition for DevOps.
DevOps 101
According to Atlassian:
“DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation.
The DevOps movement began around 2007 when the software development and IT operations communities raised concerns about the traditional software development model, where developers who wrote code worked apart from operations who deployed and supported the code. The term DevOps, a combination of the words development and operations, reflects the process of integrating these disciplines into one, continuous process.”
As you’ve just read, DevOps in and of itself is not that old a practice. But it did arise from a profound cultural and organizational need: trying to fight against fatal levels of dysfunction across the IT industry.
And what was that dysfunction, you ask? Mainly, the fact that it seemed that the software development and deployment (the ones who actually implement said software) teams were completely apart from each other. And this distance led to issues down the line that seemed to affect every part of IT operations negatively. DevOps, thus, arose from needing continuous integration industry-wide.
You can probably tell, but this phenomenon of the left hand not knowing what the right is doing is hell for an organization. And even more so when both teams sometimes seem to have competing, or outright contradictory, objectives.
This is precisely the niche that DevOps came to fill.
How does DevOps work, anyway?
DevOps tries to prevent, essentially, what’s called “organizational siloing.” In other words, it’s meant to prevent teams working in secluded little islands that don’t interact much with each other. And this fosters an environment of collaboration rather than sectarian competition and one-upmanship.
As such, DevOps teams include developers and IT teams working hand-in-hand all through the product lifecycle: from birth to death. The idea is to speed up the speed and quality of not just development, but also deployment. As such, it represents a significant paradigm shift from “the way things were”. The implications for both teams and organizations is profound.
DevOps, ideally, prevents this organizational siloing that we were discussing above. In some cases, even, teams are merged in order to maximize efficiency, with engineers working throughout the product or app lifecycle. Of course, they tend to have a wider range of skills in order to accommodate these various scenarios. Gone are the days of engineers that had just one hyper-specialized skill and worked on it with blinders on. Now, it’s all about peripheral vision. Now, we’re in the age of interdisciplinary work.
Furthermore, DevOps-enabled teams tend to use every tool at their disposal in order to automate and facilitate processes. As such, they tend to have more time to utilize their high-level skills where they are needed. And, as a much-needed plus, they don’t just accelerate processes but make them much less prone to errors.
Another thing that makes it it easier for DevOps teams are the right toolchain. DevOps fundamentals like continuous integration, continuous delivery, automation, and collaboration are the order of the day here.
Much like IT Asset Management (ITAM), DevOps values sometimes can apply beyond the borders of software development and implementation. Good practices are good practices, after all. Security teams, for instance, can adopt DevOps modalities, or even be actively integrated into the development process. When this happens, it’s an area called DevSecOps.
The DevOps lifecycle
From the time software is conceived, right up until the point it becomes abandonware, that’s what we call a lifecycle. And since DevOps is a continuous process, this is better represented through an infinity loop meant to convey the need for constant collaboration and iterative, lifecycle-long improvement.
The DevOps lifecycle, with its focus on continuous delivery and continuous integration, focuses on six distinct phases that facilitate these ends. Development (on the left side of the loop) has three, and operations (right side) cover the other three.
Of course, as we’ve said above, development and operations teams collaborate constantly to maintain alignment and keep things on the up and up for the duration of the process. And, of course, it behooves us to go into a little more detail about those practices.
- Continuous integration is a software development practice where developers merge every code change they do into a single repository. It’s here where automated builds and tests are run. The goal behind this practice is to find bugs quicker and stamp out issues before they become widespread — or reach implementation in the first place. If things go well, then the time it takes to release and update software decreases significantly.
- Continuous delivery is about implementing code changes that are automatically built, tested, and prepared for a release to production. As such, you can consider it an expansion to continuous integration, because it hinges upon deploying all code changes to a testing or production environment following the build stage. If done right, developers will have prime-time-ready builds that have already been tested adequately always at their disposal.
Now, with that out of the way, let’s take a look at all six phases sequentially in order to get a better idea of how things are laid out.
1. Planning
Improving speed and delivery is tantamount to success for DevOps teams. What’s good for that? Agile, of course. As the #1 iterative approach to project management, it’s just good practice to integrate it into DevOps planning. The way it works is by allowing teams to break down work into smaller “particles” that allow them to work at a brisker pace and deliver incremental value.
In fact, an Agile expert notes:
“DevOps can be interpreted as an outgrowth of Agile—agile software development prescribes close collaboration of customers, product management, developers, and (sometimes) QA to fill in the gaps and rapidly iterate towards a better product (...)
(...) service delivery and how the app and systems interact are a fundamental part of the value proposition to the client as well, and so the product team needs to include those concerns as a top-level item. From this perspective, DevOps is simply extending Agile principles beyond the boundaries of the code to the entire delivered service”
And speaking of code…
2. Building the code
Rapid software development and deployment are the order of the day here. Developers need to churn out new builds and updates like nobody’s business, and they need to do it following standardized testing procedures. Different tools, like Git or Docker, can help developers construct a support system for branching and rewriting repository histories as needed. And, of course, all of this needs to happen without falling too far behind schedule. Speed and efficiency are of the essence as much as all-out effectiveness here.
3. Continuous integration and continuous delivery
When employed in tandem, continuous integration and continuous delivery allow developers to reliably produce high-quality products and keep them regularly up-to-date. In fact, this reliability and predictability allow things like source code repositories to be completely automated. They also allow teams to perform things like end-to-end testing, deploy feature flags, or merge code changes as needed.
And this is not something to take lightly either. As expert Tommy Tynja noted:
“To successfully implement continuous delivery, you need to change the culture of how an entire organization views software development efforts.”
It may be that to implement continuous integration and delivery you have to overhaul the way you’re doing some things from the ground up. And that’s not a bad thing, because when all of these tools are used together, the results can be astounding.
4. Monitor and alert
Now, just because things are working doesn’t mean you can take your hands off the steering wheel. Resolving and predicting issues should always be a priority, and that’s why you should always keep a watchful eye on everything that’s going on in a DevOps process. Remember, issues fundamentally affect product uptime, functionality, and ultimately, speed.
But, of course, you should also be able to notify your teams of high-risk actions, changes, and failures. You know, so at the end of the day you can keep the lights on as well. Priorities, people!
5. Operate
This is where end-to-end IT delivery comes triumphantly into the picture. Also, where you should strive to provide the best possible service to customers. And what facilitates you providing perfect service? Having an efficient and reliable, well-maintained IT infrastructure that maximizes your chances of success. Everything plays into everything else.
6. Continuous feedback
Now, with DevOps things are not a one-and-done deal. Rather, teams are meant to evaluate each release, provide detailed reports, and create the environment for future (and constant) improvement. Thus, continuous feedback enables teams to improve their processes, incorporate customer feedback, and improve all subsequent releases.
And that brings us to the next question. While the “how” of DevOps is important, the “why” is just as crucial.
What are some of the benefits of adopting this set of practices?
DevOps benefits
According to Atlassian’s 2020 survey, 99% of respondents noted organizational benefits after adopting DevOps.
But what are those benefits?
Faster, faster, faster
Speed is probably one of the most-valued metrics everywhere. If you can couple speed and efficiency, then you’re golden. DevOps is a big aid precisely in these two: do stuff faster, but better.
DevOps teams get deliverables out the door much faster, and with higher quality and stability metrics. And this, coupled with the abilities provided by continuous delivery, allows them to outperform teams that don’t use these practices by more than a hundred-fold (!!!).
Improves across-the-board collaboration
Remember the idea behind this whole thing? Right, it was to decrease siloing and foster a culture of inter-departmental and multidisciplinary collaboration. As a result, development and operations teams share the burden and responsibility of the entire process.
As a result, this increases all-around efficiency, teams can hand off work to other teams, and saves time. Plus, teams can create code that is actually relevant to the environment it’s designed for instead of doing it in near-complete isolation.
Makes deployment much faster
DevOps shines in many areas. And one of the most important is the ability to get products out faster, and improve on them continuously. And it’s not just about stability and reliability (an all-important client-side metric), but about gaining a competitive advantage by fixing bugs quickly and releasing new features when they are actually needed.
Quality and reliability
Yep, we did. Continuous integration and delivery also help software developers ensure changes that are functional and safe, which improves overall product quality. Plus, monitoring helps teams stay on top of software performance at all times. This ensures even better results than normal, and a culture of constant improvement.
Security
This is an area where DevOps overlaps with ITIL. In our article about how to build a culture of cybersecurity, we said:
“An organization’s culture defines how employees conduct themselves in their work environment, whether in an office or work-from-home situation. It dictates how employees communicate, the boundaries, the way they dress or present themselves, and what’s expected of every employee. A cybersecurity culture attempts to reduce the overall cybersecurity risk by strengthening an organization’s weakest link and its most valuable resource: its people.”
By integrating security into continuous integration, continuous development, and continuous deployment, DevSecOps becomes an all-important part of the development process. In fact, it builds security features right into products, and reinforces this by enforcing regular security audits and testing — all within DevOps workflows and agile development guidelines.
DevOps and ITIL: separated at birth?
Now, if you’ve read our definitive guide to ITIL, then you’re probably scratching your head wondering about the obvious similarities here.
But what are the differences? Even though these systems overlap and frequently interact with each other, they’re not exactly the same. Here are the main differences:
- ITIL is a codified system of practices mostly geared towards integrating IT with business processes and strategies.
- DevOps, on the other hand, arose from a need to integrate software development and operations teams, to reduce the level of isolation and make everyone pull in the same direction, essentially.
While there are moments when these two approaches coincide, they’re meant to address fundamentally different things. So, in essence, what you’re going to want to do is to not compare these two processes in a vacuum, but rather see what each one is trying to address, and whether it’s relevant to the challenges your organization is facing.
All in all, the main focus is going to be about whether you can get something out of each philosophy, not about trying to apply trendy in-words because they seem cool. Implementation is only as good as our understanding of what we’re trying to implement — hence this article.
In closing
If you want to prevent organization siloing, get software out quicker, more reliably, and more in-tune with real-world usage, then DevOps is for you. And, considering its absolutely amazing track record, we would recommend you start implementing it.
As Gene Kim put it:
"DevOps and its resulting technical, architectural, and cultural practices represent a convergence of many philosophical and management movements (including): Lean, Theory of Constraints, Toyota production system, resilience engineering, learning organizations, safety culture, Human factors, high-trust management cultures, servant leadership, organizational change management, and Agile methods.”
And, as such, it’s the perfectly potent cocktail to help propel your software development and operations efforts into a well-oiled machine that operates as a whole.
