So a consequence of wanting to purge images from your container registry is sometimes you need to keep some of them.
One example is that in regulated industries you must be able to produce software that was deployed to production for audit/legal purposes, so if you are purging images that are over 3 months old you might have an issue.
You can update an image so that it can’t be overridden or deleted via the az acr repository update command e.
One housekeeping task if you are producing docker images is clearing your container registry of old images.
I’ve been particularly bad at this and had also made some mistakes such as publishing PR images and images produced via our auto-patching runs, leading to the ACR size being >1.2Tb (ouch!).
There are some features introduced by acr auto purge, but I found an issue since my images typically have three tags…
Just pushed a new version of WikiExport with a couple of useful features
Change titleFormat to have explicit {project}/{title} macros Support for .attachments in non-root folder - provided by @ricfre The first is just a simplification since it’s more intentional to use named values rather than {0} etc, and we can also automatically determine projectInTitle from the titleFormat.
The second one allows support for code wikis and the image path not being in the root of the repository e.
One perennial issue when developing software is how to keep documentation up to date. For detailed documentation such as APIs this has become a lot easier in recent years with capabilities such as Swashbuckle being able to pick up annotations directly from the code.
The principal of keeping your documentation as close to the code as possible means that development teams are more likely to keep it up to date and relevant to the actual behaviour - presuming you are have a good definition of done and are performing code reviews 😉.
Microsoft has published the results of some empirical studies about how development practices affect quality
Test Driven Development improves quality by 60 to 90 percent but takes 15 to 35 percent more ‘up front’ time. The time spent is compensated by savings in maintenance time later on. Team & organization structure has a huge impact on quality. Although this is conventional wisdom the study publishes figures to prove this. The metrics used data such as how many engineers are involved in a project, how many times individual source files were modified.
