advanced-lifecycle-management-impact-buildnumber-upgrade
Version 2.2 by Erik Bakker on 2022/06/13 09:53
Impact of builnumber upgrades
In this microlearning, we will focus on the helping you to assess the impact of upgrading to new buildnumbers.Should you have any questions, please get in touch with academy@emagiz.com.- Last update: August 27th, 2021
- Required reading time: 5 minutes
1. Prerequisites
- Advanced knowledge of the eMagiz platform
- Complete the microlearning that explains how to upgrade to a new buildnumber
2. Key concepts
With buildnumbers we mean the piece of software that used by a flow to make it operational inside the runtime. Several eMagiz libraries are loaded together with the flow components XML into the runtime (Java container). In essence that means that a new buildnumber means the flow is technically speaking different from the previous buildnumber.eMagiz works hard to limit the number of buildnumbers. The general approach for buildnumber is that these are backwards compatible, so the impact of moving to the next buildnumber poses a minimal impact and risk.3. Assessing the impact of changing buildnumbers
3.1 Release notes & impact assessment
These can be found in the eMagiz Portal under Community- After installing any build 50 (or higher) flow, build 48 (or lower) flows containing a Jetty server on the same runtime cannot be started anymore. If it is really necessary to still install/start a build 48 (or lower) Jetty server flow: uninstall all build 50 (or higher) flows on that runtime first, then install/start the build 48 (or lower) Jetty server flow, and finally re-install the build 50 (or higher) flows.
- When deploying a flow containing a Jetty server, the infra flow of that runtime must have a matching build number, that is: if the the Jetty server flow is build 48 (or lower) the infra needs to be build 48 (or lower) as well, if the Jetty server flow is build 50 (or higher) the infra needs to be 50 (or higher) as well.
3.2 Upgrade
Use the designed options in eMagiz to upgrade the flows to the new buildnumber. See the relevant microlearnings for that.3.3 Functional changes
Before an environment is updates to the flows with the latest releases, it is advices to first check which flows have functional changes. These flows need to be tested and put into production first so that you can isolate issues in case they occur. Once these flows are tested and live, only then move the flows witht the new buildnumbers from test to production.3.4 Approach
It is usually best to update the test and acceptance environment first and leave that running for a certain grace period. So that in case potential issues can be fixed still.4. Assignment
Take a look at the release notes in the eMagiz Portal to ensure you know where to look.5. Key takeaways
- Keep as close to the latest buildnumber as possible for the entire environment
- The best option is to have the entire environment run on the same buildnumber
- A mix of buildnumbers in a runtime is not a good plan - conflicting behaviors may occur.
- Read the release notes for builnumbers carefully to assess the impact - in case the impact is minimal proceed with the upgrade
- Make the buildnumber upgrades planable so the release schedule takes these actions into account.