We keep both projects in the same repository. We have Azure DevOps configured to do builds based on where the change was in the repositories.
Here's an example of a build pipeline definition for just the DancingGoatCore app:
trigger:
batch: true
branches:
include:
- master
paths:
include:
- 'src/DancingGoatCore/*'
pool:
name: Hosted Windows 2019 with VS2019
steps:
- template: build-pipeline-release-steps.yml
parameters:
projectName: 'DancingGoatCore'
configuration: '$(build.configuration)'
Where build-pipeline-release-steps.yml are the steps shared between projects (if any), or just replace the steps here with all the steps you want.
We would have an additional build definition .yml file for our Content Management (CMS) project.
Since both build definitions only look for changes in specific paths of the repository, completed pull requests will only trigger builds for a project when changes were made to that project. (You can also configure this for CI builds that are run with each push to the PR'd branch - this works the same way and can be configured to only run the specific CI build for each project when changes to that project were made).
This allows for easier sharing of code between the projects and also verifying that the entire solution builds.
Having a solution build is very important when sharing code. These two apps are tied together at the database, and generated custom Page Type classes or Custom Module classes are the code representation of that connection. 1 solution ensures consistent deployments of each application.