We use Azure DevOps for build and releasing our on-premise installation of Dynamics 365 Business Central.
We maintain a 3-4 different repositories each making up part of the installation. We have a main repository (Base App) with approx. 8000 source files. These are not changed very often, but are the foundation on which the other apps are build.
When we build our base app, our main artifact is an sql application database backup. This backup contains what we need to create a new deployment. The backup contains our base application code and the published sub applications, we have downloaded as build artifacts.
Technically this works just fine. With one major exception, we lose track of the deployment states of the work items of the triggering builds. And as the majority of the work items are related to our sub apps, then this is a problem.
To solve this problem I have looked into different options.
Everything in one repository The first and obvious was to put everything into one large repository (example 2). Technically I'm sure that would work just fine as well. But this would increase the number of files (the base app has about 8000 objects) and the build time of each app with the time of the base app. Each sub app build would go from 5-10 minutes to 25-30 minutes or more, which would not really be great.
Sub and master builds Ideally we would like to have the setup in example 3. Here we have a further build. By splitting the base app build into two, where the first creates our sql backup artifact without the apps and the master build publishes the apps into the database. This would cut down our sub app build/release time with approx. 15 minutes.
But again the problem is we lose track of all the work item references as they are not transferred from the triggering build to the master build.
The last option I can think of is to release the result of repository build directly to the development stage (example 4). This would mean that we would have the start by publishing all the different apps to the database for each deployment stage (besides development we also have test, uat, staging and production stages). I tested doing this by having a "pre-development" stage, which would publish the apps and create a backup used by the following stages. That would also work, but I would not be able to use Azure Pipeline or Build Artifacts, as these can only be used by build pipelines, not by release pipelines. So if we were to do it this way, I would need to publish to a network file-share instead.
Our builds are Yaml based, while we use "classic" release pipelines for deployments. I have not looked into using multi-stage pipelines yet, as I don't find it fully ready for production, especially because their approval/gating options still are quite limited.
I know it is a long question with a lot of details (but maybe not enough?) and individual questions, but
I hope that someone here have experiences or insights in the area they would like to share. What are in your opinion the pros and cons of the different options.
Or is there a way to make the work item references go through other build to the release, even if they are only from a triggering builds?
