DevOps – Out of the box

As part of development teams for more than 5 years, I have had to explain my role in that team more than once to my colleagues. In fact, there was a large part of history in which that answer was not clear even to myself. That is why I think is valuable to explain about culture and not specifically how a position or role from the point of view of the added value of carrying out methodologies that involve DevOps processes.

To begin with, it is important to mention that today the scope of a DevOps profile is not entirely clear and is more dependent on the needs of the project or the knowledge of colleagues who are part of the team. Taking this into account, the reader may feel challenged to the point of having carried out developments within DevOps scope.

So, to understand the added value that working in a scheme with DevOps profiles proposes, it is ideal to be clear about the backbone of the methodology and in my opinion it is the following:

Time to market

From this small concept extends every aspect of DevOps scope. The idea is to shorten these delivery times between the development and the client and/or user. Being able to deliver within short periods of time is an ambitious and powerful concept. Addressing this type of initiative is directly related to the implementation of agile methodologies.

From a cultural point of view, the DevOps methodology offers specific lines such as: collaborative work, visibility of changes and the correct delivery system. From these three fronts the first solid notions are born.

Regarding collaborative work, a DevOps profile is in charge of raising awareness and disciplining development teams about good practices and risks when working in parallel on the same repository. It is in charge of effectively communicating the branching strategies and the workflow in order to promote the code properly between environments.

Regarding the visibility of the changes, it is important that the DevOps profile that is part of your team carries out a clear and centralized process of communication of changes, correctly configuring the workflow to deliver clear and concise notifications in the strategic points where visibility is needed.

Finally, in relation to a correct delivery system, this workflow has to be well defined and clear across the project. Each developer and business analysts has to know (some in more detail than others) how this dynamic works, with the aim of providing the entire project with the agility necessary to spend all their capacities on their own developments. That is to say, that developers don’t need to worry about how or where their changes are going to be implemented.

In accordance with the aforementioned, there are other benefits such as:

• Improve code quality: This is due to the fact that within the automations that are carried out within the project, the validation of compilations is contemplated through the execution of tests. In that case, it gives us the assurance that each new version that we have available for publication was tested through a clear and approved process.
• Decrease in errors: Thanks to the creation of automated tasks, the existence of human error is completely degraded. Ensuring that the same protocol is followed for each deployment task gives us the security necessary to avoid making careless mistakes.
• Disaster recovery: Due to the automated deployment method and a clear and versioned release process, we have the autonomy that when faced with a problem with a specific version, we can go back to the closest stable version quickly and clearly and using the same deployment method. Also, if we had a complete degradation of the platform we could recreate the services elsewhere in a very short period of time.

However, these benefits are intrinsic to the team’s ability to work under the DevOps methodology, since if we did not respect the guidelines of the culture, all these aforementioned benefits would be completely diminished.

On the other hand, each of these fronts are attacked by an agglomeration of different tools, configured and even in some cases customized to coexist efficiently within a project.
Since the propagation of this culture began, different utilities have been created that solve the needs of development and operations teams at different levels. Some of them more oriented for one work group than another.
In order to understand what role some of the most popular tools play in the development process, I would like to give some examples.

Talking about tools alone is somewhat pointless. What really gives value to tools is how we use them and I would like to return to the aspects mentioned above.
The one that refers to collaborative work relies entirely on GIT-type repositories, like BitBucket, GitHub, GitLab or the offer within cloud providers. But as I said before, tools alone do not represent the solution. Having these instruments, we must design and agree on the correct branching strategy, anticipate the resolution of conflicts between branches, making it clear how the way of working should be and specially precise with the definition and objective of each persistent branch.

On the other hand, the visibility of changes in itself does not represent a tool precisely, but integrations between tools. For example, if the central communication channel of our project was Slack, it is desired that within this communication channel the notifications that refer to important events within the development process are made clearly and precisely, such as a Pull Request created that needs attention, the implementation of changes in a specific environment or the failure of the same process. This type of practice solidifies the workflow within the project and helps those involved feel more secure when promoting changes.

Regarding a correct delivery system, this is where a larger group of utilities that will need to coexist within the project participate. A continuous integration and continuous delivery server must be selected and maintained to carry out all the automation tasks that we need to carry out for our development plan. It centralizes the administration of the code to be implemented, the notification system and the integration with implementation and / or orchestration tools. This is where the backbone of the automation process lies and in reality what gives real validity to all these automations within a DevOps work culture, is to meet the needs of the two remaining fronts within each automated step, to understand that these solutions are carried out within the context of our project and solving possible problems that we are solving in advance.

I would like to close the topic by reinforcing the concept of DevOps culture over a role. The DevOps culture is what really provides the added value, it is the guideline of entire work teams to carry out a common project. The DevOps role within the development team is important (yet), it is not my goal to detract from the position, it is simply to make it clear that from my perspective just having a culture role within the team is not enough, but each colleague in the project has to be part of the DevOps culture, because after all it is a:

Work culture