DevOps first emerged as a set of practices and procedures to bridge all gaps between Development and Operations. Join us as we tackle how its application has become essential along these years.
Some time ago, listening to a podcast about the history of technologies and ideas that changed the world of software development, I heard a phrase that brought back (not so) fond memories: “There used to be a wall separating Development from Operations, and no one could see what was on the other side.”
I immediately thought it was a great analogy because I was on one side of that wall in my first project working at Hexacta. It was a desktop application that was the core of an international logistics company based in France but with offices and agencies all over the world.
Every time we had a release, we made sure that absolutely all the instructions were completely clear so that the Operations people could follow them, without errors or omissions, and knew what to do in case of possible failures.
Of course, for us, a development team with almost no knowledge of server configuration, networking, network security, etc., it was very difficult to put ourselves in the heads of those French people who were going to follow our instructions at some point, while in this part of the world we were still asleep. Many times, what was obvious to us was completely unknown to them and vice versa.
It was common for someone from Operations to follow our instructions and all of a sudden run into an unanticipated scenario — an error message or even a no error message that was not mentioned in the instructions which led to the decision to abort. Operations would decide that the instructions were not clear enough, suspend deployment, and inform us.
We would learn our lesson and add even more information to the already gigantic instructions and resend it. All this was done in an uncoordinated way, at the wrong time, and without everyone seeing what was happening “on the other side of the wall”.
WHY DEVOPS
Going back to the podcast I was listening to, it kept saying that “DevOps is the tool to break down that wall” and, once again, the analogy was apt.
DevOps emerged as a set of practices and procedures to bridge all those gaps that used to exist between Development and Operations. It then evolved into something even more complex and at the same time beneficial to the application lifecycle and essentially to the business.
I invite you to read why I think DevOps is so important.
PEOPLE WORKING WHERE THERE USED TO BE A WALL
Depending on the organization and how it structures its teams, DevOps professionals may be closer to code, infrastructure, or both. In fact, it is most common for this new role to take on responsibilities that were previously held by Development or Operations, but this does not imply that these areas disappear or lose relevance.
DevOps engineers work closely with both groups to understand their needs and act as a nexus where there used to be a wall.
They define some practices and procedures that developers must follow so that the input from CI/CD processes arrives in a timely manner. This way, they can implement automatic or semi-automatic processes to perform deployments and keep the environments in sync with the Operations team.
DEVOPS AND CULTURAL CHANGE
Perhaps the most important contribution that DevOps has brought to the software industry was not technical but cultural.
Having separate teams with little communication between them and disparate knowledge could have worked (in fact it did) in an industry that had other characteristics, other processes, and other urgent matters.
The reader is probably too young to remember/know that projects used to be carried out following a Waterfall methodology, where each stage (Requirements, Design, Implementation, Verification, Maintenance) was carried out only once, and no steps were taken backwards.
It is not my intention to divert the subject of this article to methodological issues, but it is worth mentioning that the deployment of an application was done only once. Then there could be upgrades, which followed the same process. With this, I want to point out that the number of deployments per application and/or project was very low.
With the advent of agile methodologies and the incremental iterative lifecycle, every time value is added to the product, it can be deployed (in fact it mostly is). This allows us to improve the time to market and get very early feedback from both users and business.
This agility could not be supported by the old wall between Development and Operations, and this is where DevOps has become an essential practice for the industry of this time.
Do not miss this: 8 DevOps best practices for a high-performance team
DEVELOPMENT KNOWLEDGE THAT ALLOWS TIMELY RESOLUTION
In my personal experience, many errors have occurred when executing deployments because the Operations team did not have the development skills to understand a problem and find a solution.
Today, DevOps engineers have development skills to detect errors at release time (e.g., a badly formed configuration file, a SQL script with errors, or a wrong reference to a package) and resolve them on the fly. They can also implement code capable of performing some action as part of the deployment and create infrastructure dynamically.
These new players have hybrid skills but limited to this role, and this is what allows them to solve problems and avoid delays.
TOOLS THAT FACILITATE PROCESSES
Although DevOps is a relatively new idea, it has been around for years, and the tools that support it have been evolving very quickly.
At first, with DevOps you had to work hard on implementing code, typically scripts in Python, Powershell, or similar that would allow you to automate repetitive tasks. You even had to add manual steps in your pipelines to complete a deployment.
With the emergence of many automation tools and the possibility of creating infrastructure dynamically, the work has become much easier, times have been substantially reduced, and the number of errors or failures has decreased, or at least, agile recovery mechanisms have been developed for these types of events.
AUTOMATION AS THE MAIN OBJECTIVE
As I have already mentioned, times have changed since that first project at Hexacta, and today, everything is more agile… and faster. There is no time to lose when it comes to meeting user needs and bringing a product to the market where competition is getting tougher every day.
Therefore, we have to be able to deploy more and more frequently with small changes and in short times. We cannot leave this responsibility in the hands of people who have their work schedules, potential impediments to tend to a task, and who are prone to making mistakes. We must inevitably move towards absolute automation, or at least the highest degree of automation possible.
Today, CI/CD pipelines are capable of detecting code changes, running functional tests, verifying technical quality and security checks, setting up the environment where the application will be deployed, actually deploying the application, running a smoke test, and doing a rollback if something goes wrong.
Mature organizations are able to employ all this automation and consequently with the agility and response times that the market demands today.
Take a look at this reading: Implementing DevOps with TFS and 11 benefits of using it
ALIGN WITH BUSINESS NEEDS
Without forgetting the title of this article, I would like to mention that DevOps is a set of practices whose ultimate goal is to bring speed, agility, and versatility to the business.
Whichever market a product competes in, being able to make constant updates and maintain stability are factors that can define success or failure. DevOps brings us closer to success, without a doubt.
TO SUM UP
From old experiences working with the wall between Development and Operations until this new stage where we have demolished that barrier, we have been through many ideas, methodologies, and tools, and Hexacta has accompanied this process with its projects and its professionals.
We are more than confident to be a valuable partner in DevOps teams, not only because of our experience and recent success stories but also because we have accompanied the whole process, from the beginning, and that is the best way to understand and master it.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
