How one of the fastest growing HR tech companies in Europe do continuous delivery
By: Jonas Versen
Tags: Continous Deployment, Continous Integration, Software Engineering, Continuous Delivery, Software Development

During the last year, we have changed our workflows to deliver features continuously. It has been a great journey and, in this text, I want to share with you the techniques that helped us most and the most important things to have in mind when moving to continuous delivery. But before that, very shortly: Why did we even choose this path?

First of all: We want to deliver things quickly. We are a fast-growing company and with more and more developers comes the capability of creating more and more great features. We don’t want to wait until the last stage to make them available to our customers because we believe that they can bring value earlier. Being quick is the key here.

Second: minimize risks. It’s a lot less risky to deploy a smaller feature than a big one you have been working on for weeks. If something goes wrong, it’s most likely not a big thing, easier to track and easier to fix.

Third: customer feedback. If we waited many weeks to make a new feature available to customers, we would miss out on the great opportunity to see how they are using the new feature. If we release just one small step of the feature, we can learn during the way, adapt to our users’ behavior and their needs.

Considering all this, it’s hard to think of anything why you should not aim for continuous delivery.

So how does or daily workflow look like?

Teams at Winningtemp usually consist of a team lead, a frontend developer, a backend developer and a UX resource. We use a Kanban style of working, prioritizing tasks that are most important right now. And we use GitHub for version control.

When a developer decides to work on a feature, he or she creates a feature branch and simply works on it until there is something to deliver. This can happen daily, sometimes it happens every second day, sometimes several times a day. Our rule of thumb is: Whatever is merged into the master branch should be able to be deployed. We also have the rule that there needs to be a code review on code that is to be merged into the master branch. Why that? I’ll explain that later.

The merge to the master branch triggers automatic tests that are run on those part of the code that have changed. As a last step, the new feature is approved for deployment. For now, this is a manual step, but we are aiming to go even further into continuous deployment where everything that is merged into the master branch automatically will be deployed.

What do we need to make this work?

During the years I have worked with continuous delivery, I have learned that there are two types of requirements. On the one hand, you need the right mindset and the right atmosphere in a company to be successful, and I am going to talk about that later on. On the other hand, there are of course some technical and structural requirements that need to be in place. Here is what is helping us.

DevOps

A functioning DevOps is closely related to continuous delivery. If you want a team to deliver fast, they shouldn’t need to wait for an operations department to deploy their code, this will always be a bottleneck. Instead, all the teams should be able to deploy and monitor their applications on their own.

Quality

In my experience, you can’t have continuous delivery without quality. That means, that we work a lot with testing and quality control. If there are deployments up to several times a day, there is simply no time to have a testing team manually going through every part of every new feature. We are continuously improving and aiming to have a high level of testing in all parts of the application. The main part today are unit tests, and it’s important that those are quick and reliable. The other big part are component tests.

Overall, it’s important that the tests are quick. One key to our testing is to create a fast testing pipeline. Be honest: If a testing pipeline takes 30 minutes or more, developers are not going to run the tests or just comment them out in the code. It simply takes too much time and interrupts the workflow.

Docker images

A neat detail but still a very important step for us to be successful in continuous delivery are docker images. When you go from a commit to deployment, you usually have several steps. Sometimes, you build from the same code several times, once for testing, once for quality assurance, and finally once for deployment. But if something changes in the build server during this process, you can end up with something being deployed that is different from what is tested. Docker images help us to avoid that. When one of our developers creates a pull request to merge a feature into the master branch, a docker image is created. And it’s that exact image that is tested and then later deployed. This really helps us to ensure quality.

Code review

I know that some people have negative feelings about code reviews and the impression that it’s all about controlling each other. But to me, code reviews are an essential part of continuous delivery. Of course, there is an element of control where you want to get a second pair of eyes on a piece of code to be sure that everything looks good. But code reviews also have an educating purpose.

Even in a case where I know that I’m an expert, I ask someone else to look at my code. They can learn from what I wrote. And when I’m sick tomorrow, they can easily do fixes on the code if that should be needed.

Last but not least, code reviews help to share the responsibility in a team. A feature moves from being one developer’s code to being the team’s code. And that brings me to the most important part I’ve learned during the years working with continuous delivery.

It’s a people issue!

When I tried continuous delivery for the first time a couple of years ago, still working for another company, I mostly thought of it as a technical problem. I focused on what infrastructure and technology we would need to make it work. But I quickly realized that it’s more about the people.

To successfully work with continuous delivery, you need an atmosphere of trust. You need to educate and empower your teams to work on their own. They need to understand that they have the ability, but also the responsibility, to deploy and stand for their products. If you have a rigid organization with a big quality assurance department that wants to approve everything, this is not going to work. You can’t be quick, and you create a “We” and “Them” between the developers on one side and quality assurance on the other side.

Instead, you need an open atmosphere where you trust your own teams. At Winningtemp I feel that we have managed to be pretty good at that, it fits our basic philosophy.

In the beginning, it can feel a little nervous, but once you are in it, you gain a much more open and creative environment. It’s so much more fun to work like that!

We definitely feel how the atmosphere has become better and trust has grown during the last year when we worked a lot on these processes. And soon, I’m sure that everyone will feel comfortable enough to even go the last step from continuous delivery to continuous deployment. It will come naturally to think: “Why do we need anyone to approve deployment for what has been merged into the master branch? Of course, it can be deployed.” I’m sure that we will soon be there.