Spring 6 migration

Last modified by Erik Bakker on 2024/04/11 08:19

Please note that this migration path is for the current runtime architecture only.

In our continued efforts to make the transition to Spring 6 as smooth as possible we have written down the advised process for identifying and updating the relevant flows as a consequence of the Spring 6 migration. Below you will find a document describing this migration path. For the critical aspects of the Spring 6 image compared to the current image, please read this release blog.

Should you have any questions, please get in touch with academy@emagiz.com.

1. Prerequisites

Basic knowledge of the eMagiz platform
A thorough understanding of your eMagiz model

2. Key concepts

This migration path allows you to smoothly and swiftly migrate your model to Spring 6
Consequences of this migration are:
- All flows that contain a component that needs to be changed to work in Spring 6 will be automatically provisioned by eMagiz with a new flow version per changed component in that flow.
- Autosaved versions will be saved with a new version first before the Spring 6 changes are applied.
- If an alert is currently present in a flow that needs to be migrated eMagiz will not be able to push a version to Deploy. Fixing the alert remains the sole responsibility of the user.
- You are informed in Deploy which flows are changed by eMagiz as a consequence of the Spring 6 migration.
  - This information pop-up will be shown to the user, even after the user deployed to an environment to ensure no flow is forgotten. If you don't want to display the information pop-up anymore you can hide it by selecting the checkbox option in the pop-up.
- eMagiz will prohibit you from deploying a release that contains an old version of a migrated flow.
- You determine what you want to deploy to a certain environment, but if you want to deploy a flow it needs to be the correct version.
- To dampen the impact after our release on April 11th on your model you can pre-select and activate a release on April 10th

Please be aware that we will create autosaved versions for affected flows still running on the legacy runtime architecture. This way, we ensure consistency in what the user sees when working with flow components in the Create phase while at the same time prepare your model for a future migration to the current runtime architecture. Should you need to make a functional change in one of these affected flows, you can do so without a deployment and without using Spring 6 in your legacy runtime.

3. Technical Migration Path

3.1. Creating the release

Once you open the Deploy phase, you will be confronted with a pop-up that details which flows have been updated. The overview specifies the flow's description and name, whether it had an autosaved version before the migration, and how many changes eMagiz performed as a consequence of the Spring 6 migration.

This pop-up will remain visible for users, regardless of their actions regarding the Spring 6 migration on a specific model. This is to avoid people forgetting that a critical action must occur (or has taken place). On top of that, it is an excellent trigger to check amongst your peers whether all necessary actions have been taken. If you want to hide the pop-up, you can do so by activating the checkbox. When you do so you won't see the pop-up on any model anymore so be cautious.

Should you want to see the pop-up again, you can click on the button called "Spring 6 migrated flows" to show the pop-up again

migration-path-migration-path-spring-6-migration--spring-6-migrated-flows.png

With this information you can create a new release through which you update the flows to Spring 6. Note that you can keep the pop-up open while editing your release.

Depending on the following two criteria you can determine how to best update

Number of flows that are impacted by the Spring 6 migration
Number of flows that have a pending functional change that was not impacted by the Spring 6 migration.

When the number of flows that are impacted by the Spring 6 migration is less then fifteen and you have atleast one pending functional changes that was not impacted we advise to manually select the correct version for all flows that you want to Deploy. In cases when you have no pending changes or the number of flows impacted by the Spring 6 migration outweighs the pending functional changes we advise to use the "Update flows to latest version" option on the release to update everything and then subsequently downgrade the flows with a pending functional change to the desired version.

3.2. Deploying the release

Once satisfied with the creation of the release you can deploy your release to the environment. In case you forgot to add a mandatory flow version for Spring 6 eMagiz will prohibit you from continuing.

migration-path-migration-path-spring-6-migration--spring-6-deploy-check.png

When you see this pop-up you need to go back and edit your release again. This way you can add the missing flow(s) to your release. In case you need to re-edit your release we would suggest to manually update these flow versions in your release.

4. Key takeaways

All flows that contain a component that needs to be changed to work in Spring 6 will be automatically provisioned by eMagiz with a new flow version per changed component in that flow.
Autosaved versions will be saved with a new version first before the Spring 6 changes are applied.
If an alert is currently present in a flow that needs to be migrated eMagiz will not be able to push a version to Deploy. Fixing the alert remains the sole responsibility of the user.
You are informed in Deploy which flows are changed by eMagiz as a consequence of the Spring 6 migration.
eMagiz will prohibit you from deploying a release that contains an old version of a migrated flow.
You determine what you want to deploy to a certain environment, but if you want to deploy a flow it needs to be the correct version.
To dampen the impact after our release on April 11th on your model you can pre-select and activate a release on April 10th