Build Retention Policies have always been a contentious thing to talk about: at some point, you need to let go of your old builds. This post is not about after how long, but to talk about a couple of things to consider which might not be immediate.
Retention policies are applied at project level:
You have three settings to think about: how long you want to keep your artifacts and attachments, your runs and your pull request runs. A run is the actual build run, and it overrides both the other settings:
You can keep a run for up to two years, but artifacts and attachments will be gone after two months and PR runs after one. This is the topmost setting you can have, and it makes sense at the end of the day: you don’t want to clog your organisation with stuff that is effectively not useful in the longer run. If you want to store your artifacts for more than two months you should publish your artifacts in a proper way (Azure Packages springs to mind…) rather than relying on the build run.
Then the elephant in the room: how should I version my build runs?
Long story short, you should have a way of easily identify your builds. It can be GitVersion, it can be Semantic Versioning, it can be something else…but don’t leave them to the standard naming convention as it won’t make your life any easier.
Do not rely on the $(Rev:r) counter - you need to be in control of your builds, and be able to come back to a certain build if needed. Using $(Rev:r) isn’t a feasible solution in the long run and also, bugs might hit. I was affected by this one, and there was no way back.