Skip to Main Content

How we develop Software Part 4: Continuous Deployment

From our point of view, there is only one right time to roll out a new feature to the server: when it is ready. Not sometime, but right away. Why wait? The work is done, the feature is tested and the developer, product owner and customer agree that it adds value to the site. So go for it. 

Of course, this only works if deploying it to the server doesn't create a huge overhead. But this is exactly what we achieved in part 3 of this series: we can fully automatically assemble the code including all dependencies and deploy it to a server. Bingo! 

Now we could sit back, sip a cup of coffee and check off another marketing buzzword. But that's not how we work. 

Harvest what we sow!

In the previous part of this series, I explained that our build chain doesn't really care which server we deliver the site to, as long as it's accessible and we have all the information we need. 

At the same time, for internal QA and for the review meeting with the client, it would be great to have an environment where we could discuss, test, and have individual features approved. 

And of course, we built just that: Our review server.

As soon as a developer submits work on a feature to our version control system, our buildchain goes off and builds for all it's worth. In addition to the many tests to see if the developer has followed the coding guidelines and the code is clean, it now builds a standalone instance that differs from the current production site in only one detail: The feature that the developer has just worked on.

Review Server with Wow Effect

Many of our customers are enthusiastic about this tool - only a few minutes after the developer has submitted his work, a completely independent version of the website is available, including its own database, all files and of course an SSL certificate. So that Google & Co. do not index it, it is secured by password protection. 

We can change individual configurations specifically. For example, we often do not deliver emails from forms on the review server to the actual mail server, but use a mailtrap tool or service. This allows the e-mails to be viewed manually and tested automatically. API connections or Solr servers for the search index are also often configured to a test environment to avoid messing up production-relevant data. 

Every change to the website is provided in a separate review instance and can be put through its paces by the customer at will. With up-to-date data, it is clear at all times what this change will do and what the live instance will look like once this feature has been accepted and played out. 

And if it takes a While?

Since our review server instances are completely self-sufficient, we have no limit to the number of instances we automatically create. When we are working at full speed on projects, it is not uncommon to have half a dozen or more review instances of a project active at the same time. If a customer's department needs a little longer to review and approve the new code, we simply keep the instance active longer. Smaller features are only active for a few hours if the customer quickly provides feedback and gives the green light. 

Of course, automation also means that we delete the instances when they are no longer needed - if the code is integrated into the main branch and the associated ticket is closed, the instance is also deleted. 

Data Protection is a top Priority

If the production environment contains data that is relevant to data protection, e.g. participant data from a competition, we can anonymize this for use on the review server and the development computers. In this way, we ensure that no data worthy of protection is stored on the developer environments and the review server, but that the tests can be run on an environment that is very close to the real data. When testing, it makes a difference whether there are 20 test data sets in the system or several hundred thousand data sets in real operation.

Our customers are thrilled with the capabilities of our review server. A few minutes after completion of a feature, a copy of the current website is available, which differs from the actual production website only by this one change to be tested. This makes testing and acceptance much easier and speeds up the development process. All stakeholders can see and try out what happens when this change is accepted and delivered to the production environment.