Skip to Content
Last modified by Erik Bakker on 2024/09/03 08:14
From version 12.1
edited by Erik Bakker
on 2024/06/24 14:05
Change comment: There is no comment for this version
To version 9.1
edited by Erik Bakker
on 2024/06/24 14:00
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -17,7 +17,7 @@
17 17  
18 18  In essence any container image consists of three layers. The first (foundational) layer comprises of a wide array of open source code heavenly rooted in the Spring and Java frameworks. The secondary layer consist of your collection of flows that should run on a container (i.e runtime). This layer is built up by the various flow designer components that are used in the flow versions in your release. The third layer is the configuration layer in the form of (application) properties, memory configuration, and other configuration elements (i.e. route, deployment location, volumes, runtime settings). Below you see a picture that illustrates this concept in an abstract form. In eMagiz, as well as in the image, you see that the three layers form one construct that facilitates the purpose of the object. For eMagiz is that the handling of data via integrations.
19 19  
20 -[[image:Main.Images.Microlearning.WebHome@advanced-lifecycle-management-impact-of-runtime-image-upgrades--runtime-layers.jpeg]]
20 +[[image:Main.Images.Microlearning.WebHome@advanced-lifecycle-management-impact-of-runtime-image-upgrades--runtime-layers.png]]
21 21  
22 22  === 3.1 Overal deployment strategy ===
23 23  
... ... @@ -26,9 +26,9 @@
26 26  === 3.2 Release notes & impact assessment ===
27 27  
28 28  Release notes for runtime images can be found [[here>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]. Please consult these at a regular basis or at the moment when unexpected behavior is observed. In the strategy of eMagiz, very frequent updates are made to the Runtime Image so that the delta in the software components are incremental. In this way, risk of unwanted side effects is minimalized. The risk is also mitigated by the fact that all flows inside the runtime will adhere to the same version of libraries inside the docker image. All this means that the release notes are relevant to better understand an issue.
29 -
29 +
30 30  {{info}}Should an issue occur we want to be informed of this so we can take action. If it turns out that a rollback is needed to an earlier image you can facilitate this via our "disaster recovery" mechanism described below.{{/info}}
31 -
31 +
32 32  === 3.3 Approach ===
33 33  
34 34  We strongly advice to update your Test and Acceptance environment first before moving to Production. This to avoid potential problems appearing in a Production environment before any other environment. To better anticipate when a new runtime image will be released we will inform our customer base along the following timelines.