BP Release Import - Rollback

[Walter.Koller]

After some time processes might not be needed anymore, because have been replaced by other processes, they become obsolete or maybe it was a one time activity only. It would be helpful if a deployed release could be rolled back (ie removed / deleted) from an enviornment.

In case of complex business processes, several BP processes and VBO might have been needed for its automation. Those dependencies between BP processes, VBO, queues, environment variables, schedules, ... are packaged into one release file and deployed into production. 
When this buisness process automation is not needed anymore, the environment should be cleaned from not needed objects and configuration.
Currently this has to be done manually, for each object individually.
It would be much more convenient if there would be a rollback feature so all objects that are part of a release package could be removed at once. Of course with dependency check and warnings if necessary

[EmersonF]

in fact it's very important, I don't know why the Blue Prism team hasn't implemented this feature yet.

[AndreyKudinov]

Not that easy. What happens if some VBO is used by several releases?

[EmersonF]

Andrey, I believe that when we are uploading a new release in HML or PRD, there are new features with new vbo, if there is any update, from any VBO when doing the rollback everything contained in the release must be returned, I believe that in this context we would have no problems relevant

[Walter.Koller]

A release should either include ALL relevant objects to run or only the ones specific to this particular process.

Let's assume two processes:
process 1 (proc1) using three VBO:
- proc1Obj
- sharedObj
- commonObj

process 2 (proc2) using three VBO:
- proc2Obj
- sharedObj
- commonObj

proc1Obj and proc2Obj are unique to each of the processes
sharedObj VBO handles an application used by both processes
commonObj VBO is something competely generic, like Utilities Environment.

We do not include commonObj in our releases since they are considered to be static. Those VBO have their own release package and are normally deployed once (ie very rarely) into an environment. Since they basically don't change and are available everywhere, we don't include them in our process releases.

In our case we would have two release packages for the two processes above:
RP1: proc1, proc1Obj, sharedObj
RP2: proc2, proc2Obj, sharedObj

When deploying RP1 and afterward RP2, sharedObj will be overwritten and there will be one historic version (sharedObj(v:RP1)) and one current version (sharedObj(v:RP2)). During a rollback the current version (v:RP2) should be replaced by the previous version (v:RP2).

All information necessary to do so is arleady available in BP repository (although it would be much easier if versions of objets are tied to releases but this would be great to have anyways)

[asilarow]

100% this would be super useful! Especially in larger environments where multiple teams import releases on a regular basis, mistakes can happen.

Currently the only way to fix the mistake where someone has overwritten content from an invalid release is to import another one with the correct content. This should not be the case.

The previous versions of most of the contents are readily available in the database, so rolling back should not be impossible to do.