What is DevOps?

You hear it everywhere, recruiters asking for ‘DevOps engineers’, managers want DevOps teams and developers want to do DevOps. The term DevOps is a hype, but you may find asking yourself: “What is DevOps?”

Let me start with telling you what DevOps is not. DevOps is not a silver bullet for success. You do not get to come to the office and say “I have the solution for all our problems, we are going to do DevOps”. DevOps is also not a plugin for TFS or jenkins. And when you have automated build and release pipelines you are not doing DevOps, although you are on the right track. And last but not least, you do not do DevOps by just combining your developers and administrators.

Then what is DevOps?

DevOps is a way of work in which the administrators, let’s call them operations, and developers work together in one team to create a product that best suits the customer. It is the intention that every team member can develop and administer the product.

DevOps teams also use a high degree of automation, so that the teams can focus more on building new features and do less repetitive work. In addition, DevOps is about collecting and processing feedback about the application as quickly as possible. In short, DevOps is a collection of tools and methods that together ensure that you can easily build what the customer really wants instead of building something you think the customer wants.

Why do we Need DevOps?

Traditionally you have many different departments within an organization to deliver a product and keep it in production. These departments usually have people with the same specialization. There is a department for testers, a department for developers and a operations department.

This sounds reasonable because they can then more easily share knowledge and thus perform their work better. However, it has been shown that communication with other departments within the company suffers from this. You can put people together much better on the basis of the product or goal that they are trying to achieve instead of the function they perform.

For a number of years there has been a shift under the influence of agile, as a result of which the developer is increasingly given the responsibility of drafting requirements and making tests. This method has managed to break down a number of the old ‘walls’ between the various disciplines. However, the wall between the developers and operations remained intact. The major disadvantage of this wall is that the development team does not hear about the problems the user experiences in time, which can lead to wrong prioritization of product backlog items.

Important principles of DevOps

Direct feedback

If we can tear down this last ‘wall’, the developers will better understand what the customer wants because the feedback from the customer ends up directly with the developers. Therefore, there is an increased chance this feedback is interpreted as intended by the customer. It is like the child’s game where the children are lined up and the first in the row whispers a sentence in the ear of the second child. Then he has to whisper it into the ear of the next person until the latter has heard it. There probably is not much left of the sentence.

The same also happens with companies. Operations gets the feedback but does not know for sure where to send it. They will send the feedback to a department where they think it has to go. This continues until it arrives at the right department. As a result, this will cost the company a lot of time before the feedback reaches the right team or department and the feedback will be heavily polluted.

Automate everything

Another important principle within DevOps is ‘automate everything’. According to DevOps, you have to automate repetitive work as much as possible. This means, among other things, that you set up a build and release street and that you write automated tests. And by that I do not only mean unit tests, but also make automatic integration tests and acceptance tests. This means that you do not have to manually test your code yourself each time the developers have made a new feature, then create a number of binaries and manually put them on a production environment.

This saves time, makes all steps reproducible and ensures that fewer mistakes can be made. But you can also think about automating certain operations tasks. For example, if you have an application where you often have to assign rights to users, you should automate it so you spend less time on operations.

Great, but how do I automate my pipelines?

In order to automate your releases, there will also have to be some changes to the way your team works. Chances are that within your organization the teams still work with a master branch, a dev branch and also a branch per employee or per feature. The advantage of this is that every developer can work in isolation on his own task. The disadvantage of this is the large number of merge conflicts that this generates. The longer a branch lives, the greater the chance that two developers will hit the same file. This means you spend a lot of time solving the merge conflicts.

You can reduce the number of merge conflicts by using short-lived branches. These are branches that usually do not live longer than a day before they go to master. You heard me right, they will be merged directly into master. This is called trunk-based development. The branches are short-lived because you create a new branch for every task on your sprint backlog and then merge them with master when you are done with that task.

Feature toggles

I can hear you think ‘great that it goes straight to master, but that means there will be features in production that are not finished yet’. That’s right, but the user will not notice this when you use feature toggles for this. With a feature toggle you determine whether a user can see the feature or not. This way you can push a feature that has not yet been completed to production.

Automatic releases bring more benefits than you might think at first. By automatic releases, I really mean automatic. Not only the release itself should be automated, but all the way to it. That means that from the moment a commit on master is done everything goes fully automated to release.

A build will automatically be triggered and build your application, then it will test your application, release it to an acceptance environment and perform the automatic acceptance tests. When all tests succeed the application will be able to be released to production.

You probably do not want it to go to production at office hours and so the release to production will have a delay set. Because of this the application will only be released at 12 o’clock in the night.

With automatic releases you will be able to stop your monthly release train and even release several times a day. This will allow you to get new features to customers faster and release with smaller changes. In general smaller release changes have a smaller impact and therefore the chance that something goes wrong is also smaller.

Is that it?

Of course DevOps is about more than what I just explained, but these are some of the important principles of DevOps. DevOps is not something you implement in a week. You will need time to change to a DevOps way of work. In my next post I will write about how I think you can slowly transform your team into a DevOps team.

If you have any questions about DevOps or if you want to discuss what I wrote, please feel free to contact me.

Share this