Just like anything in the modern world, and IT in particular, web and mobile app development is basically a truckload of complex procedures. However, the most important ones will always be the following: writing features, testing the code, finding flaws (debugging), and deployment of those features to production. Each of these stages involves a certain team of specialists: developers write code, Quality Assurance (QA) engineers are responsible for testing while system Administrators deploy stuff. As you can see, each of these teams has its own area of responsibilities.

The result of such “division of labor”, if you like, is that each team member focuses and relies on different criteria to evaluate their efficiency. E.g. for developers, it’s mostly about how fast they can implement or fix a certain feature. QA engineers are absorbed by the processes of finding every flaw to make the application work as designed. System administrators, on the other hand, do their best to keep the whole thing up and running without any crashes and make sure deployments go smoothly.

With those things considered, here’s how a typical workflow should look like:

Developers write code, forward it to QAs for testing, who, in their turn, send the tested features to sysadmins for deployment

Everything seems to be fine, doesn’t it? Well, if we lived in a perfect world, it would be. Suppose a deployed application has failed for some reason, e.g. a piece of functionality has had a bug. In that case, who’s going to fix it? But, more importantly, how soon will the issue be fixed?

Usually, when something goes wrong on the production server, the first ones who come into play are system administrators. They check the logs and see what can be done to improve the situation. If it turns out that the issue is in the code of the application, the system administrators pass this task on to developers. Now it’s their job to localize the issue and save the day. When developers find it (which they do, eventually), they come up with a fix and send it to QA engineers for testing. When the new piece of code is tested, it goes back to system administrators, who deploy it to the production server. As you can see, the issue has to go through as many as three stages before getting resolved.

Assuming that you live in a parallel universe, where you don’t need to make more than one or two releases a year, there’s absolutely nothing wrong with such workflow. However, outside of Rick and Morty, this sounds way too unrealistic because even small software houses have to make at least a dozen of releases every couple of months on average. So when there’s an issue that is yet to be fixed and you have a bunch of features scheduled to be deployed on the same day, the whole thing will most likely turn into a disaster before you manage to make a coffee.

What aggravates the situation even more, such workflow often results in bad blood between team members. In short, system administrators are drop dead certain that it’s the new piece of code that brought down the entire system and blame developers for that, while the latter ones keep saying that everything works just fine on their machines. In other words, you get a conflict of interests, when everybody is sure that the problem is not on their side. So what was supposed to be a simple deployment procedure turns into a giant mess, which costs the client their time and money.

What’s more, the teams usually not only use different tools for the same purposes, but also fail to share experiences with each other. On a psychological level, such insulation breeds distrust and even aggression. Need I say, that such a model of work will hardly be productive, if anything.

Such model of software development is called Waterfall and it used to dominate the world of project management up until 2001. In a nutshell, Waterfall everything that I’ve described above: sequential, inflexible, and assumes very little communication. However, it doesn’t mean that it’s bad or something. Waterfall is still used as a project management methodology by many companies due to the same reasons it became popular in 1970s: disciplined Approach, thoroughly laid-out scope and clear stages, concrete deadlines, etc.

In the modern, ever-changing world, such a linear way of doing things sometimes turns into a disadvantage. Using Waterfall, you can’t skip through specific stages while changing requirements in the process becomes a real challenge.

Being Agile

As technologies were evolving and business needs were becoming more dynamic and sophisticated, it was clear that the existing approach to implementing projects had to be adjusted.

As a result, the Agile manifesto was born, allowing for more productive teamwork between developers and QA engineers on top of other helpful things like the ability to change requirements on-the-go and launch projects much faster. The essence of Agile development boils down to a series of short cycles called “iterations”, which usually take about two or three weeks. In its turn, each iteration is treated like a mini-project and includes such steps as requirements analysis, planning, implementation, testing, and documenting.

Moreover, as the very name of the approach implies, Agile doesn’t enforce the necessity to plan and document every feature or piece of functionality before embarking on the actual development. Instead, Agile focuses on the needs of the client, providing more room for changes of requirements and even entire processes. It’s assumed that a project that is being developed using Agile can be released after every iteration.

The missing element

Despite the benefits, the new approach didn’t have room for system administrators. The solution that brought the last piece of the puzzle emerged in 2008. Devops (Development and Operations) is an approach, which is aimed to unite the efforts of developers, QA engineers, and system administrators for maximum productivity and tighter integration.

Roughly speaking, DevOps is Agile on steroids, not a stand-alone project management methodology. The difference is that now ALL of the development processes are interconnected. In addition to writing code, developers take part in deployment while system administrators become part developers by writing various scripts and QA engineers know how to configure simple things while system administrators can now look into the code of applications and fix simple issues themselves. Speaking of scripts, another point that is crucial to the DevOps methodology is that if something can be automated, it should be automated. Why? Despite being simple in execution, routine tasks still take time. When converted into hours, those tasks silently eat up your budget, which often results in … well, you get the idea. By writing scripts, system administrators can focus on more challenging issues.

In addition, sysadmins don’t need to wait for QA engineers to test the fixed piece of code as they can do it themselves by running automated tests. This enables sysadmins as well as all team members to consider projects as a whole and come up with better solutions more quickly.

But this doesn’t mean that they can do everything on their own. No. They still have to ask other teams for help in certain cases. The difference is that now everybody understands that there is more to a project than just their specific area of responsibility. Developers, QA engineers, and system administrators understand the priorities and needs of each other. They all work on solving problems together as opposed to blaming whoever they dislike the most and saying that the problem is “not on their side”. This results in a massive increase in productivity and speed of delivery. For example, Flickr was able to reach 10+ deploys per day after adopting DevOps (and that is, for a second, just a year after the methodology was introduced to the community in 2008).

Bottom line

The question that you probably have on your mind after reading this article is something like: “Should I ditch Waterfall and use DevOps instead?”. The short answer is: you shouldn’t. Why? There is simply too much variables to use the same approach in all cases. Even though DevOps is an all-round approach, it’s not a silver bullet. Every project management approach was designed to fit a specific project.

Waterfall was born when the technologies were only beginning to emerge and the market wasn’t as dynamic as it is today. Business owners could plan the development of their products, knowing that little could change even in a couple of years. The status quo changed when the Internet became mainstream. Suddenly, attracting customers from all across the globe was no longer a challenge. Even small businesses were able to promote their products with ease. The increased competitiveness and new realities forced industry experts to adjust the existing approach to implementing projects, resulting in Agile. In other words, each of the approaches is a response to the challenges intrinsic to a specific period of time.

For example, you wouldn’t use Agile on a project that has a detailed documentation, strict deadlines, thoroughly planned scope, and doesn’t assume changes on the go. Likewise, projects that need to be launched ASAP and have little description, wouldn’t get along with Waterfall. It’s like trying to screw a nail with a wrench, if you like — doesn’t make any sense.

As for DevOps, it’s an approach that I think will become dominant in the future considering that the market is getting more and more competitive. In addition, DevOps has accumulated the best practices from every approach, offering a whole bunch of advantages, such as

• the ability to fix issues faster;
• improved productivity and communication between the teams;
• faster delivery;
• improved customer experience;
• more time for actual development and improvements;
• and others.

In JetRuby, we’ve been using DevOps for many years now and it has helped us in developing of our clients’ projects and bringing the teams together.

Hope you’ve enjoyed the article. However, if you have any related questions, feel free to ask them in the comments section below. Peace!

The History of DevOps and Why You Should Consider Adopting It was originally published in JetRuby on Medium, where people are continuing the conversation by highlighting and responding to this story.