In trying to organize our Azure Devops we are trying to decide if we should use multiple projects, organizations, or not. The challenge is that we're housing multiple client projects each with its own solution. The options are to make multiple orgs (one for each client) or multiple projects under our own org. It seems per this https://docs.microsoft.com/en-us/azure/devops/organizations/projects/about-projects?view=azure-devops post MSFT recommends the least number of projects possible. We have about the same 10ppl jumping between the projects but there are cases where only a subset would have access, though that's less of a concern than proper use/organization of the repos in a multi-customer setting.
2
votes
Use a single organization, with a single team project. Use teams to organize your various clients, and security groups to limit access to repositories.
– Daniel Mann
Thanks for the reply @DanielMann sorry for my late answer. My issue is that pipelines and all that is based on the project level. So wouldn't my build list get insanely cluttered if there are 10+ different projects being built going to different Azure servers?
– amd3
Builds can be organized into folders
– Daniel Mann
1 Answers
2
votes
I had a call with someone from Microsoft Dev Ops, did a screen share and showed them the structure. She said that the way we have it currently split out works better and is the recommended method. I feel this goes against the published guide listed above and explained that. But given our natural tendency to have it setup this way coupled with MSFT's response I think this will work for our needs. So, for most of the projects where we will maintain the code for the long term, we will put it under our org, but continue to make different projects so we can have our own build processes, teams, boards etc. This was backed up by a MSFT MVP that I know as well, so hopefully this will help someone else thinking of how to structure their Azure Devops.
