search

OctopusDeploy / Issues

| Public | Bug reports and known issues for Octopus Deploy and all related tools
https://octopus.com
162 stars 20 forks source link

Make retention policies '# of releases to keep' be per-environment #841

Closed PaulStovell closed 10 years ago

PaulStovell commented 10 years ago

Currently if you select "Keep the last 5 releases", this means keep the last 5 releases that have been deployed to any environment. We also keep the latest deployment in each environment. This means that if you create 6 releases that are deployed to UAT, you'll be left with only one previous Production release.

Let's change the meaning of this setting to be "Keep the last X releases in each environment". This means that we'd be left with whichever 5 releases were deployed to UAT, and whichever 5 releases were deployed to Production.

Consider this too: https://octopusdeploy.uservoice.com/admin/forums/170787-general/suggestions/3913771-expand-retention-policy-to-be-version-based

dotnetwise commented 10 years ago

+1

dotnetwise commented 10 years ago

Almost three months passed and this is still a big headache issue for us. We don't ever want to remove the Production / Live releases, but only keep the last 5 in dev / staging.

However this is not possible in the current version. This is more of a buggy / missing / must have feature than simply an enhancement. Please address it to 2.4.9

PaulStovell commented 10 years ago

I would have liked to have done this on 2.4.9, but the changes required ended up being pretty invasive (a new Raven index and a large rewrite of how we apply retention policies) so I've made the change on 2.5. 2.5 should be available as a pre-release pretty soon though.

crossetj commented 10 years ago

@PaulStovell, I just installed 2.5.4 and was looking forward to this feature. I immediately realized I misread your solution. Unfortunately what you've implemented here doesn't help us at all

What both I and @dotnetwise need is to be able to apply completely different retention policies by environment.

I want to keep any release that's been deployed to production forever. I only want to keep a limited number of dev and staging releases.

I realize that Octopus doesn't really treat environments differently - 'Development' and 'Production' are just labels attached to environment IDs. Unfortunately not all environments are equal. In actual practice we need to treat production differently in many ways. I've found workarounds for most of them but retention policies are killing us.

For just one of my projects I have 27 production releases. Because of the one size fits all retention policies I have to keep more than 350 non-production releases.

This swells the database and makes it much more difficult to find the releases I do care about. This is the single biggest problem we have with Octopus to the point where I'd be happy if this was the only new feature in 2.6

dotnetwise commented 10 years ago

Perfect valid argument @crossetj ! I thought you have already implemented it like this in 2.5.0 but seems like not.

kmsheehan commented 10 years ago

Not sure if this is still being tracked - since it is marked closed - but the lack of any reasonable retention policy is very close to a stow stopper for my recommending this to any more of my clients.

I need to respect their disk space - but I also need the tool to respect a 'formal' release that I can archive forever to meet any sort of release management (ITIL or CMMI) or even common sense repeat-ability standards.

lock[bot] commented 5 years ago

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.