In Azure DevOps Server 2022.1 I recently changed the default settings of the retention policies for releases and also adapted the configuration of some of the stages within the release pipelines.
In essence, the situation is as such:
| Stage | Days to retain a release | Minimum releases to keep |
|---|---|---|
| Stage 1 | 1 | 3 |
| Stage 2 | 10 | 5 |
| Stage 3 | 730 | 10 |
These stages run after one another; as you might expect: Stage 1 -> Stage 2 -> Stage 3. A stage will only run if the stage before it completes, save for Stage 1.
Stage 3 has a pre-deployment condition, namely a manual approval needs to be given. Not every release gets the approval and, therefore, Stage 3 is not executed every single time. I would expect those releases to be gone after 10 to 11 days (including the time it takes the server to process the retention policies, which should be once a day) have past.
However, this is not always true in my scenario. Some releases have been around for well over a hundred days. Neither are they retained by the Minimum releases to keep policy nor are there any manual leases attached to them.
As far as I know, the options mentioned above (Days to retain a release and Minimum releases to keep in the team project settings and within individual stages) should be the only ones that govern the behavior of release retention (apart from manual retention, which I did not use or find anywhere in my example).
The more I read into this topic, the more I believe that this is a bug, but maybe/hopefully I am missing something. So...
Are there any other factors that can decide whether a release is kept or not?
Are there any other factors that can decide whether a release is kept or not?
The policy changes of project level settings will take affect only for the new release pipeline and stages created after saving. And you have pre-deployment condition on stage3, if the stage is not executed, the policy on this stage is not considered.
Please follow below release retention policy logic for a check:
Release retention settings project level:
maximum retention policy - maximum retention values which a release definition can choose to set
default retention policy - retention values which will be picked when a new release definition is created. These values can be changed by release definition.
Release definition's stage level retention settings:
Days to retain a release - number of days a release will be kept if a deploment is done on this stage
Minimum releases to keep - minimum number of releases which will be kept even if a release is out of retention period. (This is done so that we do not lose the history of a stage)
Deployment Condition to consider release for retention logic:
We only check if the deployment was started or not.
If deployment was started, we will retain it as part of minimum releases to keep irrespective of its success or failure.
So, if release is pending for approval it means deployment didn't start on it but if deployment started then failed, that release will be kept.
As there can be multiple deployments for each stage, we will pick the latest deployment to consider for retention.
Retention of Release based on deployment on stage
Release not deployed to any stage or Draft release - As there is no deployment on these releases, no stage level retention is applicable on them. For these releases, we depend on project level default retention policy.
Release deployed to few stages or all stages - Final retention period is decided based on retention of all stages where release is deployed.
Example:
Consider Project level retention is
maximum retention policy = {DaysToKeep = 365, ReleasesToKeep = 25}
default retention policy = {DaysToKeep = 30, ReleasesToKeep = 3}
Consider we have a Release definition that have three stages with retention
S1{DaysToKeep = 10, ReleasesToKeep = 3}
S2{DaysToKeep = 20, ReleasesToKeep = 1}
S3{DaysToKeep = 100, ReleasesToKeep = 20}
If release is not deployed to any stage then it will be in system for 30 days as defined by default retention policy
If release is deployed to S1 only then it will be in system for 10 days. (except top 3)
If release is deployed to S2 only then it will be in system for 20 days. (except top 1)
If release is deployed to S3 only then it will be in system for 100 days. (except top 20)
If release is deployed to S1 and S3 then it will be in system for 100 days.
Release marked for retain Indefinitely
If a release is marked for retaining indefintiely, it will be in system forever till the time it is not unmarked for retaining.
Note: Retainng and unretaining both are manual steps.