Dynamic development environments - What's the point?

In many of our projects it is common that we work with several employees on several developments at the same time. Therefore, it often happens that two or more tasks are developed in parallel, but are to be tested or approved independently. Why we decided to use dynamic development environments to solve this problem, we will tell you now:

Basically, we create a separate branch in Git for each task, which makes parallel testing and quality assurance no problem. For many projects, however, we have only one central acceptance system. Only one branch at a time can be deployed to this system. If, for example, the approval of a development is delayed due to the absence of an employee or the responsible contact person at the customer, all further developments are blocked for the time being and the entire project comes to a standstill. This not only causes delays in the overall project, but also dissatisfaction among our employees.

So in order for us to be able to play out several branches at the same time in the future, we needed several acceptance systems. For this purpose, we already developed a concept for dynamic development environments at the TYPO3Camp Rhein-Ruhr 2017.

Based on Docker and Kubernetes, we first set up our own cluster for Docker containers.

The dynamic development environments are controlled by Gitlab CI. Every time a branch is pushed, a job in Gitlab CI's pipeline creates a new version of a Docker image. The image for Docker is created specifically for the branch only and includes, among other things, all artifacts and the project itself.

Starting or updating a development environment is then done via Slack command or directly via Gitlab CI. If we delete the branch, the pipeline stops in Gitlab CI. Before the pipeline stops, a job still stops and deletes the development environment.

The biggest advantage is clearly that we have a separate acceptance system for each task in a project. This means that testing and approval of parallel tasks is no longer a problem. For project managers and developers, this means that there is no additional effort to play out and test a task. Particularly in customer projects, in which many developments and sub-projects often run simultaneously, we were able to take the pressure off the system through the dynamic development environments and eliminate a large part of the previously necessary coordination within the sub-project teams. The general displeasure with "busy" acceptance environments is now also a thing of the past.

As a disadvantage, we must clearly mention the required infrastructure. The more acceptance systems run on the cluster, the more hardware we need. Accordingly, the financing of the cluster must also be guaranteed. In addition, a certain amount of effort is logically required to configure and manage the cluster and the development environments running on it.