The role of Environments within GitLab
Goal
The goal of this issue is to spark some discussion around what do we mean by "environments" at GitLab and what our common vision is on this topic.
@kencjohnston described the potential situation well:
We started with thinking about environments from a CI/CD (Verify/Release) perspective and that is limiting our ability to deliver experiences around environments from an Ops (Configure/Monitor) perspective.
So some questions:
- Does the team agree with that description?
- How have our competitors in the Ops arena modeled environments?
- What is a small step we could do to improve? We are going to run an Ops ThinkBig session on 2021-01-14
Environments
Environments are at the intersection of infrastructure and release management. From a developers point of view, every branch deployed as a review application might be a separate environment. These deployments likely happen on the same infrastructure, like a development cluster, that the develop does not need to be aware of. On the other hand, from the SRE's point of view, the development cluster is a single infrastructure entity, and the individual deployments in that cluster might not even be monitored by them.
As a results, from a code management point of view, environments are represented best with different approaches. Sometimes, every branch in a repository is the best abstraction, in other cases environments are the directories and/or subdirectories on the master branch. Still, as the industry is moving towards "X as Code" and we expect repeatable builds and immutable release artifacts being code drive is the trend.
Environments have special access rights attached to them. These access rights determine who can modify, monitor or troubleshoot a given environment, and there might be various authorizations around provisioning new environments too. Moreover, environments likely have environment specific data, like variables and secrets that should not leave the given environment, but should be shared between GitLab and the target platform.
As already hinted upon, environments might take many forms. They might mean a whole infrastructure starting with networking and IAM up to a running cluster, or they can be just an EC2 or Fargate instance running on AWS with a public IP.
Target user
The primary users are enterprise SREs, Engineering Team Leads and DevOps engineers who have to manage environments.
Affected categories
There are many product categories at GitLab that might consider Environments to have at their core. Actually, I'd argue that all the categories in Configure, Monitor and Release actually evolve around environments. Still, my impression is that GitLab has a pretty weak abstraction for environments.
Current status
GitLab provides environment "labels" that can connect CI jobs to running target environments and clusters, so we can build environment boards. Based on occasional user feedback I received, the environment boards are mostly useless in their current form, and related features, like the web console don't work as expected. As a result, environments are used for review apps and can provide very-very basic insights into the current status of the given environment, without much management possibilities.
Today we miss
- authorization and access rights management around environments
- we have only hacky support for directory based environments, if any
Discussion starter
- How do you see environments in your group? Are they central to you? Do you have any plans around them?
- Do you have any vision what should environments be and how should they act? Are these aligned with the above thinking?
- Where are we today in this journey? How do you see this aspect of GitLab?