What is DevOps?
DevOps is a funny concept.I have spent the last few months trying to find an accurate explanation of what it is, reading books, articles and participating in discussions which led me to the following personal definition: DevOps is a set of processes which aims to enhance the Application Lifecycle Management (ALM) of an Agile project by creating tighter links between the different actors (Developers, Operations and testers) through the use of automation and communication. Wow!
Why DevOps?
The traditional development cycle of an Agile project usually leads to two to four major releases a year which means the delivery of a lot of new functionalities, tons of bugs fixes and therefore a lot of testing pre and post production. Such releases can prevent the good visibility of specific problems in the application itself; create a huge stress on the people involved as it is not conceivable to miss a deadline with two releases a year, and create an ever-extending list of requirements for the next release.
While many important projects succeed in this approach, many major companies such as Facebook, Amazon or Flickr have chosen to perform shorter cycles of over ten deployments to production a day. That process enables them to have a very specific scope per release and with the help of automation almost everywhere, especially in testing, creates higher quality deliveries.
How to DevOps?
One important thing to remember here is that you cannot call Merlin and ask him to send you a “DevOps person” to solve all your problems, including your personal ones.
In order to achieve a successful transition from a two-releases-a-year cycle to a ten-releases-a-day one, it’s going to take time, a lot and skill, a lot. The team in charge of the changes will have to study the way you work, analyze the current process, identify potential problems and then make a list of recommendations
Those recommendations usually include breaking the different walls between people. One big goal of DevOps is to make people realize that whatever their role, their objective is common with the rest of the project: to deliver quality and to do so efficiently. Imagine for one second that a bug is found in pre-production (it happens). Usually the sysadmin will perform an analysis within its domain and if he cannot find the cause or identifies it as a “not my fault”, will forward the bug to the development team who as usual will answer “it worked in dev., must be environment related”. The pointing fingers game will take some hours maybe days before someone finally jumps in and finds the problem.
Now imagine the same bug handled by people on a project where DevOps is used correctly. When the bug is identified by testers, developers and operations are contacted together and retrace all the steps. Is it due to an error in the specifications? Can we reproduce it in other environments? What changes in the code triggered that bug and so on and so on. By having people working together instead of one after another, you create ownership of the product and a strong team feeling. If everyone is concerned when a problem arises and if everyone understands the application from the conception to its application, problem solving becomes a breeze and an actual good way to create natural collaboration between people of different groups.
The other main changes that come with DevOps are related to automation. Maybe easier to implement than mentality changes, setting up automated releases, testing, deployments requires expertise and a lot of testing on the way but can lead to great time sparing.
DevOps in Real Life.
One my favorite thing in life is food. Eating it, making, talking about it… Let’s use food as a simple example of how to use DevOps.
Imagine yourself in a starred restaurant kitchen; there is the executive chef, a sous-chef, a saucier and a vegetable chef.
The chef has envisioned a dish and asked his new staff to do their parts based on what he explained to them. Ideally this would go well but: the sauce is too acidic for the vegetables and the plating is terrible with the shapes and colors making the dish look sad. Everyone blames each other and the utensils for not being adapted.
Add a zest of DevOps to the recipe and try again.
Now the vegetable and saucier chefs work together and make sure that what they produce respects the wishes of the chef while working perfectly with the protein produced by the sous. It doesn’t happen instantly but they all try the overall dish together and after many iterations, manage to produce an experience that is visually astonishing on a plate and which flavors combine divinely in a way that is neither too heavy nor too light. To be able to cook and plate correctly, they had to buy more adapted utensils that everyone in the staff could use if needed.
One month goes by and the head chef asks them once again to repeat the operation on a new dish.
This time the whole staff knows how to work together and while everyone is working on his own specialty, they all work together from the beginning, sharing their experience with the utensils and understand which way to go, tasting their creation as they progress, leading to another perfect dish done in a much shorter time.
DevOps is not magic.
Many things can go wrong in a project and DevOps might be one possible solution to solve some specific problems but it is important to remember that implementing new processes, changing mentalities and using new tools can take a very long time and be really expensive.
You have another definition? You don’t agree With me? Feel like adding something? The comments are here for that, please let me know what you think, sharing is caring!