How should we organize VSTS repositories?

Question

We are a small company with the following systems:

• External Web Site for pre-customers (already created in ASP.NET Framework),
• External Mobile Application for customers (in progress in Flutter),
• Internal custom CRM that work on items collected by this External Web Site and Mobile App (already created in ASP.NET Core),
• Internal DataBase and REST API Server (already created in ASP.NET Core this will NOT be changed in a long time).

So External Web Site and Mobile App talks to Internal Database by API, and then Internal CRM uses this API to retrieve data collected by those External Systems. We are moving from mono repo in Subversion to GIT in VSTS.

How should we divide projects into the repository? Should we have one repository to manage all products and then later build CI/CD configured to release few projects at once? This will be easier to run development on a single machine with API running in the background. Or should we have few repositories with Test environment to manage API and Database version? This will require setting up an additional server for Web API and Database.

I am asking from a project manager and developer perspective what will be easier and more convenient to use and manage?

Answer 1

From the perspective of build automation, I find that it is better to have multiple repositories. This allows for smaller configurations and more granular control of your build/release process. You can allow references and pull in source code to build or release (of course you can also ignore source code as well in VSTS build pipeline).

This leads to being able to release just the project you want or need to your desired environment. You can, of course, pull in artifacts from other builds and include them in your release if you need to.

To summarize, I tend to go as small as possible and only group things into the same repository if they are indeed part of the same project and no part of the project can be used elsewhere.