Business Central v17: what does the new release method mean for you?

Business Central 17 release

Business Central v17: what does the new release method mean for you?

The update to Business Central v17 is closing in. As you could read in our previous blog, updating to the newest technology is important to stay in business. In the last months, a growing share of our customers already work with version 16 or 17. However, chances are you are still working with v13. To get straight to the point: the transition from version 13 to the newest version of Business Central is quite a big step. The most notable difference between the two, is the change from the Windows Client to the Modern Client. But that is only one of the visible changes. Under the hood, a great number of technical changes can be found. Understandably, this raises all kinds of questions: what changes for you as a customer when development takes place? Or, in what way will technical changes be released in your environment. In this blog, I’ll dive into the consequences of the new methodology of releasing new functionalities.

In the rest of the blog, the term ‘release’ will be used. This is an update or expansion of your software. In other words, a technical change to improve functionalities.

The situation up to and including Business Central version 13

Let’s start with the current (or old) situation. Schematically, the way of releasing in this situation looks like the image below. Step 1 describes how one of our developers makes an adjustment in the code of your solution, and how he applies this directly into your database. In practice, the alteration is first tested in the RAPP environment. When approved, it is added to the PROD. The complete process that concerns your specific product development takes place in the blue field.

However, it doesn’t stop there. Steps 2 and 3, in the orange fields, describe how the code is further processed by Boltrics. First, the alterations in the code from your database and the database of other customers, are combined into the Development Database (2). The combined code is then released to other environments. For example, with an update or new installation. In this way, you take advantage of the branch standard.

The characteristic of this way of working, is that an alteration in your environment can be done quickly. There aren’t any extra steps needed. A good thing, of course, but this also means there is little control in the process. Therefore, small mistakes can easily be made. In the new situation, this changes.

The new situation

The image of the new situation is more complex and represents a lot more steps. There are two main differences compared to the old situation:

  1. The code isn’t kept in a Business Central Database. Instead, the code is stored in a code repository (a kind of library).
  2. It is not possible to alter code directly in a database. Instead, apps are released (updated), of which 3PL Dynamics is the most important one.

‘What does this mean’, you ask yourself? As you can see in the image below, after development (1a), new functionalities are added to the code repository (2). This code is then built into an app (3). Finally, the app is released (4). With the help of a shortcut, you can still test new functionalities directly in the RAPP (1b). Using this shortcut is quicker, but also less secure. Therefore, this way of working is only used in the RAPP environment to test the new functionalities.

The code repository contains multiple varieties of our code. This makes it possible to distinguish the specific version you use, and you have tested with, and the version other customers work with. De functionalities that have been developed for you are also added to the code varieties of other versions (2). These are then compiled (5) and eventually released to other customers (6). So, when updating, you will still have the ability to use functionalities that were originally developed for other customers. In other words, we still provide you with the branch standard.

What does this mean for you?

The new way of working is much more modern and structured. It offers Boltrics the possibility to improve the quality of releases in the future. In different ways, error sensibility is drastically reduced in the new situation, thanks to the extra structure. Furthermore, it is possible to release identical apps to different environments. This is an advantage when you work with different sites, all with their own Business Central Database. In this way you can make sure they all have the same functionalities.

Release process

Another consequence of the new structure is that releasing a PROD environment will take more time, because there are more steps in the process. Furthermore, it is no longer possible to alter a single code object without influencing the rest of the organization. For all technical changes, a complete app must be released. The impact of this is small, but noticeable: for example, you will have to restart all sessions. That is the reason why, preferably, the release takes place on a calm moment. Though the process to release takes longer, you are, however, ensured of a secure and safe environment with reduced chance of error.

Technical possibilities

The technical differences with previous versions, are a stimulus to rather implement some bigger changes, instead of many small adjustments. Small adjustments take longer because of the lead time of the process to release. On the other hand, the process now has a stronger foundation for when you wish to implement big changes. Besides, product development is in general simpler, and therefore faster. Especially for bigger changes, thanks to the modern development tools we now have available.

More information about releasing

Are you interested in the technical side of our branch standard? And do you want to learn more about the software releases behind the scenes? Do not hesitate to ask and mail to marketing@boltrics.nl.

Posted by
Wildrik Oosterhof