Page History
...
This step is similar to Step 1 only that we will now add back the nodes we removed in step 1 and remove the running currently running nodes.
The nginx configuration should look like this:
...
Users having open sessions on "Weather" project version 1 should see no difference, but new users that access the project should be redirected to "Weather" project version 2.
4. Undeploying old versions
You can use two strategies to undeploy old versions
...
.
4.1 Undeploy during upgrades
Using the example above, version 0.0-v1 can be undeployed when upgrading 0.0-v2 to 0.0-v3. Using this strategy there are always two version deployed. In order to ensure users always use the latest version, make sure that the shortcut points to the latest versions and projects can only be started using shortcuts.
4.2 Undeploy after upgrade
4.2.1 Undeploy using the publisher
After a successful upgrade has been performed and sufficient time has passed so there are no more sessions using the old version, the old version can be unpublished. The cluster does not have to be restarted.
4.2.2 Undeploy export files
After a successful upgrade has been performed and sufficient time has passed so there are no more sessions using the old version, the old version can be deleted. The same process described in steps 1-3 can be used:
- remove some of the nodes from the cluster
- delete the old version from the nodes removed from the cluster
- restart the nodes
- add the nodes back to the cluster
- repeat until the old version is deleted from all the nodes
Info |
---|
If the project exports are deployed on a shared folder, the old version will be deleted only once. The runtimes still have to be restarted in order to clear the application cache. |
TBD
Panel | |||||||||
---|---|---|---|---|---|---|---|---|---|
|