Skip to content

CI / CD

We at Statista thrive for maximum automation with minimal human interaction for tasks like deployments or dependency updates. We are commited to use GitHub Actions as our CI/CD pipeline tool. (All legacy Jenkins jobs are deprecated and must be migrated.)

The Continuous Integration in CI/CD

CI is responsible for building and testing the code. It is triggered on every commit to the repository. This ensures that the code is always in a releasable state. Things that can/should be tested:

  • Unit tests
  • Integration tests
  • End-to-end tests
  • Formatting
  • Building the code
  • For Docker Images, build them and run them in your pipeline
  • everything that cant be run in CI needs to be deployed to a test environment and tested there (preferable automated) a good example is Cloudfront Functions.

Automated Dependency Updates

We use Renovate to automatically update our dependencies. Renovate will create a PR for every dependency update. If configured properly through the Policy-Bot minor and patch updates will be merged automatically. A good example is this Repository. The amount of human interference is reduced to a minimum. If all tests passes, those PRs will be merged automatically and even deployed.

  • [] Add more Details about Renovate & Policy Bot and how to properly integrate it

The Continuous Delivery in CI/CD

CD is responsible for deploying the code. It can (in the best case will) be triggered on every commit to the repositories main branch.

Infrastructure as Code

  • [] add an abstract and links to why?

Branching Model

For a proper delivery of commits from a your local branch to the main branch, we propose the following branching model:

  • main branch: this is the main branch of the repository. It should always be in a releasable state. (this should be automatically deployed to stage)
  • production branch: this is the production branch of the repository. It should always be in a releasable state. (this should be automatically deployed to prod)

from main to production branch, we should use Fast-Forward-Only-Merges or Rebase. This way we maintain a clean history of the commits and deploy the exact same commit hash anywhere. Teams can decide for other workflows as long as a clean git history is maintained so commits can be traced down exactly.

If you dont have to support multiple versions of your App or Library a Git Workflow like Git-Flow is discouraged. It is too complex, hard to maintain and messes up the git history. We recommend to use a simple branching model.

Ultimately, the goal is to have a clean history of the commits and deploy the exact same commit hash anywhere.

The golden outcome could be Trunk Based Development where every commit which passes the CI is automatically deployed to stage and prod. This is the goal we want to achieve in the future. For that we need to have a proper Feature Toggle system in place. This way we can deploy the code without having it enabled for the users.

Last updated: January 05, 2026 at 13:31
By: Markus Wolf