Plant SCADA 2023 R2: Timely Deploy of a previous version ?

Hi Gordon Ward ,

Unfortunately, there is no roll-back feature implemented in the deployment system. You can add this to Improvements of the deployment functionality on the ideas portal.  Plant SCADA | AVEVA Plant SCADA (aha.io)

What do you mean? You can deploy older or newer versions (builds) of a project. It should be faster to deploy a version that was already copied to a client if it is still cached locally.

That is correct Eric. Deployment supports rollback to any version you have on your deployment server.

Hi Brad,

I'm seeing no specific change (ie reduction) in the time taken to restart to a previous version that is already available locally on the client.   Can you please confirm that such a version 'deploy' should be a far quicker process than the typical new version deploy ?

As an aside, I've also been playing with the 'PackagesToKeep' parameter in ~\config\SE.Asb.Deployment.Node.WindowsService.exe.config to try and cater for more than just the standard 2 versions being kept locally ... with a hope that there might be an ability to promptly bounce back to (say) any one of several recent deploys.  Changing the parameter works as expected, but I'm still not having any luck speeding up the restart process.   Suggestions ?

You won't see a reduction in the actual start time of the client itself as that is just Plant SCADA Runtime loading up your project. What you will see is a reduction in deployment time of a previous version. I guess you could interpret that as overall reduction of time getting client going again with a previous version as you have eliminated the network file copy of the project.

As you've noticed we cache the last 2 versions (one of them being the active one). So if you revert to the previous version the deployment server won't have to resend your project across to the clients. If you change that parameter you will have more copies of your project on each client. So unless this is common for you to need to revert back more than one version, 2 is usually good enough (one rollback).

Hi Brad,

Sorry, I probably haven't been as clear as I could have been.

I'm performing / reviewing activity from the Deployment_Computer tab within Plant Studio.

Step 01.  I deploy a brand new version (X) to a typical workstation. In my specific test environment, it takes approximately 4:20 to deploy (from hitting the 'deploy' button to seeing the client session restart).

Step 02. I deploy a brand new version (X+1) to same workstation. Once again, it takes approximately 4:20 to deploy.

(In both instances, I can see it takes just over a minute before the client's cache folder is updated to reflect the new version. The remainder of the deploy time seems to cover the unzipping effort.)

Imagine the scenario where there is an urgent need to roll back the client from version (X+1) to version (X) for whatever reason. It is a valid real-world scenario.

Step 03. I select version (X) for (re)deployment and hit the deploy button. I fully expect the client session to promptly restart to version (X), because version (X) is cached locally and has already been unzipped etc. But no, the 'deployment' bar starts filling as per usual, and it takes a good 2:45 (in my test environment) before I see the client session restart.  Initial checks suggests that the zipped file is not copied out to the client again. However, it does appear that the unzipping process is repeated.

Step 04. I select version (X+1) for (re)deployment and hit the deploy button. Once again, it takes a good 2:45 before I see the client session restart.

This process makes no sense. Looking at it from the client-side. I could write some code that simply adjusts the Citect.ini [Deployment]Version parameter, and run path (etc) and I could promptly restart the client session.  Why can't the Deployment process do this ?

Are there any configurable parameters (somewhere) that may offer a solution ?

TIA.

Hi Gordon,

Thanks that is clear.

Yes I am pretty sure it unzips again. I think the reason we do that is to guarantee that the version you are moving to has all the files from the cached backup. Unfortunately, I don't think there is a way to override that behaviour.

That is Redeploying not Rolling back. The deployment server doesn't know the status and integrity of previously deployed project and it will do "redeploy" and make sure the project runtime remains in integrity. A rollback is to skip the redeploy/integrity check, attempt to run the previous version, and update the active version in the deployment DB if the previous version is up running. The redeployment will be required if the roll-back fails. Unfortunately, there is no true roll-back mechanism available in the current deployment system.

Even without deployment manager, I will sometimes put two runnable versions of the project on the same installation(like a _Test suffix on the project) and clean up the new copy when I am done testing.  Roll back is just a quick project setup run.  Yes, it does require signing into each computer with a remote operating program, but all of the networking is already in place if Citect is working properly. I'm sure there are ways to switch the .ini files and restart from the station you are working from. ProjectGet() and ProjectSet() could give you a way of doing it by cicode.  I know this is not in Deployment manager.  I've had at least a half dozen Deployment installations, and we have always had to go back to the manual method due to problems.