DevOps, what and why

By definition, DevOps is a mix of culture, processes and tools, but to understand it properly you have to understand where we come from. We come from a software development background that developers and operations people have always had friction with.

Developers are people who embrace change, and people who like to create, but operations people don't like change. They like stability. To try to avoid these problems that we have been suffering from, the idea of DevOps appeared, which is to mix the Development Department with the Operations Department in a way that they can relate to each other with as little friction as possible.

Not only is their cultural change, but there are a series of specific tools and a series of specific processes that are going to help us do this.

What processes do we need?

If you look up the definition of DevOps, you will see an image with an infinity symbol. This defines a bit of the software development lifecycle.

What parts do we have as processes?

We have the planning of the development, the coding of the development, the compilation of that development and the testing. This process is the one that facilitates this relationship between developers and operations.
By compiling the code and testing it, the operations people have extra assurance that the code we're going to upload is bug-free and won't bring down the systems. The developers will deliver those features and they need to get them into production as soon as possible. This is where the operations people come in and they are going to develop a series of processes to get those features into production as quickly as possible so that end users can use them.

Once it is in production, the operations people have to monitor, control that the system is always online and give feedback to the developers. One very important part remains: As technology companies, we compete. We want our product to be on the market as soon as possible. That's where a fundamental pillar of DevOps comes in: automation, that human intervention is kept to a minimum and that we have a guarantee that the code we are uploading to production is as good and stable as possible. What I represent is bringing together those two teams that were previously separate and now work together. By bringing the two teams together, the knowledge of the developers transfers to the knowledge of the systems people, and the systems operators also transfer knowledge to the development team that they didn't have before.

Let's take an example. A developer wants to realise an extra functionality in the application. If he has an operations person, he can discuss it with them and can say to the operations person. "Be careful what you're going to do, this might cause this. This and this" and vice versa. So you see, it's a cultural change where collaboration is the basis of everything with all the advantages.

- You don't have internal problems within the team.

- Your solutions get to production sooner, not only because they implement automation, but because the two teams are synchronised and united.

How did you start using DevOps at Innovation Strategies?

It was a natural change. The client needed our deployments to production to be much faster. We were deploying two features every three months and we are deploying it per week. Three or four features per week. There was a big automation effort and from then on everything flowed.