Continuous Integration (CI) at

At we are always striving to improve not only our products, but also our processes. One thing we have recently focused on is automated testing. To avoid breaking things as we move forward, we have developed a growing set of tests that are run before we deploy anything to production. In this short post, you will learn:

What Continuous Integration at looks like

While we obviously are an "infrastructure company", we also write our own software, e.g. for our cloud control panel. Just like many of our customers, we use Git to keep track of the source code that makes our user experience unique. This is where GitLab CI comes into play: GitLab CI detects when new commits are pushed. On every new commit, it runs a "Pipeline" consisting of multiple testing jobs.

In the case of our cloud control panel we have two different sets of tests: Unit tests and integration tests. Unit tests are run isolated against a small piece of code and do not require interaction with other services. Integration tests on the other hand really test the entire infrastructure. For instance, we have tests that actually start servers in our OpenStack-based cloud, or create Buckets in the Object Storage which is backed by our Ceph cluster. This gives us a good indication that the now-changed code still fits the use cases our customers rely on.

How Continuous Integration helps with our quality assurance

To make sure that all of our services are continuing to work, we are also running our tests every night, in addition to the permanent monitoring of all the systems and individual components. This enables us to detect potential problems within our infrastructure early and take action to ensure the best service possible.

In addition, our Terraform implementation is also tested on a daily basis using a special set of acceptance tests. This way we make sure that our Terraform provider interacts seamlessly with our API.

A good test suite is at the core of every good software and should continue to evolve and improve over time. While we keep improving and extending our software, we can be confident that our large and growing set of tests helps us avoid breaking things. Automated testing not only enables us to develop code faster, but also allows for broader test coverage, resulting in higher product quality.

Why we move further towards Continuous Delivery (CD)

While automated integration testing takes a huge load of tedious, manual work off our shoulders, there is still room for improvement: We also plan to use Continuous Delivery with GitLab CI. Continous Delivery will allow us to push to the production branch and just watch that commit being deployed.

We know that you want to use the latest features and improvements as soon as possible – who wouldn't? This is why we empower our engineers by giving them the tools they need to avoid repetition. After all, it is not about repetitive background tasks when creating value for our users, but about building actual solutions – and, of course, getting them delivered.

Testing and delivering,
Your team

Back to overview