Recently I was helping an enterprise where they have large number of repositories in Azure DevOps projects and wanted to have a folder hierarchies to ease the navigation. Azure pipelines have folder structures but there is no feature at this point to organize repositories into folders. There is a open feature request about it already.
I have written an extension that allows “Project Administrators” to create and organize folders and assign repositories into these folders. Other users can use the folder structure for navigations but they can’t create/delete folders or assign repositories into them.
Here’s a quick look into the extension in action.
How to use it
I haven’t published this extension publicly as I built it for a very specific scenario. However, I have the source code for the extension in GitHub.
Build & Publish
Microsoft has great documentation how to create extensions. This repository took the Microsoft sample and modified it. You can build it like following:
npm build
Once the build is completed successfully, you can publish it as extension and deploy it to your organization.
npm package-extension
License
The code is provided as-is. You can modify/change anyway you want. The author doesn’t take any responsibility to provide any kind of support. However, If you get benefit of this, an acknowledgement would be highly appreciated.
Reverse Engineering 
Nice one Moim and thanks for sharing the code
LikeLike
Thank you!
LikeLike
This looks great, Moim! I had a quick look at the source, albeit I’m not very familiar with React and TypeScript. From what I can see, it looks like you’re using one document to describe the folder structure, and another document to track the links between repositories and folders.
– Do the repository names still have to be unique?
– What happens if two users attempt to modify these documents at the same time?
I’d very much like to apply this to Environments as well, because for each of our repositories we end up with ‘RepositoryX-Test’, ‘RepositoryX-UAT’ and ‘RepositoryX-Prod’ environments. Three environments for every one repo.
LikeLike
Andrew:
– Repository names don’t have to unique, as the extension deals with the repo ids for mapping and storing.
– First one wins, second one fails. The ETag of the document will mismatch for the second user and they need to refresh/start over to make changes.
LikeLike