Skip to content
GitLab
Next
Closed (promoted) (promoted)
Issue created by Jackie Porter@jreporterDeveloper

Share production environments across projects

Problem to solve

Production environments are special ones and sometimes we could have several environments that we use as a production. Currently, the growing GitLab roles leave the ability to edit environments and trigger a manual release to production vulnerable.

We want to be able to support environments at the group-level. This would address the nature by which environments were created in, at the project level for project members. The lack of context and ability to manage access when a environment is shared across multiple projects is disruptive to they way teams may work with each other in production.

The desire for views across shared environments was addressed in #15419 (closed), this will support the ability to manage environments at the group level.

User experience goal

Allow users to see their shared environments @ group level.

UX DoD (Definition of Done)

Click to see the UX DoD (Definition of Done) tasks 🔽

Entry Criteria for Design

  • Problem has been validated
  • Has UX effort accounted for in long term cycle, we know unknowns

Criteria for UX DoD

  • UX label is added to the issue
  • User stories and acceptance criteria have been created
    • Edge cases were considered
  • Cross-team dependencies have been identified, if applicable
  • Prototype or mock for each user story have been created
    • Empty states
    • Responsiveness
  • If changes involve copy, UI text label has been added
  • Pajamas: UI Component design have been identified
    • Pajamas issue is created (new workflow)
  • Marked as Ready for engineering evaluation per user story moved into workflowplanning breakdown & needs weight

Entry Criteria for Ready for Development

  • Scope has been defined and reviewed with engineering
  • User stories have been weighed and are less than 5 MRs
  • Create new issues for follow up user stories

Criteria for Engineering DOD (in addition to defined process)

  • UX review for MRs that include user experience changes - mandatory for frontend that has impact to UI/UX
  • Update SSOT in issues:
    • Update prototypes of deliverables
    • Add link to documentation
  • Create new issues for follow up and open scope

❗ Do not remove this expandable section. The content is part of the UX Definition Of Done process. DRIs: @rayana @jmeshell

Intended users

Further details

Additional considerations for access to shared environments at the group level or how this plays with Protected Environment Functionality.

Proposal

Supporting environments at the group level would mean, as per the scope of this issue, being able to:

  • Visibility into environments across projects, to be shared by users within a group in different projects.
    • View which environments share production environments/deployments
  • Administration of environments across projects.
    • Manage the access/permissions/variables
  • Create context when a single environment is being used in different projects.

Theme: View which environments share production environments/deployments

The criteria that classifies an environment as shared by multiple groups is the external URL. However, there may be times when you want a dynamic URL - you don't know the URL before the deployment script finishes (see documentation). To fix that, you can rely on environment variables, that are at this point configured on a group level only.

For this MVC, we would only be able to track environments that share a static URL.

For example:

Project 1: rayana's group > test-project-1

environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://development-$CI_COMMIT_REF_SLUG.com

and

Project 2: rayana's group > test-project-2

environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://development-$CI_COMMIT_REF_SLUG.com

These environments would appear as shared in the group overview.

UX proposal

In order to create visibility at the group level, we can create a new section/area in the group overview that allows users to have an at a glance picture of existing shared environments.

  • At the group level, add a new menu option called Environments.
    • We can rethink this to follow the same menu hierarchy used at the project level (Operations > Environments), but for now we would not add any other submenu options.
  • In the Environments group page, users have an overview of environments created at the project level that share the same URL.
    • Environments would be grouped by URL.
    • Within each environment, we display to users the in a table view:
      • Project name
      • Environment name/ID
      • Status
      • Updated at
      • Commit (?)
      • Deployment

We can potentially reuse the same list view for environments in the frontend.

If we need to have a separate section, we should allow users to see how many projects have that environment enabled and it should allow them to jump into each projects last pipeline deployment to that environment. The users also wanted to be able to create environments at the group to be consumed by the project.

Manage the access/permissions/variables

Administration of environments across projects is done within the settings page. Today, permission/access is still managed at the project level.

It is possible to configure Variables at a group level (group > settings > ci/cd settings - Variables). These variables are configured in the parent group settings, and will be active in the project in addition to the project variables. Users can only see the variables at the project level, management happens at the group level.

UX proposal

Users should be able to set access/permissions at group level per environment, and those permissions would cascade to the projects the environments are being used.

Permissions and Security

  • Environments shared across projects, should allow those that can deploy within their project the same permissions at the group-level.
    • Another way to phrase this: when permissions are set at the group level for an environment, those should flow into the project.
  • Access to protected environments should follow the same pattern/model.

Documentation

Testing

  • Those who cannot deploy at the group should not be able to deploy in the project
  • Those who cannot deploy at the project should not be able to deploy at the group
  • All group members should be able to view the environments and environments dashboard for their projects

What does success look like, and how can we measure that?

  • Less requests for access control changes for environments and releases
  • Increase in usage of environments and visibility into environments that are shared

What is the type of buyer?

  • Premium, Ultimate
  • Might consider starter

Out of scope

  • Managing environments variables is going to be tackled with a different issue: #2874 (closed)

  • We need to allow users to protect environments at the group - This is managed in #215888 (closed)

Links / references

Target documentation link https://docs.gitlab.com/ee/ci/environments/#group-environments'

Edited by Rayana Verissimo