Pipeline view of environments

Description

We currently show the list of environments, and which code is deployed to each. We can improve on the display a bit to convey upstream/downstream environments, and at the same time, add valuable information such as which merge requests are deployed to each environment, that are not in the downstream environment.

We support arbitrary deployment pipelines such as staging and production, but also UAT, QA, testing, whatever. Since we don't inherently know the direction of flow between environments, perhaps you could move the columns around to order the environments how you like.

We should show the current status of each environment, grouped by major category (review, staging, production), and let you trigger manual actions to promote between them.

Then a key value-add for us is to display the MR information for each environment. e,g. list out which MRs are in staging, but not yet in production.

Proposal

Notes

• I'm not sure the deployment pod status is necessary on this page.
• We can't detect review apps with 100% certainty. We suggest naming review app environments like review/*, but it's not enforced. We should degrade gracefully if not. For example, just call the column "Review" so it matches the rest of the column names and can be autogenerated however you name your folder. Maybe we hide the deployment information for any group of environments, which implies the current design would not show the nodes for Staging. Or maybe we just hide things that only have 1 pod.
• Manual actions all have unique names that are user-specified in .gitlab-ci.yml. We could detect deploys between environments much like we do today for chat commands so we can still construct a Promote function.

Links / references

• Dashboard of all environments in a group

mentioned in issue #18439 (moved)

/cc @dimitrieh @tauriedavis

@dimitrieh I'm sure you could leverage patterns from issue boards for this.

mentioned in issue #28707 (moved)

Created https://gitlab.com/gitlab-org/gitlab-ce/issues/28707 for the dashboard view of the same thing across all projects in a group.

For the right-most environment (usually Production), I'm not sure which MRs to include, if any. If we define the list as "MRs in this environment, but not in the downstream environment", and there's nothing downstream from Production, then the list should be blank. If you happen to deploy to production before creating a release, then the stable release could be considered the downstream, and the MR list would include everything in production, but not in the stable release. But that's probably a small edge case. Perhaps it would be more valuable to show which MRs were deployed to production in the last deployment. Or even just the last X MRs.

@markpundsack @tauriedavis what about:

That's pretty awesome!

How do you detect review apps environments? What about testing, dev, integration,.. environment?

@alexispires Our recommendation is to put name review app environments like review/<branch-name>, but we don't enforce that so detection won't be 100%. If there are other stages, we'd handle them as additional columns.

Moved the design to the description, so copying the old images here for posterity:

---

I'm envisioning something like Heroku pipeline view:

changed milestone to %Backlog

@bikebilly I think this is growing in importance. It's not urgent as the current views are functional, but this feels like a significant improvement over our current environment lists. I'm not sure if it's addition to or instead of the environment lists. Maybe we do it instead of https://gitlab.com/gitlab-org/gitlab-ce/issues/31701, although that's not really saving us much effort.

added deploy label

moved to gitlab#8500

Hey! 👋

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue