We have a number of environments we are slowly phasing out of our deployment process to keep it more streamlined. Ie. Instead of deploying to 5 environments, we have logically separated these to 2 or 3.
Is there a way to remove the release history for a given project and environment so that it doesn’t appear in the dashboard view?
Ideally we’d like to do this in small steps rather than completely blow away an environment.
I would very much like to see a solution to this.
We have separated an environment in multiple pieces, and now old deploys are still shown on the original environment (which is still in use) for projects that have been moved to the newer environments.
Can anyone tell me the status of this issue?
Is it implemented, and I just couln’t find out how to do it?
Is it on the way, or has it been dropped?
My suggestion would be either to a) remove that environment from that Project Group, so it wouldn’t show on the Dashboard, or b) delete the releases that were deployed to that environment.
a would allow the releases to be kept, and just hide the info from the dashboard, while b would allow you to slowly phase out old releases until none left had ever been deployed to that environment.
Thanks for the reply ccamburn!
The workaround are nice, but in our case they unfortunately cannot be used.
We cannot do a) because we are actually using the environment for other product releases - removing the environment would also remove these good releases.
We cannot do b) because we actully need to be able to install that particular release on other environments. But of course in the future we will be able to do this.
Anyway I think this still is a bug, because we will probably run into this situation again, and waiting some months until the releases are too old is not the rigth way to do this.
I’m just a user, so I can’t say what the Octopus team would consider it, but I consider this as an intentional feature, not a bug. One of the things that makes Octopus great is the ability to keep information about previous releases. Removal of that audit info goes against one of the basic principles.
It seems the issue stems from a combination of two things in your setup. The first is the changing of environments. My suggestion would be if you plan on swapping around machines in an environment like that, remove the original one and split them into new ones. This way you wouldn’t have any projects using the old one, and it could be removed from the Project Groups.
The other issue is that Projects within the same group should be deployed to any environment in that group. If you have a project that will never again be deployed to a particular environment, then perhaps it no longer really belongs in that same group?
I’ve never run into an issue where I have needed to get rid of anything on the dashboard, but that is because I don’t really change my environments, and I have multiple Project Groups for different groups of environments.
Hi,
Interesting discussion! Just to summarise the available solutions:
From a product design point of view I think this is where we walk a bit of a tightrope. On the one hand, its your data and you should be able to do what you want with it. On the other hand, there’s pressure for Octopus to have a certain amount of integrity (i.e., you can’t rewrite history) - without that, there’s no reason for anyone to place any trust in what Octopus shows. Taken to the extreme, it shouldn’t be possible to delete environments or releases either, but I don’t think we’d go that far.
The compromise is you can delete an environment or a whole release, but you can’t delete individual deployments. If we allowed individual deployments to be deleted, it would be possible for someone to deploy a bad release to production, then delete the deployment and have the dashboard now show the old deployment - i.e., what’s shown in Octopus is now wrong, and the feature would be open to abuse. Deleting and recreating a whole release has more of an impact (new dates would be shown, etc.) so it’s less likely to be abused.
That said, we do have an audit trail in Octopus, and it would be possible to allow the deployment to be deleted (perhaps by admins only) and to simply audit the fact that someone deleted it. I’m not convinced that it would be a good idea yet, but I’ve created a suggestion on UserVoice to allow voting on it: http://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6119608-allow-individual-deployments-to-be-deleted
Paul
Thank you both for replying! Very good points you have.
Firstly, i agree about the audit information should not be deleted. But maybe it can help to say, that what I am suggesting does not necessary mean deleting of audit. It rather means putting on some kind of view about what to see on the screen.
We redesigned our setup, and the view is now showing some of the old design.
About the example of deleting a bad release and by that making Octopus show the old good one, which is wrong, I think my case is actually an example of more or less the same.
We copied some servers to a new environment to make product B reside here and product A reside in the old (A and B on the same server though). Now A and B have version let us say 1 both on the servers. And in Octopus they will figure as version 1 on the old environment. Now we deploy version 2 of product B to the new environment (only possible choice), which means that the server got version 1 of A and version 2 of B, but in Octopus it will figure as version 1 of both A and B on the old environment and version 2 of B on the new environment.
That showing of version 1 of product B is obsolete and wrong, and that is the one we would make history by not showing it (but still in the audit log somewhere behind the scenes)
Hi Troels,
Thanks for all of this extra information.
What we have decided is to allow for deleting deployments via the command line.
I have created a GitHub issue that you can track here:
Cheers!
Vanessa
Thank you very much.
I appreciate the very quick feed back on this!
Hi Troels,
Just as a follow up, this has been added to the API (see the issue in GitHub) and is available as a pre-release from here: http://octopusdeploy.com/downloads/2.5.3
Cheers
Vanessa