The cost of not automating your software processes

If you have ever required working with servers, you will have noticed that the process of configuring one or the other instance is quite similar. Although the process is repetitive, it takes a long time; in addition to being subject to human error.

When I started working directly on some servers to configure my projects in Django and WordPress I noticed that the steps were basically the same all the time, so the questions arose:

1. Why can’t I automate it if there is a manual and repetitive process?
2. Why should I be interested in automating processes?

Why can’t I automate it if there is a manual and repetitive process?

There are cases in which not automating can be a valid option, although the only ones that I can think of are:

1. I am not in charge of the servers or infrastructure in my company and/or the time periods in which I have to carry out a server process are quite long.
2. The changes are made directly on the server, so once configured you only work there.

From these questions, my experience and extensive research, I came to the following conclusions: In the first case, non-automation can be justified with a simple lack of need. The frequency with which I must perform these tasks is so low that I do not consider it repetitive (there remains the question of how security patches are applied in that case, but it is not the subject of this post).

In the second case, when working directly on the server, the automation of the processes is very difficult since changes are made to the code frequently. By working directly on the server, any modifications that are made automatically, without taking these modifications into account, will cause work to be lost. In this case, before thinking about automating, it is better to think about using best practices when working.

With this in mind, unless we rarely touch the server, or use it as our desktop computer, I couldn’t find valid reasons not to automate.

And what are the reasons to automate?

It’s easier to find reasons to automate your software processes:

1. You want to optimize your time, using it for operations that really matter and not for repetitive processes. On average, setting up a new server can take 1-2 hours depending on the stack you are using. Automating it can reduce the time you spend to one click, and the server will be ready in 5 minutes or less.
2. You want to eliminate human error from the equation: Humans make mistakes, especially when we are tired and doing repetitive tasks! Automating a process lowers the risk of error and makes recovering from it much easier and faster.
3. You want to optimize costs: A developer’s time is expensive, so it is important to spend it on the right tasks. If the staff required to keep your infrastructure running is reduced, so are your costs, while increasing the quality of your products.

Automating is not free, it requires a large initial investment to become familiar with the necessary technologies and methodologies. In my case I started with BASH scripts, then I tested AWS CodeDeploy and I finally found Ansible. I went from configuring my servers manually command by command to configuring them according to my parameters with a single task. After being at that point, it could be further automated, integrating tests within our process and creating a flow similar to the following image.

Basically, our flow is the following:

• Some of our developers send something to our version control system (GIT).
• The automated testing process begins.
• If the testing process fails, the developer in charge must correct what went wrong in order to complete their task.
• If the testing process is successful we proceed to update our development server.
• General tests, in addition to the automated ones, are carried out by someone in charge of QA.
• If all the features needed for the next release are ready, the project manager, who is not very familiar with the technical process of the deploy, can release.
• The testing process is repeated, with the difference that if everything goes as expected, the production server is updated, not the development server.

There are several details about this flow. Among the many advantages that this flow offers us, it is worth emphasizing that our development server always contains the most updated version that has passed the tests, so you can see a feature live as soon as a developer finishes it. This is very important both for internal processes and for communication with the client; since we can receive feedback and react quicker if changes in strategy are required.

On the other hand, let’s move on to costs. We currently have 8 active developers, who constantly update the repository of our projects (more than 10 active). If we wanted to keep all development instances up to date without our automation tool we would require one or two additional people fully dedicated to updating them, with all the additional downsides that brings.

Do you want to try this process in your company? Do not know where to start?

As part of our process we develop a tool that allows us to support our entire process. If you are interested in automating the processes in your company we can advise you on how to start and we are open to offer our tool as a service.