Azure DevOps - organizing projects and repositories

Question

---

(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')

---

Hello,

I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.

Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.

As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).

I am a bit puzzled about the 'Project' part. Documentation says

In general, we recommend that you use a single project to support your organization or enterprise.

So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?

As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).

This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.

I need to be able to:

• easily navigate/see all the tens/(hundreds?) of applications that we create,
• view their separate kanban boards (for those project that do have it, not all of them will)
• to see their repositories (Git or TFS), commits etc
• see & manage their pipelines

At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:

And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:

1. Is that the intended way to organize the structure?
2. Any alternative approaches?
3. Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
4. What about creating documentation for each 'product'?

Answer 1

The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.

With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.

• Create team for the real teams you have in your organisation.
• Create an area path for each major project/product in the org.
• Assign the area paths of the projects to the teams who are working on them. This can change over time.
• Optionally tag work items with the major project/product for additional filtering.

This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.

Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.

The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.

You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.

The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.

Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.

As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.