The web.config transform appears at first glance to be somewhat orphaned in Azure DevOps. If you are deploying to a WebApp then the pipeline wizard will probably have given you this snippet for your Build step:
To run config transforms you can add the additional parameter /p:TransformConfigFile=true to your msbuildArgs.
The replacement, of course, is the independent FileTransform task (which can also work within zip files). But once your site is packaged the Web.Release.Config is left behind; so you have to run the FileTransform task before, not after, the build step. (Similarly the WebAppDeployment task can’t transform a Web.Release.config that isn’t inside the package).
Slightly magically, the default parameter for the FileTransform is exactly what you typically want for web.Release.config transforms:
FileTransform can also do variable substitution, and you can have multiple FileTransform steps in your pipeline. I also like to see some diagnostic feedback so I include script step to show the xml transform result. But I put it before variable substitution, because the variables often include secrets:
I recently stumbled into a slightly different take on the question of should a function say what it does or what it intends?
When a function implements business process Alpha that today consists of steps A and B (but tomorrow may change) should you call the function DoBusinessProcessAlpha or call it DoStepsAandB?
One answer would be, if the function is in a public package which exposes business functionality then the name should probably show that it does BusinessProcessAlpha. But if it is a private, not exposed, function then the reader is probably looking for the detail, that it does StepsAandB.
The question is more awkward if Steps A and B are themselves business process functions. That is, if you asked your customer, they would understand what steps A and B mean.
I suppose in that case you could always call it DoAlphaAsStepsAandB().