Environments

marvinCI

We’re using our self-developed marvinCI to automatically deploy our GitLab projects to the 🐳 Docker servers.

However, as you can see in the next 2 chapters, we differ between Development environments, and Service environments.

Hint

Check out the environment documentations to see all available marvinCI MCI_* environment variables.

Development environments

For our self-developed projects, we’re leveraging the deployment pipeline of the Shared GitLab CI files.

This ensures that every branch gets automatically deployed to its own dedicated 🐳 Docker environment:

Environment

Git ref

URL

🛡️

♻️

Review

Feature & hotfix branches

{branch}-{project}.review.confirm.ch

♻️

Main

main branch

{project}.main.confirm.ch

🛡️

♻️

Release

release/* branches

{project}.release.confirm.ch

Stable

Git tags

{project}.stable.confirm.ch

🛡️

Note

Legend:

  • 🛡️ Eternal branch, which will never be undeployed

  • ♻️ Data clean up when a new commit is pushed (clean up = delete)

The {branch} is a sluggified version of the branch name.

Important

All deployments are made to the development server.

In case MCI_DEPLOY_TAGLESS is set, deploying to main will directly result in the deployment of the stable, rather than the main environment.

Service environments

For our ⚙️ Services, we’re leveraging the service pipeline of the Shared GitLab CI files.

By setting the MCI_DEPLOY_SERVICE CI variable, the deployment target can be controlled to one, or multiple of the following environments:

Environment / server

Git ref

MCI_DEPLOY_SERVICE

URL

Test

Non-main branch

contains test

{service}.test.confirm.ch

Live

main branch

contains live

{project}.confirm.ch

Customers

main branch

contains customers

{project}.customers.confirm.ch

Management

main branch

contains management

{project}.management.confirm.ch

Environment subdomains

As described in the Development environments, and Service environments, we’re using a clear convention for the DNS hostnames of the deployments.

Most of these deployments will leverage our DNS wildcard domains, so that we don’t have to update the DNS records, each time we’re deploying, or undeploying an environment.

Deployment URL’s in GitLab

We’re leveraging GitLab Environments to simplify deployments, resp. deployment URL’s during the review. The environments, resp. deployment URL’s will be displayed within a GitLab project on several places: