Clear entries from top level DashBoard

[peter_m_mcevoy]

We find the top-level DashBoard on the UI very useful as an information radiator… However as our infrastructure has changed over time, and new environments have been added we’d like to clear/erase entries from specific (Project, Environment) combinations as a way to indicate that pair is no longer relevant (and thus reduce noise / increase the signal).

Asides from visual information, it’s would be useful to clear a Project/Environement deploy when auto-deploy Triggers are in play and a new environment is not ready for auto-deploys.

Anyway to do this? Would you consider as a minor feature?

[Bob_Walker]

Hi @peter_m_mcevoy,

A little background on how the dashboard works. Think of each project group as a Cartesian join of all the environments available to a project. For example, I have this project with the following lifecycles.

The dashboard will show all the environments for this project. Not just the ones in the default lifecycle.

If I remove an environment from the lifecycle

The dashboard will be updated to reflect that.

In addition, it will go through and add all the environments for all the channels for all the projects in each project group. If I move that project group up to the default project group you’ll see the development environment appears next to it, but it is empty.

To remove an environment from a project group, you’ll need to remove it from all lifecycles used by all the projects in that project group. Removing an environment from a lifecycle will not affect any releases. If a release went out to that environment it still is there. What you’ve changed is how releases are promoted going forward along with what appears on the dashboard.

If you don’t want to remove an environment from a dashboard. You can customize the dashboard by clicking the configure button in the top right corner. In this case, I only want to see test and production.

Which results in:

But this is a per person setting, not a global setting.

In regards to your specific feature request:

it’s would be useful to clear a Project/Environement deploy when auto-deploy Triggers are in play and a new environment is not ready for auto-deploys.

Our UX team is looking at how to make dashboarding better. I’ll raise this as a use case with them, but there is no guarantee it will be done, nor a timeframe if/when that’ll happen. I think it could be useful, but the question we always have to ask ourselves is, how many of our customers will find this useful and how many have been asking for it? This is the first time I’ve heard of a request, so the chances are fairly slim it’ll be picked up.

[peter_m_mcevoy]

Hi Bob,
Thanks so much for the detailed response: it’s great that you can take the time to construct such a detailed explanation in a forum post (like you have to my past questions), so I really appreciate it.

I totally understand that this is probably a case that’s very far down the feature list, so my expectations aren’t that high!

In your explanation at one point you say:

If I remove an environment from the lifecycle

(and you remove “Staging” from the lifecycle)

The dashboard will be updated to reflect that.
…
If I move that project group up to the default project group you’ll see the development environment appears next to it, but it is empty.

But in the case of the “Redgate - Feature Branch Example” project listed, there is still a “Staging” deployment listed, even though Staging is not a possible deployment environment anymore (from the Lifecycle change you made). It’s that information noise that my request is trying to address. I realize that the dashboard is displaying the historical deploys in an environment, but it’s no longer relevant information anymore. (and my naieve solution was to ask for a way to remove the historical deployment records - but I prefer the way of using the lifecycles you describe)

Unfortunately customizing the environment columns is not really what I’m looking for, as there are cases where we have projects that would have alternate lifecycles that would continue to deploy to Staging (to continue your example)

BTW, I hope I’m not coming across as argumentative - I love the product and this was just a minor bug-bear of mine on the information display

Pete

[Bob_Walker]

Yeah, in this case, my recommendation would be to organize your projects into appropriate groups where appropriate. My preference is project group == application. Each project in the project group is a component for that application, and they will typically have the same lifecycles.

Outside of writing your own interface and invoking the API directly, there isn’t a ton more possible. It is an interesting thought experiment, what would one consider noise vs signal and how can we reduce that…