Skip to content

Application Lifecycle Management (ALM)

The ALM is one of our most important topics in our development strategy. Here, you gain an insight of our company's philosophy concerning lean and professional software development.

This document describes the different roles of our configuration management. Principles, features and tools are explained in detail. This document is linked to our Hosting & Maintenance document, where we also follow our philosophy.


To satisfy the principle of separation of concerns, we have defined specific roles, which are involved in our ALM. Every role has different requirements and expectations from the environment they are working in.

The roles are:


First of all, the ALM is designed to provide the biggest benefit for our customers. The customer expects working software and wants to see results as fast as possible. This leads to short feedback cycles, a faster progress and a good communication between the customer and ourselves.

So, the customer and their product can have a short time to market.


This role has the most interactions with the ALM environment. A developer has the following requirements:

  • fast setup of a developer environment
  • enable collaboration in a developer team
  • a proper way to communicate with the customer
  • of course, develop the software
  • fast execution of tests
  • short feedback cycles with the building system


Although in our case the builder role is a machine, it is described here as well. The reason is we want the builder to work completely automated. Here, the focus is on consistency. So, e.g., the tests should run as fast as possible, but since this process is automated, it is not that time critical. The builder logs all the build steps and satisfy the fail fast principle. This means the build immediately stops, when something is wrong. Those build failures must be reported to the developers, so they can fix them as soon as possible.


Here you can see the complete process of our ALM and how it satisfies all the goals and requirements of each role described above.


First, we start with the role developer in the bottom right. One of the most important interactions for a developer is with the repository. We use GitLab for our entire configuration management. Everything a developer needs to work with, is stored here:

  • Source Code in GIT repositories
  • Developer Tools in Docker Images
  • Documentation in Wiki projects

We also use GitLab as our ticket system, where we can interact with the customer and other teammates. For our Drupal development the toolset allows us to pull data from the live system. This allows the developer to work with the real data or to reproduce bugs as fast as possible. The developer has the total control of the process. They can work and run the tests on their local machine and when they decide to push a change, the builder role gets triggered. The builder takes the same Docker images from GitLab (without the developer tools) and starts to build the project. This is important, because we follow the DRY (don't repeat yourself) principle, and the builder should use the same tools as the developer. The building process covers the following steps:

  • Build
  • Prepare
  • Test (Unit, Integration, Visual Behaviour, Code Style, etc.)

If all the phases are passed, the site gets deployed depending on the branch, like "Feature A", "Test" or "Live". This is completely automated. The deployment scripts are written with Ansible, which are also stored in GitLab projects. So, after a build was successful, the customer can see the results immediately on the specific version. For instance, if we work on a feature, and a product increment is ready, the customer can use and provide feedback in a little while.

To summarize our process the following chapters provide a comprehensive list of our features, principles and the tools in use.

Features and Principles

Infrastructure as Code

This is one of our key concepts. All our code for creating our infrastructure and tools is stored in Ansible scripts in our GitLab. These scripts can always be executed through jobs in a build pipeline.

Provide customer benefit as fast as possible

After a product increment or an entire feature is implemented, the customer can see the result in a few minutes. The customer has access to our GitLab projects which include the ticket system and pipelines.

Provide Quality Software

Of course developers strive to provide good software, and they can write and execute the tests on their local machine. But we go a step further. In our build pipeline every test gets executed automatically and fails if something goes wrong. If this happens, nothing gets deployed, so we can always provide a running system.

Single point of entry

The customer just can go the specific GitLab project and contact us by opening a ticket. They can also follow the progress in Kanban Boards or even in the build pipelines.

The same goes for the developers. They are working on the code base, which is managed by GitLab. Even the tools for development are managed by GitLab.

Keep Drupal Configuration up to date

As you can see in the overview picture above, there is a connection between the live configuration and the GitLab repository. If someone updates the configuration on the website, the changes are pushed to the Git repository. This assures an actual system and retracing the changes that are made.

Open Source Toolset

You do not need a paid licence for using Drupal of course. We want to keep this philosophy for our tools as well. All deployment scripts and developer tools are free to use for everyone. This allows to raise the quality, and the number of features, so everybody can benefit from.

Easy entry area for Drupal developers

Developers just need Docker on their local machine. The development tool L3D, which is open source, creates all the Docker containers needed for developing Drupal. This also includes debugging and testing. Now, the developer can use the IDE of their choice.


Here you see our tools, which are involved in our ALM. As you can see, we make heavy use of GitLab. This allows us to maintain just one tool, which provides a huge set of features and a single point of entry for our customers. We also want to satisfy our principle of separation of concerns. Every tool is designed to achieve a specific goal and just using it for this.

Function Tool
Repo / Versioning GitLab
Issues / Communication GitLab
Agile Planning GitLab
CI/CD Pipelines GitLab
Drupal Development Docker
Deployment Ansible

Last update: January 12, 2021 18:06:10