Search code examples
azure-devopsdynamics-business-central

Multiple devops builds triggering each other

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.

Example 1

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.

Example 2

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.

Example 4

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.

Example 4

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?

Solution

  • According to your description the mail problem is that "we lose track of the deployment states of the work items of the triggering builds"

    If you want to associate the related work items to the release, then you have to set CI/CD for the build/release pipelines. Thus,the linked work items from the CI build will transferred to the CD release. And it can only getting work items from the latest build associated with the release.

    For example, if you have a commit/changeset which has work items lined to it, then you triggered a CI build A from this commit/changset for the first time. The work items will be linked to this CI build, and the CI build will trigger the CD release once the build complete, then the associated work items from the build will be transferred to the CD release. However, if you trigger a build (B) manually for the second time with the same commit/changeset, then the work items will not be linked to the build B.

    More information about linking work items to release, please reference this thread : Is it possible to link a work item to a release?

    If other builds triggered the CI/CD build/release (e.g Build C trigger CI build D, then CI build D trigger the CD release ), then the work items linked to build C will not be transferred to build D and the further CD release.