In our last Best Practices post (which you can read here) we talked a little about cleanup policies. The operative word there is “little” – there’s a lot more to say.
This one may be obvious, but a best practice is to store build artifacts and binaries inside Nexus Repository. Development is messy, relentless, and complicated. Having a central place to store build artifacts is a major step towards DevSecOps. There are lots of repositories you can use for this purpose…but we’re biased, so we say Nexus Repository is best.
Another best practice is to store your SBOMs inside Nexus Repository, also. In fact, it’s generally wise to treat your SBOMs like build artifacts. Why? SBOMs are a point-in-time accounting of your app’s contents, in much the same way a manifest or lock file is a point-in-time declaration. They’re a build artifact in all but name.
But doing these things make controlling your blob storage even trickier. Build artifacts are naturally bulky. And though SBOMs are more lightweight, they’ll pile up fast, especially if you’re generating SBOMs with every build (and you should be).
So how do you use cleanup policies to address this? There’s no simple, one-sentence answer here, but we can offer some advice.
- Snapshots pile up fast, and you typically only need n-1 or n-2 versions. Find the build cadence of your snapshots and set the cleanup policy for slightly longer than that.
- SBOMs for snapshots, development, or test builds are low-importance. Again, set the cleanup policy for slightly longer than the build cadence.
- Release candidates are different. You need the ability to rollback to n-2, n-3 or farther. Find the build cadence of your release candidates, quadruple it, and set the cleanup policy for slightly longer than that. Don’t try to fine-tune that cleanup policy until you’re confident you can rollback.
- SBOMs for release candidates are important. Again, they’re a point-in-time accounting of your app’s contents. Default to keeping release candidate SBOMs for a long time. Consider moving them to cold storage rather than deleting them.
And, though it goes without saying, the last best practice is to adhere to regulatory requirements, common sense, and your company’s guidelines when it comes to keeping SBOMs and release candidates.
Next time, we’ll talk about how to combine staging with cleanup policies and put a bow on this whole process with the blobstore.compact task.