1. Upgrade

Blueriq is a platform that’s in a constant state of development. A new version of the Blueriq platform contains new features and techniques that allows to add higher value for you or your customers.

1.1. Functional improvements

Every new version of Blueriq contains new functionalities and bug fixes. With these functionalities you be able to deliver more value to your customers.

 The Blueriq platform uses third party software. Those third parties are upgrading their products also with new functionality. New versions of the Blueriq platform will contain new versions of third party software to enrich the product with new functionality from the third party software.

1.2. Platform support

The Blueriq modelling platform is dependent on third party software. This kind of software is required to be able to work with Blueriq. This can be an operating system, database or an application server. New versions of the Blueriq Platform contains new versions of the third party software.

A vendor of third party software may choose to stop support of (a specific version) the third party library.  The rough and ready rule is that Blueriq will stop supporting a version in the first minor release after a third party vendor stopped support for their software. Blueriq always aims to support the latest and “latest-1” version of the third party software in the Blueriq platform.

Blueriq will test a new version of the Blueriq platform with all supported versions of the third party software.

An overview of the current, future and past supported third party software is available on: https://my.blueriq.com/display/DOC/Platform+support

1.3. Common vulnerabilities and Exposures (CVE)

A third party library can contain Common Vulnerabilities and Exposures (CVE). Those vulnerabilities are being published by an American government agency when a solution is available. Blueriq actively monitors the latest supported Blueriq versions to see if there are any reported CVE’s in the third party software used by Blueriq. 

Whenever a CVE is found, Blueriq strives to fix the CVE in the upcoming planned release. If no release is planned, Blueriq will plan a release to make the fix available.

The list with CVE’s that affect Blueriq can be found here: https://my.blueriq.com/display/DOC/Blueriq+Runtime+Vulnerabilities

2. 2. The Building blocks for a successful upgrade strategy

2.1. Blueriq Platform

Blueriq is always aiming for our software to be the highest quality. You can not only build with us, you can build on us as well. You don’t have to test the Blueriq components yourself. You only have to test your models and the components you created yourself in or for the Blueriq platform, as well as the custom components you may have built.

2.2. CI / CD

Blueriq advises a Continuous Integration / Continuous Delivery approach. The best fit for a CI/CD is depending on your own situation. A continuous delivery maturity model can help you by finding the best fit for your situation.

The more automatic tests you have in place to test your software, the less manual tests you have to perform. Also when upgrading, automatic tests can speed up the upgrade process.

2.3. Limit the amount of custom code

Limiting the amount of custom code helps you while upgrading. The less custom code you have, the easier you can perform an upgrade. When you are certain that custom code is needed, we advise to separate the code from the Blueriq application as much as possible.

2.4. Isolating the upgrade

Blueriq advises to separate a functional upgrade from a technical (product) upgrade. Combining these upgrades will make your testing more complex. Also debugging and creating a solution when you find an issue will be more complex if you combine both upgrades.

Before you do a technical upgrade, make sure all deprecations are removed in your application. After you removed your deprecations and tested the new functionality, you can start doing the technical upgrade.

As the Blueriq platform uses third party software, we advise to upgrade this software first if these are not packaged with Blueriq. For example a Database or a higher Java version. This is regular platform support that should be updated regularly, independent of Blueriq upgrades. This helps you keeping Blueriq updates small and will help you finding potential issues in an earlier stage. 

2.5. Repetitive approach

It is advised to create an update strategy and document this strategy. For every upgrade you have to perform you can use this uniform way of work and do your upgrades repetitive. Make sure your update strategy contains a Back-up and rollback plan in case you might need it. 

3. Upgrade strategy

3.1. Intake

The first step of an upgrade is the intake step. In the intake step you determine if you want to upgrade to the latest version (minor or major) of the Blueriq platform. The release notes can help you make an estimate of the effort the update will cost. In the release notes you can also find the benefits each version brings. Although we want to encourage you to stay up to date, it is possible that sometimes the effort is higher than the gains. In that case you can choose to postpone the upgrade.

We advise to always migrate to the latest minor version of a major, before migrating to the major itself. On the latest minor you can remove al deprecations that will be deleted in the new major.

Before upgrading to a new major version, make sure you have a license that is valid for this version. If you are in doubt you can always contact support@blueriq.com. 

3.2. Upgrade

When there’s an impactful change, you might want to choose to do the upgrade on a parallel environment. This way you make sure the current stack of your products isn’t changed. If you want to do the upgrade on a new server, make sure you have a valid license that includes the correct hostname and domain name.

3.3. Visual recap