Retention strategy
Design and implement a retention strategy
Retention balances four pressures: cost, compliance, traceability, and the ability to roll back.
What retention governs
| Asset | Consideration |
|---|---|
| Run records and logs | Audit trail — who deployed what, when |
| Test results | Trend analysis and flaky-test detection |
| Pipeline artifacts | Rollback capability and storage cost |
| Package feed versions | Reproducible builds of older releases |
The rollback constraint
The binding rule: retain artifacts at least as long as you might need to roll back to them. A retention policy that deletes the previous release's artifact while it is still the rollback target converts a two-minute redeploy into a rebuild from source — assuming the source still builds identically, which is exactly what you cannot assume in an incident.
Runs to keep
Policies commonly retain runs that are still meaningful — the latest run per branch, and runs that produced a currently deployed release. Deleting the run that produced production removes the audit link between what is running and how it was built.
Feeds
Package feed retention is a separate policy from pipeline retention. Deleting old package versions breaks reproducible builds of older releases, so the retention window there should reflect how far back you might need to rebuild — often longer than for artifacts.
Primary sources