DevOps is not a single person, nor is it one team. Instead, it’s a collaboration of groups integrated efficiently and autonomously to promote faster code changes to production.
Life Before DevOps
Most companies have separate teams contributing to new application features for clients. Getting code from a developer’s computer to the client is called a pipeline. You’ll hear that word a lot in the DevOps world.
Below is a list of teams you can usually find in a company’s workplace. Of course, names can differ, but these are the most common ones.
| Development (Dev) | Developers work on coding new features based on given requirements. Once they finish, they provide the updated code to the QA team to test. |
| Quality Assurance (QA) | QA analysts test the updated code by conducting example situations that the client might encounter (i.e., clicking a button and seeing what happens). If there are any issues, they notify the Dev team to remedy them before declaring the update application is bug-free. |
| Security (InfoSec) | Security analysts are responsible for catching potential vulnerabilities in the new code that may make the company prone to malicious users. |
| Infrastructure (Infra) | Infrastructure engineers manage the hardware that the applications run on. |
| Operations (Ops) | Ops engineers assist in predicting application performance. To do so they run numerous tests and analyze the results. |
| Production Support (Prod) | The Prod Support team monitors the application once it’s in the hands of the clients’. In case of any issues, they relay the information to the Dev team. |
| Release Engineering | Release engineers are responsible converting the code into a usable application (often called compiling or building code), moving the new application through the steps mentioned above, and finally providing the latest updates to the client. |
Now, imagine how difficult it is to coordinate all these teams to deliver a slight change to the client. Just writing about it gives me a headache.
DevOps as a Solution
Patrick DeBois, an engineer, frustrated about the disconnect between developers and the rest of the workforce, coined the term “DevOps” in 2009. DevOps is simply a combination of the words “Development” and “Operations,” but the meaning behind this new idea encompassed so much more than just these two teams.
You can think of DevOps as a shift in cultural thinking towards automation. By automating tasks, you reduce manual human interference and become less prone to human error. Also, it’s just so much faster to teach a computer to do your job for you.
Patrick was an impatient man. More on his work here.
What’s happening here is that non-developers think more like developers and approach their projects with a “code-first” mentality. So, for example, a QA engineer can write a program to click every button in an application instead of manually clicking every button themself. This speeds up application testing and removes possible human error.
[A] QA engineer can write a program to click every button in an application instead of manually clicking every button themself.
Me, a DevOps Engineer.
Pre-Devops Wasn’t So Bad, Was It?
You’ll be sorry you asked. Let’s look at what life was like before the idea of DevOps came about.
Gross, right? Everything in red is manual and unnecessary. Yet, up until around 2009, this is how most companies pushed application updates to their clients. It was gruesome, tedious, and led to many human error-related delays.
So, how can automation help?
From Chaos To DevOps
Before you ask about the automation magic, notice the more straightforward process.
This new process removed the interdependency between teams. The new code is automatically available to the client as the Dev team finishes working on it.
Automation Magic
So, all the missing teams aren’t necessarily gone from the company. They are just no longer directly involved in deploying the new application updates. Instead, they shift their focus to automation. These teams now have engineers writing automation scripts to handle all their manual tasks. So they don’t have to be available for every release anymore, just when their scripts break or need updates.
What Now?
If you’re new to DevOps and looking for more content like this, please subscribe for updates, so you’ll never miss out on new content!