Why do we automate software development? 

Quality is one of the principles that we uphold at Droptica. We want to create the best software, in line with our clients’ requirements - efficient, error-free and cost-effective. In this post, I am going to tell you about one of the most crucial factors impacting the quality of the software we develop - automation of the software development process.

We are enthusiastic supporters of automation. Over the course of the last ten years, we’ve had many opportunities to work with multiple clients on various projects and to collaborate with diverse teams. Every time, we lobbied for the highest degree of automation possible and for getting as close as possible to Continuous Integration. Often this was saving projects from grave consequences.

Before I move on to the benefits of automation, I’m going to provide you with a short summary of the way it works.

Software development automation

The automated software development process is characterised by the following characteristics:

1. A single common code repository is put in place. All developers place the code they write in the repository. Currently, Git is the most popular version control system. The code in the repository is the sole source of software in the project. There are no additional scripts, programs or other code sent by e-mail or distributed in the company in any other way.
2. There is the so-called “build process” in place. The build process is a standardised method for creating and building subsequent software copies. Every developer, tester, testing script and mechanism uses the exact same process for obtaining the current version of the software.
3. The build process is automated. Obtaining the current version of the software does not require anybody to perform a large number of manual actions. In an ideal situation, the build process is another script or a piece of software, which is also versioned in the code repository. A developer downloads the latest code from the repository starts the build process (for example by starting a script) and obtains the current state of the application. The same script should be used by all the testing tools and testing environments, as well as for building demo versions.
4. The build process is fast. Building the software package does not last too long. This allows for testing results and implementing fixes multiple times.
5. The team commits changes often, every day or several times per day at best. The working code is pushed to the master branch in the version control system on an ongoing basis.
6. The testing environment should resemble the production environment as closely as possible. In an ideal situation, it would be a direct copy of a production environment.
7. The process of pushing software to production is automated. In a best-case scenario, pushing new changes to production should be done by clicking a single button or running a single script.

By achieving all the goals listed above, you gain many benefits that make the software development process more ordered.

1. You can quickly rebuild development environments. One of the biggest problems with projects with bad automation is the constant discrepancies between how the software works and runs in production, compared to development and testing environments. Due to the fact that the changes between environments need to be replicated by hand, it’s either done rarely or not at all. Each and every environment has some specific quirks, and if there are many of them, this problem just gets exacerbated further. Thus, the risk that the code or a configuration created in one environment will work differently in another one becomes high. Automated quick environment rebuilds eliminate this problem altogether.
2. There is only one source of truth about the current state of the project: The Build. Building the software gives you a true image of what the code looks like and how it works. The assessment of the results is clear, and there are no issues like “It worked on my computer” or “It works in dev but doesn’t run in the test.” A fresh and automated build of a project is the only thing that undergoes an assessment.
3. You can “build” software and test its deployment in the testing environment until you get the desired effect and a guarantee that the deployment will go exactly as predicted and that it will have predictable results.

In other words, the benefits of build automation can be summed up as follows:

1. “You know where you stand” – you can have a certain degree of certainty regarding the current state of your software.
2. Everyone works on the same version.
3. There is a single and objective way to check whether something works or not.

This alone can spare you the fate of many teams that waste a large amount of time on

1. checking why something worked in one environment, only to fail when deployed to another one,
2. or trying to replicate errors from the testing environment in a development or a local one.

Automated building is just half the success, however. Testing is the other half. 

Automated testing

Today’s software is very complex, often comprising hundreds of thousands of lines of code spread across many files. Such complex projects use numerous libraries and other dependencies. Changes in code and libraries tend to affect multiple functionalities in the system.

When implementing changes, software developers usually check whether the code works as intended. However, more often than not, they don’t have the knowledge of the system or the ability nor time to check whether their changes affect other functionalities of the system they are working on.

The same applies to testers as well - they are simply unable to check the entire system for errors which could have snuck in when testing new functionalities. If on a project they actually do perform all testing scenarios manually with every deploy, deploys start to be tedious and expensive. Every error that is found and subsequently patched requires changes in the codebase, which means testing the entire system from scratch or risking errors. Often, using such practices causes a long spiral of tests, errors, more tests, more new errors... Or, to make matters worse, sloppy testing resulting in errors being pushed to production.

This issue can be solved by implementing automated testing. There are many methods of creating tests and software testing, which is why I’m not going to list them here, just describe the required characteristics:

1. Tests should be automated, and they should be easy to run. Every developer should be able to run all the tests in their development environment.
2. Tests should be quick because otherwise they might be skipped due to them taking a long time to complete. Tests should be done every single time when the software is changed. In an ideal situation, each commit would be tested, but you should definitely test at least every piece of code to be pushed to the master branch.
3. Tests should cover the largest possible scope of the software. The number of tests and the way they are planned should enable testing all the crucial and significant functions of the software, and the team should be certain that the fact that all tests completed successfully means that the software works properly. There are many techniques for estimating test coverage, which can be used to control the number of tests.
4. Tests should be a part of the build. In an ideal situation, every build should automatically launch all the tests and display their results.
5. Every change should be checked by testing the entire system. Again, in an ideal situation, you would test every single commit, but often it’s enough to test the code before merging it with the master branch. When a developer updates the master branch with code that breaks the software, they hinder the work of other people who want to start working on a new task using the latest build – it simply won’t work due to errors in code. Teams that do not use automated testing often face an issue where some new commit breaks a part of the software and everybody who wanted to work on it are stalled until the error is fixed. Automated testing prevents such situations.

Automated builds and testing are keys to success

When you automate the building process, along with testing, you will end up with a mechanism in which you always know the state of your software. What is important, before adding any new changes, you can check whether or not they introduce new errors. Thanks to that, you can almost always decide to deploy the current version of the software to production. What is more, you can do it quickly and safely because it will be done by an automated process, which was tested beforehand in a testing environment, which is identical to production.

By achieving this level of automation, you can safely develop new functionalities, knowing that they surely work and don’t break anything, and then deploy your software. Basically, you eliminate the risk of breaking something, and if you find any error, you can fix it quickly.

Our experience

At Droptica, we do mostly Drupal development and Drupal support and we try to apply these methodologies to every project that we take over or start from scratch.

Usually, the time and work invested in creating tests pay off very quickly. The number of manual tests required before deployment falls dramatically, thus compensating the costs. Automated testing allows us to catch all errors and mistakes much quicker. Often when we start creating automated tests for a project that never used them before, we tend to find many errors that were never caught by anybody before.

Thanks to this, the team stops looking for errors and spends more time on developing software. Automation directly translates to higher satisfaction and confidence of our clients and shortened lead times, with an additional benefit – our team is more satisfied with their work.

When the automation is implemented properly and the tests are designed well, we can deploy our software even several times a day or according to a set schedule – for example, once a week – without running the risk of breaking our production environment. What is important, the deployment won’t take too long.