If you've been working in development long at all, you've probably heard the term "DevOps" kicked around quite a bit — and if you work in a non-technical capacity, you probably ask yourself what the heck it is every time you see the word.
The problem with answering this question is the term means different things depending on who you ask. Like most industry buzzwords, the term has taken on a ton of tangentially related definitions over the years, making it hard to ascribe a single meaning to it without skipping over several others.
The good news? Even without a singular definition, it's not hard to get a grip on the basic ideas behind the development-operations methodology: why it came to be, what it values and aims to change about the development world, and so on. Here are a few signposts and how they can help organizations of all sizes take a more modern approach to development.
No matter what role you play in the development world, you've undoubtedly seen the effects of so-called "siloization" on workplaces and the products they produce. When various departments within an organization don't trust one another or work well together, problems manifest in a number of ways: poor communication, missed goals, drama and infighting, to name a few.
DevOps aims to change this by placing importance on ideas such as teamwork, effective communication, trust and collaboration — things any group of people working toward the same goal should have in the first place.
The trick here is knowing who needs to communicate better, and that's as simple as breaking the name down. Generally speaking, DevOps is all about getting the people who build the code within a company (developers) working in tandem with the people who handle stuff like QA testing and deployment (operations). The basic goal makes sense: When several standalone, yet highly important, groups are all working to push a product out the door, enabling better communication among them means fewer problems on the way to finishing, faster time to market, etc.
Improving communication can be as simple or complex of a task as you care to make it. Some businesses swear by the power of "small" changes, such as putting your developers and operations folks together into small teams (or even just the same building, if they work in separate offices); others preach the importance of communication-enabling tools such as Hubot, which automates various aspects of cross-department communication and the various tasks that come from it.
On the human side, DevOps also tends to place huge value on full-stack developers. Ideally, these devs should be able to do all sorts of other important development-related stuff in a pinch, such as QA or database administration.
How important these utility players are to a given organization is up for debate. Many experts, for instance, will tell you they work best in start-up situations, where every employee wears multiple hats and communication between all employees is more frequent. Others will tell you the same idea can work in a large-scale organization with a little restructuring — moving people into the small groups mentioned earlier, for instance.
Other parts of the methodology, such as automation, are more universally accepted. When you look at DevOps as a sort of "spiritual successor" to Agile (many people will tell you it basically takes Agile development practices and applies them to operations), you begin to see why.
The big twist here is what's being automated — namely, anything that can be. While practices such as continuous, automated delivery and integration are key, automating processes is also a big deal with the methodology. Without getting too technical, this blog post from Mobify puts a lot of value in "stringing stuff together with shell scripts," thus making the nuts-and-bolts aspects of development and ops faster and easier.
Automated security testing and monitoring also play a big role, considering the methodology's focus on rapid deployment. When you're deploying multiple times a day, knowing every iteration you put out is safe and secure is hugely important. And unless you want to spring for people to specifically test every little change you make, an automated platform is by far the most efficient way to do that.
In a nutshell, DevOps takes the sort of practices that help start-ups prosper and applies them to organizations of all sizes. That's just one basic definition, of course, but it's a good leaping-off point. However you look at it, though, and whatever words you use to define it, there's a reason big and small organizations alike have latched onto the practice: it works. In an industry full of constantly changing trends, that's saying something.
Photo Source: Wikimedia Commons