The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Deploy |
| Maturity | Viable |
| Content Last Reviewed | 2023-04-06 |
Welcome to the direction page of the Environment Management product category of GitLab. This page is part of the bigger Delivery direction. It is owned by the Environments group and is maintained by Viktor Nagy (Email).
Your feedback helps us building a world-class environment management offering in GitLab. We welcome your feedback in issues, epics and are always open to user interviews to learn more about your use cases or share more details about our roadmap. You can register a call with us through your GitLab account manager or through customer support.
Environments are at the heart of DevSecOps. From the application developers' perspective, environments are where the application gets deployed. Environments can differ in terms of lifespan, related change management processes, and policies. Some environments are short-lived, ephemeral, while others are long lived. Production environments are the place where your applications meet your users.
Environments are the culmination of the work of several teams and are the place where the application will finally serve its users. As a result, they should present their current state and related artifacts to support critical decisions in security, rollout and troubleshooting.
The key aspects of environments are:
Environments are as central to a DevSecOps organization as Merge requests are to a Dev organization. We envision GitLab environments to serve as the single entry point to every information and action related to a given environment from status data to security reports and actions related to new release rollouts and troubleshooting.
As GitLab offers solutions for the whole DevSecOps lifecycle, we want to visualise data to environments on the environment pages. The environment page should show
related to the running deployment(s) together with information about
Release managers should be able to rely on environment pages to gather all the information they need to block or move a release forward. Moreover, they should be able to do it from within the environment pages. The rollout might involve running a dedicated CI/CD job in a pipeline or changing a feature flag. Either should be supported. The GitLab Continuous delivery direction provides more details on our plans to support release managers, and the Feature flags direction descibes our strategy and plans related to feature flags.
As Environments typically include deployments, this direction is best read together with the Deployment management direction.
While Environments can be best interacted with through the GitLab UI, we see that highly efficient teams prefer chat-based, integrated solutions for at least some of the functionality. While ChatOps is not a priority now, it partially falls under the environment management category.
We are in the process of building up our roadmap to work towards the vision described above. Some items we already know to be on this roadmap are
We don't plan to
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
The key capabilities of environment management applications are
This section is work in progress.
Primary persona:
Secondary personas:
This section is work in progress.
This section is work in progress.