Release management Business Central Team

With the release of the new Business Central version in AL and the associated changes, the solution maintenance landscape for the STAEDEAN Business Central team has changed, We will still maintain our solutions in DevOps, but we will store our code in GIT-repositories, we are maintaining multiple smaller apps as a replacement of the BIS monolith and we will introduce release pipelines in DevOps that will support our transition to monthly releases as per the CI-CD requirements. This document is / will be valid for the on-premises as well as the online versions of our solutions. Over time, the code-bases for the two platforms will become identical (if not already realized), but the structure described here will not change.

App-structure

We have created a new structure where not only the BIS monolith has been broken up into multiple apps, but where we have also broken up the fixed structure in our verticals. Depending on the selection of the functional solution, will additional apps be installed or not (see pictures 1, 2, 3 and 4).

At the base of everything, there is the STAEDEAN-Common app. In a regular app-environment this means that STAEDEAN-Common is the first app to be placed on top of the Base BC app. In the Mega-app or Embed-app environment, it means that STAEDEAN-Common is the first app and the embed-app is installed second. The STAEDEAN-Common app supports other apps with shared components such as time&date, RecRef Metadata handling and, over time, this app will also contain license-controls and other shared functionality. This app will not be visible in the Extension list in Business Central and will be considered a depend-app.

The second layer is our BIS app. This app has changed in such a way that it now only contains the business logic that is used by the former BIS-solutions Replication Management, Connectivity Studio, Notification Management and EDI-Studio. However, the BIS-app also contains the framework for Labelprinting and BC Anywhere. The BIS app will also not show up in the Extension list in BC and is also a depend-app.

At the same level as the BIS app, there is the TI-Lifecycle Base app. This app will only be used in combination with the FOOD-, PE or IEM vertical. It is a shared components app for lifecycle functionality that is present in the verticals (Lifecycle Management is discontinued as a stand-alone solution). As with STAEDEAN-Common and BIS, this depend-app will not show up in the extension list.

The former BIS-solutions are now all separate apps. As an example, if a customer requires CS, he will install the CS app and not be bothered with NM, EDI and RM. Likewise, if a customer requires IEM, he will no longer have to install BIS. STAEDEAN-Common and TI-Lifecycle Management Base is sufficient to install IEM. For the FOOD-solution, BIS is currently still required for Labelprinting and the BC Anywhere for Food suite. The app-landscape will therefore be composed of multiple apps in multiple configurations, where the rules are:

  • STAEDEAN-Common mandatory in all cases where STAEDEAN-apps are installed
  • STAEDEAN-BIS is a pre-requisite for ANY, CS, RM, NM, EDI and Labelprinting
  • STAEDEAN-Lifecycle Management base is a pre-requisite for IEM-, PE- or Food-Lifecycle Mgt.
  • If Anywhere is added to Embed-apps like IEM or Food, STAEDEAN-BIS is a prerequisite.

Examples of app-landscapes using one or more solution-apps:

Picture 1

Examples of app-landscape using the IEM apps:

Picture 2

Release cadence

STAEDEAN will release monthly updates of the Business Central solutions. The goal will be to release an update of all STAEDEAN-solutions in the first week of the month following on the month of the Microsoft update and when required. In other words an update will only be created when there are new features or fixes. This means that there will be no more hotfix-updates, the bug-fixes that are released will be released together with the monthly update. We estimate that we will need around 5 working days to integrate a new version from Microsoft in our builds, which means that at the earliest we will release our solutions on the new CU 5 days after Microsoft. If, for some reason, Microsoft does not release a Monthly Update, we will still deliver an update. This update will then contain bugfixes and new features only.

Another major shift is that new functionality will be delivered with each update. However small the new feature or part of the new feature is, it will be released monthly and the documentation will be updated at the same time.

The release-notes that accompany a new release will be different from the Hotfix-report or the release-notes as we know them know. The new information will contain two parts, a part with the bugs that are fixed in this version (Internal number, title and description) and a brief description of the new functionality with a reference to the new online help. The release-notes will not be sent by e-mail, but can be downloaded from our online help website and the link will be communicated. This implies also that we will no longer offer a code-compare for the fixes that have been made. Because all customers will be using extensions (either depend-apps, solution apps or embed-apps), there will be no more modification of base code for customer specific functionality. This means that there will also be no more merging of customer specific code, which in term means that even the on-premises customer can be updated monthly.

Bugfix delivery

With the changeover to the modern support lifecycle announced by Microsoft starting with 2019 Wave 2 (V15) we will change our policy for that version as well. All previous versions (14 and earlier) will be supported as they are now.

When a bug is reported, we will change the way in which we deliver the fix, as well as in which version(s) we will deliver it. On the Online platform, Microsoft will maintain a maximum of 4 versions. When a bug is reported in any of the 4 supported versions currently available online, or in an earlier version used by a customer on-premises, we will deliver a fix in the next update for the current major function. Only in transition periods where two major versions are available online, will we deliver fixes in two versions. The follow example clarifies the situation:

Situation 1:
Versions available on Online Platform: 16.1 – 16.2 – 16.3
Bug found in Version 15 or Version 16 and not solved in 16.3
--> Bug-fix delivered in version 16.4 only

Situation 2:
Versions available on Online Platform: 15.3 – 16.1 – 16.2
Bug found in Version 15 or Version 16 and not solved in 16.2
--> Bug-fix delivered in version 16.3 AND in 15.3

This implies that the last version that was available on the online platform is also the last version in which we deliver bug-fixes, It becomes our current “Final Freeze cumulative update”. Bug-fixes will therefore no longer be automatically delivered in the version the customer reports them on.

This delivery mechanism is valid for online as well as on-premises. Due to the fact that everything is contained in apps now, we expect the partner to regularly update the customers on-premises version as well (see also https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/terms/lifecycle-policy-on-premises for explanation on the modern support lifecycle by Microsoft).

The only exception where we will deliver a fix in a non-current version available on the online platform is if there is a priority one issue at the customer or if there is a necessity due to security- or legal concerns. If that is the case, updates will be delivered on request only, the partner should contact us with such a request.