AzureDevOps · http · HTTPS · Identity · node · react · react-js

Folder structure for Azure DevOps repositories

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


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.

4 thoughts on “Folder structure for Azure DevOps repositories

  1. 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.


    1. 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s