I came across the MSDeployAllTheThings extension from the Azure DevOps Marketplace. Is this used in the Azure Release pipeline, or in the Azure Build pipeline?
- you can see in its description of what usages it has, usually extension meant for help in the cicd will be available for all.
- you should probably not install ANY extensions outside the default ones that come bundled.
- There are exceptions but overall just dont use 3rd party ones.
- Anything they can do you can as well with some powershell and thus limiting your dependency on the creator or the potential risk of using 3rd party tools that literlay act as admin on your code and processes. especially not in any gov environments.
- I would even say you should disable MS ones, create your own and you support and publish privately and then install it in your orgs. That way you know EXACTLY what is in them *obviously not for everyone and requires quite some programmatic background"
Instead of following that advice, you could enable RenovateBot for Azure Pipelines, have it set the exact versions of tasks in your YAML pipelines and disable classis Release and UI-based pipelines.
You do need to review the extensions on the marketplace carefully, many of them are in disarray after 2 years of wavering support of Azure DevOps. Now that Microsoft is picking up the pieces again, hopefully more extensions will stay current on dependencies and adopt tools like GitHub Advanced Security and Dependabot.
I kinda wrote half a book about that 
https://jessehouwing.net/security-state-of-the-azure-devops-marketplace/.
But publishing custom extensions for EVERYTHING means taking on a huge maintenance burden. Yet I agree, using reusable templates and small bash/powershell snippets can achieve pretty much everything you need.
Lol , that one got you triggered ? 
Its ok if you just follow the first 4 as those are best practices in todays ecosystem.
the 5th one is for the more secure-paranoid, and it makes things more secure for the most FedRamp but obviously not the casual user.
In each task that proper, you should be able to see their code in their repo (requires some knowledge in typescript/javascript( but you can find an alternative way).
You can also republish extensions under your own publisher, it’s pretty easy to do. That way you’re in full control when you upgrade anything and have an opportunity to review. Just republish under a PRIVATE extension.
I think it’s good advise on some cases but definitely not for everyone
Iirc is talking about his own personal site or something here and if he wants to use some random extension from somewhere, eh go for it :shrug:
Id say its not much about what versions you have, its more about not using 3rd party ones if you dont REALLY need to. I have some that i use myself but i went over their code to make sure it doesnt have any things i dont like.
As you mentioned you can always republish an extension privately to save coding time but then i am the responsible for supporting it
In this case I’m considering my own Azure DevOps, not work. I want to deploy to a new web hosting provider a website.
This script downloads extensions from the marketplace. It would be quite doable to create a pipeline that you feed an extension publisher and Id, that would grab it and republishes it under your own private publisher from here.
I do like Dependabot in GitHub.
I’ve considered building a tool or a website that allows you to pick any built-in task or any public extension and repulishes it under your own private publisher or gives you a vsix to upload.
Dependabot is great, but won’t tell you when to upgrade your azure pipelines’ tasks. Renovatebot will. I know, as I wrote the code for it .
makes a good point about paying attention to 3rd party extensions. We use a number of them and they work out well enough I suppose and we let them auto update. We are dealing with one now that hasn’t seen an update in years that apparently some project managers have come to depend on for sprint planning. Its just not working like it used to. Sure we could clone/fork it and maybe improve it but then that puts my team in the business of supporting it which isn’t our goal.
I’ve shared your blog post internally about the state of the marketplace, its a great post.
Thanks. I haven’t run a new scan recently. I might in the summer. But it doesn’t look like much has changed in the meantime.
Many of the extensions in the marketplace were once a community extension, but the community around it fell away. Some are now commercially maintained by a 3rd party.
But most of these things have been maintained by people wanting to support their organization in the same way. It’s how I inherited the TFS team tools, TFS aggregator and the Azure DevOps extension tools.
All of my other extensions were a stop-gap solution for a client that needed to migrate from A to B that had a weird need.
