DevOps — one abbreviation, multiple meanings
Although DevOps is more and more recognized across, its meaning still is not that obvious as it is commonly considered, and what it could be assumed from the definition. In this article, I will present different approaches to this subject.
However, it will be only the beginning of the series. In the next publications, we will focus on how we understand DevOps at Craftware and how we operate according to this method. What does it mean for us in practice from a technological point of view? What business benefits does it give to our customers? Welcome to the world of DevOps!
A DevOps Specialist and a DevOps Engineer, that is “DevOps person”
We call one of the approaches the tool approach. How does it work? In simplest terms, it is employing someone responsible for tools that developers use in an organization or a team. Thus, if they use a code repository, a DevOps specialist mission is to prepare and configure it. A person in this position is usually half UNIX specialist and half developer.
What does this approach aim at? Obviously, at offloading developers. If they have a DevOps specialist support, they can take care of only what they are supposed to do in the light of this approach, that is writing a code and preparing subsequent versions of an app.
Where did this practice come from? Foremostly, from the fact that the broader approach to DevOps, the one we use at Craftware (read more about it the next articles), which is understood as a combination of development and operations, is more challenging to implement. Not every organization and not every team is capable of dealing with it and establish this approach at work and at software development. That is why DevOps specialists are employed because it is a convenient solution. It makes the life of developers much easier: they have fewer responsibilities and do not have to extend the range of their competencies. But does it bring real benefits? Well, yes and no — it is explained in detail below.
DevOps — more than a tool
There is another side of DevOps mentioned before: more holistic, meaning the method of work. It is simultaneous development of new functionalities and streamlining as well as the improvement of what has been implemented before.
Until organizations were convinced of this approach, the development and operations functioned as separate entities: on one side, new releases, and on the other — support for the production environment, resolving issues and mistakes. Over time, it appeared that such an approach causes problems. Providing support for a new portion of work by a developer to a support team was related to the transfer of knowledge, which is the logic of the design and operation of a given element. The risk that something is missed along the way is unavoidable. There is also another issue: how to guarantee that fixes made by the operation end up at developers in due time? And that they end up at developers in the first place? Coordinating the tasks of both teams was becoming more and more complicated.
Based on these experiences, the DevOps idea was created: a single team that takes care of the development and operations at the same time, by developing new functionalities and fixing bugs.
DevOps — benefits for the team, benefits for the business
How the team working on a project, that is, the DevOps team, benefits from the implementation of this approach? Naturally, if the continuity of communication is maintained, you do not have to focus on coordination and keeping an eye on things not to miss relevant details. You work faster and more effectively. We see what we implement and how, and this ensures full control over the project, improvement of the workflow, higher product quality.
And what are customer, that is business, benefits? First of all, they see one team, and it is an important signal that the work goes smoothly. However, savings thanks to working in the DevOps approach, which result from not duplicating roles, are the most important. For example, if you have one tester who is needed both in the development and in operations (if those work as separate teams), it means more working hours and generates higher costs. In the DevOps approach, one person combines the responsibilities from both areas.
The above example shows that the DevOps working method does not concern only developers job as it is sometimes mistakenly believed. It applies to different persons who work in the project. Craftware’s DevOps Teams that carry out projects for customers in the Salesforce technology are such multitasking teams, responsible for both development and operations.
DevOps — one for all, all for one
Sometimes, I also face a kind of understanding of the DevOps concept that involves full interchangeability. It is considered that, especially in the Agile methodology, in a DevOps team, everyone is capable of taking over the role of someone else.
In my opinion, this is too far-fetched, because though it is achievable but only to some extent. A developer can deal with testing, but can a tester replace s developer? Not necessarily. And what about requests from users relating to versions implemented for production? Again, in theory, a developer could take care of the request service. But will the best developers prove themselves in communication with users? Not everyone has personal traits that predispose them to a certain position. Let us remember that today specialization is valued, and experts in specific fields are most wanted. It is not expected that everyone knows everything.
So, how do we build our DevOps Teams at Craftware? How do we organize the work of those teams? We combine development and operations, but still, roles in the team are distinguished, and every person has their own area of expertise. The support mentioned before can serve as an example — we delegate those who have advanced soft skills to these tasks. Of course, our support specialist after receiving a ticket from a user can make a simple change in the system, but it does not mean being a developer.
Would you like to find out more about our Craftware DevOps Teams and the benefits they might bring to your organization? Read more about that soon on our blog.
Author
- Co-founder Craftware, Co-CEO Craftware
-
A graduate of the Electronics and Information Technology Faculty at the Warsaw University of Technology. He started his career as a developer, and later he became a leader of Java developers team. Co-founder of Craftware, established in 2009. Since then, he had many different hats – as an analyst, architect, developer, managing partner. Since 2011, he has been engaged in the development of systems based on the Salesforce platform that he values for the capability to deliver quickly full-blown solutions and close work with the business partners. He is truly passionate about this technology — he participated several times in Dreamforce in San Francisco, one of the biggest tech conferences in the world. He holds certificates confirming the knowledge about Salesforce. He has cooperated both with corporations and start-ups.
Outside his work, he is passionate about team sports and MMO games.
