What does an automated pipeline bring us besides initial costs? Above all, a documented deployment flow that anyone can execute. Automated deployments save time, money, nerves and make room for value- added work ‒ but how does it all work exactly? This article provides the answers and presents a corresponding set-up.

The set-up presented below can also be found on the GitHub account of Never Code Alone, since the topic of open source is a central concern for the author ‒ after all, it means giving more than taking [1]. The aim of the article and the technologies presented here is to create an automated deployment flow that can also be executed by the product owner via mobile phone from a sunny park, leaving more time for other tasks. This way, not only us programmers will be happier, but software will also be developed more sustainably.

From Maven to GitLab

This article doesn’t want to go too far back in history, but there was already a perceived difference between Java Enterprise development and the PHP script kiddies. Yes, our dear programming language is still marked by prejudices and has an elephant as its logo. One very important difference is that Java must be compiled, and PHP just runs like that. In the context of our article, this means that Java developers have always been concerned with automated processes, while their PHP colleagues somehow bring their projects live. In the beginning, there was Maven, which then became Jenkins or was spun off. The countless offshoots, CodeShip for example, should only be mentioned here. In the following, we will take a closer look at GitLab, but other deployment technologies are of course also possible. The differences are particularly noticeable in the number of available plug-ins, but this should not play a role in our Symfony and e-commerce projects.

There’s no way back ‒ what’s now will never be undone

Even though Wolfsheim is a terrible band [Ed. the author relates to Wolfsheim ‒ Kein Zurück, which translates to 'No turning back'.], there’s a lot of truth in song lyrics ‒ and it’s very much about IT. If we look at what exactly we want to bring live, it’s ‒ with the increasing age of the applications – only a few individual files: vendor updates. Usually, not much happens on the database side. In reality, it’s new content elements and, of course, bug fixes. Sometimes only a link or a headline must be removed. But no matter how much code there is that needs to be brought live, it happens all the time ‒ especially in teams. And even if it’s not live, it always must be brought to staging environments. In practice, this is very often done manually on servers, where a connection is made via SSH, a git pull is executed and then the cache is manually cleared. This is usually followed by a quick, cursory sign-off before doing the same thing live. Bugs that arise during changes are only found much later in manual processes and usually these processes are not even designed for a rollback ‒ and if they are, then with the status from last night. So here, there is only forward developing. As a result, a lot of deployments happen very quickly, certainly not just every fortnight, at the time when they were scheduled. Software must be rolled out constantly and quickly: So, automating this very process makes perfect sense. And it’s not as difficult as you might think.

Stages adapt and let us grow overall

We have already described the simplest use case above: Git pull...