The next version of Octopus will include the concept of retention policies. These allow you to control how many releases and deployments are kept, in order to keep control of disk space usage and to help improve performance. In this blog post I wanted to share some plans for how this new feature will work, in order to get your comments.
Setting retention policies
Retention policies will plug into the recently released Project Groups feature. This allows them to be configured for a group of similar projects, without being repeated too many times.
The first two settings relate to the Octopus web portal, and they control when Release, Deployment and Task objects get deleted from the RavenDB database. These settings are useful if, for example, you have a CI server that is using Octo.exe to create releases every build. If such a release is never deployed within a week, you'll probably want to delete it. On the other hand, you might want to keep releases that have been deployed to an environment much longer.
The third setting affects Tentacles, and controls when the extracted packages are deleted. If you're not already aware, Tentacle places packages into different folders based on the version number - for example:
C:\Apps\Production\MyApp\1.0.0
C:\Apps\Production\MyApp\1.0.1
C:\Apps\Production\MyApp\1.0.2
C:\Apps\Production\MyApp\1.0.2_1 // This was a retry
C:\Apps\Production\MyApp\1.0.3
If this setting were to be set to keep 3 deployments, then the folders 1.0.0 and 1.0.1 would be deleted when 1.0.3 was deployed. Note that this third setting is specified using # of deployments rather than # of days, to avoid having timers/scheduled jobs running on every Tentacle just for cleanup.
NuGet packages (on the Octopus and Tentacle) are also going to get cleaned up, but this will be an automatic feature that runs every 12 hours and cleans up packages more than three days old, so I don't expect it to be configurable. That's because the NuGet packages can always be re-downloaded from the NuGet server.
Feedback requested
I want to make sure this feature is powerful and useful, but I also want to keep it as simple as possible. How does the mock-up above look to you? Are project groups the right level at which to define retention policies? I'd appreciate your comments in the box below!
