Mastering Environments in GitLab CI/CD: Static vs. Dynamic

Environments in GitLab CI/CD exist to help you manage different configurations and deploy code at various stages of your software lifecycle. They solve the problem of needing distinct settings for development, testing, and production without the hassle of manual configuration each time. By using environments, you can automate deployments and ensure that your code behaves consistently across different stages.

You can create two types of environments: static and dynamic. Static environments, like staging and production, have fixed names and can be created manually or as part of a CI/CD pipeline. Dynamic environments, on the other hand, are generated during the pipeline execution and are typically used for single deployments. They have names based on CI/CD variables, making them flexible for review apps. You can also set environment URLs and capture generated URLs as dotenv variables, which is particularly useful for dynamic environments.

In production, you need to be aware of some gotchas. If the environment URL is malformed, the system won’t update it, which can lead to confusion. Also, the stop_review job doesn’t generate a dotenv report artifact, meaning it won’t recognize the DYNAMIC_ENVIRONMENT_URL variable if you try to set it there. Remember that to create environments, you need specific roles in your project, such as Developer or Maintainer. With the introduction of features in GitLab 15.2 and 15.3, managing URLs has become more flexible, but be cautious with version changes, like the removal of environment renaming in GitLab 16.0.